Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Aug 2010 15:39:41 -0700

Murray, et al,

I think the Introduction's first paragraph is the best summary of DKIM that's 
been written for any of our document's, so far.

Throughout the document, there is a tendency to offer advice without 
justification.  While I, of course, think the advice is good, the fact that it 
is cast as advice means it needs to carry a statement of efficacy.  Why do 
things this way?  Why not do them some other way?  Advice requires a context of 
tradeoffs.

SUBSTANTIVE
===========

> When should an author, or its organization, use DKIM for mail sent
>       to mailing lists?

The word "should" implies an intent to make a normative statement.  This 
conflicts with the stated goal of Informational status.  So does the distinction 
between Normative and Informative references.

Either the goal should be BCP (or even Proposed) or perhaps the language for 
this type of statement needs to be softened to something like "Under what 
circumstances does..."

My own guess is that this document should target BCP.  However on further 
reading I came to the conclusion that this might be two documents, one BCP per 
its original goal and one Proposed, defining value-added semantics.  See below.

> What are the tradeoffs regarding having an MLM verify and use DKIM
>       identifiers?

This might not need "fixing" but I found myself asking what it means for an MLM 
to "use DKIM identifiers"?  Perhaps in an Introduction it's ok to say this 
without prior setup.  Dunno.

Of the four bullets, aren't the latter three the details for the first one?

 > Terminology

This is a philosophical question:  Given a document making normative statements, 
aren't the definitions upon which it bases those statements themselves 
normative?  How can foundational language for normative statements not, itself, 
be normative?

 > 2.4.  Message Streams

The concept of streams is discussed in the Deployment doc (RFC 5863):

      <http://tools.ietf.org/html/rfc5863>

and the DKIM Wikipedia article:

      <http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail>

I suggest citing them.  We should make sure this doc conforms to their 
definition of explains its variation.

By my reading, your text does conform, but your definitional sentence probably 
offers a more explicit and complete definition than the other docs.

However...

 > partition
 >    them somehow (most commonly via DNS subdomains, and/or the "d=" tag
 >    value in the context of DKIM)

If the reference to subdomains isn't for d=, then what does it refer to?  If it 
does mean the d= value, then the sentence wording is a bit confusing.

More conceptually, what way other than d= subdomains is within the scope of the 
DKIM signing specification, for distinguishing among streams?

 > author:  The agent that actually constructed the message

I've been finding myself distinguishing between responsibility for content 
versus responsibility for initial handling, and using the term "author" for the 
former.  "Sender" or "originator" seem to refer to the latter.  Your use of 
Originator seems to match this.

I've gotten diligent about using the word "content" since that seems to be a 
magic way to get people to focus on substance rather than matters of form.  That 
is, it's where "responsibility" gets much more serious.

 > There reportedly still exist a few scattered mailing lists in
 >    operation that are actually run manually by a human list manager.

This sentence hangs there, without a label and without context.  What is the 
reader to do with it?

 > 3.4.  Alternatives of Participation and Conformance

While the content of this section seems useful, it doesn't really discuss either 
of these as "alternatives".  In fact, I initially thought the title meant them 
as alternatives to each other!  Only by reading later sections did it occur to 
me that you meant each to have a "non-" form offered as the alternative.

 > As DKIM becomes more entrenched, it is highly desirable that MLM
 >    software adopt more DKIM-friendly processing.

It occurs to me that the term "DKIM-friendly" would be far more useful if it 
were first defined.  I suggest that up in Terminology it be introduced.  No 
doubt, the details for the term will be subject to some debate.  Best conduct 
that debate during definition, rather than in the middle of its substantive use...

(It's only used other time, up in Section 1, but my sense is that as a group 
we've been using the term more and that it might be worth making it a real 
technical term of art.)

 >    considerations (see Section 3.5 of [DKIM]).  Its use is therefore
 >    discouraged.

That sounds very much like a SHOULD NOT.  Assuming the doc is really going to be 
normative, then now's the time to start using the right language.

 >    There is currently no header field proposed for relaying general list
 >    policy details, apart from what [LIST-URLS] already supports.  This
 >    sort of information is what is commonly included in appended footer
 >    text or prepended header text.  Rather than anticipating or proposing
 >    a new field here for that purpose, the working group recommends

List policy details?  Huh?

    1) I don't really know what that means

    2) I'm not sure why this is being mentioned here

    3) Any use of the word "policy" usually works against doing productive work
       in these groups.

Seriously.  Show me an IETF "policy" specification that's been successful.  Show 
me a second one.

And "for that purpose"?  What purpose?  Again, I've missed the context.

Has this morphed into a more general MLM BCP?  (I assume this is what the 
earlier discussion of such a BCP, sometime back, was about.)

 > If an author knows that the MLM to which a message is being sent is a
 >    non-participating resending MLM, the author is advised to be cautious
 >    when deciding whether or not to sign the message.

This is the sort of guidance that is comforting to the writer, but has no 
practical benefit.  Never mind whether an author is ever going to know the 
required information.  The guidance "be cautious" has no meaning or, at least, 
no meaning in a technical specification seeking substance and precision.  The 
later text, two paragraphs down in the document, acknowledges this problem.

 > incumbent upon site administrators to consider how support of users
 >    wishing to participate in mailing lists might be accomplished as DKIM
 >    achieves wider adoption.

This text suffers the same problem.  Site administrators can't be expected to 
have enough knowledge or time "to consider" much about this topic.  Rather, this 
document should give simple and direct guidance for their choices.  Language 
like the following "A common suggestion" is exactly what they need an direct, 
prescriptive form.

With respect to the guidance being given, there is a gaping hole that is implied 
but not cited, although we've already seen it in the wild:

      If an organization insists that all mail be signed under the same domain 
name that is in the From: header field and it publishes a strict ADSP record, 
then it is not possible for mail from that organization to go through a mailing 
list.  Ever.

     Messing with d= is of course irrelevant to this problem.

 > In general, the
 >    more strict practices and policies are likely to be successful only
 >    for the mail streams subject to the most end-to-end control by the
 >    originating organization.  That typically excludes mail going through
 >    MLMs.

And my point is that this language is too soft, modulo debating what "more 
strict" means.  The document should make a simple statement of the condition and 
a simple statement of the result, since I think we understand both.

 > 4.2.  Verification Outcomes at Receivers

I think everything said in this section is probably correct, but I am not sure 
what it is referring to, within the scope of DKIM.  What technical actions do 
"Verification Outcomes" refer to?

 >    For example, an MLM might be designed to accomodate a list of
 >    possible signing domains (the "d=" portion of a DKIM signature) for a
 >    given author, and determine at verification time if any of those are
 >    present.

This sounds reasonable, but I'm hard-pressed to believe it's practical.

I think the danger, here, is that listing impractical alternatives gives the 
impression of having resolved something that actually remains unresolved.

 >    Per the discussion in [AUTH-RESULTS], there is no a priori reason for
 >    the final receivers to put any faith in the veracity of that header
 >    field when added by the MLM.  Thus, the final recipients of the

This is off-topic, but I keep wondering whether there isn't an opportunity for a 
value-added function in the form of a header-field, which says something like 
"the presence of this header field, when signed by DKIM, means that the contents 
cited in this header field are asserted to be 'valid'...

So, for example:

    DKIM-Valid:  From, Date, Subject, Body

could mean that the signer claims all of that information is "correct", not just 
carried correctly.  Of course, the signer's DKIM h= also have to cite those 
fields, as well as DKIM-Valid.

I think the hard part, here, is deciding whether the signer's d= has any 
constraints, and what a receiver might or might not do, depending on who did the 
signing.

but as I say, this is off-topic...

 >    A signing MLM is, as any other MLM, free to omit redistribution of a
 >    message from an author if that message was not signed in accordance
 >    with its own local configuration or policy.  However, selective
 >    signing is discouraged; essentially that would create two message
 >    streams from the MLM, one signed and one not, which can confuse DKIM-
 >    aware verifiers and receivers.

I don't think I understand what this means.  What is "selective signing" and 
where is the basis for giving directions about it?  This is being used as a term 
of art, but I don't think it's been defined and I think that there isn't 
community consensus about it.  And I'm not sure that anything about it is 
dependent upon MLMs.

 >    A recipient that trusts signatures from an MLM may wish to extend
 >    that trust to an [AUTH-RESULTS] header field signed by that MLM.  The

"Trust"???  What does that mean, exactly, here?  It needs to be defined.  Seriously.

 >    Receivers are advised to ignore all unsigned Authentication-Results
 >    header fields.

Oh boy.  No doubt this really is good advice, but ultimately it's based on a 
value-added semantic that isn't written down anywhere, nevermind "approved"...

Again, I think this document really has two heads -- and possibly three -- and 
probably needs to be split into two or three documents.  One of them is a BCP 
per the original goal.  Another the other is a value-added technical 
specification for Intermediaries that support DKIM.  The third is that generic 
MLM doc that folks have been mentioning.

The alternative is to go back and redefine the semantic of a DKIM signature.  I 
suspect that would cause some existing signers to stop using DKIM, since their 
basis for using DKIM entails a much lower level of meaning that is being implied 
here.

To be clear, I'm not saying that the value-added semantic is a bad idea.  Merely 
that it needs to be defined explicitly and, hopefully, in a generic fashion, so 
that a receiver does not have to wander all over the header fields trying to 
asses assorted interdependencies, before being able to determine what a 
signature or a header field means.

 >    Upon DKIM and ADSP evaluation, a receiver may decide to reject a
 >    message during an SMTP session.  If this is done, use of an [SMTP]

DKIM and ADSP evaluation are not performed during an SMTP session, unless the 
session is delayed after the crlf.crlf, and that's not supposed to happen.

 >    Upon DKIM and ADSP evaluation, a receiver may decide to reject a
 >    message during an SMTP session.  If this is done, use of an [SMTP]

Although this is useful text, it isn't in a form that's appropriate for a BCP. 
I'm not sure what to suggest.

 >    MLMs are encouraged to apply these or other DKIM failure reporting
 >    mechanisms as a method for providing feedback about issues with DKIM

MLMs SHOULD apply a DKIM failure reporting mechanism, for providing feedback 
about...

NITS OR UNCONTROVERSIAL
=======================

> to make a claim of responsibility for a message by
>    affixing a domain-level digital signature to the message

...to make a claim of responsibility by affixing a validated domain-level 
identifier to the message...

>  Although not the only possibility, this is most
>    commonly done as a message passes through a Mail Transport Agent
>    (MTA) as it departs an Administrative Mail Domain (ADMD) toward the
>    general Internet.

Given the short history of DKIM use and the fact that this document will live a 
long time, making normative assertions is a bit risky.  Perhaps:

    One configuration of DKIM use attaches the DKIM signature as a message 
passes through a...

> Common modifications include:

Good list.  I suggest adding two figures that show a before and after example of 
a message, reflecting these modifications.

>    The above list is not exhaustive, but instead only lists common
>    modifications.  It also does not consider changes the MTA might make
>    independent of what changes the MLM chooses to apply.

First sentence really is redundant.  Perhaps instead:

    However note that MLM's vary widely in their behavior, as well as often 
allowing subscribers to specify individual treatment.  The above list also does 
not...

> The DKIM specification documents deliberately refrain from the notion

I think the signature doc is the only "DKIM specification document".  Singular. 
  Given how often people say DKIM when they mean ADSP, we'll do better to refer 
to them separately.  Especially for this statement, since ADSP does not refrain 
from the notion...

> of tying the signing domain (the "d=" tag in a DKIM signature) to any

This isn't a comment on this draft.  It's a broader question:  I think I'm 
seeing "signing domain" used as the common reference for d=, rather than the 
newly-minted SDID term.  Does that match other folks' perception?

> identifier within a message; any ADMD could sign any message

    ADMD could sign any message -> ADMD handling a message can sign it

> As such, there is no
>    specification of any additional value if the content of the "d=" tag
>    in the DKIM signature and the value of (for example) the RFC5322.From
>    field match, nor is there any obvious...

Awkward wording.  Might not be understood if the reader does not already know 
this point.  Perhaps:

      In particular, DKIM does not define any meaning to the occurrence of a 
match between the content of the "d=" tag in the DKIM-Signature: header field 
and the value of (for example) a domain name in the RFC5322.From field.  Nor is 
there any obviously...

> a DKIM signature added
>    by an MLM has no more, or less, meaning as a signature with any other
>    "d=" value.

    with -> than

> The previous section describes some of the things MLMs commonly do
>    that are not DKIM-friendly, producing broken signatures and thus
>    reducing the perceived value of DKIM.

    The previous section describes some of the things MLMs commonly do
    that produce broken signatures and thus
    reduce the perceived value of DKIM.

> MLM behaviors are well-established and standards compliant.

The preceding paragraph appears to (correctly) contradict this assertion. I 
suggest deleting this sentence and merging the next sentence to the end of the 
preceding paragraph (possibly with slight massaging.)

> An MLM is an autonomous agent that takes delivery of a message
>    delivered to it and can re-post it as a new message (or construct a
>    digest of it along with other messages)

    delivered to it -> [delete]

    drop the parens; the surrounded text is integral.

> is some idea of how such a
>    signature might be applied by an recipient's evaluation

   is some idea of -> [delete]

   an -> a

> and if so,

   if so???  i got lost in this reference and suspect the sentence need a bit of 
simplification.

> Note that where in this document there is discussion of an MLM
>    conducting validation of DKIM signatures or ADSP policies, the actual
>    implementation could be one where the validation is done by the MTA
>    or an agent attached to it, and the results of that work are relayed
>    by a trusted channel not specified here.

ditto.

> An FBL reporting address

   -> An address to which FBL reports are sent

    { This isn't just quibbling; a reader might not know what the current 
reference means. They might think it means an address that a sender reports to...}

> not actionable and thus undesirable.

    and thus is undesirable

> An attempt
>    has been made to prefer imposing changes to behaviour at the signer
>    and verifier rather than at the MLM.

    { I suspect that attempt is to satisfy the preference rather than to have 
the preference... }

    An attempt... changes to
    ->
    In general the document shows a preference for imposing changes to...

> Readers are encouraged to become familiar with [DKIM] and [ADSP]
>    which are standards-track protocol documents as well as

    which are standards-track protocol documents
    ->
    which are core specification documents,

> In the remainder of this document we distinguish Two relevant steps,
>    corresponding to the following SMTP transactions:
>
>    MLM Input:
...
>    MLM Output:

This begs for a diagram.

> Much of this document focuses on the resending MLM

    the resending class of MLM

> 3.3.  Current MLM Effects On Signatures

Nice section.

> Other header fields:
...
>            If these fields were included in the original
>       message, it is possible that one or more of them may have been
>       signed, and this could cause a concern for MLMs that add or
>       replace them.

I think your politeness gets in the way of clarity:  If they were part of a 
signature calculation and they are changed, the signature is simply and utterly 
broken. No?

I think the issue is distinguishing "problem" from "broken" in the document. 
The latter is a binary condition.  I'm not sure what qualifies for the former, 
other than breakage, but I suggest calling breakage breakage, so the reader has 
no room for misunderstanding.

>  MIME part removal:

For diligence, the text should note that this breaks a sig.

>  reconstruct the original message as it appeared at time of signing

    at the time of

> and thus whether or not an author signature is actually valid after

seems to be missing a word.  maybe the verb.  can't tell what the context for 
the 'whether or not' is.

> MLM rewriting.  Moreover, even if an MLM currently passes messages
>    unmodified such that author signatures validate, it is possible that
>    a configuration change or software upgrade to that MLM will cause
>    that no longer to be true.

Perhaps I'm not reading this properly, but I can't seem to connect the Moreover 
sentence to the preceding sentence.  I suspect this, too, needs some more context.

>    the note about "h=" in Section 3.5 of [DKIM]).  The shortest path to
>    success for DKIM would be to mandate that all MLM software be re-
>    designed or re-configured with that goal in mind.

Perhaps the text should demure a bit, by adding "Were it likely to to be widely 
adopted, the shortest path..."

>    to bound the portion of the body covered by the body hash, but this
>    not workable for [MIME] messages and moreover has security

    but this is not

    messages; moreover it has

>    A receiver's ADMD would have to have some way to register such non-
>    participating lists to exempt them from the filtering described in

The 'such' has no referrent.  Just delete the word.

>    [ADSP] presents an additional challenge.  Per that specification,
>    when a message is unsigned or the signature can no longer be
>    verified, the verifier must discard the message.  There is no

There is no "must discard" in ADSP.  In any event, I thought the 'request' to 
discard applies only to the more strict setting of discard.

>    the message.  Furthermore, authors whose ADSP is published as
>    "discardable" are advised not to send mail to MLMs as it is likely to
>    be rejected by ADSP-aware recipients.  (This is discussed further in
>    Section 5.4 below.)

Since this is advice to signers, it should be in the earlier sub-section.

>    Of course, such a policy could be applied after subscription, so this
>    is not a universal solution.  An MLM implementation could do periodic
>    checks of its subscribers and issue warnings where such a policy is
>    detected.

Concerning ADSP enforcement, the simple form of this is to check for every 
submission and possibly even reject at submission time if the later receipt will 
be rejected.

> It can require that messages using a given
>    RFC5322.From address also have a DKIM signature with a corresponding
>    "d=" domain.  (Note, however, that it is entirely reasonable for an

It occurs to me that this model is a variant of the FBL registration model...

However as implied by the reference to ADSP, an implication is not being able to 
submit mail that is posted through alternative ADMD MTAs.  This should be noted.

>    This suggestion can be made more general.  Mail that is of a
>    transactional or generally end-to-end nature, and not likely to be

This sounds interesting, but I don't really know what "end-to-end" means, here.

>  different mail stream than a stream that serves a broader purpose.

broader purpose?  perhaps "more varied uses"?

>    Although it is a common and intuitive conclusion, however, not all

    however -> [deleted]

>    As is typical with DKIM signing, the MLM signature must be generated
>    only after all modifications the MLM wishes to apply have been
>    completed.  Failing to do so generates a signature that can not be

"Typical" DKIM signing doesn't involve an MLM.  I think the meaning here is 
something like:

      As is typical with DKIM signing, the MLM signature MUST be generated 
immediately prior to sending, and after all other processing has been completed.

>    A signing MLM is advised to add a List-Post: header field (see
>    [LIST-URLS]) using a DNS domain matching what will be used in the
>    "d=" tag of the DKIM signature it will add to the new message.  This
>    could be used by verifiers or receivers to identify the DKIM
>    signature that was added by the MLM.  This is not required, however;

This advice is predictable, understandable, and wrong.  It declares a linkage 
that DKIM explicitly does not assert -- and in fact this draft earlier notes 
that it does not.

There are some different directions that changes to this text might reasonably 
go.  I'm not sure what I'd recommend.

This section also appears to suggest hashing on a series of header-fields based 
on a belief that the DKIM header hash is "protecting" or "validating" those 
header fields.  It doesn't do that.

At its core, I believe this line of specification is attempting to creates a 
value-added meaning of a DKIM signature for an MLM.  That seems an entirely 
worthy goal, but it's a new goal and requires new specification, including some 
flag that declares the additional semantic.

>    A DKIM-aware resending MLM is encouraged to sign the entire message
>    as it arrived (i.e. the "MLM Input" from Section 3.2), especially
>    including the original signatures.

This appears to run contrary to the earlier advice to sign just before 
re-posting the message.

>    Some concern has been expressed about an MLM applying its signature
>    to unsigned mail, which some verifiers or receivers might interpret
>    as conferring more authority to the message content.  The working
>    group feels this is no different than present-day lists relaying
>    traffic and affixing RFC5322.Subject tags or similar, and thus it
>    doesn't introduce any new concerns.

This isn't written in a final form appropriate to an RFC.  I suggest:

    One concern is that having an MLM apply its signature to unsigned mail might 
cause some verifiers or receivers to interpret the signature as confirming more 
authority to the message content than is defined by DKIM.  This is an issue 
beyond MLMs and primarily entails receive-side processing outside the scope of 
the DKIM specification.  However it is worth nothing here.  In the case of MLMs, 
the presence of an MLM signature SHOULD be treated as similar to MLM handling 
that affixes an RFC5322.Subject tag or similar information.  Thus it does not 
introduce any new concerns.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 9 Aug 2010 22:57:14 -0000

>session is delayed after the crlf.crlf, and that's not supposed to happen.

Why not?  My MTA usually does a whole spamassassin run between the end
of data and the ack.  It adds maybe five seconds, at a point where 5321
says the timeout should be ten minutes.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Aug 2010 16:37:38 -0700

> says the timeout should be ten minutes.

It's considered bad form to hold up senders that way. For one thing, it adds 
non-determinacy at a point which can produce retransmissions.

I'm sure you're not the only one doing it, but as I recall, the standards to no 
institutionalize anything that forces it.

d/
-- 

   Dave Crocker

---

From: Graham Murray <[email-masked]>
Date: Tue, 10 Aug 2010 06:59:42 +0100

> session is delayed after the crlf.crlf, and that's not supposed to happen.

Anyone using the opendkim sendmail/postfix milter will be doing this
checking during the SMTP session.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 23:53:32 -0700

A couple of points before I drop for the night from all these edits.  I'll pick it up tomorrow, probably after posting an -02 incorporating the editorial feedback so far.  Since Dave suggests a fissioning of this document into two or more, I'll hold off applying his until after that's done and some discussion about it has been had.

> -----Original Message-----
> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Monday, August 09, 2010 3:40 PM
> To: Murray S. Kucherawy; DKIM IETF WG
> Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
> 

Some time ago we discussed this and the consensus seemed to be (to me, at least) to produce an Informational document on our first pass through this process with an eye towards doing a BCP (in the formal IETF sense) afterwards.  I think some people have been calling this a BCP because it generally espouses what we think of as best practices, but that term has some special status meanings in the IETF so perhaps that caused some confusion.

This is why I have been avoiding use of the RFC2119 words in this document to date.  So I'm inclined to change it to "Under what circumstances..." as you suggested.

If we have changed our consensus and want to take a run at a full BCP document, I'll happily go through and start using RFC2119 language.  Finding ways to avoid using those magic words, even in all-lowercase, can be a little time-consuming.

> without prior setup.  Dunno.

The document goes into what that means, particularly in terms of verifying signatures inbound to the MLM and then signing mail outbound from the MLM.  And it seems to me "use DKIM" means exactly the same thing as "use DKIM identifiers", since the carrying of a verified identifier is precisely the point of applying DKIM.

> definition of explains its variation.

Naturally I'm fine citing RFC5863 and ensuring this document's definitions match the ones found there, but do we really want to cite a Wikipedia article?

(cf: http://www.theonion.com/articles/wikipedia-celebrates-750-years-of-american-indepen,2007/)

> Seriously.  Show me an IETF "policy" specification that's been

It's not an effort at talking about any policy stuff in the IETF normative sense.  I'm talking about MLM configuration features, which are themselves expressions of the list admin's policies.  It's way outside of what I think you're talking about.

> "Verification Outcomes" refer to?

Weren't you the one that suggested this title?  :-)

> fields, as well as DKIM-Valid.

Didn't we toss out that argument when debating whether "i=" had any practical use, because any assertion it claimed by the signer couldn't be independently verified?

> "Trust"???  What does that mean, exactly, here?  It needs to be

[AUTH-RESULTS] talks extensively about trusting (or not) the content of the header field.  As it's a normative reference, is the term used unreasonably here?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Aug 2010 23:56:41 -0700

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Graham Murray
> Sent: Monday, August 09, 2010 11:00 PM
> To: [email-masked]

For that matter, anyone implementing any kind of filtering using the milter API is specifically doing so during SMTP.

And I think that goes for non-milter implementations that do things with forward-to-pipe mechanisms, which at least Sendmail supports; I'm fairly certain the post-DATA reply only happens when the pipe completes, so that an appropriate SMTP reply can be returned in case the piped-to program fails.

It's pretty universal.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 07:06:08 -0700

On 8/9/2010 11:53 PM, Murray S. Kucherawy wrote:
> Since Dave suggests a fissioning of this document into two or more, I'll hold
> off applying his until after that's done and some discussion about it has
> been had.

I'm a fan of getting the mix and balance of documents right.  Extra documents 
are a hassle, but a single document that mixes agendas is too.  I was a bit 
surprised to make the suggestion that this doc get split.

1.  Are there different topics?  If so, what are they and which should be 
pursued?  The working groups needs to comment on this.

     I think I saw 3 different topics, and that there has already been a bit of 
discussion about this.  The topics are:

     a.  Handling DKIM messages transiting a Mailing List Manager

     b.  Trust-based enhancements for Mailing List Managers based on DKIM

     c.  Best practices for Mailing List Managers

The first is/was the official goal of the current work.

The latter two have emerged.  Neither is formally within scope of the working 
group, although b. is a natural addition.  Note, however, that it is formal 
protocol specification work and we need to worry about adoption first -- who 
needs to adopt it and why do we think they will?

c. is not reasonably in scope; I do not see any way to justify it within this 
working group, in spite of there having been some good discussion.

2.  If a split is appropriate, how should the existing content be divided?

     I vote for letting Murray handle this.  (You're welcome, Murray.)

So, the first question is intended to get some working group consensus, before 
Murray puts in the effort of dividing things up.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 07:08:19 -0700

> It's pretty universal.

wow.  I had managed to miss this, particularly given the frequent comments from 
folk that they wished DKIM could operate at SMTP time.  (No doubt, they'd much 
rather have it be useful before data transfer, rather than after.  Still, during 
SMTP is better than later.)

This tidbit probably needs to be touted more.  Not sure how.

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Aug 2010 15:32:50 +0100

So it seems reasonable for folks to discuss this for a few days
and if a consensus is clear we can go from there. Otherwise maybe
we can poll about in next week or so. (Other suggestions welcome,
particularly from Murray as editor.)

S.

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Aug 2010 10:39:25 -0400

Dave CROCKER wrote:
> wow.  I had managed to miss this, particularly given the frequent 
> comments from folk that they wished DKIM could operate at SMTP time.  
> (No doubt, they'd much rather have it be useful before data transfer, 
> rather than after.  Still, during SMTP is better than later.)
> 

Probably helps to read a wider range of people comments rather than a 
selected few.  This has been discussed for at least a number of years, 
here and in IETF-SMTP and it was discussed immensely during the Thread 
Analysis and the SSP Requirements drafting helping to provide 
guideline as to when a POLICY was necessary.

Keep in mind that DKIM verification is not always required when ADSP 
is supported making a simple DNS lookup useful at the SMTP Level.

For example, the payload is transferred with:

     From: [email-masked]
     DKIM-Signature: d=someother.com

before the response is provided, the author domain, paypal.com ADSP 
lookup shows DKIM=DISCARDABLE. Since the DKIM-signature domain is not 
paypal.com
no need for any DKIM verification at this point because it would be a 
100% zero-false positive condition for instant rejection.

On the other hand it was a 1st party header:

     From: [email-masked]
     DKIM-Signature: d=paypal.com

a valid 1st verification is short-circuits the need for a POLICY 
lookup as it would be only possible to get a valid 1st party DKIM 
signature with proper 1st party public keys.

As outlined in the SSP requirements, only when the signature failures, 
can a POLICY lookup come into play.

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 10 Aug 2010 11:59:29 -0400

a and b. c is well outside the scope. Stick with informational for now.

> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, August 10, 2010 10:33 AM
> To: [email-masked]
> Cc: DKIM IETF WG
> Subject: Re: [ietf-dkim] Splitting the mailing list document?
> 
> 
> >> off applying his until after that's done and some discussion about
it
> has
> > are a hassle, but a single document that mixes agendas is too.  I
was a
> bit
> > 1.  Are there different topics?  If so, what are they and which
should
> be
> >      I think I saw 3 different topics, and that there has already
been a
> bit of
> > The latter two have emerged.  Neither is formally within scope of
the
> working
> > protocol specification work and we need to worry about adoption
first --
> who
> > c. is not reasonably in scope; I do not see any way to justify it
within
> this
> > So, the first question is intended to get some working group
consensus,
> before

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 09:56:16 -0700

> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Tuesday, August 10, 2010 7:06 AM
> To: DKIM IETF WG
> Subject: [ietf-dkim] Splitting the mailing list document?
> 

If the document has indeed wandered off into this more general area (and I'd have to re-read it to find the parts you're talking about), we should reel it back in.  I don't want to maintain a general treatise on how MLMs should behave unless perhaps I manage to enlist some co-authors of major current MLMs to do so.

I think the other two are within scope and would probably be fine to include in a single document.

> needs to adopt it and why do we think they will?

Is that really true?  The document is informational and is deliberately avoiding being normative about anything.  Its posture is intended to convey experience of the industry so far in deploying DKIM and MLMs in tandem, and provide some suggestions of how that co-operation could be improved.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Aug 2010 10:09:16 -0700

On 8/10/2010 9:56 AM, Murray S. Kucherawy wrote:
>> The latter two have emerged.  Neither is formally within scope of the
>> working group, although b. is a natural addition.  Note, however, that it
>> is formal protocol specification work and we need to worry about adoption
>> first - - who needs to adopt it and why do we think they will?
>
> Is that really true?  The document is informational and is deliberately
> avoiding being normative about anything.  Its posture is intended to convey
> experience of the industry so far in deploying DKIM and MLMs in tandem, and
> provide some suggestions of how that co-operation could be improved.

The comment was about b, which specified additional semantics and a set of 
conventions (that is, a protocol) for achieving it.  This is the extra 
header-field I suggested.  The current draft touches this realm, but clearly 
it's beyond the scope of your current project.  Rather, the current effort is 
prompting us to note some related issues.

As for Informational, I'll repeat that the core of your draft -- the part that 
is entirely withing the direct scope as I understand it -- contains normative 
language.  And I think that's appropriate.  But that makes it not Informational, 
but probably a BCP.

d/
-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Tue, 10 Aug 2010 10:16:23 -0400

Should DKIM transit a mailing list?
if a message arrives at a list manager the author/sender theoretically should be a pre-qualified by whatever means used to be a member of that list. Any recipient that has subscribed to that list has a reasonable expectation that any message addressed to the list would be interesting. With that in mind all signatures should be discarded, resigned by the dkim aware mailing list then forwarded on as if it is a "new" mail message. Now whether a dkim aware mailing list should follow adsp practices is worth discussing.
thanks,
Bill Oxley

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Aug 2010 10:49:30 -0700

> [email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, August 10, 2010 7:16 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [ietf-dkim] dkim and mailing lists
> 
> if a message arrives at a list manager the author/sender theoretically
> should be a pre-qualified by whatever means used to be a member of that
> list. Any recipient that has subscribed to that list has a reasonable
> expectation that any message addressed to the list would be
> interesting. With that in mind all signatures should be discarded,
> resigned by the dkim aware mailing list then forwarded on as if it is a
> "new" mail message. Now whether a dkim aware mailing list should follow
> adsp practices is worth discussing.

Bill,

Have you read the draft?

A lot of this is already discussed in there.  If you have specific feedback about the text that's in there already, that would be really helpful.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 11 Aug 2010 21:22:48 +0100

On Tue, 10 Aug 2010 15:16:23 +0100, <[email-masked]> wrote:

> list.

Not necessarily so. There exist lists to which anyone may post (and in
which actual subscription is by invitation).

> Any recipient that has subscribed to that list has a reasonable  
> expectation that any message addressed to the list would be interesting.  
> With that in mind all signatures should be discarded, resigned by the  
> dkim aware mailing list then forwarded on as if it is a "new" mail  
> message.

I agree about the "new" mail message, but how do subsequent agents as the
forwarded mail is propagated "know" that it is new, unless the From: is
changed? To them, it is indistinguishable from a mail from someone at the
original discardable domain.

Note than you cannot assume the ultimate recipient is in a position to
identify special cases that apparently are unsigned emissions from a
discardable domain. Our normal expecation is that will be done by his
boundary ISP (where his mailbox is likely to be kept).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 17 Aug 2010 12:06:22 +0100

--On 9 August 2010 16:37:38 -0700 Dave CROCKER <[email-masked]> wrote:

>>> DKIM and ADSP evaluation are not performed during an SMTP session,
>>> unless the session is delayed after the crlf.crlf, and that's not
>>> supposed to happen.
>>
> It's considered bad form to hold up senders that way. For one thing, it
> adds  non-determinacy at a point which can produce retransmissions.

Yep. My experience is that MS Outlook MUA does this, but I think I've only 
ever seen one incident where an MTA did so.

My belief is that best practice is to queue password authenticated email 
submissions, and bounce later if necessary (but not to bounce to a 
non-local domain). Unauthenticated mail should be scanned at SMTP time, and 
rejected at SMTP time if necessary.

Mail that's authenticated by DKIM, could, perhaps, be treated as 
bounceable. However, I think one might only want to apply that rule when 
there's some clear relationship between the RETURN PATH address and the 
signing domain. For example, if the return path address matches the From 
header address, and the From header is DKIM signed.

>
> I'm sure you're not the only one doing it, but as I recall, the standards
> to no  institutionalize anything that forces it.
>
> d/

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 17 Aug 2010 12:08:01 +0100

> checking during the SMTP session.

Yes, out Exim/Spamassassin installation does DKIM (but not ADSP) evaluation 
during the SMTP session.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 17 Aug 2010 06:51:56 -0700

On 08/17/2010 04:08 AM, Ian Eiloart wrote:
>
>
> --On 10 August 2010 06:59:42 +0100 Graham Murray<[email-masked]>
> wrote:
>
>> Dave CROCKER<[email-masked]>  writes:
>>

I'm not positive, but I believe that Ironport does it that way too.

Is there anybody who *doesn't* do DNS lookups at SMTP time these days?
That's all DKIM really amounts to, and the entire mail infrastructure would
seize if we weren't (cf, blacklists).

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Aug 2010 01:53:01 -0400

>> Yes, out Exim/Spamassassin installation does DKIM (but not 
> ADSP) evaluation during the SMTP session.
> 
> Is there anybody who *doesn't* do DNS lookups at SMTP time these 
> days? That's all DKIM really amounts to, and the entire mail 
> infrastructure would seize if we weren't (cf, blacklists).

In the past, I followed how implementations of SPF was being done - at 
SMTP or post acceptance. I recall it was interestingly spread out 
depending on the software being used. Most of the MTAs that allowed 
embedded hooking with programming scripts had scripts available and 
others used general 2822 text file mail bot SPF scripts.

But I've also followed other MTAs such as YAHOO, AOL, MSN.COM, 
gmail.com and so on, where you definitely saw a shift towards DATA 
level rejections than in the past.

The only issue overall between the two was how the ENVELOPE 
information was read or written into the 2822 file for post smtp to 
read.  In general, you could get this from the top Received: line 
stamped by the MTA (a requirement), but other MTA add specific syntax 
envelope info at the top before the 2822 blocks.

At the SMTP level, you don't need to work about that but generally, 
the scripting language is proprietary to the MTA engine in use.

So POST SMTP scripts tend to be more general and made to work with for 
most MTAs, with no or little change.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Aug 2010 11:40:37 -0700

> [...]

Ah, the deafening silence...

After thinking about it for a while, I believe it would be fine to fork the document as described.  Given the working group's scope and charter, and in the absence of any objection, I propose the following:

1) The current document covers what you have as (a) above with no change to name, and an intended status change to BCP.

2) The parts of the current document suggesting possible enhancements become a new WG document with a similar name.  The status of this document would be Informational.

3) A general BCP for lists irrespective of DKIM is probably something the email world should have.  I'd be fine with this being either Informational or BCP status.  I would take this up as an individual submission and probably move it through the APPS area, but I would really like to hear from some of the MLM maintainers, past and present, on this list willing to help with that work before I agree to add it to my queue.

None of this will happen before the start of September in any case, but I thought I should finally reply to this.

-MSK