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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 May 2010 11:01:54 -0700

I've posted an individual submission draft that attempts to capture some of the consensus and some appropriate guidance around the use of DKIM in the context of mailing lists.  I don't propose that it's final at all, but merely an anchor point for further discussion.

http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/

Would the WG like to bring it in and make it a WG document?  If so, I volunteer to act as editor.

-MSK

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 10 May 2010 14:51:01 -0400

I read about half of it (duty called) and think Murray has created a
good first draft. Given the nature of the topic it would be appropriate
for it to be brought in as a WG document with Murray as the editor.

Just my 2 cents.

Mike

P.S. I'll save any nit-picking for later when I have a chance to review
it more closely.

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, May 10, 2010 2:02 PM
To: [email-masked]
Subject: [ietf-dkim] Lists "BCP" draft available

I've posted an individual submission draft that attempts to capture some
of the consensus and some appropriate guidance around the use of DKIM in
the context of mailing lists.  I don't propose that it's final at all,
but merely an anchor point for further discussion.

Would the WG like to bring it in and make it a WG document?  If so, I
volunteer to act as editor.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Mon, 10 May 2010 13:43:01 -0700 (PDT)

This looks good. Ok to become a WG document 

Pity we may need a separate document for "forwarding" or can this notion be included in the current document? 

Also can parts be more normative than informational? ie what a MLM MUST do when supporting DKIM. 

From: "Murray S. Kucherawy" <[email-masked]> 
To: [email-masked] 
Sent: Monday, 10 May, 2010 11:01:54 AM 
Subject: [ietf-dkim] Lists "BCP" draft available 

I’ve posted an individual submission draft that attempts to capture some of the consensus and some appropriate guidance around the use of DKIM in the context of mailing lists. I don’t propose that it’s final at all, but merely an anchor point for further discussion. 

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 May 2010 13:53:14 -0700

Whether or not this document is normative vs. informative is up to the WG really.  I’d be fine with either, though there’s the argument that we should start with something informational (non-normative) first and then upgrade it to BCP (normative) later.

I’d argue that the practices for forwarding fall under the aliasing-style MLMs as the mechanism is identical.  Perhaps we could say so here.

From: Franck Martin [mailto:[email-masked]]
Sent: Monday, May 10, 2010 1:43 PM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [ietf-dkim] Lists "BCP" draft available

-MSK

---

From: John Levine <[email-masked]>
Date: 10 May 2010 21:47:04 -0000

>volunteer to act as editor.

Yes, please.  I'll be happy to help.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 10 May 2010 15:28:15 -0600

> This looks good. Ok to become a WG document

+1

> Pity we may need a separate document for "forwarding" or can this notion be included in the current document?

It's complex enough with all the different ways that MLM-style remailing can be implemented.  Single-address forwarding is clearly related to /some/ of those methods, but not all, so I think confusion would be even more certain if we included that too.

> Also can parts be more normative than informational? ie what a MLM MUST do when supporting DKIM.

That brings up the strange question of what "supporting DKIM" is.

I think we could write normative language for what MLM software MUST NOT do if it wants to pass DKIM-signed messages through unscathed.  We could also write normative language for what MLM software MUST do if it wants to sign the messages itself (that's pretty obvious.)  But it's all the places in between that get complicated -- particularly when MLM developers are (in my experience) notoriously slow to add features.

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

---

From: Steve Atkins <[email-masked]>
Date: Mon, 10 May 2010 15:24:05 -0700

> http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/

Looks good.

What's described there as an "authoring" mailing list manager isn't really what I think of as a mailing list, and there's not that much to say about it compared with the other sorts discussed. If it simplified things it could be dropped without affecting the rest of the document, I think.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 May 2010 16:55:38 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of J.D. Falk
> Sent: Monday, May 10, 2010 2:28 PM
> To: IETF-DKIM WG
> I think we could write normative language for what MLM software MUST
> NOT do if it wants to pass DKIM-signed messages through unscathed.  We
> could also write normative language for what MLM software MUST do if it
> wants to sign the messages itself (that's pretty obvious.)  But it's
> all the places in between that get complicated -- particularly when MLM
> developers are (in my experience) notoriously slow to add features.

I think your second paragraph gave the definition that answers the first:

An MLM "supports DKIM" (or "is DKIM-friendly", to use some earlier language) if it either (a) doesn't do any message modification that would generally invalidate an author signature, or (b) re-signs mail upon re-posting it, or (c) both (a) and (b).

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 10 May 2010 17:20:07 -0700

On 5/10/2010 3:24 PM, Steve Atkins wrote:
> What's described there as an "authoring" mailing list manager isn't really
> what I think of as a mailing list, and there's not that much to say about it
> compared with the other sorts discussed. If it simplified things it could be
> dropped without affecting the rest of the document, I think.

I don't think of it as a mailing list, either, but apparently some folks in 
industry do.  Hence, including this case ensures that there is no confusion with 
readers.  The incremental cost of including it is pretty small.

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: Mon, 10 May 2010 17:22:22 -0700

On 5/10/2010 2:28 PM, J.D. Falk wrote:
> I think we could write normative language for what MLM software MUST NOT do
> if it wants to pass DKIM-signed messages through unscathed.

Seems an odd thing to make normative, since all that is entailed is not breaking 
the signature, and the details of what goes into a signature are in the base 
DKIM signing spec.

This actually winds up arguing for not worrying about the subtleties or niceties 
of normative language and instead just trying to provide discussion that is 
largely tutorial.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 10 May 2010 17:39:16 -0700

> An MLM "supports DKIM" (or "is DKIM-friendly", to use some earlier language) if it either (a) doesn't do any message modification that would generally invalidate an author signature, or (b) re-sign…
This draft has not offered a reasonable solution for ADSP policy 
assertions of From email addresses having valid Author Domain Signatures.

It is unreasonable to:

A) assume ADSP policies will be applied by mailing lists. (Most don't.)

B) assume mailing lists will not damage DKIM signatures. (Most do.)

Section 4.1 third paragraph states:
,--

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.

'--

The protective goal underlying restrictive ADSP policies in blocking 
potentially deceptive messages is not provided by this strategy. Use of 
alternative domains represents a very bad practice as this leaves 
recipients even more vulnerable to look-alike ploys once the practice 
becomes common.  No benefit is derived by not pursing a better 
solution.  In fact, greater harm seems likely.

-Doug

---

From: John Levine <[email-masked]>
Date: 11 May 2010 01:02:29 -0000

> I’d argue that the practices for forwarding fall under the
> aliasing-style MLMs as the mechanism is identical.  Perhaps we could
> say so here.

I'll bet I can get a 50 message thread going arguing about whether and
how the bounce address should change, with at least 10 of the messages
pointing out that DKIM doesn't look at the bounce address.

You are of course correct that they both have the same implications
for DKIM (none, unless the signer is actively perverse), but when has
that stopped us?

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 11 May 2010 10:50:09 +0100

--On 10 May 2010 15:24:05 -0700 Steve Atkins <[email-masked]> 
wrote:

>> I’ve posted an individual submission draft that attempts to capture
>> some of the consensus and some appropriate guidance around the use of
>> DKIM in the context of mailing lists.  I don’t propose that it’s
>> final at all, but merely an anchor point for further discussion.
>>
> What's described there as an "authoring" mailing list manager isn't
> really what I think of as a mailing list, and there's not that much to
> say about it compared with the other sorts discussed. If it simplified
> things it could be dropped without affecting the rest of the document, I
> think.

It's just another MSA, isn't it? Granted, one can often use an MLM for 
announcements only, but those would not fit into this category for purposes 
of the present discussion. I agree that this type of list manager isn't 
really relevant here, because it's not going to break any DKIM signatures. 
However, a statement to that effect would not hurt. And, it should be made 
clear that we're NOT talking about a "resending MLM" used as an 
announcement list (ie, with a very restricted list of permitted senders).

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

---

From: Serge Aumont <[email-masked]>
Date: Tue, 11 May 2010 16:37:45 +0200

On 05/10/2010 08:01 PM, Murray S. Kucherawy wrote:

I’ve posted an individual submission draft that
attempts to capture some of the consensus and some appropriate guidance
around
the use of DKIM in the context of mailing lists.  I don’t propose that
it’s
final at all, but merely an anchor point for further discussion.

That's a nice document. I would have be very glad to read it when I
started DKIM implementation for Sympa. Sympa MLM  already respect
almost all ideas described in this draft (see DKIM Sympa reference
manual chapter : http://www.sympa.org/manual_6.1/dkim ).

-Sympa include DKIM signature verification and use DKIM signature
status in the process of message submission and email commands

-it remove broken pre-existing DKIM signature and keep others as is
(not all messages are processed in way that brake signature)

-it reject message comming from  author ADSP record is discardable
and if the process of message by the MLM brakes signature. This prevent
brodcasting of a message that should be discarded by final recipients.

-it add it's own signature (on per list configuration parameter)

-it sign MLM services messages and digest.

- etc

I notice a good idea :  as Sympa verify incomming DKIM signature it
should add a [AUTH-RESULTS] header field ; this header should be part
of the DKIM signature added by the MLM engine. I will add this feature
in Sympa in a near future.

Section 4.2

"Verifiers that receive mail bearing DKIM signatures that fail to
verify might benefit from attempting to detect that such mail passed
through a non-participating MLM and then decide not to apply [ADSP] in
order to avoid aggressive filtering of mail that should otherwise have
been delivered.".

This proposition may introduce a security issue : spammers could fake
an sender email and a MLM engine in order to bypass ADSP from a
particular domain. This proposition is a limit of what "ADSP
discardable" mean. If we accept this idea that the final verifier may
not test ADSP because the message comes from an non DKIM MLM, "ADSP
discardable" is not usefull anymore. We all known that the use case of
"ADSP discardable" is really limited.

Please remove this paragraph from this draft.

Section 3.4

At last, another idea usefulness is that draft in   :

"A possible mitigation to this incompatibility is use of the "l=" tag
to bound the portion of the body covered by the body hash, but this has
security considerations (see Section 3.5 of [DKIM])."

The "l=" tag is one of the worth idea of DKIM if introduced because of
message body footer added by some MLM. MLM must not add anything after
the end of a message because this break Mime content. When adding a
footer, MLM should add an extra mime part, and this often require to
modify mime headers. So "l=" tag should not ne considered as an
efficient way to protect DKIM signature.

I known that the problem is comming from rfc-4871 but I  propose to
remove this sentence from this draft.

Serge Aumont

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 May 2010 10:10:24 -0700

> From: McDowell, Brett [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2010 9:51 AM
> To: Murray S. Kucherawy
> I'm an IETF newbie, so correct me if I'm wrong.  But it seems you are
> only asking the binary question of whether the WG is willing to add
> this deliverable to it's scope, with your draft as a strawman, and you
> acting as the editor.  You are not asking us if we have rough consensus
> on the contents of the document in its current form.  Correct?

Yes, that's right.  (And I'm not sure you meant "strawman" so much as "skeleton"...)

> From what I see on the list, there is clear consensus that this
> document should be produced as a WG document (which I support as well).
> So can we consider that question closed?

That's up to the chairs, but I suspect we have enough agreement to move forward.  There is the incomplete matter of re-chartering though.

> Now that it's a WG document, what's the review process... do we just
> chime in with comments and suggested edits on this thread?

Once it's official, I'll go back and plow through the huge recent threads about DKIM and lists and try to distill things the document needs, as well as soliciting feedback explicitly.  You're welcome to start commenting right away if you like.  (Everybody else has!)

-MSK

---

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 11 May 2010 10:51:06 -0600

> Would the WG like to bring it in and make it a WG document?  If so, I volunteer to act as editor.

I'm an IETF newbie, so correct me if I'm wrong.  But it seems you are only asking the binary question of whether the WG is willing to add this deliverable to it's scope, with your draft as a strawman, and you acting as the editor.  You are not asking us if we have rough consensus on the contents of the document in its current form.  Correct?

>From what I see on the list, there is clear consensus that this document should be produced as a WG document (which I support as well).  So can we consider that question closed?

Now that it's a WG document, what's the review process... do we just chime in with comments and suggested edits on this thread?

-- Brett

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 May 2010 10:48:47 -0700

On 5/11/10 7:37 AM, Serge Aumont wrote:
Serge,
> and if the process of message by the MLM brakes signature. This 
> prevent brodcasting of a message that should be discarded by final 
> recipients.
Why limit rejection to ADSP "discardable" and not include ADSP "all"?
Why would it be okay to accept messages having ADSP "all" that lack a 
valid Author Domain Signature?

BTW, ADSP "discardable" does not imply the desire to have messages 
rejected, especially from a MLM application running post acceptance.
> in Sympa in a near future.
In respect to Auth-Results, when is it safe to assume MLM applications 
ensure compliance with ADSP?

> "ADSP discardable" is really limited.
Agreed.  When ADSP requires alternative domains to be compliant with 
third-party services, this lessens security.  Essentially, this approach 
requires recipients to ignore the From header and to pay attention to an 
unseen DKIM signature perhaps without an indication of it being valid.
> Please remove this paragraph from this draft.
How would removing this paragraph change signing behaviors in a way that 
improves security?

>
>       *Section 3.4*
>
> At last, another idea usefulness is that draft in *  :*
> to bound the portion of the body covered by the body hash, but this 
> has security considerations (see Section 3.5 of [DKIM])."
>
Would you also suggest a practice of not altering the Subject line, or 
of not providing uniform message formats?

It seems unlikely there is a desire to have these features removed from 
most mailing-lists.

Would you be interested in an alternative mechanism requiring the same 
overhead as for ADSP, that eliminates a need to change any MLM handling?

If ADSP is worth doing, why is it not worth doing in a way that 
increases security?

s/brake/break/

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 11 May 2010 14:37:04 -0600

> What's described there as an "authoring" mailing list manager isn't really what I think of as a mailing list, and there's not that much to say about it compared with the other sorts discussed. If i…

I think it should stay, primarily as a way to prevent confusion from people who think the "authoring"/one-way-blast MLM is the only important use of email.  (I'm sure you know some people like that....)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 May 2010 13:29:16 +0100

On 05/11/2010 06:10 PM, Murray S. Kucherawy wrote:

> That's up to the chairs, but I suspect we have enough agreement to move forward.  

Agreed.

> There is the incomplete matter of re-chartering though.

Right. Doing that now.

Stephen.

---

From: Serge Aumont <[email-masked]>
Date: Mon, 17 May 2010 11:47:11 +0200

> Why limit rejection to ADSP "discardable" and not include ADSP "all"?
"ADSP = discardable" means  : "the domain encourages the recipient(s) to
discard it.". So a pretty MLM should discard thoses messages unless it
is able to brodcast it to subscribers without DKIM signature alteration.
"ADSP = all" does not recommend to drop thoses messages.

If think it would be an error to recommend that MLM handles  "ADSP =
all" in the same way as they handle email with "discardable" domain. If
so "ADSP = all" will have a very poor difference with  "ADSP =
discardable" a very very low number of domaines will use such ADSP policy.

> ensure compliance with ADSP?
It can be useful to add an header that prove the  MLM as verified the
DKIM signature and ADSP compliance of the incomming message. This can be
done in a safe way adding an [AUTH-RESULT] header included in the new
DKIM signature.

> If ADSP is worth doing, why is it not worth doing in a way that 
The "l=" seems to be ignored by every DKIM users. It's interest is
really limited. My opinion is that we should not recommend its usage
because it is not MIME compatible. MIME is an very old standard
implemented by almost every mail products. "l=" tag is an hack in DKIM
introduced only for dirty MLM software that still ignore MIME and will
probably ignore DKIM for a long time ;-). It should be forgotten !

Serge

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 May 2010 13:36:20 +0200

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

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 17 May 2010 13:55:30 +0200

+1

> probably ignore DKIM for a long time ;-). It should be forgotten !

I see my messages get a dkim=pass for my signature when they come back 
from the (few) mailing lists I'm subscribed to that don't remove 
signatures, because of the "l=". That is to say, IME it works as 
advertised.

As for signing MIME messages, I agree DKIM is broken, because it is 
legal to alter even the MIME preamble. The discussion on a 
MIME-compatible canonicalization algorithm has been moved to ASRG, and 
I look forward to going about it in the near future.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 May 2010 12:20:42 -0700

> "ADSP = all" does not recommend to drop thoses messages.
ADSP  "discardable" modifies SMTP acceptance assurances by encouraging 
ADSP evaluation failures be discarded rather than generate rejections or 
DSNs.  The lack of an Author Domain signature in conjunction with "all" 
assertions still represents an ADSP evaluation failure!  Invalidation of 
Author Domain signatures will result in subsequent ADSP evaluation 
failures.   ADSP "discardable" is not the only actionable assertion 
since "all" may also cause invalid Author Domain signatures to not be 
delivered.
> discardable" a very very low number of domaines will use such ADSP policy.
The difference between "all" and "discardable" is whether a rejection or 
DSN is expected when a message is not delivered.  That represents a 
sizable difference!

A mailing list that accepts messages containing From domains asserting 
"all" or "discardable" will not be in compliance when Author Domain 
signatures are made invalid by message modifications.   Interpretations 
that suggest only "discardable" provides actionable assertions leaves 
DKIM as offering protection only in conjunction with inherently 
unreliable services.  :^(
>> rejected, especially from a MLM application running post acceptance.
Should any invalid Author Domain signature for domains asserting "all" 
or "discardable" cause mailing lists to not distribute the message?

Discarding a message is limited to domains asserting "discardable", but 
ADSP "all" failures may also result in messages not being delivered!   
Under what conditions is it safe to accept ADSP "all" failures?  It 
would be much safer to allow domains seeking ADSP protection to 
determine specific exceptions.
> It can be useful to add an header that prove the MLM [has] verified the
Should receiving MTAs know whether mailing list applications:
  a) remove spoofed Authentication-Results headers,
  b) make reasonable modifications to messages,
  c) and properly evaluate Author-Domain signatures?

What grace period should MTAs allot for new mailing lists?

Is ADSP "all" protection a function based upon interactions between 
users and MUAs?  When would a user or MUA know whether it is safe to 
make ADSP failure exceptions for messages from unknown mailing lists?

An authorization scheme would allow domains seeking protection to 
indicate in each case whether they deem it safe to accept messages not 
compliant with "all" or "discardable" assertions.
Agreed.

-Doug

---

From: John Levine <[email-masked]>
Date: 18 May 2010 05:41:26 -0000

>discardable" a very very low number of domaines will use such ADSP policy.

Agreed.  We have no idea what "all" means in practice, other than perhaps
an ill-defined small decrement to some sort of reputation if the signature
isn't present.

R's,
John

---

From: John Levine <[email-masked]>
Date: 18 May 2010 05:08:13 -0000

>was not signed?  Do I want to confer more authority to that message than 

Yes, of course.  The signature means that this message really truly
came from the mailing list, as opposed to being a random piece of spam
that happened to resemble list mail.  What else would it mean?  Lists
have never promised that the original sender was "real" nor that
messages aren't edited on the way through.

I like Murray's draft, and I hope that we can resist the urge to add
vast amounts of non-productive complication to it.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 18 May 2010 02:18:55 -0400

> Lists never have had DKIM to deal with, so they've never had the option to 
> make any such promise.  The signature lends the MLM's credibility to the 
> message, which in turn could hurt the MLM's credibility if it turns out to be 
> signing garbage.  How else would a reputation for signers work?

Once again we return to this strange assumption that list managers will 
supinely allow garbage to flow through their lists, yet go to great effort 
to apply clever signature hacks so their recipients can recognize that 
same garbage.  The lists I've been using for the past 35 years have used a 
variety of techniques, some automated and some manual, to manage the stuff 
that gets onto the list and keep the garbage out in the first place. 
Does anyone expect that to change?  Why wouldn't a list just do whatever 
it does to manage its traffic, and then sign all its outgoing mail, so you 
can recognize mail from the list?  It might well add DKIM to the 
repertoire of techniques used to filter the incoming mail, but that's no 
more evident (mechanically at least) to the recipients than any of the 
filtering techniques they use now.  And if a list does lousy message 
management and does leak garbage, wouldn't you want the list and its 
signature to have a poor reputation?

> The MLM wants to signal to the recipient the veracity of the origin.

Nothing personal, but there is not a shred of evidence that any list has 
any such intention.  If it were important for lists to verify that the 
contributor's address were "real", they would be verifying and applying 
S/MIME signatures.  The fact that there's no A-R like thing to tell 
whether an S/MIME signature used to verify suggests that it's not 
something anyone's wanted to know.  I want to know whether an incoming 
message is from a list to which I subscribe.  But I don't try to second 
guess the way the list owners manage the lists now, and I see no reason 
why DKIM would change that.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 May 2010 07:51:58 +0200

John,

> messages aren't edited on the way through.

Lists never have had DKIM to deal with, so they've never had the option 
to make any such promise.  The signature lends the MLM's credibility to 
the message, which in turn could hurt the MLM's credibility if it turns 
out to be signing garbage.  How else would a reputation for signers work?

The MLM wants to signal to the recipient the veracity of the origon.  
That's why Murray's approach in the draft is to add an A-R header, which 
he states in the draft goes beyond A-R's intent in terms of trust.  An 
alternative would be to simply not sign the message.

Eliot

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 May 2010 10:40:05 +0100

> is able to brodcast it to subscribers without DKIM signature alteration.

No, it (or it's foreground MTA) should reject the message at SMTP time, on 
the grounds that it can't be sure to deliver it.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 May 2010 11:39:13 +0100

--On 18 May 2010 10:40:05 +0100 Ian Eiloart <[email-masked]> wrote:

> No, it (or it's foreground MTA) should reject the message at SMTP time,
> on  the grounds that it can't be sure to deliver it.

Of course, if the DKIM signature is good, and the return-path is in the 
signing domain, then it's probably OK to generate a bounce.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 18 May 2010 13:06:41 +0200

> for this or can we change it?

Would you expand on that, please? In particular, it doesn't seem 
misused to me, according, e.g., to wikipedia's definition[1]

  Feedback loop - the causal path that leads from the initial
  generation of the feedback signal to the subsequent modification of
  the event

and its application to email[2]. What "already common" acceptation do 
you mean?

For MLMs, there is a tradition of equating a feedback signal to an 
unsubscribe request, thereby preventing the possibility to use a 
list-specific FBL for cooperative list maintenance. Section 1.3 does 
not mention this, but conveys the idea that abuse reports should be 
routed differently when reported messages belong to lists.

-- 
[1] http://en.wikipedia.org/wiki/Feedback
[2] http://en.wikipedia.org/wiki/Feedback_Loop_(email)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 18 May 2010 14:55:14 +0200

On 18/May/10 07:08, John Levine wrote:
> that happened to resemble list mail.

+1. However, may I ask how does the verifier know which signature is 
the one that belongs to the list? I can think of

* look at the MAIL FROM domain, à la SPF (breaks forwarding),
* have the list's domain in a white list (requires maintenance),
* use some of the "List-*" fields (which one?)

Apparently, section 5.4 doesn't cover this point.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Deutschmann <[email-masked]>
Date: Tue, 18 May 2010 07:49:51 -0700 (PDT)

> an ill-defined small decrement to some sort of reputation if the signature

If I were in charge, I'd retire "all", to be replaced with two new
options with clearer semantics.  One would be the "except-mlist" I
proposed a few months back.

The other would be "rejectable".  "rejectable" would indicate that all
missing/bogus signature mail is to be rejected -- the reciever is not to
worry about the possibility that the message went through a mailing list.

"rejectable" would differ from "discardable" only in the case of a
validator that has no ability to reject in-transaction.  The most obvious
case would be a DKIM-checking plugin for an MUA using POP3 with a
DKIM-unaware ISP.

"discardable" would tell the MUA that it is ok to simply drop invalid
messages.  "rejectable" would indicate that, should it be impossible to
send the problem message backwards, it is better to let it go forward to
the end user than to blackhole it.

"discardable" would be the choice for those paranoid about phishing in
their name.  "rejectable" would be for those who are eligible to use
"discardable", but prefer not to risk mail *silently* disappearing should
a bug cause the signature to appear bad to some receivers.

Sending a bounce message would comply with the spirit of rejectable, but
that is not wise in general as the internet is beginning to punish
backscatter.  Unless the problem message's MAIL FROM: is independently
proved valid (eg: by SPF), discarding or delivery are the only choices a
late-acting validator has.

(One note referencing things upthread:  Back when I proposed
"except-mlist", most objections were on the basis that there is no
*automatic* way for the reciever to implement it differently from
"unknown"; only vanity-domain recipients can benefit.  But it would be
correct for a mailing list input mailserver to treat "except-mlist" as
"rejectable", since lists don't mail to each other.)

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 18 May 2010 17:10:28 -0000

>proposed a few months back.

I don't understand what verifiers are supposed to do with that.  How
is an MTA doing the DKIM verification and filtering supposed know
what's a mailing list and what's not?  If I were a bad guy, I'd put
fake headers on my spam to make it look like a list mail.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 18 May 2010 13:16:42 -0400

> It'll be the one that's not broken, I presume. If there's more than one 
> unbroken signature, I guess the signing domain might want to match the 
> list-id header.

Why is it important to match signatures?  If there's a valid signature 
with a good rep, deliver the mail.  If the mail turns out to be nasty, 
decrease the rep of all of the valid signatures.  Why make this more 
complicated than it needs to be?

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 May 2010 18:10:46 +0100

--On 18 May 2010 14:55:14 +0200 Alessandro Vesely <[email-masked]> wrote:

>>>>      A DKIM-aware resending MLM is encouraged to sign the entire
>>>>      message as it arrived, especially including the original
>>>>      signatures.
>>>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 May 2010 11:12:00 -0700

> complicated than it needs to be?
Signed messages might be replayed in a spam campaign.  Many copies of a 
signature's hash would be normal for mailing lists.

When a mailing-list signature provides greater acceptance, wouldn't this 
lead to mailing lists being exploited?

How should new signatures be handled?

If your wish for ADSP "except-mlist" is granted, how would a domain's 
recipients protect themselves exploits or spoofs of mailing lists?

Perhaps there should also be "except-signed-mlist"?

Wouldn't a non-specific mailing list exception lead to mailing list 
being targeted?

Why can't "all" represent "reject" as you described?  Is your concern 
that "all" creates an obligation for mailing list to either reject or 
bounce messages lacking valid Author Domain signatures?  How many MTAs 
check DKIM signatures during the SMTP session?  How many invalid 
signatures would normally seen by mailing-lists?

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 18 May 2010 13:22:22 -0600

+1

Likewise, I hope that we can resist the urge to re-argue all the old arguments about ADSP.  This BCP won't fix those issues, but it might clarify 'em somewhat.

---

From: Michael Deutschmann <[email-masked]>
Date: Tue, 18 May 2010 13:46:28 -0700 (PDT)

> fake headers on my spam to make it look like a list mail.

1. "except-mlist" is primarily for the benefit of vanity domain
recipients who have programmed their MTA with knowledge of exactly which
lists they are subscribed to.  Just guessing which list to forge is a big
hurdle for the bad guys.

*I* recognize friendly mailing lists by their MAIL FROM: domains, which
means SPF will also be an obstacle to such forgers.

But yes, big ISPs that know no details about their users have to treat
"except-mlist" as "unknown".  But they still gain, because they will know
everyone who publishes "rejectable" really means it.

2. As I touched on in a parenthetical at the end of the message, mail heading
to a mailing list *input* can be processed as if "except-mlist" was
"rejectable".  Lists don't subscribe to other lists.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 May 2010 15:50:19 -0700

> means SPF will also be an obstacle to such forgers.
The ADSP effort started by agreeing not to dictate how messages are to 
be handled,  and to assume administrators are able to take correct 
actions.  The assertion "discardable" muddled an expectation of 
competence, where some now suggest "all" lacking a valid Author Domain 
signature does not empower "rejection".

MTAs are to ignore invalid Author-Domain signatures with "except-mlist" 
assertions.  Vanity, or otherwise, it is not difficult to defeat SPF, to 
find mailing-lists offering one-time access, or to create messages 
appearing to be from some mailing-list where the message lands in the 
inbox.
> "except-mlist" as "unknown".
>    
Agreed,  and "except-mlist" declares open season on mailing-lists, and 
perhaps any message that has ever touched one.
> But they still gain, because they will know
All messages are "rejectable", especially when "all" assertions lack 
Author Domain Signatures.   Why would you see "rejectable" as being 
different from "all" assertions?  There is no ADSP assertion that makes 
it clear which messages are _really_ from mailing lists.
> "rejectable".  Lists don't subscribe to other lists.
How would this be any different from recommending mailing-lists to 
reject ADSP "all" assertion lacking a valid Author-Domain signature?   A 
recommendation might also suggest tolerance be given mailing lists.  A 
better alternative would be to use a third-party authorization 
mechanisms to curtail exploits caused by the knowledge gap.

-Doug

---

From: Michael Deutschmann <[email-masked]>
Date: Tue, 18 May 2010 17:18:17 -0700 (PDT)

On Tue, 18 May 2010, Douglas Otis wrote:
> Why would you see "rejectable" as being different from "all" assertions?

Just about everyone thinks EITHER that "rejectable" would be redundant
with "all", OR that "except-mlist" would be redundant with "all".  But
narrowing "all"'s meaning down to two choices is not an agreement.

This ambiguity is paralysing deployment - a conservative sender who means
"except-mlist" must publish "unknown", and a conservative receiver who
sees "all" must read it as "except-mlist" (and thus as "unknown" in most
cases due to ignorance of local users' subscriptions.).

Rather than try to settle the fight over what "all" means, let's just
deprecate it and give each camp their own, *unambiguous* flag.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 May 2010 18:04:57 -0700

On 5/18/10 5:28 PM, Stephen Farrell wrote:
> That doesn't seem to be about mailing lists.
>
> I don't see that we're re-opening ADSP now and we're not
> chartered for that, so I don't really see much point in
> this discussion.
>
> So perhaps take that discussion offlist?
>    
Stephen,

Deprecating "all" to "except-mlist" and "rejectable" is about dealing 
with message state changed by mailing lists.  Without this state change, 
there would not be an issue.  IMHO, the suggestion for changing ADSP 
assertions does not resolve the uncertainty, but instead creates risks 
related to mailing list operation, when they then become exploitation 
targets.

Perhaps John and Michael are right, and people need explicit 
instruction.  Nevertheless, these instructions should not be spelled out 
in ADSP assertion mnemonics.  That is the purpose of the RFC being 
discussed.   I agree, the chartered work is not aimed at changing the 
spelling of ADSP assertions, but instead at explaining how they are best 
used.   A rose by any other name would still smell as sweet.

P.S. It turned out leaving Ireland was not as hoped.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 May 2010 01:28:20 +0100

Stephen.

On 05/19/2010 01:18 AM, Michael Deutschmann wrote:
> with "all", OR ...

---

From: John Levine <[email-masked]>
Date: 19 May 2010 02:52:01 -0000

>lists they are subscribed to.

If you already know what lists you're subscribed to, why would you do
anything other than accept all the mail from the lists?

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 May 2010 11:44:33 +0200

>>  unbroken signature, I guess the signing domain might want to match the

Unfortunately, that header does not make a net distinction between the 
list-label and the domain-name. Perhaps, the list-label could be made 
explicit using the local part of the "i=" tag (RFC 5672 exemplifies a 
"mailing list manager" for this datum.)

> complicated than it needs to be?

To recommend any special treatment for mailing lists --e.g. tweaking 
FBL routes-- we should also say how a verifier can recognize a list 
message when it sees one.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 19 May 2010 11:09:26 +0100

> anything other than accept all the mail from the lists?

And conversely reject everything from lists you are not subscribed to  
(which will likely include the ones invented or appropriated by the Bad  
Guys).

My MUA detects and displays separately all mailing list message (by the  
presence of List-* headers). If an unfamiliar mailing list shows up (as  
occasionally happens), it sticks out like a sore thumb.

-- 
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: Michael Deutschmann <[email-masked]>
Date: Wed, 19 May 2010 03:49:30 -0700 (PDT)

> anything other than accept all the mail from the lists?

True, vanity domains likely won't bother to treat "rejectable"
differently than "except-mlist".  The only difference is in a case that
shouldn't happen.

But the advantage of "except-mlist" to vanity domains is that *many* more
senders are eligible to publish it.  They would otherwise use "unknown".

With the status quo, vanity domains can only protect themselves from
forgeries of:
  1. The minority of senders who truly send to no mailing lists
  2. Senders who recklessly assume that "all" is universally treated
     as "except-mlist"

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 19 May 2010 09:53:06 -0400

> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, May 18, 2010 8:28 PM
> To: Michael Deutschmann; Douglas Otis

+1. The current discussion was supposed to be about BCP. I agree with
Stephen with the caveat that if the group thinks re-opening ADSP
discussion is important then include it in the re-charter. Personally
I'd like to wait until we hear some numbers about ADSP deployment and
experience.

Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 19 May 2010 15:21:48 -0600

+1

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 19 May 2010 15:35:06 -0600

On May 19, 2010, at 3:29 PM, Michael Thomas wrote:

> On 05/19/2010 02:21 PM, J.D. Falk wrote:
> Doesn't that sort of undermine the impetus to do a BCP on lists?
> Most of the sticky questions about lists are intertwined with ADSP,
> as evidenced by the recent messages here from paypal folks.

If writing the BCP reveals situations where ADSP makes DKIM difficult for mailing lists, let's document it so that a future effort can work on fixing it.  We shouldn't be trying to fix it within the BCP effort.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 May 2010 14:31:42 -0700

> Sent: Wednesday, May 19, 2010 2:22 PM
> To: DKIM List

+1.  (Or at least change the Subject: field!)

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 May 2010 14:29:08 -0700

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 May 2010 14:44:37 -0700

> If writing the BCP reveals situations where ADSP makes DKIM difficult for mailing lists, let's document it so that a future effort can work on fixing it.  We shouldn't be trying to fix it within th…

I'm not suggesting we fix anything, I just find it odd the juxtaposition of "no adsp experience"
with "Let's do a BCP about lists". ADSP experience is a pretty important component for the
"common practices" part of BCP because it's the source of lots of conflict, and we frankly
don't have any common practices, best or otherwise. It seems that this would be a whole lot
more interesting if the paypal folks could give a report about their experience with the
way they're dealing with this when they're ready.

Mike

---

From: Michael Deutschmann <[email-masked]>
Date: Thu, 20 May 2010 04:25:32 -0700 (PDT)

> I'd like to wait until we hear some numbers about ADSP deployment and

Well, if RFC 5617 (current official ADSP) is to be regarded as engraved
in stone, writing a list BCP seems trivial to me:

There's just two options:

1. Must take ownership of the header From: -- change it to something in
the list operator's domain.

2. Should DKIM-sign the outgoing message.

3. Should only accept mails that pass DKIM/ADSP validation, treating
"all" as what I call "rejectable".  (List input mailboxes don't need to
worry about whether "all" means "rejectable" or "except-mlist", because
lists don't subscribe to lists).

Or:

1. Must relay message verbatim.  No subject tags, disclaimers, or "how
to unsubscribe" footers.  But new headers above the DKIM signature can
be ok.

2. Must only accept mails that pass DKIM/ADSP validation, again treating
"all" as my "rejectable".

After selecting an alternative, breaking any of its musts will risk mails
getting blocked, so long as anyone publishes dkim=all (regardless of what
they *mean*), and anyone interprets dkim=all as my "rejectable".

Neither sounds that palatable to list operators.  Which one is
mipassoc.org going to use?

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 20 May 2010 10:09:43 -0400

> [email-masked]] On Behalf Of Michael Thomas
> Sent: Wednesday, May 19, 2010 5:29 PM
> To: J.D. Falk
> Cc: DKIM List

Let me clarify my statements. My point was that re-opening ADSP was not
part of the re-charter so unless the group feels it is important to
change ADSP we should stick to discussing the Lists BCP based on the way
that DKIM and ADSP are currently written. 

If Brett or anyone else has data points that would impact the decision
as to whether the group sticks to a Lists BCP discussion based on
current practice/implementations or sets that aside to modify ADSP, now
is the time to present it. 

>From my perspective, it would have to be very compelling for me to
support modifying ADSP at this point. ADSP is the DKIM tail and not vice
a versa.

Mike

---

From: John Levine <[email-masked]>
Date: 20 May 2010 18:22:33 -0000

>support modifying ADSP at this point. ADSP is the DKIM tail and not
>vice a versa.

Entirely agreed.  As this point the only concrete datum I'm aware of
is that ADSP has been observed to break IETF mailing lists.  I would
want to see a lot more practical as opposed to hypothetical experience
before offering further advice.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 20 May 2010 14:42:59 -0400

> From: John Levine [mailto:[email-masked]]
> Sent: Thursday, May 20, 2010 2:23 PM
> Cc: MH Michael Hammer (5304)

That's ironic, I heard it the other way around.... that many mailing
lists break DKIM signatures and thus ADSP..... go figure <G>.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 May 2010 14:08:36 -0700

John,

Your advise is generally good, but not in respect to "all".   Rather 
than weakening MTA acceptance barriers imposed by DKIM+ADSP "all" or 
"discardable", these barriers need strengthening.  ADSP "all" is 
intended to mitigate the significant harm caused by phishing.  It is not 
reasonable to expect recipients will know whether a message contains a 
mailing list related headers that might defeat ADSP protections.   ADSP 
"all" or "discardable" offers email service providers a clear basis to 
not deliver non-compliant messages.  Email service providers should 
ensure strict ADSP compliance.  While resorting to "discardable" might 
increase the number of non-complaint messages blocked, this is at the 
expense of delivery integrity, which "all" was to avoid.

To achieve greater compliance with "all" or "discardable", a legal 
imperative seems needed.  The "except-mlist" assertion offers 
potentially deceptive results, where the author domain needs to make 
explicit exceptions.  An ADSP "copyrighted" assertion along with an 
Author Domain Signature that includes a "(copyright)" comment should 
allow injured domains a means to seek expeditious compliance.   By 
creating a potential for needing to respond, email service providers 
would then likely become proactive and strictly adhere to ADSP 
assertions.  Those wanting to participate on mailing list would then 
need to use alternative domains, where perhaps the list subscription 
could ask about their desired ADSP compliance, with a checkbox or 
command "as currently signed".

-Doug

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 20 May 2010 16:01:34 -0600

> is the time to present it. 

A) I hear you and I'm working on making some confidential data publicly available for the first time.  It's more than a notion to achieve, but I'm working on it.  But if folks don't trust my anecdotal evidence/use case, why would they trust my data?

B) I'm going to re-subscribe to this (and all outside-the-firewall mailing lists) with a personal email address to avoid the current situation (of my messages going to SPAM or the bit bucket due to the firm ADSP=discardable policy on paypal.com and MLM's inability to sustain DKIM signatures in a form receivers need to see it in order to verify the paypal.com signature).  It's a temporary work-around and we are developing a long-term solution for our employees that I'll write about once it's live so other ADSP=discardable organization can learn from our experience.

C) I don't know if this list is the right place to discuss updating/expanding ADSP, but it is absolutely related and important in the big picture.  That said, I agree the BCP for MLM's is separate and needs to be published for the world as it is today, or it won't be published for quite some time.

-- Brett

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 21 May 2010 10:37:11 +0200

> to unsubscribe" footers.  But new headers above the DKIM signature can

If MLM software were smart enough to avoid adding subject tags and 
footers in case they are already present, then the list manager could 
ask subscribers who sport incompatible ADSP policies to carefully 
submit their posts, so that list processing won't break their author 
domain signatures.

> "all" as my "rejectable".

Yes, reject so that inattentive posters have a chance to amend their 
messages as required.

This second option seems simple enough to me.
-- 
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 22 May 2010 10:44:53 -0700

> lists break DKIM signatures and thus ADSP..... go figure<G>.

Well, I think both perspectives are valid and useful.  The "list breaks adsp" is 
perhaps the more intuitive view.

On the other hand, the purpose of a mailing list is to get a message delivered 
to a set of recipients.  An ADSP record for a subscriber will break their 
ability to get that mailing list message, which can reasonably be viewed as 
breaking the mailing list...

When talking about tradeoffs, this sort of inverted perspective can be quite 
helpful in understanding implications.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 22 May 2010 10:50:28 -0700

On 5/17/2010 10:08 PM, John Levine wrote:
>    The signature means that this message really truly
> came from the mailing list

Actually, DKIM makes no statement about authorship or even actors in the 
handling sequence.  It merely says that that verified domain is willing to take 
"some" responsibility for the message.

The more we slip into loose references to authorship or operational origins, the 
more we wind up having to dig ourselves out of semantic mismatches later.

If there is a desire and need to have the semantic be "came from the mailing 
list" then there needs to be a mailing list equivalent to ADSP, which correlates 
a DKIM signature with the domain in a List-ID header field.

d/
-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 23 May 2010 12:48:17 +0200

+1

---

From: Eliot Lear <[email-masked]>
Date: Sun, 23 May 2010 15:24:51 +0200

Hi Dave & John,

I read both of you as actually agreeing in principle.  My issue was 
whether a signature would confer more authority upon a message than 
perhaps it deserved, and how would an MLM behave in terms of its 
incentives.  In thinking about this, I'd have to say that you're both 
right, that either the MLM is taking responsibility for the message or 
it is not.  There may yet be a grey area for very sophisticated or 
experimental MLMs (like "Hmm... SpamAssassin medium score; maybe let it 
through but don't sign"), but then they don't need a BCP; we need them 
to publish the results of the experiment ;-)

The only thing that leaves are non-participant MLMs and there really 
isn't much to be done with them.

Eliot

---

From: "John R. Levine" <[email-masked]>
Date: 23 May 2010 12:35:48 -0400

> There may yet be a grey area for very sophisticated or experimental MLMs 
> (like "Hmm... SpamAssassin medium score; maybe let it through but don't 
> sign"), but then they don't need a BCP; we need them to publish the 
> results of the experiment ;-)

Quite right, and as always, the ASRG stands ready if someone wants to do 
some, you know, research.

> The only thing that leaves are non-participant MLMs and there really isn't 
> much to be done with them.

We have one concrete failure scenario, in which someone who publishes 
dkim=discardable sends mail to a MLM that as usual breaks the signature, a 
subscriber's mail system carefully follows the ADSP and rejects that mail, 
causing the subscriber to be bounced off the list.  (This really happened, 
on an IETF list.)  The advice is obvious a) put a shim in front of your 
MLM to reject discardable mail and b) the usual advice not to use ADSP at 
all, but it definitely needs publishing.

I'm surprised we haven't seen that problem on this list, since we have at 
least one subscriber whose domain publishes dkim=discardable.  I keep 
having to fish his mail out of the spam folder.

R's,
John

---

From: Roland Turner <[email-masked]>
Date: Mon, 24 May 2010 11:50:57 +0800

On 24/05/2010 00:35, John R. Levine wrote:

>
>> The only thing that leaves are non-participant MLMs and there really isn't much to be done with them.
>>      
Surely the stance of a dkim=discardable sender is that it is absolutely 
OK to discard affected messages if there is any reason at all for doubt 
and that, therefore, "non-participant" MLMs aren't, actually, breaking 
anything.

- Roland

---

From: Michael Deutschmann <[email-masked]>
Date: Mon, 24 May 2010 01:23:12 -0700 (PDT)

On Sat, 22 May 2010, Dave Crocker wrote:
> If there is a desire and need to have the semantic be "came from the
> mailing list" then there needs to be a mailing list equivalent to ADSP,
> which correlates a DKIM signature with the domain in a List-ID header
> field.

That's not necessary.

The weakness of the "except-mlist" approach is not the difficulty of
authenticating that a given mail really is from the list it purports to be
from.  We have off-the-shelf technology to do that: the list manager just
needs to use a constant MAIL FROM: domain, and protect that domain with
SPF.

It requires some cooperation from the list owner, but so would "LDSP".
Only if you have irrational Not Invented Here sentiments towards SPF does
LDSP become needed.  The SPF approach has the advantage that some lists
are already in compliance, by accident.

Rather, the weakness of "except-mlist" is that it requires that the MX
know which mailing lists each mailbox is legitimately subscribed to.
Without that, the badguys can pretend the victim subscribes to lists they
control.

Now, people keep arguing that "except-mlist" is pointless because no
regular ISP is so well informed about its own users.  But vanity domains
like mine *do have the needed intelligence*.

The only further knowledge they need, is which sites are publishing
"unknown" because they don't sign everything yet, and which sites are
publishing "unknown" solely because of the mailing list problem.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 24 May 2010 10:24:24 +0100

--On 23 May 2010 15:24:51 +0200 Eliot Lear <[email-masked]> wrote:

> through but don't sign"),

I don't see the value of that. By forwarding the mail, they are -in 
practice- taking responsibility. By signing it, they're simply telling the 
world that they've done so. I'd think it dishonest of a list manager to do 
this kind of selective signing.

> but then they don't need a BCP; we need them
>> handling sequence.  It merely says that that verified domain is willing
>> to take "some" responsibility for the message.
>>
>> The more we slip into loose references to authorship or operational
>> origins, the more we wind up having to dig ourselves out of semantic
>> mismatches later.
>>

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 24 May 2010 10:27:18 +0100

--On 23 May 2010 12:35:48 -0400 "John R. Levine" <[email-masked]> wrote:

> dkim=discardable sends mail to a MLM that as usual breaks the signature,
> a  subscriber's mail system carefully follows the ADSP and rejects that
> mail,  causing the subscriber to be bounced off the list.  (This really
> happened,  on an IETF list.)  The advice is obvious a) put a shim in
> front of your  MLM to reject discardable mail and b) the usual advice not
> to use ADSP at  all, but it definitely needs publishing.

The other piece of advice should be to actually discard, rather than 
rejecting, discardable email. That would have protected the subscriber from 
automatic unsubscription.

> having to fish his mail out of the spam folder.

I guess the list should be rejecting his email! Then, perhaps, his 
organisation would get around to deploying a non-discardable domain.

---

From: "John R. Levine" <[email-masked]>
Date: 24 May 2010 09:08:42 -0400

> organisation would get around to deploying a non-discardable domain.

I've suggested it.  They know they have a problem, but they won't yet say 
what they're going to do about it.

As you may recall, they suggested that lists sign an A-R header and all 
recipient systems track what lists they're subscribed to and do 
complicated processing to see whether list mail was signed when it showed 
up at the list.  Oddly, that didn't get much traction.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 24 May 2010 15:02:02 +0100

> up at the list.  Oddly, that didn't get much traction.

I do recall. Perhaps if the list (and other lists) were rejecting the mail, 
they'd be more likely to act. We don't have to wait for them, do we?

---

From: "John R. Levine" <[email-masked]>
Date: 24 May 2010 10:36:46 -0400

> they'd be more likely to act. We don't have to wait for them, do we?

Not at all.  If we can agree that lists should reject discardable mail out 
of self defense, that's a good point to add to the BCP.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 24 May 2010 15:41:19 -0000

>like mine *do have the needed intelligence*.

Not to keep beating a dead horse or anything, but I still don't see what
real life (as opposed to contrived) problem this is supposed to solve.

Bad guys have been trying to sneak unwanted messages onto mailing
lists since the era of Krazy Kevin.  List managers have developed a
variety of techniques to keep the bad stuff out, and there is no
reason to think that will stop.  The only utility I can see for this
hack is in a world where list managers don't do that.

Also, there are a lot of reasonable scenarios other than mailing lists
in which a legitimate message would arrive without its domain's
signature, with mail-an-article, and web mail that consolidates
multiple accounts being only two of the most familiar.  Your hack
doesn't address the general issue at all.

So give it a rest, please.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 May 2010 12:32:28 -0700

> needs to use a constant MAIL FROM: domain, and protect that domain with
The SPF element authorized is often poorly defined,  whose resolution 
can induce a large number of transactions against any third-party 
domain.  This is especially true when attempts search for the possible 
element.  Some now use SPF to signal reverse DNS PTR records having a 
defined label, which suggests cooperation among the 40,000 IP address 
owners.  However, deployment of IPv6 will cause SPF and reverse DNS to 
become vast and difficult to manage.

See: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03

This scheme provides a LDSP type of third-party authorization where an 
"L" flag signals a required list-id (see: RFC2919).
This scheme could even be extended to produce a policy similar to 
"except-mlist" along with an ability to make exceptions.

If a BCP recommends "discardable" be discarded by mailing lists, it 
should also recommend "all" be rejected as well.  Neither "all" nor 
"discardable" produces a compliant message when the Author Domain 
signature is invalidated.  (A flag added to DKIM signatures to signal 
the presence of TPA policies.)
> It requires some cooperation from the list owner, but so would "LDSP".
The TPA scheme does not require cooperation of list owners!

> Without that, the badguys can pretend the victim subscribes to lists they
The TPA scheme requires those seeking policy protections to provide the 
relationships for MX handling.   The "except-mlist" approach places the 
burden upon the MX to know which mailing lists are safe.   Unlike the 
TPA scheme, the "except-mlist" will not allow author domains a means to 
mitigate ongoing exploitation.

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 24 May 2010 17:19:35 +0100

--On 24 May 2010 10:36:46 -0400 "John R. Levine" <[email-masked]> wrote:

>> I do recall. Perhaps if the list (and other lists) were rejecting the
>> mail,  they'd be more likely to act. We don't have to wait for them, do
>> we?
>
> Not at all.  If we can agree that lists should reject discardable mail
> out of self defense, that's a good point to add to the BCP.
>

I think that's probably the most principled thing to do.

For self-protection, there's also the option of NOT sending the message 
with a VERPed sender address. That would mean that a subsequent rejection 
should not count against the recipient. If the list is using some other 
mechanism to count rejections, then that mechanism should not be used.

That option isn't so easy to deploy though, because it's performed after 
the signature is broken. And, there's no point sending the message because 
we can't expect that it will be delivered.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 May 2010 13:36:27 -0700

> and that, therefore, "non-participant" MLMs aren't, actually, breaking 

There's some risk that what a list thinks might be unrecoverable is not.
I guess I don't see it as being especially valuable to do anything heroic
in the middle of the mail path (= forwarders) rather than letting it be
done end to end (where end=delivery domain). The amount of traffic here
is tiny, and asking MLM's to do just about anything is in reality asking
for very fragmented adoption. So what's the use?

Getting MLM's to resign actually does something useful because you can
attach its reputation to the message. But adoption will be spotty for years
to come even if it's in their advantage.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 24 May 2010 13:41:37 -0700

+1

Refusing signups from those domains is probably a bit extreme, though.

> mechanism to count rejections, then that mechanism should not be used.

If the recipient is rejecting mail from the list, then the list should stop
attempting to send mail to that recipient. It should not try and guess
why the mail is no longer wanted. 

We really don't want people to use ADSP (or, much worse, DKIM) as
an excuse for not handling bounces nor for sending unwanted email.

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Mon, 24 May 2010 14:33:13 -0700

On May 24, 2010, at 2:28 PM, Murray S. Kucherawy wrote:

>> [email-masked]] On Behalf Of Steve Atkins
>> Sent: Monday, May 24, 2010 1:42 PM
>> To: DKIM List
> What about a warning at signup time if a "discardable" ADSP record is found for the registrant's domain?

Seems like a reasonable UX design to me but probably
more a choice for the developer than a BCP, I think.

(I think that refusing signups from ADSP using domains
may also be a reasonable choice for the developer or list
admin in some cases. But not something to put in a BCP.)

Cheers,
  Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 May 2010 14:42:55 -0700

On 5/24/10 1:41 PM, Steve Atkins wrote:
> > Not at all.  If we can agree that lists should reject discardable
> > mail out of self defense, that's a good point to add to the BCP.
>

Providing immediate feedback regarding a domain likely to cause 
recipients to miss their conversation should reduce the number of 
subsequent support issues.  Otherwise, lost conversations will likely 
generate complaints requiring detailed analysis to resolve.  Refusals 
for either "all" or "discardable" when the list is known to invalidate 
Author Domain signatures ensures list participants receive full 
conversations.

>  If the recipient is rejecting mail from the list, then the list
>  should stop attempting to send mail to that recipient. It should not
>  try and guess why the mail is no longer wanted.
>
>  We really don't want people to use ADSP (or, much worse, DKIM) as an
>  excuse for not handling bounces nor for sending unwanted email.

The "discardable" assertion does NOT mean a mailing list will see 
rejections.  Only the "all" assertion ensures this level of feedback.  
This is why it remains important to have "all" refused whenever 
"discardable" is discarded.   The concept of "discardable" was to offer 
just this type of excuse.

-Doug

>  Cheers, Steve
>
>  _______________________________________________ NOTE WELL: This list
>  operates according to http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 24 May 2010 14:28:49 -0700

> mail

---

From: John Levine <[email-masked]>
Date: 25 May 2010 01:38:53 -0000

>found for the registrant's domain?

That doesn't help.  In the IETF's scenario, domain A sent mail which
was marked discardable to the list, and recipients at domain B were
rejecting it and the people at B got bounced off the list.  I'd have
to squint awfully hard to come up with an argument that it is wrong to
reject unsigned discardable mail at SMTP time.

Since ADSP causes problems for innocent bystanders, I think it's
reasonable to decline A's mail in the first place.  This is doubly
true since the ADSP RFC rather specifically says that you shouldn't
mark a domain discardable if its users send mail to lists.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 May 2010 18:50:35 -0700

>   This is doubly

Only if you care about the mail being delivered. I think that if we do this
BCP, we should give some advice about what, say, a company like, oh say, paypal
ought to do consider if they want to set adsp discardable. Like:

   1) make people who want to contribute to lists on a the corpro accounts get
      a gmail account
   2) create new external/non-discardable accounts in a subdomain for that tiny
      fraction of the population that needs to post to lists from a corpro account
   3) etc.

Since this is a bcp, it doesn't have to be generalizable to every conceivable
setup; it's just advice for the common cases, which corpro and isp mail certainly
are.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 24 May 2010 18:55:39 -0700

> reject unsigned discardable mail at SMTP time.

I think that Murray was suggesting that in addition to rejecting all
mail from domain A it would be polite to also warn anyone from
domain A who subscribes to the list that their mail would be
rejected (which seems good UX design to me).
> mark a domain discardable if its users send mail to lists.

It causes no problems at all to innocent bystanders in that case - the
recipient at domain B is a willing participant who has chosen both
to pay attention to ADSP and to respond to it by rejecting, rather than
discarding, mails labeled "discardable". 

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 25 May 2010 14:01:57 +0200

> rejected (which seems good UX design to me).

That warning is an /alternative/ to refusing signups. The BCP 
distinguishes between participating and non-participating MLMs, and 
that warning belongs to the former kind. I'd expect a participating 
MLM has also fixed the double-footer problem, while most lists have no 
problems with double subject-tags. Hence, the warning may merely 
recall that posts from the discardable address will be rejected unless 
they include the correct footer, and the subject-tag appears exactly 
once, the latter especially for new posts. (Notice that such practice 
is may also help to avoid light-minded posts.)

We cannot suggest anything to DKIM-unaware MLMs. Hence, the "refuse 
signups" option, that would apply in this case, has to be put through 
by subscribers themselves.

> discarding, mails labeled "discardable".

That user will probably contact postmaster@B and ask for the relevant 
list to be whitelisted. If a list's operators seek such explicit 
whitelisting at their subscribers' MXes, then they might want to 
leverage ADSP that way.

BTW, is "discard" exactly synonym with "drop"? I'd recommend dropping 
mail only in cases of negligibly low FP rates _and_ high risk, e.g. 
viruses. Deliver-as-junk is used as a makeshift, and I tend to 
associate "discardable" with such behavior. Is that what RFC 5617 
means by it?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Brett McDowell <[email-masked]>
Date: Tue, 25 May 2010 09:08:09 -0400

On May 20, 2010, at 6:01 PM, McDowell, Brett wrote:

> B) I'm going to re-subscribe to this (and all outside-the-firewall mailing lists) with a personal email address to avoid the current situation (of my messages going to SPAM or the bit bucket due to the firm ADSP=discardable policy on paypal.com and MLM's inability to sustain DKIM signatures in a form receivers need to see it in order to verify the paypal.comsignature).  It's a temporary work-around and we are developing a long-term solution for our employees that I'll write about once it's live so other ADSP=discardable organization can learn from our experience.

This is just a quick follow-up to let folks know that I'll be using this personal account for public mail lists until we have addressed the "DKIM+ADSP=discardable breaks MLM's/MLM's break DKIM+ADSP=discardable" problem in a more systemic manner.  

-- Brett

---

From: Brett McDowell <[email-masked]>
Date: Tue, 25 May 2010 09:17:43 -0400

> automatic unsubscription.

The advice should be to discard the mail vs. bouncing it back to the MLM.  That solves the use case of subscribers being auto-unsubscribed to mail lists without undermining all the other use cases that led the IETF to standardize ADSP in the first place.

-- Brett

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 25 May 2010 11:43:28 +0100

--On 25 May 2010 01:38:53 +0000 John Levine <[email-masked]> wrote:

> That doesn't help.

It doesn't help if this is instead of rejecting the mail. But I don't think 
that was the intention. A message to this effect might be very useful: 
"You've joined the list, and will get messages from it. However, you can't 
post to the list using your email address because..."

Now, if the subscriber doesn't intend to post to the list, they're fine. If 
they do, then surely it's helpful to warn in advance that they can't.

> In the IETF's scenario, domain A sent mail which

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 25 May 2010 11:39:52 +0100

> admin in some cases. But not something to put in a BCP.)

Why not? At least mention that it might be polite to make such a warning. 
After all, the person signing up might have no clue at all that their 
domain is 'discardable'.

I guess we can't claim that it's common practice, never might best common 
practice. But it is, surely, a good idea.

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 25 May 2010 11:37:14 +0100

--On 24 May 2010 13:41:37 -0700 Steve Atkins <[email-masked]> 
wrote:

>> with a VERPed sender address. That would mean that a subsequent
>> rejection  should not count against the recipient. If the list is using
>> some other  mechanism to count rejections, then that mechanism should
>> not be used.
>
> If the recipient is rejecting mail from the list, then the list should
> stop attempting to send mail to that recipient. It should not try and
> guess why the mail is no longer wanted.

No, there are plenty of reasons that a recipient might reject *some* email 
from a list, but not the rest. For example, the recipient site might be 
more fussy about RFC compliance in the email. I've been unsubscribed from 
Yahoo lists because they relayed mail with ';' separating email addresses 
in sender headers.

> an excuse for not handling bounces nor for sending unwanted email.

No, and of course a site needn't reject ADSP mail with broken signatures. 
Indeed, to protect it's members from unwanted unsubscriptions, it might be 
better to drop the email than reject it. But, then the sender might never 
discover what they're doing wrong. If the recipient rejects the message, 
then the list should be able to bounce back to the sender, since it was 
originally properly signed.

>>...

---

From: Brett McDowell <[email-masked]>
Date: Tue, 25 May 2010 12:30:45 -0400

> what they're going to do about it.

I'll be happy to report on our decision once we've implemented it.  FWIW, I agree with the recommendations made on this list, at least in the short-term.  

Step one: was to start using anything that wasn't under an ADSP=discardable assertion (so here I am using a me.com account).  

Step two: is to do something along the lines of what's been recommended here (a non-discardable domain).  

Step three: fix the status quo for *participating* MLM's by offering up a new technical solution that enables MLM's to assert that they've validated the original sender's signature.  

> up at the list.  

That is a mischaracterization of what I proposed.  What I actually proposed was:

> On Apr 26, 2010, at 1:19 PM, McDowell, Brett wrote:
> 
>> On Apr 26, 2010, at 10:05 AM, MH Michael Hammer (5304) wrote:
>> 
>>> I think we are having the wrong discussion. The real question is:
>>> 
>>> "What are appropriate practices for mailing lists in handling DKIM
>>> signed mail?"
>> 
>> Agreed.
>> 
>> From my perspective, I'd like to enable (not mandate or expect universal compliance with) the deployment scenario where the sender's DKIM signature is either maintained without adulteration or "proxied" by the list so the transient trust can be carried through the mailing list intermediary to the destination (per Murray's note which I'm also going to respond to).  That's my use case.  By sharing this use case I'm not trying to deprecate or undermine John Levine's original use case.  But there is a diversity of valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to consider (which is why I'm so pleased to see Mike H. take our discussion in this direction).
>> 
>> -- Brett

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 25 May 2010 11:02:14 -0600

> rejected (which seems good UX design to me).

Yup, I think this would be an appropriate addition to the BCP document.

---

From: "John R. Levine" <[email-masked]>
Date: 25 May 2010 13:46:02 -0400

> Step three: fix the status quo for *participating* MLM's by offering up 
> a new technical solution that enables MLM's to assert that they've 
> validated the original sender's signature.

Not to pick on Paypal specifically, since this is a general failure of 
ADSP, but:

We want everyone to throw away mail from us that doesn't have our
signature.

no, wait, ...

We want everyone to throw away mail from us that doesn't have our 
signature EXCEPT if it has an A-R header showing that it was signed when a 
MLM received it.

no, wait, ...

We want everyone to throw away mail from us that doesn't have our 
signature EXCEPT if it has an A-R header showing that it was signed when a 
MLM received it AND it has a signature from the MLM to show it's actually 
from the MLM

no, wait, ...

We want everyone to throw away mail from us that doesn't have our 
signature EXCEPT if it has an A-R header showing that it was signed when a 
MLM received it AND it has a signature from the MLM to show it's actually 
from the MLM AND the signature is known to the recipient to sign mail from 
real MLMs.

no, wait, etc.

I entirely endorse Paypal's efforts to make it easy to identify their mail 
and easy to throw away the forgeries.  But you (and anyone else whose 
transaction mail is a forgery target) shoot yourself in the foot every 
time you make the message more complex, since that makes it less likely 
that people will go along.

In particular, all of the normal mail from paypal.com says one thing, log 
in and look at your account, so losing the occasional message isn't a big 
deal since you can find what it said on the web site.  Now you're saying, 
well, actually, there's some paypal.com mail that says other stuff that 
you can't reconstruct, and that mail may well show up without our 
signature.  Really, really, don't do that.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 May 2010 15:50:59 -0700

On 5/25/10 5:01 AM, Alessandro Vesely wrote:
> That warning is an/alternative/  to refusing signups. The BCP
It should be possible for sending domains to detect mailing-list 
conversations.  When desired, they can then immediately publish 
third-party authorization labels to allow ADSP exceptions.  The 
exception approach retains their ability to quickly mitigate any 
reported abuse.
>>> >>    mark a domain discardable if its users send mail to lists.
Disagree.  This suggests ADSP makes a deliver-ability distinction 
between "discardable" and "all".   It does not.  Appendix B makes a 
general statement about what might invalidate DKIM signatures, without 
mention of "discardable".  Appendix B.3 warns "discardable" may cause 
their email to be discarded (dropped), and makes no specific mention of 
mailing lists.  Appendix B.5 refers to _both_ "all" and "discardable" as 
causing significant breakage for messages sent through paths lacking 
Author Domain Signatures.
>> >  discarding, mails labeled "discardable".
ADSP "all" might be rejected, where ADSP "discardable" might be 
discarded.  Neither ensures delivery without an Author Domain Signature.

A reasonable use for "discardable" would be for domains that don't send 
email.  DSN of rejected mail should be used to report abuse and to 
escalate take-downs of illegal activity.  It is amazing ISPs feel safe 
in using reverse DNS PTR records to qualify their outbound servers, but 
then ignore clear evidence of wrong doing that should lead to a similar 
consequences for ignoring reported ADSP assertions that clearly indicate 
their lack of authorization.
> whitelisting at their subscribers' MXes, then they might want to
Why should some user be trusted?  Only the Author Domain should be 
allowed to make these exceptions.  Ideally this should be done with a 
single transaction mechanism.

SPF will not serve this role.  Often SPF must authorize servers carrying 
messages for thousands of domains.  By not knowing with certainty which 
email headers or parameters should be in compliance, and by not having 
border MTA IP addresses captured by Authentication-Results,  SPF is far 
less practical at mitigating abuse and potentially dangerous messages.  
On the other hand, ADSP in conjunction with a third-party authorization 
mechanism provides a clear and certain indication of non-complaint 
email, which should offer far greater protection with less overhead.

-Doug

---

From: Brett McDowell <[email-masked]>
Date: Tue, 25 May 2010 19:05:09 -0400

On May 25, 2010, at 1:46 PM, John R. Levine wrote:

> Not to pick on Paypal specifically, since this is a general failure of ADSP, but:

<snip>

Colorful, but those were not my/our words or sentiment.

>> From my perspective, I'd like to enable (not mandate or expect universal compliance with) the deployment scenario where the sender's DKIM signature is either maintained without adulteration or "pr…

There are mailbox providers who want to leverage email authentication technologies to protect their users from phishing.  I'm not making that up.  What we have done with Google and Yahoo! is well known, but who here actually believes those are the only two deployments in the world today (or in-process)?  

I don't think it's in the best interest of the Internet to leave these use cases with no alternative but to pursue closed, proprietary mechanisms.  It is my opinion that the standards community (if not IETF, then who?) could view these use cases as an opportunity to evolve the standards in a way that will gain more adoption and utility.  The only thing we would be doing is evolving the existing standards to enable -- not compel or coerce -- consumer protection use cases. 

Everything I've articulated since joining the mail list has been rooted in the concept of choice.  This authenticated messaging ecosystem is optional, not mandatory.  Any effort to make it mandatory is doomed.  So why not provide the option?  Why not spec out a means for MLM's to participate in a DKIM/ADSP=discardable flow in a way that supports consumer protection use cases?

-- Brett

---

From: "John R. Levine" <[email-masked]>
Date: 25 May 2010 19:18:30 -0400

> Once again, our use case is:

Maybe, I'm dim, but I don't see any practical difference between what 
you're saying and what I'm saying, other than perhaps that you have a far 
more optimistic idea of what people will deploy that doesn't directly 
benefit them.

Like I said, "throw away anything that doesn't have our signature" has 
some chance of broad adoption.  Every extra word you add to the message 
makes it less likely that people will do it.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 May 2010 16:46:36 -0700

> makes it less likely that people will do it.

"Don't deliver" rather than "throw it away" retains email integrity with 
feedback necessary for ceasing abusive sources.

For example, what prevents ISPs from publishing bogus PTR records in 
their reverse DNS entries?

Removing uncertainty of non-compliance better ensures how reports of 
abuse will be handled.  Uncertainty is caused by not allowing domains a 
means to unilaterally make exceptions on their behalf.  The information 
such an exception mechanism provides better conform to current email 
infrastructure, and will be safer to act upon.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 25 May 2010 20:43:39 -0400

>makes it less likely that people will do it.
I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. 

Scott K

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 26 May 2010 10:00:43 -0400

> discarding, mails labeled "discardable".

Perhaps I missed something, but if domain B is rejecting email from the list
Authored by A, then won't that cause a list member at domain B to be removed
from the list as well? I think that is what John meant by innocent
bystander. Most MLM remove subscribers after repeated bounces. I don't know
if they are smart enough to look into why the message bounced.

-- 
Jeff Macdonald
Ayer, MA

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 07:48:29 -0700

On May 26, 2010, at 7:00 AM, Jeff Macdonald wrote:

> 
> 
> On Mon, May 24, 2010 at 9:55 PM, Steve Atkins <[email-masked]> wrote:
> 
> Perhaps I missed something, but if domain B is rejecting email from the list Authored by A, then won't that cause a list member at domain B to be removed from the list as well? I think that is what John meant by innocent bystander. Most MLM remove subscribers after repeated bounces. I don't know if they are smart enough to look into why the message bounced.

That's exactly the issue, and not a theoretical one.

However, domain B is not an innocent bystander, as they intentionally configured their mail system to reject mail it shouldn't, and the recipients at domain B support that decision, on some level.

The mailing list operator is the one caught in the middle between two domains that have made bad decisions, so is an innocent bystander, but the level of inconvenience to them is pretty small, relative to the usual overhead of running a mailing list.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 May 2010 08:09:19 -0700

> However, domain B is not an innocent bystander, as they intentionally configured their mail system to reject mail it shouldn't, and the recipients at domain B support that decision, on some level.

Wait a minute. There's nothing wrong with discarding something set to discardable (cf, "shouldn't").
Or are you saying that it shouldn't produce a bounce/5xx and just silently discard it?

Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 08:17:37 -0700

> Wait a minute. There's nothing wrong with discarding something set to discardable (cf, "shouldn't").

Yup. They didn't do that, though.

> Or are you saying that it shouldn't produce a bounce/5xx and just silently discard it?

Exactly.

If they would otherwise deliver the mail, and the reason they decided not to was because of a combination of an ADSP-discardable record and the lack of a DKIM signature then they should silently discard the mail.

(If you're about to reject or bounce a mail for some other reason and happen to notice that it's discardable mail that's a quite different issue, and one we've not really talked about.)

Cheers,
  Steve

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 26 May 2010 11:32:09 -0400

On Wed, May 26, 2010 at 11:17 AM, Steve Atkins <[email-masked]>wrote:

> >>>> Perhaps I missed something, but if domain B is rejecting email from
> the list Authored by A, then won't that cause a list member at domain B to
> be removed from the list as well? I think that is what John meant by
> innocent bystander. Most MLM remove subscribers after repeated bounces. I
> don't know if they are smart enough to look into why the message bounced.
> >>
> >> However, domain B is not an innocent bystander, as they intentionally
> configured their mail system to reject mail it shouldn't, and the recipients
> at domain B support that decision, on some level.
> >

Ah, and somehow I missed this part in your earlier message:

'rather than discarding, mails labeled "discardable". '

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 May 2010 08:38:09 -0700

> If they would otherwise deliver the mail, and the reason they decided not to was because of a combination of an ADSP-discardable record and the lack of a DKIM signature then they should silently di…

I don't think that we've ever come to any consensus on whether it should be silently
discarded or not. I can see reasons for both arguments, but given that we've also talked
about fbl reports back to the discardable domain that seems rather circuitous in the
non-list case.

Mike

---

From: Brett McDowell <[email-masked]>
Date: Wed, 26 May 2010 10:45:14 -0400

> I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third…

I agree that adding anything to "throw away anything that doesn't have our signature" add complexity to implementation and therefore, by definition, is a barrier to adoption.  That's not what we are debating.  What we are debating is whether such complexity is a necessary evil that we should provide a specification to support -- as an optional mechanism for stakeholders who want to opt-in to the authenticated email ecosystem.  I *think* the answer is "yes".  But we haven't yet had the meaningful debate that will resolve that question.

Let's debate whether transient trust through a MLM is actionable.  Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make any difference in the deliverability of that message to the receiver, and if yes, is that actually a good thing?  I say "yes" and "yes".  But I expect that if we debate this specific point one of you might highlight an unintended consequence that would tip the balance away from pursuing such a model.  

Thoughts?

-- Brett

---

From: SM <[email-masked]>
Date: Wed, 26 May 2010 08:09:00 -0700

Hi Doug,
>exception approach retains their ability to quickly mitigate any

I don't have a clue how to implement this.  I can implement measures 
for the mailing lists I am subscribed to but it doesn't scale.  Due 
to legacy reasons it would be impossible to "fix" the local-part anyway.

The short answer I would give is that it is not possible for the 
signer to detect mailing list conversations [1].

Regards,
-sm

1. http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html

---

From: Brett McDowell <[email-masked]>
Date: Wed, 26 May 2010 11:40:24 -0400

This is a good example of a tradeoff that I think would benefit from some agreed upon principles.  If we agreed to the following two principles, I think we'd all find a lot more common ground:

1) Authenticated email is optional, not required
2) We desire to fully enable the functionality of the authenticated email ecosystem, but
3) We will do nothing with the authenticated email architecture that forces non-participating email stakeholders harm/breakage/errors

If we agree to that then I believe it opens up some opportunities and clarifies why we would have rough consensus on some of the major issues that have been under debate for a few weeks now.

For example: In the past I have argued that the receivers should simply not bounce DKIM+ADSP=discardable messages back to the MLM.  But that position assumes the receiver is participating in the authN email ecosystem.  The principles listed above would lead me to change that position.

Thoughts?

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 May 2010 09:59:05 -0700

> Let's debate whether transient trust through a MLM is actionable.  Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make…

Aesthetically I like the idea of some way for the MLM to tunnel authentication information through to the recipient.

But I don't think it's clear that doing so would change anything at the recipients MX. As a concrete example, if two subscribers to a mailing list send mail to the list, one DKIM signed and one not, and the list then signs each message and sends it to the recipient, is there any reason that the recipients MX would treat those two messages differently?

Cheers,
 Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 May 2010 10:39:44 -0700

> Sent: Wednesday, May 26, 2010 8:18 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] more on discardable, was Lists "BCP" draft
> 
> If they would otherwise deliver the mail, and the reason they decided
> not to was because of a combination of an ADSP-discardable record and
> the lack of a DKIM signature then they should silently discard the
> mail.

I don't think we can talk about "right" or "wrong" actions based on DKIM and ADSP because the language of RFC5617 is so soft with respect to the actual message disposition.

The BCP can only provide advice about what has been observed to work, or what the WG believes will work.

And I think we need to be very specific about "silently discard" if that's the practice we want to espouse.  That's not something RFC5321 really suggests either.  RFC5617 doesn't define what "discard" means, leaving the receiver open to choose to deliver to the spam folder, reply 250 but send it to the bitbucket, or reply 5xy, or even 4xy.

For that matter, the same goes for "all".

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 May 2010 14:03:49 -0700

On 5/26/10 8:09 AM, SM wrote:
> for the mailing lists I am subscribed to but it doesn't scale.  Due to 
> legacy reasons it would be impossible to "fix" the local-part anyway.
See:
http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03

DKIM is a process handled by domain administrations, not individuals.  
The third-party label authorization method scales to _any_ practical 
level,  and allows domain administrators a means to unilaterally resolve 
reported issue involving third-party services.  Whether these issues 
relate to abuse or to refused and missing messages, the third-party 
authorization scheme offers an easy and low overhead solution.  Perhaps 
in the future, mailing-list subscription acknowledgments could be 
standardized to trigger any needed third-party authorization.

Of course, there should be facilities, such as user web pages, to deal 
with potential refusal issues proactively.  Exchanges of DKIM keys with 
any number third-party services clearly does not scale, nor would this 
be practical.
> signer to detect mailing list conversations [1].
When the domain administration receives DSNs or MARFs indicating a 
problem, they should also be able to recognize whether it involves a 
trusted third-party service based upon content.  A third-party 
authorization method offers a practical means to extend ADSP "all" with 
a method to mitigate possible disruptions.  IMHO, "discardable" should 
be limited to domains not sending mail.

As a side note:

Rather than using ADSP "discardable", it would be better to a mandate 
the use of MX records.  BNAME zones will soon make the use of address 
records to discover MTAs impossible.  As such, the Address Record 
discovery should be depreciated.

Secondly,

Not delivering non-ADSP complaint email protects recipients, especially 
those sorting From headers, which is a technique that offers protection 
from look-alikes.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 May 2010 17:04:48 -0400

>Let's debate whether transient trust through a MLM is actionable.  Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make a…
That's not quite the question. 

Such transient trust can't be spoofable. It needs to have properties such that if it asserts "trust me, it was signed by PayPal when I got it,  so you can ignore their discardable flag" it can't be used by arbitrary senders to bypass PayPal's ADSP.

I don't know of a way to do that which doesn't require a trust relationship with the mail list provider. If you have such a relationship then it's relatively trivial to just not bother with ADSP checks for mail from such lists.

I'm left not knowing what advantage there would be from a more complex standardized approach. 

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 May 2010 14:23:16 -0700

On 05/26/2010 02:04 PM, Scott Kitterman wrote:
>
>
> "Brett McDowell"<[email-masked]>  wrote:
>

Right, and where I have problems is that I doubt that most admins have any clue whatsoever
which lists their users subscribe to. Some certainly have policies which may inform them
(= don't do it), but beyond that this sounds somewhere close to an impossible task.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 May 2010 14:55:30 -0700

> I don't know of a way to do that which doesn't require a trust relationship with the mail list provider. If you have such a relationship then it's relatively trivial to just not bother with ADSP ch…
Agreed.  Author Domains use "all" or "discardable" to help recipients 
deal any number of bogus messages.  Since Author Domains may have an 
interest in retaining trust, domains should also be able to indicate 
their relationships with third-party services unable to furnish 
Author-Domain signatures.   Perhaps ADSP "all+tpa" might better signal 
such an extension of trust.  Clearly, mailing lists represent reasonable 
examples of where sharing DKIM keys represents an impractical solution.
> I'm left not knowing what advantage there would be from a more complex standardized approach.
A conservative domain would retain trust by limiting their 
authorizations to vetted third-parties.  A DKIM specific authorization 
scheme would give senders a clear voice in how their messages lacking an 
Author-Domain signature are expected to be handled.   With this 
information, recipients would not need to guess or to consult gurus in 
how a specific service's messages should be handled.  This burden would 
be placed upon the trusted sender.  DKIM specific authorization would be 
an infrequently used mechanism managed fully by those having the 
greatest interest in mitigating abuse that might otherwise obscure their 
messages.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 May 2010 17:53:24 -0700

On 5/26/10 2:23 PM, Michael Thomas wrote:
> >> I don't know of a way to do that which doesn't require a trust
> >> relationship with the mail list provider. If you have such a
> >> relationship then it's relatively trivial to just not bother with
> >> ADSP checks for mail from such lists.
> >>
>  Right, and where I have problems is that I doubt that most admins
>  have any clue whatsoever which lists their users subscribe to. Some
>  certainly have policies which may inform them (= don't do it), but
>  beyond that this sounds somewhere close to an impossible task.

Domains that assert ADSP "all" or "discardable" are assisting recipients 
who might be inundated with messages spoofing their From domain.  This 
assistance can be extended by also indicating which employed third-party 
service may benefit from Author Domain signature exceptions.  Every 
increase in the number of sources granted a policy exception represents 
an increased opportunity for exploitation.

For example, specific authorizations of communications via mailing lists 
run by standard's organizations, or NGOs, would offer recipients far 
better security, than would resorting to unlimited numbers of different 
email domains having undefined authentication polices.

While much can be said for reputation services, they are not good at 
preventing abuse from otherwise reputable sources.  An authorization 
scheme for ADSP greatly reduces a domain's exposure within an 
environment seeing a growing diversity of abuse.

Importantly, a DKIM specific authorization scheme places the burden of 
retaining trust on the sender, where it belongs.   If you agree with 
this, stop kvetching. :^)

No one requires senders to defend their recipients.  Allowing ADSP to be 
more comprehensive with a simple and deterministic authorization 
mechanism, enables greater use and provide a stronger rationale for 
employing these policies.

-Doug

"The significant problems we face cannot be solved at the same level of 
thinking we were at when we created them."
"Make everything as simple as possible, but not simpler."
   -- *Albert Einstein*

---

From: SM <[email-masked]>
Date: Wed, 26 May 2010 21:11:42 -0700

Hi Doug,
>http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03

I read that draft.  Are there any plans for an implementation?  By 
the way, the question is not to brush you off.

>authorization method offers a practical means to extend ADSP "all" 
>with a method to mitigate possible disruptions.  IMHO, "discardable" 
>should be limited to domains not sending mail.

I'll stay out of the "discardable" and "all" discussion for now.

>Rather than using ADSP "discardable", it would be better to a 
>mandate the use of MX records.  BNAME zones will soon make the use 
>of address records to discover MTAs impossible.  As such, the 
>Address Record discovery should be depreciated.

I prefer not to comment. :-)

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 May 2010 03:20:49 -0700

Hi Subramanian,

Thank you for your comments.

On 5/26/10 9:11 PM, SM wrote:
> I read that draft.  Are there any plans for an implementation?  By the 
> way, the question is not to brush you off.
Murray suggested that at one time, he might be willing.  It seems better 
to first arrive at understanding the need.

The draft includes open code that is needed to generate the tpa labels, 
and has been tested on few systems.  The draft was aimed at illustrating 
how domain based authorization schemes could implemented without 
imposing an inordinate number of transactions.  Since this scheme is 
only needed to handle a small number of exceptions not practically 
avoided, its impact should be slight.

The third-party scheme could also protect vanity domains signed by major 
providers who confirm ownership prior to signing, i.e. gmail.
Why would unilateral authorization be troubling, since these are also 
infrequent?

In this way, individuals would also be allowed to stray off the 
reservation, provided they get permission. :^)

-Doug

---

From: Roland Turner <[email-masked]>
Date: Thu, 27 May 2010 18:35:00 +0800

On 25/05/2010 18:37, Ian Eiloart wrote:

> discover what they're doing wrong.

Worse, such a configuration would do collateral damage: other "broken 
ADSP" cases (forwarders which aren't mailing-lists in the sense that 
we're describing) would lead to silent message loss.

> If the recipient rejects the message,

Ideally, but without a reliable indication by the receiver that the 
refusal was for DKIM failure, there's no easy way for the MLM to know 
which bounces to return to the sender.

- Roland

-- 
   Roland Turner | Director, Professional Services Group
   BoxSentry Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
   Mobile: +65 96700022 | Skype: roland.turner
   [email-masked] | http://www.boxsentry.com/

---

From: Roland Turner <[email-masked]>
Date: Thu, 27 May 2010 18:21:51 +0800

On 26/05/2010 22:48, Steve Atkins wrote:

> configured their mail system to reject mail it shouldn't, and the 
> recipients at domain B support that decision, on some level.

Domains don't subscribe to mailing lists, individual recipients do. The 
recipients in a domain may oppose the domain[-administrator]'s decision, 
but often lack the power to have it changed. "Failure to quit your job" 
cannot reasonably be construed as consent/support in this context.

- Roland

---

From: Roland Turner <[email-masked]>
Date: Thu, 27 May 2010 18:29:51 +0800

> 3) We will do nothing with the authenticated email architecture that forces non-participating email stakeholders harm/breakage/errors

That would be three principles, and I think they're sound.

This does leave us somewhere rather unpleasant for:

- sender from a discardable domain sends to a mailing list, despite the 
advice being not to
- the MLM is a non-participant
- a subscriber is rejecting messages which fail DKIM authentication 
(conservative stance: avoid silent failures causing mail loss)
- the MLM unsubscribes the recipient for [multiple] refusals

In this case, a participating-but-conservative receiver cops collateral 
damage because of incorrect/ill-advised behaviour by a sender. This is 
an undesirable outcome.

I'd strengthen #3 with unrelated harm/breakage/errors should not arise 
from participating stakeholders behaving conservatively.

- Roland

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 May 2010 07:28:13 -0400

>cannot reasonably be construed as consent/support in this context.

This just brings us back to the "Do domain owners have a right to control how their domains get used in email" question. 

If they do, the point is irrelevant. 

If they don't,  email authentication policy is wrong and we should just stop.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 May 2010 06:21:51 -0700

> cannot reasonably be construed as consent/support in this context.

So this problem is obviously larger than just discardable. This
can happen any time a list member gets a piece of mail that the filter
in the receiving domain finds objectionable for *whatever* reason. So
what we're really talking about is a 5822 problem, not a DKIM/ADSP problem.

So the question is, in my mind, should the receiver just silently discard
it which breaks reliability but allows the MLM to do nothing special, or
should the receiver bounce/5xx it back. To my mind, if the MLM is going to
do something as drastic kick the receiving user, it ought to at least be
open to a 5xx explanation that it's the mail in question that's the problem
instead of blindly giving the user X number of 5xx's before they're declared
a nuisance and kicked.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 27 May 2010 07:35:42 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Thursday, May 27, 2010 6:22 AM
> To: Roland Turner
> Cc: DKIM List
> Subject: [ietf-dkim] bad mail blowback
> 

This is something the lists BCP could discuss.  Perhaps something like: bounces with enhanced status codes of 5.7.1 should not be counted against the recipient as they are done for message-specific policy reasons and not for something more general.

(I might have the "5.7.1" wrong, but you get the idea.)

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 May 2010 07:49:01 -0700

> (I might have the "5.7.1" wrong, but you get the idea.)

Considering that this is really a 5822 level problem, I have my doubts that a DKIM/ADSP
targeted document is the right place to bury this kind of advice. And I'm also skeptical
that we have the right set of eyes looking at this in this working group because this is
certainly a very old topic and it would be stupid of us to come out with advice that goes
against or without the consent of the much larger smtp community.

On the other hand, if the larger email community already has a normative or BCP solution
to this which we can just restate, then that's great. (which might be what you're getting at).

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 27 May 2010 07:53:37 -0700

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, May 27, 2010 7:49 AM
> To: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] bad mail blowback
>  

I think it's appropriate since ADSP is creating the problem (or in your view, extending the existing problem).

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 27 May 2010 11:07:06 -0400

> [email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, May 27, 2010 7:28 AM
> To: DKIM List
> This just brings us back to the "Do domain owners have a right to
control
> how their domains get used in email" question.
> 
> If they don't,  email authentication policy is wrong and we should
just
> stop.

+1

---

From: SM <[email-masked]>
Date: Thu, 27 May 2010 07:54:10 -0700

Hi Doug,
At 03:20 27-05-10, Douglas Otis wrote:
>Murray suggested that at one time, he might be willing.  It seems 
>better to first arrive at understanding the need.

Don't read anything in here as a statement of support for the draft.

Convince Daniel to write the code. :-)  It can be committed as a FFR.

>The draft includes open code that is needed to generate the tpa 
>labels, and has been

That's not how the project works.  Someone has to do the work and 
help the users when they have questions.  Obviously, any comments 
from marketing departments are discouraged.

>Why would unilateral authorization be troubling, since these are 
>also infrequent?

Once the code is out there, it may be easier to find an answer to 
that question.

Regards,
-sm

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 27 May 2010 11:24:25 -0400

> (I might have the "5.7.1" wrong, but you get the idea.)

Ah, my type of tangent. I think 5.7.1 is right. Ideally, in the
future, it would be a 5.8.z. But before even that, we need more folks
to support RFC3463.

---

From: SM <[email-masked]>
Date: Thu, 27 May 2010 10:05:38 -0700

>Considering that this is really a 5822 level problem, I have my 

5322. :-)

>against or without the consent of the much larger smtp community.

There's a discussion of local policy in Section 6.3 of RFC 
4871.  I'll emphasize the first sentence of that section:

   "It is beyond the scope of this specification to describe what actions
    a verifier system should make."

In terms of implementation, we might be doing some rejects at the 
SMTP level.  I refrained from suggesting having that as part of the 
default knobs because of the odd cases.

I am wary about going beyond the RFC 5322 level for some of the 
reasons you stated above and because DKIM does not operate at that level.

At 07:53 27-05-10, Murray S. Kucherawy wrote:
>I think it's appropriate since ADSP is creating the problem (or in 
>your view, extending the existing problem).

Maybe, but this is the kind of thing where some people will take the 
simplistic answer and ignore the caveats.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 27 May 2010 11:02:42 -0700

> From: SM [mailto:[email-masked]]
> Sent: Thursday, May 27, 2010 10:06 AM
> Cc: Michael Thomas; Murray S. Kucherawy

True, but that doesn't mean it's not worth saying.  I'd rather say it to what limited audience this draft might have than not say it at all.

---

From: Daniel Black <[email-masked]>
Date: Sat, 29 May 2010 19:09:46 +1000

Comments on draft-kucherawy-dkim-lists-00

Murray,

Well done on your draft. This encompasses many themes from current email 
practices namely:
1. sender responsibility
2. keeping it simple
3. attempts to keep impact minimal and provide a compatible way forward.

Historical Sender Responsibility for SMTP:

Email has slowly changed the way it has been sent over the years in the 
following ways:
* open relays fell out of favour
* email gateways became authenticated
* 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.

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.

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. MLMs, like mailman, have taken the 
simple option of stripping DKIM signatures which has also had a positive effect 
for many list admins. The conflict in these approaches has put receivers in 
limbo as to how to perform appropriate actions based on DKIM signatures. 
Introducing a recommended way of doing things like this rfc-draft is an 
important step.

Previously email verifiers had introduced practices over time. The key to 
changing the sender behaviour has been using the feedback mechanism of SMTP 
rejection and NDR. The feedback mechanism for future filtering I see is the ARF 
RFC (once published). Specificity to DKIM/ADSP is draft-ietf-marf-dkim-
reporting standard. In the same way that NDR drove email practices from 1984 
to where they are now, DKIM/ADSP reporting feedback via ARF I see as a way to 
provide sender domains information relating to genuine phishing attempts 
against their domains, and also feedback on incompatibilities due to MLM and 
the occasional MTAs along the way.

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. 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.

Some mechanism, potentially part of draft-mark-dkim-reporting, for 
intermediaries signature to receive notification whenever a final delivery 
didn't get accepted independent of the verification status of the DKIM 
signature added. This would enable MLM to gain an idea as to which recipients 
are rejecting emails based on author domain signatures. Some MLMs currently 
manage bounce list to unsubscribe broken end user accounts.

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.

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.

section 1.2

insert as 1.2 before the current 1.2:

"1.2 DKIM / ADSP failure reporting
 
It is in the author domain interest to have its messages widely accepted by 
MLM recipients. For this reason senders are advised to utilise a [draft-marf-
dkim-reporting] feedback mechanism to help them make informed decisions about 
what DKIM/ADSP verification failures are occurring. Based on the feedback 
received it can be evaluated as phishing attempt or a message that passed 
through the gateway that was desirable to reach its intended recipient. Some 
options listed in section 4.1 Author-Related Signing could be utilised for 
future mail to this destination.

It is in the recipients interest to allow messages through that pass DKIM/ADSP 
checks. MLM are likely to cause some difficulties in processing. Whatever action 
a recipient may choose to take sending a ARF message back to the via [draft-
marf-dkim-reporting] is an important way that a sender domain or MLM can occur 
take action to enhance DKIM/ADSP."

significant: this adds a feedback mechanism for everyone.

section 1.3 Feedback Loops And Other Bi-Lateral Agreements

insert as last paragraph:

"[draft-marf-dkim-reporting] allows a FBL between non-related entities without 
a bi-lateral arrangement."

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."

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."

(ref: http://mail.python.org/pipermail/mailman-users/2009-October/067391.html)
RFC5322 also lists Sender and Reply-to as originator fields.

Alter start of body changes paragraph to:

"Some lists filter attachments, prepend, or append"...

minor: filtering attachments is a common body modification

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.
Alternate practices like rejecting messages with attachments would some the 
malware case. There is some convenience to users to be able to send messages
to a mail list with attachments that get archived on the MLM and users receive 
a HTTP link to its content. A dkim compatible way for this to be facilitated 
would require the sender to sign only the non-attachment portion of the 
message using l= dkim tags.

Prepended or appended lines currently tend to describe unsubscribe information 
or list policy information. List unsubscribe is currently a RFC2369 header 
field with few implementations in MUAs. List policy information is currently 
unsupported as header field however its purpose could be implemented.
Policy notices could be sent periodic notices authoring list notices from the 
MLM.

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.

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.

significant: explores options in changing MLM behaviour, that while is not 
going to happen in any hurry may end up occurring eventually.

3.4.  Alternatives of Participation and Conformance

Alter beginning of second paragraph to:
"However, the practice of applying headers and footers to message
 bodies, modifying subject header field and attachment filtering is common"

minor: adds the other equally as common signature breaks to the rational.

4.1 Author-Related Signing

note:

Not adding signatures removes the mechanism provided by [draft-marf-dkim-
reporting] for gaining feedback.

4.3.  Handling Choices at Receivers

"[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."

minor: "should" would be closer to the RFC5617 meaning.

4.3  Handling Choices at Receivers

add to end:

"A verifier should choose to send a [ARF] message to the author domain 
reportable address [draft-marf-dkim-reporting] enabling them to take action 
for future messages sent to the MLM."

minor: highlight the benefits of ARF

5.1.  Author-Related Signing

change title - "Author verification by MLMs" perhaps

minor: Title seems misleading. especially considering the first paragraph.

second paragraph probably should be removed or merged into 4.1  Author-Related 
Signing. Removing this second paragraph will make 5.1 flow into 5.2 better. I 
suspect the 5.2 heading could be removed.

5.2 Verification Outcomes at MLMs

append to second paragraph.

An author domain may request for DKIM and ADSP failures to be reported through 
[draft-marf-dkim-reporting]. A participating MLM is advised to comply with 
this request.

minor: highlight arf 

5.3 Pros and Cons of Signature Removal

a con of signature removal is it removes the tags need for a recipient to give 
feedback via [draft-marf-dkim-reporting].

significant. Breaking a feedback mechanism isn't a great improvement.

5.3 Pros and Cons of Signature Removal

comment:

minor: given resending MLM set the envelope to receive bounce message, they 
are in a good position to know which recipients reject based on ADSP/DKIM 
failures. A enthusiastic MLM implementer could avoid deliver there or deliver 
there as an authoring list.

5.4.  MLM Signatures

Question with regard to "as it arrived". I suspect signing it after 
modification provides greater utility to the recipient. I'm not sure of the 
value in an arrival signature - wouldn't this be the same as the author 
signature that potentially got removed?

Add also at this point:

DKIM-aware resending MLM may decide to use the [draft-marf-dkim-reporting] 
mechanism to determine if any DKIM signature breaks are occurring between the 
MLM and the recipient.

Append new section:

5.X MLM ADSP

A participating MLM should be able to assert a ADSP policy. This is especially 
true for authoring and digesting mailing lists. Resending and aliasing lists 
still have benefits as administrative messages are likely to have a domain as 
an author domain. Care should be taken if the MLM domain is shared with other 
message streams.

important: As mailing list domains are probably the ones going to have 
filtering exceptions at the recipient end because of signature breaks this 
makes them potentially a targeting domain to use if phishing attacks. An ADSP 
policy will make it easier for recipients to apply filtering rules as mailing 
lists are unlikely to be chained together outside a recipients ADMD.

5.5.  Verification Outcomes at Final Receiving Sites

comment:

minor: As a final receiving site will have a recipient that is likely be be a 
participant in the MLM, some form of feedback look within the receiving ADMD 
to produce a favorable(?) set of MLM signatures.

Daniel

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 30 May 2010 18:53:03 +0200

> (I might have the "5.7.1" wrong, but you get the idea.)

There is apparent consensus that posting to MLMs using discardable 
addresses is a bad practice. By discouraging it, the BCP already 
implies that any ADSP/MLM conflicts are odd cases that someone has 
to handle specifically. But who?

There are three actors involved: the domain who set "discardable", 
the user who posts to MLM, and the MLM who breaks the domain's 
signature. I think no advice can satisfy all them. However, I'd opt 
for letting the domain admins know about the fact, since they chose 
to reject rather than drop. That is,

    MLM: in case of ADSP rejections, kick the user
    unless you are sending a dkim-report to the admins.

Kicked users will report to the admins themselves, unless they 
already know what to do. Notified admins can prepare alternative 
addresses, whitelist, authorize, etcetera. List grandmas can avoid 
bad experiences to their subscribers that way.

Of course, it would be even better, and smoother, if MLM rejected 
the offending posts in the first place. /Participating/ MLMs do so.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html