Subject: Re: [ietf-dkim] Lists "BCP" draft available

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Jun 2010 00:12:21 -0700

Hi Eliot,

By ‘standards compliant’ there I actually mean ‘not non-compliant’, meaning there’s no basis on which to coerce MLMs to change their behavior.

I can change to the “RFC5322.From” notation if necessary.

The use of FBL in this context is in line with how the MARF working group is using it and also lines up with the discussion that got this whole recent effort started.  Is there some other definition I should be aware of?

I’ve extended 3.2 as you suggested.

For 4.1, I’ll need to go over it again, unless you (or someone else) has some suggestions.  I just looked at it and it seemed reasonable to me; it’s not hard for me to figure out which lists I’m on that are and aren’t MLM-aware.  This document might even encourage MLM operators to announce this to their users at subscription time so they can be appropriately informed.

For 5.1, I’ve changed it to “mail streams”, which is defined earlier in the document.

For 5.2 and 5.4, I’ve added some clarifying text.

Thanks for the thorough review!

-MSK

From: Eliot Lear [mailto:[email-masked]]
Sent: Monday, May 17, 2010 4:36 AM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [ietf-dkim] Lists "BCP" draft available

Hi Murray,

Thanks for taking a shot at this.  Here are some comments on the Lists draft.

First, I support the draft becoming a working group document.

However, I wonder if it requires simplification with a bit more discussion as to motivation.  I'll get into some of that below.

Introduction 3rd and 4th bullets should use consistent terminology, so I suggest:

s/mailing list/MLM/

Section 1.2

   MLM behaviors are well-established and standards compliant.

I don't understand what you mean by standards compliant.

Same section lower down:

   However, the fact that the From

   field of such a message is typically the same as for the original

   message and that recipients perceive the message as "from" the

   original author rather than the MLM creates confusion about

   responsibility and autonomy for the re-posted message.

Isn't there standard terminology to distinguish between the From and from (e.g., SMTP-From)?

Section 1.3

FBL?  What a horrible misuse of an already common term.  Is there a cite for this or can we change it?

Section 3.1

I *love* the title of this section!!!

However- I believe we need to be careful to cite the source of these definitions, so as to avoid conflict should they change.

Section 3.2

 The remainder of this document operates on the presumption that a

   message going through a re-posting MLM actually comprises two message

   transactions

s/re-posting/resending/

?

I think, by the way, that 3.2 should probably be expanded with regard to the logic behind steps 1 and 2.  Seems to me that's the thing that will help mailing list maintainers understand why the solution is correct.

Section 4.1.

I'm uncomfortable with this section.  I don't know how an author is supposed to know whether an MLM is a participant or non-participant.  Moreover, discrimination at the enterprise level seems like a great opportunity for us vendors to sell more hardware without much customer benefit.

I would rather see this section simply say that messages originating from ADMDs that have strict ADSP polices are advised to not make use of either non-participating MLMs that corrupt signatures.

Section 5.1

Authors may be well-advised to create a DNS domain specifically used

   for generating signatures when sending traffic to MLMs

I think you have to be really clear on this point, because it can be read in one of several ways:

 *   Author domain should be used expressly to transmit to MLMs, in which case you should make it clear when this should be the case (e.g., you couldn't imagine an entire enterprise redoing their email infrastructure to such an end)
 *   The SIGNING domain and NOT the author domain should be used expressly to transmit to MLMs, in which case we have a problem I mentioned above;
 *   Something else
Section 5.2:

   In the case of verification of signatures on subscriptions, MLMs are

   advised to add an [AUTH-RESULTS] header field to indicate the

   signature(s) observed on the submission as it arrived at the MLM and

   what the outcome of the evaluation was.

What if any level of operational trust should be placed in such a header?

Section 5.4

   A DKIM-aware resending MLM is encouraged to sign the entire message

   as it arrived, especially including the original signatures.

Would I as an MLM want to resign a message that I received that itself was not signed?  Do I want to confer more authority to that message than is warranted?

Eliot
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Jun 2010 01:05:58 -0700

> -----Original Message-----
> From: Daniel Black [mailto:[email-masked]]
> Sent: Saturday, May 29, 2010 2:10 AM
> To: [email-masked]; Murray S. Kucherawy
> Subject: Re: [ietf-dkim] Lists "BCP" draft review
> 
> Comments on draft-kucherawy-dkim-lists-00
> [...]

Wow, Daniel.  Thanks for a very thorough review.  I picked mid-day Friday as the cutoff for feedback of what went into the -01 version of the draft, and now I'm regretting it.  :-)

I'll give a more complete reply tomorrow and make use of some of the text you submitted.  Just wanted to acknowledge the work right away.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 01 Jun 2010 03:47:32 -0700

On 5/29/2010 2:09 AM, Daniel Black wrote:
> * email gateways became authenticated

What does this mean?

> * email providers were pressured to stay off blacklists by complying to a set
> of practices including no open relays, RFC compliance to not sending bulk
> spam.

Pressure from whom?  How is it manifest/documented?

Although closing open relays is probably an acknowledged universal rule, not 
much else is. "Pressure" for 'RFC compliance' is certainly not new. 
Unfortunately, it also is not precise.

> These changes have occurred because of receivers changing the way they
> receive, block and filter email. The senders have had a choice here of change
> practices or risk their email not being accepted.

How have receivers changed the way they "receive"?

> In the same way that receiver practices have previously changed the way email
> is sent DKIM, despite its infancy has also had an impact. Brett has mentioned
> earlier the positive effects for paypal as a mechanism that domains can use to
> protect their customers from phishing.

DKIM, by itself, does not protect against phishing.  DKIM does not attempt to 
help find bad actors.  Generic statements about DKIM and phishing, in some DKIM 
documents, has no technical substance.

On the other hand, ADSP certainly was motivated by the direct goal of finding 
spoofed From: domains.

> MLMs, like mailman, have taken the
> simple option of stripping DKIM signatures which has also had a positive effect
> for many list admins.

This implies that DKIM-stripping is an active choice among MLMs.  It isn't.

> Actual Review:
>
> Principle Recommendations:
>
> Incorporate ARF/draft-ietf-mark-dkim-reporting as strong recommendations so
> that any incompatibilities anywhere will be obvious the the sender domain.

I do not understand this recommendation.

> It is in the recipients interest to allow messages through that pass DKIM/ADSP
> checks.

As stated, this assertion is largely incorrect.  It declares that a sender who 
publishes DKIM/ADSP is (automatically) to be interpreted as a good actor.

> section 3.3 Current MLM Effects On Signatures
>
> Append at end of subject tags paragraph.
>
> "The content of MLM modification of the subject tag is effectively replicating
> the List-ID value in a way visible to the recipient. This behavior was
> motivated by a lack of MUA support for displaying List-ID tags. It desirable
> for MUA to start supporting List-ID tags in order to deprecate this behaviour
> in MLMs."

This document has no goal nor scope for recommending basic changes to the 
operation of mailing list managers.  Nor is there any history of having MLMs 
adopt such recommendations.

Nor, I suspect, is there likely to be community agreement that changing this 
widespread Subject: field behavior is a good idea...

> Addition to other header fields paragraph:
>
> "The modification of Sender/Reply-to stems from a goal to guide the recipients
> behaviour to continue the conversion or or off list. There could be an attempt
> to create a new header field to describe the desired behaviour and for MUAs to
> take note of this header field."

Having one specification recommend that someone, somewhere, initiate a new 
specification effort is generally not useful.

> Add to end of this paragraph:
>
> The filtering of attachments is a part of MLMs that are aimed at reducing
> message size and preventing malware aimed at MLM subscribers.

This document does not have the goal of explaining MLMs.  We should be extremely 
careful to keep this document within its scope.

> new paragraph at the end of 3.3
>
> In essence, the practices of MLM breaking DKIM signature verification could be
> reduced with better MUA support on existing standards and the introduction of
> a few simple standards so that MUA and MLM can operate consistently rather
> then retrofitting desired behavior into existing header fields potentially in a
> incompatible way.

Changing MUAs will not alter MLM DKIM breakage. Please explain how you think it can.

The rest of that sentence has no technical substance and is not the sort of 
language that is helpful for a specification.

> Append new section:
>
> 5.X MLM ADSP
>
> A participating MLM should be able to assert a ADSP policy.

This sort of statement is certainly controversial but worse is outside the scope 
of this specification.

d/
-- 

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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 01 Jun 2010 07:30:04 -0700

On 6/1/2010 7:14 AM, Daniel Black wrote:
> On Tuesday 01 June 2010 20:47:32 Dave CROCKER wrote:
> MSA became authenticated - generally a reduction in open relays.

An MSA is not a gateway[1].

>>> * email providers were pressured to stay off blacklists by complying to a
>>> set of practices including no open relays, RFC compliance to not sending
>>> bulk spam.
>>
>> From the users that get DSN or the intended recipients harassing their mail
> administrators because mail isn't going trough.

Recipients complain to their own ISPs, not to senders.

>>> simple option of stripping DKIM signatures which has also had a positive
>>> effect for many list admins.
>>
> I was more highlighting there was an active choice in a MLM development to
> remove DKIM headers (as a default enabled option I think) and without a
> guidance such as what the draft is trying to achieve there could be more.

And my claim is that there was no such active choice.

>>> "The content of MLM modification of the subject tag is effectively
>>> replicating the List-ID value in a way visible to the recipient. This
>>> behavior was motivated by a lack of MUA support for displaying List-ID
>>> tags. It desirable for MUA to start supporting List-ID tags in order to
>>> deprecate this behaviour in MLMs."
>>
>> operation of mailing list managers.
>
> An exploration of DKIM for MLM (ref abstract) sounds like recommending changes
> is a possibility.

There is a very big difference between suggesting the handling of DKIM and ADSP 
and quite another to suggest making user visible changes, especially for MLM 
behaviors that are so well-entrenched.

> MLM behaviour is driven by client need. It is presumably there because MUA
> can't or won't provide the desired functionality. MUA changes may remove the
> need for DKIM incompatible MLM behaviour when clients have this function
> served by their MUA.

I do not understand your explanation.  My failure to understand is so extensive 
I cannot even think of a question or comment to offer in an attempt to resolve 
the point.

>> This sort of statement is certainly controversial
>
> I suspect more ADSP angst reasons than technical reasons.

angst is a nicely deprecatory term.  it suggests that there are no serious 
operational or policy concerns.

d/

[1] rfc 5598
-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 1 Jun 2010 11:32:00 -0400

> Recipients complain to their own ISPs, not to senders.

If I had a nickel for every case where I got the complaint instead of
the ISP I'd be rich! :)

-- 
Jeff Macdonald
Ayer, MA

---

From: Daniel Black <[email-masked]>
Date: Wed, 2 Jun 2010 00:14:24 +1000

> Although closing open relays is probably an acknowledged universal rule,
> not much else is. "Pressure" for 'RFC compliance' is certainly not new.

I agree - lack of precision is why feedback loops are important. I suspect 
open relays got to the state they are now because of a set of pressures.

> How have receivers changed the way they "receive"?

mail gateways rejecting based on blacklists of many descriptions, strictness 
in reverse IP address, friend list and numerous secret sauces of message 
acceptance. Some recipients may even look at dkim.
 
> > In the same way that receiver practices have previously changed the way
> > email is sent DKIM, despite its infancy has also had an impact. Brett
> > has mentioned earlier the positive effects for paypal as a mechanism
> > that domains can use to protect their customers from phishing.
> 
> DKIM, by itself, does not protect against phishing.  DKIM does not attempt
> to help find bad actors.  Generic statements about DKIM and phishing, in
> some DKIM documents, has no technical substance.
> 
> On the other hand, ADSP certainly was motivated by the direct goal of
> finding spoofed From: domains.
acknowledged.

> > Incorporate ARF/draft-ietf-mark-dkim-reporting as strong recommendations
> > so that any incompatibilities anywhere will be obvious the the sender
> > domain.
> 

Strongly recommending the placement of the optional reporting address defined 
in draft-ietf-dkim-deployment will enable somebody to know the message isn't 
getting through. Recipients also have a role in reporting ARF by using this 
header field.
 
> > It is in the recipients interest to allow messages through that pass
> > DKIM/ADSP checks.
> 
> As stated, this assertion is largely incorrect.  It declares that a sender
> who publishes DKIM/ADSP is (automatically) to be interpreted as a good
> actor.

ok for clarity - the message received shouldn't be rejected on DKIM/ADSP 
grounds.

Barry's comment #4 as chair in the email 'Some procedural notes from the 
chairs' suggests it is not out of bounds of the working group or this draft.

> Nor is there any history of having
> MLMs adopt such recommendations.

acknowledged. Barry explains this well too.

> Nor, I suspect, is there likely to be community agreement that changing
> this widespread Subject: field behavior is a good idea...

I image some community disagreement however as Murray points out, MUAs may be 
changing faster than previously accounted for and provided the MUA is doing a 
comparable thing as the subject alteration. Perhaps avoiding the possibility 
of subject changes will preclude the benefits it may gain.

> > "The modification of Sender/Reply-to stems from a goal to guide the
> > recipients behaviour to continue the conversion or or off list. There
> > could be an attempt to create a new header field to describe the desired
> > behaviour and for MUAs to take note of this header field."
> 

Quite right - this is more a discussion point.

> This document does not have the goal of explaining MLMs.  We should be
> extremely careful to keep this document within its scope.
Sure. An examination as to why thing are is sometimes more revealing than what 
they are.
 
> > In essence, the practices of MLM breaking DKIM signature verification
> > could be reduced with better MUA support on existing standards and the
> > introduction of a few simple standards so that MUA and MLM can operate
> > consistently rather then retrofitting desired behavior into existing
> > header fields potentially in a incompatible way.
> 

> but worse is outside the scope of this specification.
It falls within the scope of exploring the DKIM and MLM topic. I suspect its a 
little too early in discussions to limit scope beyond the WG charter.

Daniel

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Jun 2010 11:38:23 -0700

On 6/1/10 3:47 AM, Dave CROCKER wrote:
> >> In the same way that receiver practices have previously changed

> >> the way email is sent DKIM, despite its infancy has also had an
> >> impact. Brett has mentioned earlier the positive effects for
> >> paypal as a mechanism that domains can use to protect their
> >> customers from phishing.

>  DKIM, by itself, does not protect against phishing.  DKIM does not
>  attempt to help find bad actors.  Generic statements about DKIM and
>  phishing, in some DKIM documents, has no technical substance.
>
>  On the other hand, ADSP certainly was motivated by the direct goal
>  of finding spoofed From: domains.

Agreed.

See section 4.3, third paragraph:
,---

[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
exception in the policy for a message that may have been altered by
an MLM.  Verifiers are thus advised to honor the policy and disallow
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.3 below.)

'---

There is no MUST discard, only "encourage".  Secondly, there is no clear 
definition for discard, although it is generally understood to mean 
silently delete.
This recommendation appears to be making deliver-ability distinctions 
between "discardable" and "all", that does not exist in the ADSP 
specification.  Problems caused by MLMs are true for refusals based upon 
"all" as well.  In fact, "all" precludes silently deleting which could 
even help reduce the number of subscribers being dropped.

Please include "all" and "discardable" whenever making general policy 
statements.  The only difference between "all" and "discardable" is 
permission granted to silently delete, however either may cause messages 
to be refused.   When email integrity is important, "all" should be used 
instead of "disardable".

Section 2.4, Message Streams ( in conflict with ADSP)
,---

This document makes reference to the concept of "message streams".
The idea is to identify groups of messages originating from within an
ADMD that are distinct in intent, origin and/or use, and partition
them somehow (most commonly via DNS subdomains, and the "d=" tag
value in the context of DKIM) so as to keep them associated to users
yet operationally distinct.

'---

Please add a statement indicating this concept is in conflict with 
ADSP.  Such as:

ADSP is in conflict with the Message Stream concept, since An Author 
Domains Signature must match exactly with the email-address domain.

Section 4.1.  Author-Related Signing

,---
  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.  The MLM could make
  a change that would invalidate the author's signature but not remove
  it prior to re-distribution.

  Hence list recipients would receive a message message purportedly
  from the author but bearing a DKIM signature that would not verifiy.
  This problem would be compounded further if there were receivers that
  applied signing policies ([ADSP]) and the author published any kind
  of strict policy.

  If this is cause for concern, the originating site can consider using
  a sub-domain for the "personal" mail that is different from domain(s)
  used for other mail streams, so that they develop independent
  reputations, and more stringent policies (including ADSP) can be
  applied to the mail stream(s) that do not go through mailing lists.

'---

 From a phishing perspective, advocating use of different domains, or
sub-domains will lead to phishing being more successful, and also
likely increase the number of attempts.

There are some 20K financial institutions being heavily phished, with 
perhaps a similar number involving other institutions.  Clearly, the 
phishing problem affects a small percentage of the domains in current 
use, albeit causing substantial damage to their ability to utilize email 
for personal and transactional exchanges.  There are a number of U.S. 
regulations affecting these institutions, such as PCI DSS, HIPAA and 
GLBA.   Third-party services being used by this small segment of domains 
should already be known by their administrators.  Publishing a list of 
these services would enable specific ADSP policy exceptions, and 
significantly reduce possible phishing sources.  This approach would 
also allow these institutions a means to directly react to any reported 
abuses.

Importantly, specific authorization of third-party services avoids 
highly detrimental advice of using multiple domains.  It seems many 
marketing departments, (including our own) still need to be educated on 
this matter.   Please don't offer confusing advice about using similar 
domains.  Don't recommend use of different domains, when there is a 
better alternative that should be advocated.

People are taken in by phishing, see:
http://www.antiphishing.org/reports/APWG_GlobalPhishingSurvey_2H2009.pdf
,---

Most maliciously registered domain strings offered nothing to confuse a 
potential victim.

Placing brand names or variations thereof in the domain name itself is 
not a favored tactic, since brand owners are proactively scanning 
Internet zone files for such names. As we have observed in the past, the 
domain name itself usually does not matter to phishers, and a hacked 
domain name of any meaning, in any TLD, will usually do. Instead, 
phishers almost always place brand names in subdomains or 
subdirectories. This puts the misleading string somewhere in the URL, 
where potential victims may see it and be fooled. Internet users are 
rarely knowledgeable enough to be able to pick out the "base" or true 
domain name being used in a URL.

'---

Advocating that targets of phishing attacks utilize similar sub-domain 
tactics will lead to greater confusion.  If anything, consumers need to 
experience greater predictability in which domains names these 
institutions use.  This also helps the receivers attempting to manually 
mitigate this problem.

> >> MLMs, like mailman, have taken the simple option of stripping
> >> DKIM signatures which has also had a positive effect for many
> >> list admins.
>

Clearly,  it is?

Section 4.2 of RFC 4871 states:
,---
Signers SHOULD NOT remove any DKIM-Signature header fields from messages 
they are signing, even if they know that the signatures cannot be verified.
'---

This is not a MUST NOT and then states:

,---
Verifiers SHOULD ignore failed signatures as though there were
not present in the message.
'---

The choice is open.  How would you envision an invalid signature being 
valuable with respect to third-party services?

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Jun 2010 12:24:20 -0700

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Douglas Otis
> Sent: Tuesday, June 01, 2010 11:38 AM
> To: [email-masked]
> There is no MUST discard, only "encourage".

Correct, and as has been discussed on the list already, this document is avoiding making normative assertions.

> Secondly, there is no
> clear

Can you point me to such a definition someplace?

> specification.

Yes, that is precisely the problem.

> Domains Signature must match exactly with the email-address domain.

I fail to see how those two are in conflict.  ADSP works just fine to nail down the use of one particular message stream while leaving others less restricted.

> likely increase the number of attempts.

This and the rest of it seems to be a variant of the ADSP debate, so I'm going to avoid replying within this thread.  It belongs in a different thread.

---

From: John Levine <[email-masked]>
Date: 1 Jun 2010 18:43:22 -0000

I have to say that I share much of Dave's bafflement.  And as a minor
list developer, I don't recognize any MLM I know in many of the
assertions below.

>guidance such as what the draft is trying to achieve there could be more.

It's challenging to parse that sentence, but if you're saying that
MLMs currently strip DKIM headers, they don't other than perhaps by
turning on a general header-stripping feature.  We're still arguing
about whether it's a good idea to do so.

>getting through. Recipients also have a role in reporting ARF by using this 

If you're assuming that MLMs will routinely send back DKIM failure
reports, that seems, ah, exceedingly unlikely.

>ok for clarity - the message received shouldn't be rejected on DKIM/ADSP 

How is this different from the way you'd handle any other message?

>> > deprecate this behaviour in MLMs."

As Dave said, no.  Subject tags are a feature, not a bug.  I hope we
can resist repeating the mistake that many SPF advocates made of
claiming that any mail behavior that doesn't work with SPF is a bug in
the mail software rather than a limitation of SPF.

>need for DKIM incompatible MLM behaviour when clients have this function 

Maybe I'm suffering from a lack of imagination, but I can't parse this
in any way that makes any sense.  It might be saying that if MUAs
contained all the features of MLMs, we wouldn't have MLMs, but that's
just silly.

>> > A participating MLM should be able to assert a ADSP policy.

Since list messages have, pretty much by defintion, From: line
addresses in domains not under the control of the list manager, this
must be something other than what's described in RFC 5617.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Jun 2010 14:09:16 -0700

> about whether it's a good idea to do so.

Mailman in particular was at one point stripping DKIM headers specifically
in at least one version until I convinced them that was the wrong thing
to do. Whether they actually incorporated the change back to leaving them
alone, I don't know.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Jun 2010 14:17:22 -0700

On 6/1/10 12:24 PM, Murray S. Kucherawy wrote:
> > -----Original Message----- From: [email-masked]
> > [mailto:ietf-dkim- [email-masked]] On Behalf Of Douglas Otis
> >
> > exception in the policy for a message that may have been altered
> > by an MLM.  Verifiers are thus advised to honor the policy and
> > disallow 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.3 below.)
> > '---
> >

This draft is incorrectly translating ADSP as making a normative 
statement when saying:

"Per that specification, when a message is unsigned or the signature can 
no longer be verified, the verifier must discard the message.

> > Secondly, there is no clear definition for discard, although it is
> > generally understood to mean silently delete.
>

IIRC, Sendmail defined DISCARD in their Access Database Format, where to 
override rejection, assert OK; to permit relaying, assert RELAY; to 
always reject the message, assert REJECT; and to discard the message 
completely, assert DISCARD.  Unfortunately, ADSP  did not define what 
was meant by "discardable".  This draft could add clarity with a section 
that defines its meaning.

> > This recommendation appears to be making deliver-ability
> > distinctions between "discardable" and "all", that does not exist
> > in the ADSP specification.
>

Is the intent to modify normative language which did not make any 
statement where deliver-ability is to be viewed differently between 
"all" and "discardable"?

The term "discardable" is related to whether a message that was not 
rejected and not delivered may then not return a NDN.

> > ADSP is in conflict with the Message Stream concept, since An
> > Author Domains Signature must match exactly with the email-address
> > domain.
>
>  I fail to see how those two are in conflict.  ADSP works just fine to
>  nail down the use of one particular message stream while leaving
>  others less restricted.

ADSP does not encompass mail streams, it only covers specific domains, 
not sub-domains.  Although the ADSP's Author Domain Signature definition 
is a bit unclear, section 3.1, among other sections, adds the following:

Section 3.1 "ADSP as defined in this document is bound to DNS. For this 
reason, ADSP is applicable only to Author Domains..."

ADSP has no bearing on mail streams that are defined as having 
sub-domains of the same domain.   In other words, a parent domain can 
not produce a valid Author Domain signatures for a sub-domain.  As such, 
the concept of mail stream is incompatible with the definition for 
Author Domain Signature which specifically excludes references by a 
parent domain.  An indication of these being incompatible concepts could 
prevent some confusion, and help avoid inappropriate terminology when 
referring to ADSP.

How would the concept of mail stream be used in conjunction with ADSP 
which is silent on the presence of a parent signature?

-Doug

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 02 Jun 2010 10:56:17 +0200

Douglas Otis wrote:

> completely, assert DISCARD.  

And the Postfix man page for accesss defines DISCARD as:

Claim successful delivery and silently discard  the message. Log the optional text if specified, otherwise log a generic message.

But the fact that Sendmail or Postfix define it this way does not 
necessarily mean that "discard"/"discardable" has the same meaning in 
the context of ADSP. If "discardable" needs further definition, it has 
to be defined in the context of ADSP in the next revision of the ADSP 
document.

> Unfortunately, ADSP  did not define what 

No, not in this BCP draft. It has to be defined in the next revision of 
the ADSP document.

/rolf

---

From: John Levine <[email-masked]>
Date: 2 Jun 2010 13:06:45 -0000

>> Unfortunately, ADSP  did not define what was meant by "discardable".

We said:

               All mail from the domain is signed with an
               Author Domain Signature.  Furthermore, if a
               message arrives without a valid Author Domain
               Signature due to modification in transit,
               submission via a path without access to a
               signing key, or any other reason, the domain
               encourages the recipient(s) to discard it.

Keeping in mind that senders cannot force receivers to do anything,
what else should we have said?

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 02 Jun 2010 15:53:59 +0200

> what else should we have said?

given the recent discussions, it seems to me that people want to have a 
definition of what 'discard' means in the context as described above. As 
a non-native English speaker (or what's the right term?) I suppose (but 
am not sure) the word 'discard' can have multiple meanings (apart from 
'To throw away'). Otherwise 'silently discard' would be a pleonasm, 
isn't it?

I suggest to put the subject 'discard and discardable' on the to-do list 
for a next revision of ADSP. If my analysis (that the word 'discard' 
means different things to different people) is correct, then there's 
still some discussion to go. After all, throwing away mail silently is 
contradictory to the original SMTP model (mail is delivered or a NDN 
comes back) and can have negative impact on the reliability of the 
e-mail system, as perceived by users of e-mail.

/rolf

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 10:48:03 -0400

> definition of what 'discard' means in the context as described above. As a 
> non-native English speaker (or what's the right term?) I suppose (but am not 
> sure) the word 'discard' can have multiple meanings (apart from 'To throw 
> away'). Otherwise 'silently discard' would be a pleonasm, isn't it?

Your English is fine.  "Discard" means throw away.

R's,
John

---

From: Al Iverson <[email-masked]>
Date: Wed, 2 Jun 2010 10:08:24 -0500

> Your English is fine.  "Discard" means throw away.

Agree. "Discard" and "silently discard" mean the same thing, in my
opinion. Though, I am guilty of using the phrase "silently discard."
Maybe in an attempt to be slightly over-specific.

Cheers,
Al

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 08:43:37 -0700

> Maybe in an attempt to be slightly over-specific.

I do not recall seeing a dictionary or technical definition of "discard" that 
says anything at all about whether the discarder says anything at all.

Taken on its own and without further technical specifications 'discard' does not 
direct, imply or request that the action be silent or noisy, and if noisy who 
gets to hear it.

d/
-- 

   Dave Crocker

---

From: Al Iverson <[email-masked]>
Date: Wed, 2 Jun 2010 10:50:15 -0500

On Wed, Jun 2, 2010 at 10:43 AM, Dave CROCKER <[email-masked]> wrote:

> I do not recall seeing a dictionary or technical definition of "discard"
> that says anything at all about whether the discarder says anything at all.
>
> Taken on its own and without further technical specifications 'discard' does
> not direct, imply or request that the action be silent or noisy, and if
> noisy who gets to hear it.

I'm perfectly fine with being more explicit, but I do think there's an
implication of silent by the use of the word discard in the context of
email delivery. If it's not delivered, it's either bounced back --
rejected, with a DSN, or discarded. The 99.9999% example of this is
Hotmail, and their discarding is silent. I would also suggest that a
noisy discard, perhaps "discard + a status notification," (is there
any other kind there could be?) is already covered by the existing
case of a DSN/bounce.

So, by my own experience, my only experience with discarding, it has
always been and only been silent. Like I said, I'm fine with being
more explicit, but keep in mind that I sure that I am not the
exception as far as my understanding of what discard means in the
context of email delivery.

Regards,
Al Iverson

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 02 Jun 2010 16:08:39 +0100

> Your English is fine.  "Discard" means throw away.

And, to "silently discard" is to discard without informing anyone. It 
means, for example, that you don't also generate a bounce message, or a 
notification to the recipient.

My guess is that the phrase "the domain encourages the recipient(s) to 
discard it" is intended to refer to a silent discard. Otherwise it would 
say "bounce" (which I take to mean "discard and notify the sender). 
"Bounce" is an unlikely recommendation, since most people don't like to 
bounce messages of uncertain origin these days. I guess you might bounce if 
it you had an SPF pass.

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 08:53:08 -0700

On 6/2/2010 8:50 AM, Al Iverson wrote:
> email delivery.

Among some folk, perhaps.  But this is not the sort of issue that should be 
relied on by implication or statistical likelihood of interpretation, if there 
is to be productive discussion and use of the term in a standards arena.

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Jun 2010 08:53:58 -0700

> Maybe in an attempt to be slightly over-specific.

In the email filter space there is sometimes a distinction.

"Discard" is sometimes used to mean "discard and notify". That is "throw
away the content of the message, but send a message to the intended
recipient telling them you've done so." Virus filters often do this sort of thing.

"Silently discard" clarifies that you really just mean "throw it away", and
throughout the development process that was the intended meaning of
the word "discard" in the spec.

The advantage of the notification is that it allows the recipient to be aware
of false positives. The disadvantage is that, unlike virus filtering, phishing
can be designed to work even though the main body of the message is
discarded, by designing the message such that the right part of it (such
as a URL) is passed through the notification process. The only way to
entirely avoid that is to avoid identifying the message that was discarded
in the notification, and that's just appallingly bad UX all around.

Given the appalling false positive rates, I'm not sure that "silently discard"
is *clearly* the right thing to do, but "discard and notify" has even bigger
problems.

Cheers,
  Steve

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2010 12:55:56 -0400

> And, to "silently discard" is to discard without informing anyone. It means, 
> for example, that you don't also generate a bounce message, or a notification 
> to the recipient.
>
> discard it" is intended to refer to a silent discard.

I don't think any of us expected the recipient to send a notification.  I 
certainly didn't, since the assumption would be that the message was 
probably from a hostile sender.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 02 Jun 2010 13:10:52 -0400

>direct, imply or request that the action be silent or noisy, and if noisy who 

IIRC, this is by design since there was no consensus around what exactly to do.  Personally, I tend to favor not having messages silently vanish.

Scott K

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 02 Jun 2010 20:20:45 +0200

> IIRC, this is by design since there was no consensus around what exactly to do.  Personally, I tend to favor not having messages silently vanish.

+1

As stated before, I have not followed the entire discussion on ADSP in 
depth, so please bear with me. I could not find relevant items in the 
archives, but has there ever been suggested to have a 'rejectable' in 
addition to 'discardable' and 'all'?

/rolf

---

From: Derek Diget <[email-masked]>
Date: Wed, 02 Jun 2010 14:05:23 -0400 (EDT)

Branching the discussion with regard to MLM subject tags.....

On Jun 1, 2010 at 18:43 -0000, John Levine wrote:
=>
=>>> > "The content of MLM modification of the subject tag is effectively
=>>> > replicating the List-ID value in a way visible to the recipient. This
=>>> > behavior was motivated by a lack of MUA support for displaying List-ID
=>>> > tags. It desirable for MUA to start supporting List-ID tags in order to
=>>> > deprecate this behaviour in MLMs."
=>
=>As Dave said, no.  Subject tags are a feature, not a bug.  I hope we
=>can resist repeating the mistake that many SPF advocates made of
=>claiming that any mail behavior that doesn't work with SPF is a bug in
=>the mail software rather than a limitation of SPF.
=>
=>>MLM behaviour is driven by client need. It is presumably there because MUA 
=>>can't or won't provide the desired functionality. MUA changes may remove the 
=>>need for DKIM incompatible MLM behaviour when clients have this function 
=>>served by their MUA.
=>
=>Maybe I'm suffering from a lack of imagination, but I can't parse this
=>in any way that makes any sense.  It might be saying that if MUAs
=>contained all the features of MLMs, we wouldn't have MLMs, but that's
=>just silly.

Not a direct reply to the discussion above, but the more general 
discussion of "upgrades" to MUAs....

* What about non-MUA filtering?  How many SIEVE/procmail filters live 
on systems that filter MLM streams by the subject tag?  "Upgrading" the 
MUA won't fix those filters.

Granted those filters can be updated to use the List-ID header too, just 
wanted to mention another place where they are used.

* What about MLM options where subscribers get to choose if they receive 
messages with the subject tag or not?  If the change to the Subject 
header by the MLM was the only thing that broke the DKIM signature, you 
have fragmented the issue so far discussed.  (I am new to ADSP so my 
thinking is probably off.)  How should the MLM handle the difference 
between those two subscriber types (non-subject-tag=valid DKIM signature 
v. subject-tag=broken DKIM signature) so that you have consistence 
deliverability?

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 02 Jun 2010 12:15:44 -0700

On 6/2/10 10:10 AM, Scott Kitterman wrote:
> "Dave CROCKER"<[email-masked]>  wrote:
>
The initial intent was to assert signing domain's policies rather than 
attempting any receiver recommendations.  In this vein, a better an 
alternative to "discardable" could have been 
"no-third-party-services-used" such as N3PS.  The "discardable" 
assertion did not emerge directly from the list.  John explained 
"discardable" as his response to phished domain's concerns of being 
flooded with NDNs.  ADSP did not produce a flood, as seen by the 
phisher's reactions of avoiding exact matches.

Rather than asserting author domain signing policies, ADSP could be 
changed into offering receiver recommendations, which "discardable" 
attempts.  Perhaps "all" could change to "non-deliverable".  However, 
could this result in bounces, in addition to rejections.  After all, not 
all receivers evaluate DKIM prior to acceptance.  Should these 
recommendation be "rejectable" and remain silent about accepted 
messages?  To avoid this quagmire, the WG concluded that ADSP was to 
state the domain's signing policy.   Clearly, "discardable" represents a 
clear departure.  Will "discardable" ultimately prove helpful?  It has 
already caused many to ignore handling for "all", since "all" lacks the 
concise instruction offered by "discardable".  It seems "discardable" is 
in danger of ensuring an unproductive outcome for ADSP.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 2 Jun 2010 15:43:26 -0600

+1

Also, there's documented precedent within the IETF.  RFC 863 has a clear definition: "A discard service simply throws away any data it receives."  RFC 5321 (and 2821, and 821) applied that definition to email, with specifics for programmers:

> 2.3.6.  Buffer and State Table
> 
>    SMTP sessions are stateful, with both parties carefully maintaining a
>    common view of the current state.  In this document, we model this
>    state by a virtual "buffer" and a "state table" on the server that
>    may be used by the client to, for example, "clear the buffer" or
>    "reset the state table", causing the information in the buffer to be
>    discarded and the state to be returned to some previous state.

5321 uses "discard" or "discarded" in other places, too.

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Jun 2010 15:36:10 -0700

> Also, there's documented precedent within the IETF.  RFC 863 has a clear
> definition:
...
>> 2.3.6.  Buffer and State Table
...
> 5321 uses "discard" or "discarded" in other places, too.

Well, one must always respect the lawyerly exercise of doing an audit to find
precedent.

But there's some distance between respect and agreement.

The problem is that an existence proof is quite different from being able to
assess/predict dominant human interpretation of the term.

In other words, just because someone, somewhere, sometime used the word in a
particular way, it says nothing about what most people, most of the time, will
take it mean.  I thought the issue here was the latter, not the former.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Jun 2010 13:27:28 -0700

> Subject: Re: [ietf-dkim] Lists "BCP" draft review

Hi Daniel, sorry for the less-than-timely reply.

Some specific replies to points you made, and then I'll work the rest into the next draft revision.

> that any incompatibilities anywhere will be obvious the the sender
> domain. As
> gaining statistics and experience is a dominate objective of this
> working
> group getting report forwarding done by verifiers so senders have a
> full
> picture is essential.

I'm not sure that this is the right place to refer people to the MARF work on DKIM failure reporting.  Generally it's a concept that would be of use to all senders and requires participation of all receivers, and isn't specific to mailing lists.

Perhaps it would be appropriate for an appendix.

> Another idea based on what Barry said was to introduce a section of why
> MLM
> break signature and potentially dkim compliant practices that could be
> achieved in the medium to longer term. An attempt at this has been
> incorporated into the current section 3.3.

Do you have a summary of either set of practices?  (Those being things MLMs do that break signatures, and things MLMs could do to provide the list-specific information people want without breaking signatures.)  That would be extremely helpful here.  You're right, I've tried to do that in 3.3, but I've only got my own experience plus feedback from one other person to go on so far.

> Specific components of the draft:
> 
> section 1.1
> 
> add to list of questions:
> 
> "What options exist for a recipient verifying a message?"
> 
> minor: I tend to think this current list of questions omits the
> significance of
> the end recipients' options in decision making based on dkim signatures
> and
> this is discussed in the draft.

Absent any kind of formal definition that binds a DKIM signature's "d=" tag to something specific to the list (such as a domain in a List-* header field) I don't think there's much advice we can provide here that DKIM itself doesn't already say.  Until then, a list signature is just another third-party signature.

> section 1.2
> 
> insert as 1.2 before the current 1.2:
> 
> "1.2 DKIM / ADSP failure reporting
> [...]

I think this would be useful advice in general, but your specific case depends on work being done in a different working group and possibly on a different schedule.

Would it be sufficient to make a more general reference to DKIM feedback mechanisms?  Or is it safe to make a reference to an I-D as a "work in progress" and proceed from there?

> replicating
> recipients
> to create a new header field to describe the desired behaviour and for
> MUAs to take note of this header field."

I think I agree with Dave that we shouldn't make a vague reference to future work.  The focus here is making DKIM work in the current context.

I'd be happy to help with such an effort if you'd like to start one.  I'm skeptical about its success due to MUA development inertia, but then I had the same concern about MLMs and it has been allayed somewhat.

> significant: explores options in changing MLM behaviour, that while is
> not
> going to happen in any hurry may end up occurring eventually. I
> acknowledge
> that the bit on attachment filtering alternatives isn't complete.

While discussing helpful MLM behavior changes is certainly useful, the recommendations of this document should probably presume those aren't going to happen in the short term and thus only be limited to DKIM-specific things.

> could be

I wonder if collecting all of the sentiments about MLMs and MUAs and their respective changes to improve the situation overall should be collected in an appendix.  It seems to be a common thread in conversation though.  I'll try it from that angle.

Thanks again!

-MSK

---

From: Daniel Black <[email-masked]>
Date: Sun, 27 Jun 2010 15:35:55 +1000

> > From: Daniel Black [mailto:[email-masked]]
..
> > Incorporate ARF/draft-ietf-mark-dkim-reporting as strong
> > recommendations...
> 
> I'm not sure that this is the right place to refer people to the MARF work
> on DKIM failure reporting.  Generally it's a concept that would be of use
> to all senders and requires participation of all receivers, and isn't
> specific to mailing lists.
> 
 
ok - it seems like a particularly useful for MLM that will incur failure as 
people try to generate filtering rules taking DKIM into account.

> Do you have a summary of either set of practices?  

I think the list you had with the small additions pretty much covers it.

> Absent any kind of formal definition that binds a DKIM signature's "d=" tag
> to something specific to the list (such as a domain in a List-* header
> field) I don't think there's much advice we can provide here that DKIM
> itself doesn't already say.  Until then, a list signature is just another
> third-party signature.

If there is nothing we can offer the recipient is there a usefulness?

> I think this would be useful advice in general, but your specific case
> depends on work being done in a different working group and possibly on a
> different schedule.
> 
> Would it be sufficient to make a more general reference to DKIM feedback
> mechanisms?  Or is it safe to make a reference to an I-D as a "work in
> progress" and proceed from there?

I'd like the explicit reference. Its a useful spec to say this is what a 
feedback mechanism is rather than people missing it or relying on their own.

> I think I agree with Dave that we shouldn't make a vague reference to
> future work.  The focus here is making DKIM work in the current context.

ok

> I wonder if collecting all of the sentiments about MLMs and MUAs and their
> respective changes to improve the situation overall should be collected in
> an appendix.  It seems to be a common thread in conversation though.  I'll
> try it from that angle.

that could be useful.

> Thanks again!

Thank you.