Subject: Re: Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP

From: "John Levine" <[email-masked]>
Date: 13 May 2011 00:38:55 -0000

The document is well written and does a good job of describing the
various issues related to lists and DKIM.

My problem with it is that most of the advice is as far as I can tell
unimplemented, so it's more of a Best Hypothetical Practices than a
BCP.  A typical example is section 4.1 which suggests different
message signatures for mail sent to lists rather than mail sent to
other places.  I'm not aware of anyone doing that, and it's not
obvious how you could even tell whether a message is going to a list
short of keeping an error prone manually maintained registry of list
names.

I'd suggest publishing it as Informational or Experimental rather than
BCP.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: SM <[email-masked]>
Date: Fri, 13 May 2011 00:15:50 -0700

At 08:02 12-05-2011, The IESG wrote:
>The IESG has received a request from the Domain Keys Identified Mail WG
>(dkim) to consider the following document:
>- 'DKIM And Mailing Lists'
>   <draft-ietf-dkim-mailinglists-10.txt> as a BCP
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2011-05-26. Exceptionally, comments may be

 From Abstract Section:

   "Based on deployment experience with DKIM, this Best Current
    Practices document provides guidance for the use of DKIM
    with scenarios that include Mailing List Managers (MLMs)."

Although one can extrapolate from experience and provide some 
guidance, I would not call it "Best Current Practices".  I suggest a 
change to that sentence:

    Based on deployment experience with DKIM, this document provides
    guidance for the use of DKIM with scenarios that include Mailing
    List Managers (MLMs).

Quoting the Introduction Section:

   "The goal for this document is to explore the use of DKIM for
    scenarios that include intermediaries, and recommend Best
    Current Practices based on acquired experience."

The Intended Status of this document is BCP.  I cannot support a 
recommendation for "Best Current Practices" that is not based on 
existing practices.  If the IETF wants a stick to tell the outside 
world what to do, it can publish this document as a BCP.  If the IETF 
would like to provide guidance, leave it to the outside world to 
adopt that and then document the current practice, it should not 
publish this document as a BCP.

 From Section 2.5:

   "Each of these could have different security policies imposed
    against them, or there might be a desire to insulate one from
    the other (e.g., a marketing campaign that gets reported by
    many spam filters could cause the marketing stream's reputation
    to degrade without automatically punishing the transactional or
    user streams)."

Shouldn't that be sending policies instead of "security 
policies"?  If we go a stretch further, a marketing campaign might 
end up be labelled as a terrorist act and that falls under the Security Area.

I'll translate that paragraph for a wider audience.  Some companies 
send out spam; it keeps businesses happy if it is called a marketing 
campaign.  These companies also send out messages that the receiver 
actually wants to read.  On the receiving side, there is a lot of 
zealotry that goes on.  One way to mitigate the effects of that 
zealotry is to provide the receiver a means to separate the spam from 
other mail.

In Section 3.3:

   "Some lists prepend or append a few lines to each
    message to remind subscribers of an administrative URL for
    subscription issues, or of list policy, etc."

It's funny to see how some MUAs adapted to that by hiding these lines 
thereby rolling back that "fix".

In Section 4.1:

   "In an idealized world, if an author knows that the MLM to which a
    message is being sent is a non-participating resending MLM, the
    author SHOULD be cautious when deciding whether or not to send a
    signed message to the list."

The author generally does not have any control over that decision as 
DKIM signing is not done at the MUA level.  The usage of a key word 
is somewhat excessive here as the ideal world is out of scope for RFC 2119.

   "This problem can be compounded if there are receivers that apply
    signing policies (e.g., [ADSP]) and the author publishes any kind
    of strict policy, i.e., a policy that requests that receivers reject
    or otherwise deal severely with non-compliant messages."

The "definition of insanity is doing the same thing over and over and 
expecting different results".   There are parallels between ADSP and SPF.

In Section 5.1:

   "It is RECOMMENDED that periodic, automatic mailings to the list are
    sent to remind subscribers of list policy."

This is currently being done by the IETF under the guise of mailman day.

In Section 5.5:

   "In that case, authors SHOULD create a mail stream
    specifically used for generating signatures when sending traffic to
    MLMs."

I suggest using "DKIM signatures".

   "This suggestion can be made more general."

Shouldn't that be recommendation?

In Section 5.8:

  "DKIM-aware authoring MLMs MUST sign the mail they send according to
   the regular signing guidelines given in [DKIM].

   One concern is that having an MLM apply its signature to unsigned
   mail might cause some verifiers or receivers to interpret the
   signature as conferring more authority or authenticity to the message
   content than is defined by [DKIM].  This is an issue beyond MLMs and
   primarily entails receive-side processing outside of the scope of
   [DKIM].  It is nevertheless worth noting here."

Removing the MUST and saying:

   DKIM-aware authoring MLMs signs the messages they send according to
   the regular signing guidelines given in [DKIM]

gives more weight to the last two paragraphs, especially with the 
note about the concern.

In Section 5.10:

   "An FBL operator might wish to act on a complaint from a user about a
    message sent to a list."

Shouldn't that be FBI? :-)

In Section 5.11:

   "Receivers SHOULD ignore or remove all unsigned externally-applied
    Authentication-Results header fields, and those not signed by an ADMD
    that can be trusted by the receiver."

Quoting Section 5 of RFC 5451:

   "For security reasons, any MTA conforming to this specification MUST
    delete any discovered instance of this header field that claims to
    have been added within its trust boundary and that did not come from
    another trusted MTA."

   "For simplicity and maximum security, a border MTA MAY remove all
    instances of this header field on mail crossing into its trust
    boundary."

The MUST and the MAY are aggregated into a SHOULD.  Is that intentional?

 From Section 5.11:

   "Upon DKIM and ADSP evaluation during an SMTP session (a common
    implementation), an agent MAY decide to reject a message during an
    SMTP session.  If this is done, use of an [SMTP] failure code not
    normally used for "user unknown" (550) is preferred; therefore, 554
    SHOULD be used."

This falls under policy decision.  The usage of a 554 code is 
inappropriate.  From Section 3.6.2 of RFC 5321:

   "If it [SMTP server] declines to relay mail to a particular address
    for policy reasons, a 550 response SHOULD be returned."

 From the same section of this document:

   "SMTP servers doing so SHOULD also use appropriate wording in
    the text portion of the reply, perhaps explicitly using
    the string "ADSP" to facilitate searching of relevant data
    in logs."

I wouldn't put a SHOULD in there.  The working group made the 
argument.  Leave it at that.

Quoting two sentences from the same section to provide better context:

   "In such cases where the submission fails that test, the receiver or
    verifier SHOULD discard the message but return an SMTP success code,
    i.e. accept the message but drop it without delivery.  An SMTP
    rejection of such mail instead of the requested discard action
    causes more harm than good."

I would remove the SHOULD as the argument (second sentence) is 
clear.  The usage of the SHOULD raises the question about whether 
this is a SMTP receiver action and whether it is appropriate to 
create a black hole (silent drop of message).

I found the document well-written.  In places where the document 
advocates a particular approach, it provides an explanation for 
that.  This document can be published as Experimental or 
Informational.  Please note that such an intended status is not a 
dilution of the value of the document.

As there has been some discussion about an Applicability Statement 
experiment, I'll quote some text from RFC 2026:

   "An Applicability Statement specifies how, and under what circumstances,
    one or more TSs [Technical Specifications] may be applied to support a
    particular Internet capability."

This document covers RFC 4871 (4871bis actually), RFC 5451 and RFC 
5617.  The document specifies the circumstances under which the 
capabilities discussed here are applicable.  If the DKIM working 
group decides on taking that path, it could ask for publication of 
the document as Proposed Standard.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 May 2011 11:23:26 +0200

On 13/May/11 09:15, SM wrote:
> capabilities discussed here are applicable.  If the DKIM working group
> decides on taking that path, it could ask for publication of the
> document as Proposed Standard.

+1, it seems to make more sense to call a PS PS rather than BCP.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 May 2011 10:30:08 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Thursday, May 12, 2011 5:39 PM
> To: [email-masked]
> Subject: Re: Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP
> 
> [...]

It originally started out as Informational but there was at some point WG consensus to shift it to using normative language, making BCP the appropriate status.

I don't think I'd object to going back to Informational.  I imagine I can get the diffs out of RCS and just play them backwards if that's the way we decide to go.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 May 2011 11:17:02 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Friday, May 13, 2011 12:16 AM
> To: [email-masked]
> Cc: [email-masked]

Hi SM,

By my read, the bulk of your comments fall into these categories:

(1) Remove the normative language, publish as Informational

As I said to John, I'd be fine with this.  The document started out as Informational but there was working group momentum in the direction of a BCP instead, hence the conversion to use of RFC2119 language.  I personally don't have strong feelings about that so if the preferred course of action is to go back to that, I'd be fine.

As for the idea of using PS instead, that doesn't seem appropriate to me given we're not standardizing a protocol here, and at best we don't have enough implementation experience to back up the claims.

(2) Editorial changes

I'd be fine with all of the changes you proposed.

(3) RFC5451 discussion

> The MUST and the MAY are aggregated into a SHOULD.  Is that

Yes, I believe they are consistent.  The citation you made from RFC5451 directs implementations to delete forgeries (the MUST) and optionally delete everything else as well (the MAY).  The citation from this document does not dispute the MUST, and provides further guidance for this particular application (which is also consistent with other parts of RFC5451) in terms of how to deal with what's left after the MUST part is done.

>     for policy reasons, a 550 response SHOULD be returned."

3.6.2 applies to relays, not recipients.  A relay might try DKIM validation and ADSP evaluation, but that's not the model this document discusses.

However, if that doesn't matter, unfortunately this makes the distinction we're trying to make impossible without using enhanced status codes, which aren't universally used.  But to be conformant, I suppose 550 5.7.0 would be appropriate.

> create a black hole (silent drop of message).

If we are leaving the normative language in (for BCP, should that status stay) then I think the SHOULD is appropriate in the sentence that defines the normative action.

Thanks for the review!

-MSK

---

From: SM <[email-masked]>
Date: Fri, 13 May 2011 21:57:08 -0700

Hi Murray,
At 11:17 13-05-2011, Murray S. Kucherawy wrote:
>As I said to John, I'd be fine with this.  The document started out 
>as Informational but there was working group momentum in the 
>direction of a BCP instead, hence the conversion to use of RFC2119 
>language.  I personally don't have strong feelings about that so if 
>the preferred course of action is to go back to that, I'd be fine.

Ok.

>Yes, I believe they are consistent.  The citation you made from 
>RFC5451 directs implementations to delete forgeries (the MUST) and 
>optionally delete everything else as well (the MAY).  The citation 
>from this document does not dispute the MUST, and provides further 
>guidance for this particular application (which is also consistent 
>with other parts of RFC5451) in terms of how to deal with what's 
>left after the MUST part is done.

Ok.

>3.6.2 applies to relays, not recipients.  A relay might try DKIM 
>validation and ADSP evaluation, but that's not the model this 
>document discusses.
>
>However, if that doesn't matter, unfortunately this makes the 
>distinction we're trying to make impossible without using enhanced 
>status codes, which aren't universally used.  But to be conformant, 
>I suppose 550 5.7.0 would be appropriate.

You can use 550 5.7.1.  The enhanced status code used in the draft is 
appropriate.

Thanks for the quick response.  BTW, I forgot to the "best current 
practices" in Section 8.  It's an editorial nit.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 May 2011 11:35:15 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Saturday, May 14, 2011 5:14 AM
> To: [email-masked]
> Cc: IETF General Discussion Mailing List; Alessandro Vesely
> Subject: Re: [ietf-dkim] Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP
> 
> Ideally, if Murray wishes to support Jeff McDonald's Anti-Spam ID that
> is intended to update RFC3463, he might use (since this is all new
> anyway):
> 
>     554 5.8.0 Undefined Policy detail
>     554 5.8.1 Message refused by local policy
> 
> or perhaps Murray can propose to Jeff to add a 5.8.27 status code
> specifically for ADSP related policy rejects:
> 
>     554 5.8.27 Message refused by ADSP From.Domain=<IDENTITY-ODID>

I don't have an opinion on that draft yet, but I don't want to delay MLM's publication by referring to Jeff's, whose future is indeterminate right now.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 15 May 2011 09:36:00 -0700

> Sent: Saturday, May 14, 2011 5:00 PM
> Cc: [email-masked]
> Nits and Comments:
> In Section 3.1.
>     author:  The agent that provided the content of the message being
>        sent through the system.  The author delivers that content to the
>        originator in order to begin a message's journey to its intended
>        final recipients.  The author can be a human using an MUA (Mail
>        User Agent) or a common system utility such as "cron", etc.
> 
> What is "cron?" and how does it interface with the originator defined as
> the MSA?  is cron an MTA or MUA?

It's a daemon that runs on UNIX systems which can be told to run specific programs at specific periodic times.  It is neither an MTA nor an MUA; it is an example of something that is an "author" in this context but is not also a human.

> I suggest to remove the "or a common .." text since we already know
> what MUA implies - a mail creation application or replace the text
> with:
> 
>        or any other message creation application [with an MTA
> component].

That doesn't make sense in the case of cron because it doesn't have an MTA component.  It invokes a local MTA.

> I personally say take it out. Not needed. Thats an *nix idea.  Windows
> people generally do not know what that is.

I think it's best to have an example.  "cron" seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one.  If not, changing 'such as "cron"' to 'such as the "cron" UNIX utility' seems a better change to me.

> In Section 3.1.
> 
>     verifier:  Any agent that conducts DKIM signature analysis.
> 
> I know this is a semantical nit, but RFC4671 uses verification, never
> analysis and it (analysis) is only stated as an out of scope boundary
> layer concept (in section 3.11).   Perhaps the intent is to suggest
> the verifier does both:
> 
>     verifier:  Any agent that conducts DKIM signature validation and perhaps
>                [results|TRUST and ADSP] analysis.

The verifier does not do both.  An external module deals with ADSP and "trust" or other evaluation of the delivered domain name.

I would be fine with changing "analysis" to "validation" though, to make that clear.

> In Section 3.1 for receiver, it is very clear with stating the agent
> for "final delivery", so why not add the MDA labeled terminology as it
> was done with originator with MSA?
> 
>     receiver: ..... This agent can be often referred to as the
>        Mail Delivery Agent (MDA).

Works for me.

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 15 May 2011 13:04:05 -0400

> I think it's best to have an example.  "cron" seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one.  If not, changing 'such as "cron"' to 'such a…

Anyone who's ever managed a Unix or linux system knows what cron is. 
It's a fine example.

Indeed, on my own servers, there are cron scripts that push out daily 
digests which are DKIM signed on the way out.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Sun, 15 May 2011 22:42:30 -0400

>>> the MSA?  is cron an MTA or MUA?
...
> It was a rhetorical question.  I don't think its necessary and IMO,
> unprecedented.

I'd be very surprised to find that mention of "cron" in an RFC is
"unprecedented".  Maybe I'll download the RFC set, have Google do a
word index on it, and see.

In any case, I think it *is* useful, and should stay.

> In principle, examples are good, but IMO this particular one seems out
> of place.

I think it's not at all out of place, and that it's an excellent
example, because it's frequently used to send automated messages based
on system events and state.  Which might be signed, and which
sometimes go to mailing lists.

> I think what you are essentially saying here is the distinction
> between a Human (UI) Agent and Automated (no UI) Mail Agent. So
> perhaps the last sentence could be restated :
>
>       The author can be a human using an MUA (Mail User Agent) or
>       an automated mail robot with an MTA.

I don't see that "automated mail robot with an MTA" is right at all.
But I see what you're getting at, and I'd support a change such as
this:

       The author can be a human using an MUA (Mail User Agent) or
       an automated process that may send mail (for example, the "cron"
       Unix system utility).

Barry

---

From: "John R. Levine" <[email-masked]>
Date: 15 May 2011 23:09:24 -0400

> word index on it, and see.

RFCs 2123, 2839, 4833, and 5427 refer to cron and cron jobs.  There may be 
others, but I found those with a simple grep.  (If anyone was planning to 
ask what grep is, don't.)

>       an automated process that may send mail (for example, the "cron"

There's no need to change the current language.  RFCs have been referring 
to cron jobs since 1997.

R's,
John

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 16 May 2011 09:15:35 +0200

Actually since 1991, see below

	jaap

% cd ~/library/rfc-editor/in-notes
% grep -w cron *
rfc1244.txt:            - Checks all commands in the "/etc/rc" files and "cron"
rfc2721.txt:   applications to analyse the flow data, and various scripts, cron
rfc2839.txt:   parts of the Internet, e.g. in batch or cron jobs that update news or
rfc3164.txt:           both Facilities 9 and 15 for clock (cron/at) messages.
rfc3834.txt:      processes (such as UNIX "cron jobs") which are not direct
rfc4833.txt:   tools, such as cron that operate on wall clock time, it is possible
rfc5427.txt:            label 'cron' are known to vary across different operating
rfc5427.txt:              cron            (9), -- clock daemon messages
% sed 15q rfc1244.txt

Network Working Group                                        P. Holbrook
Request for Comments:  1244                                       CICNet
FYI: 8                                                       J. Reynolds
                                                                     ISI
                                                                 Editors
                                                               July 1991

                         Site Security Handbook

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 16 May 2011 07:34:54 -0500

>       an automated process that may send mail (for example, the "cron"

+1

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 May 2011 10:51:03 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Monday, May 16, 2011 5:35 AM
> To: IETF list; DKIM List

Works for me.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 21 May 2011 17:18:40 -0400

> I'd suggest publishing it as Informational or Experimental rather than

As DKIM chair, I'd like to reply to this and other messages in this
thread that discuss the status of the subject document:

There was extensive discussion in the DKIM working group about what
the status here should be.  The charter item covering this is here:
  5. Consider issues related to mailing lists, beyond what is
  already documented. This includes considerations for mailing
  list software that supports or intends to support DKIM, as well
  as considerations for DKIM/ADSP deployment in the presence of
  mailing lists that do not have such support. Include
  recommendations in the informational documents, or produce a
  new informational document about mailing-list considerations.

Despite that this says "new informational document", the working group
has long referred to it as "the mailing list BCP".  The language was
originally written as informational, and was changed to normative
language, and BCP status, after discussion and consensus.  Clearly, it
was rough consensus, not unanimity.

There is, indeed, much in the document that isn't so much "current
practice" as "recommended practice".  Some of it is our best current
recommendation, and that might change over time (as implementations
change in general) and experience (as we find what actually works
best).

Personally, I think what this amounts to is a "proposed standard" for
how to deal with maling list managers that have not yet been changed
to support DKIM.  Whether that is published as BCP or Proposed
Standard, it's definitely not "experimenta" so much as "proposed".

As chair, I can say that consensus was to make this normative, not experimental.

Barry, DKIM working group chair

---

From: "John R. Levine" <[email-masked]>
Date: 21 May 2011 17:59:55 -0400

> As chair, I can say that consensus was to make this normative, not experimental.

With the best will in the world, I was there, and I saw no such consensus.

The closest thing I can find in a quick search of the archive is this 
note, which says that the group agreed on one thing (that lists should 
sign their mail) but not on anything else:

http://mipassoc.org/pipermail/ietf-dkim/2010q4/014630.html

This document does not describe existing signing practice.  It makes a 
variety of highly speculative recommendations unsupported by experience. 
It is an experiment.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Sat, 21 May 2011 18:22:26 -0400

> With the best will in the world, I was there, and I saw no such consensus.

We discussed it live at IETF 80, and I posted the following minutes to
the mailing list on 28 March:

3. Discussion of mailinglists document:
Murray listed some questions he has...
   1. Should we include an appendix discussing what we see as useful
changes to MUAs?
      a: No; out of scope.  Perhaps an MUA BCP done at another time.
   2. Should this be Informational or BCP?
      a: BCP, making it clear when we're insufficiently certain about something.
         Last Call will sort out any objections.
   3. Should we remove discussion about dealing with broken DKIM
implementations?
      a: No.
   4. Should we put advice in about what header fields re-signing MLMs
should sign?
      a: No.
   5. Should explicitly reference ESPs?  They're different from MLMs.
      a: No.
   6. Should we change advice about subdomains, creating "streams"?
      a: No.

That reflects strong consensus in the room in Prague, and there was no
objection on the mailing list after the minutes were posted.

Barry

---

From: "John R. Levine" <[email-masked]>
Date: 21 May 2011 18:43:46 -0400

>         Last Call will sort out any objections.

Well, I couldn't afford to go, so I can't say you're wrong, and I don't 
know why I didn't see that on the list.

I guess on procedural grounds, you win, even though we all know that 
there's nothing B or C about this document.

Regards,

---

From: [email-masked]
Date: Sun, 22 May 2011 15:59:10 -0700 (PDT)

> there's nothing B or C about this document.

I cannot comment on the process issues, but I'm afraid I have to agree with
John's technical assessment of this document.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 23 May 2011 11:03:11 -0700

>      guidance for the use of DKIM with scenarios that include Mailing

an entirely reasonable wording change, IMO.

> existing practices.

Then you are using criteria that go beyond the requirements of a BCP.

 From RFC 2026:

    "5.  BEST CURRENT PRACTICE (BCP) RFCs

         The BCP subseries of the RFC series is designed to be a way to
         standardize practices and the results of community deliberations.
         ...
         The BCP subseries creates a smoothly
         structured way for these management entities to insert proposals into
         the consensus-building machinery of the IETF while gauging the
         community's view of that issue."

Nothing in the definition of BCPs require that it be limited to covering 
existing practice.

> If the IETF wants a stick to tell the outside
> world what to do, it can publish this document as a BCP.

Perhaps the wording is a bit more coarse than one would like, but at base, 
"telling the community what to do" is what standards-track and BCP documents do, 
whether based on existing practice or not.

> gives more weight to the last two paragraphs, especially with the

Not really.  The latter paragraph merely notes that there are receivers that do 
not understand what a DKIM signature means.

The normative statement, however, either is supposed to direct MLM behavior or 
it isn't. The existing language says it is, which makes sense.

> Shouldn't that be FBI? :-)

You country has one of those, too?

> On 5/21/2011 2:59 PM, John R. Levine wrote:
>> This document does not describe existing signing practice. It makes a variety of
>> highly speculative recommendations unsupported by experience. It is an experiment.

Again, we seem to have an attempt to impose a more stringent requirement on 
qualifying for BCP status than exists in IETF formal documentation.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 23 May 2011 18:43:17 -0000

> Nothing in the definition of BCPs require that it be limited to
> covering existing practice.

Well, other than the naive assumption that something called a Best
Current Practices would in fact document best current practices.

But since this argument seems to be all about proving that we've
followed the official process rather than about publishing something
accurate and useful rather than speculative and misleading, who cares?
Now that I understand the rules, I plan to publish all of my
experiments as BCPs.

R's,
John

---

From: SM <[email-masked]>
Date: Mon, 23 May 2011 15:06:01 -0700

>covering existing practice.

This creates debates along the lines of "the RFC says so" or "the 
IETF says that this should be the practice".

>Perhaps the wording is a bit more coarse than one would like, but at 
>base, "telling the community what to do" is what standards-track and 
>BCP documents do, whether based on existing practice or not.

A RFC is a way of telling the community what you did and how you did 
it.  If people believes it is a good idea, they will pick it up.

I'll diverge from the topic.  Let's say that you are writing a 
proposal and there is a controversial issue.  You are technically 
correct in your arguments but there are several people who disagrees 
with you on the issue.  Your options are:

  (i)  Don't make a change (assuming the IESG is fine with that)

  (ii) Make a change to gain goodwill (they will implement your proposal)

I leave it to the IETF to determine which option to pick.

>Not really.  The latter paragraph merely notes that there are 
>receivers that do not understand what a DKIM signature means.

I'll stick to my previous comments on this to avoid further 
distractions to the draft.

>You country has one of those, too?

No, but I came across abuse reports where the people mentions that 
they will contact one of those about the matter. :-)

>Again, we seem to have an attempt to impose a more stringent 
>requirement on qualifying for BCP status than exists in IETF formal 
>documentation.

>Now that I understand the rules, I plan to publish all of my

One little gem from an I-D which will be published as a BCP is that 
the information is intended to reflect "consensus on the ground".  A 
RFC is not worth a pinch of salt if it override that.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Mon, 23 May 2011 19:46:24 -0400

Dave CROCKER wrote:
?> In Section 5.8:
> Not really.  The latter paragraph merely notes that there are receivers 
> that do not understand what a DKIM signature means.

Something is amiss if after 6 years of development, after countless 
repeated explanations and messages over the years, it still seems very 
a difficult feat to describe in one or two sentences to the layman 
what DKIM is suppose to do for them, today or in the some distance future.

The fact is DKIM has many conflictive semantics.  While the above says 
its out of scope, it says the opposite in RFC 46751bis 6.3:

    Once the signature has been verified, that information MUST be
    conveyed to the Identity Assessor (such as an explicit allow/
    whitelist and reputation system) and/or to the end user.  If the SDID
    is not the same as the address in the From: header field, the mail
    system SHOULD take pains to ensure that the actual SDID is clear to
    the reader.

See the SHOULD? See the technical association highlighted between the 
signer domain (SDID) and the the originating, copyright holder/author 
of the Message?

Now, look at the conflict in the Abstract and repeated again in 
Section 1.2 defining the Signing Identity:

    DKIM separates the question of the identity of the signer of the
    message from the purported author of the message.

What question is that?  RFC4871 never quite clearly defined thee 
"question."

Lets think about what that question may be. Answer this:

     Do Electronic Mail Author Domains have any security
     rights and controls over who DKIM signs their mail?

Be nice for someone to answer that question.

Then of course, we have augmented RFC productions, such as RFC5585 
that describes the "DKIM Service Architecture" and the illustration 
has that Author Domain "Checking Signing Practices" process component 
displayed in the diagram:

                              |- RFC5322 Message
                              V
+--------+    +--------------------------------+
| Private|    |  ORIGINATING OR RELAYING ADMD  |
| Key    +...>|  Sign Message with SDID        |
| Store  |    +---------------+----------------+
+--------+                    |
  (paired)                 [Internet]
+--------+                    |                     +-----------+
| Public |    +--------------------------------+    | Remote    |
| Key    |    |  RELAYING OR DELIVERING ADMD   |    | Sender    |
| Store  |    |  Message Signed?               |    | Practices |
+----+---+    +-----+--------------------+-----+    +-----+-----+
      .              |yes                 |no              .
      .              V                    |                .
      .        +-------------+            |                .
      +.......>|  Verify     +--------+   |                .
               |  Signature  |        |   |                .
               +------+------+        |   |                .
                  pass|           fail|   |                .
                      V               |   |                .
               +-------------+        |   |                .
               |             |        |   |                .
      +.......>| Assessments |        |   |                .
      .        |             |        V   V                .
      .        +-----+--+----+      +-------+              .
      .              |  |          / Check   \<............+
      .              |  +-------->/  Signing  \
      .              |           /   Practices \<..........+
      .              |          +-------+-------+          .
      .              |                  |                  .
      .              |                  V                  .
+----+--------+     |            +-----------+     +------+-----+
|Reputation/  |     |            | Message   |     | Local Info |
|Accreditation|     +----------->| Filtering |     | on Sender  |
|Info         |                  | Engine    |     | Practices  |
+-------------+                  +-----------+     +------------+

                Figure 1: DKIM Service Architecture

Then you have the RFC5863 Development guide with a few dedicated 
sections, but not the only sections:

     7.3.  Author Domain Signing Practices
     7.3.2.  A Few Definitions
     7.3.3.  Some ADSP Examples

Then finally, you have the crux of the problem with this RFC5017 
section 5.3 item #10 statement:

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

So on the one hand you have functional specifications across multiple 
RFC which  recommends receivers to honor author domain signing 
practices as a security measure to help product DKIM domains, but then 
we have miscellaneous peppered injections of statement that conflicts 
with these goals by telling receivers they MUST (not a MAY) to mind 
their own bee's wax if they see an unexpected, unsolicited, unknown, 
unauthorized non-first party DKIM signed mail when the author domain 
may have a policy that says "Thats a NO NO"

Dave, you got receivers all twisted up in knots!

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com