Subject: Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 May 2011 11:42:21 -0700

This was a delayed notice.  There's not actually a new version today.

> -----Original Message-----
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Friday, May 06, 2011 11:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
> 
> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Keys Identified Mail Working
> Group of the IETF.
> 
>     Title         : DKIM And Mailing Lists
>     Author(s)     : M. Kucherawy
>     Filename      : draft-ietf-dkim-mailinglists-08.txt
>     Pages         : 31
>     Date          : 2011-04-27
> 
>    DomainKeys Identified Mail (DKIM) allows an administrative mail
>    domain (ADMD) to assume some responsibility for a message.  Based on
>    deployment experience with DKIM, this Best Current Practices document
>    provides guidance for the use of DKIM with scenarios that include
>    Mailing List Managers (MLMs). {DKIM 12}
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-08.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

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

---

From: [email-masked]
Date: Fri, 06 May 2011 11:30:05 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF.

---

From: Franck Martin <[email-masked]>
Date: Sat, 7 May 2011 04:31:43 +0000

Sorry if I jump in, some comments:

4.3 it would be nice to talk about message encoding change like QP->8bits,
may be in minor or major body changes. It is a minor change for the human
but major for the machines as many characters got changed.

5.1 "Some mail filtering software incorrectly penalizes a message
containing a DKIM signature that fails verification." You should
remind/add that a message that fails DKIM must be considered like having
no signature at all. Then you can bring ADSP, policy in the picture, and
there ADSP too will not make the difference if a message has no signature
or a failed signature. I have the feeling that making the point clears
helps in building message policies (out of scope of this document).

"such as a signing and author subdomain {DKIM 12}" -> "such as a signing
and author subdomain {DKIM 12} or a totally different domain"

5.2 There are some professional services that allows to look in to
reception at some providers

5.3 postmaster should inform their users that messages are likely to be
discarded if sent via a MLM.

6.8 talk about headers to add to the message but do not talk which
recommended headers should be signed. They are specified in DKIM 5.5 but
would be nice to do a reminder here specific to MLM.

Speaking of DKIM 5.5, List- headers are recommended to be signed, but
doesn't it creates confusion?  My feel is that they should be signed only
if present in the message, if they are not present DKIM should not mention
them in h= at all.

On 5/7/11 6:30 , "[email-masked]" <[email-masked]>
wrote:

>draft-ietf-dkim-mailinglists-08

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 May 2011 08:59:08 -0400

It would have been nice to get this *before* working group last call
ended, or even before it started.

Murray, use your judgment on how to handle these, and we can get other
input on any that aren't straighforward.

Barry, as chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 8 May 2011 00:21:52 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Franck Martin
> Sent: Friday, May 06, 2011 9:32 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
> 

+1 to Barry's comment about this being a week late.  :-(

> but major for the machines as many characters got changed.

Which MLMs do this?  I've never heard of that.

> helps in building message policies (out of scope of this document).

I don't think it's necessary to add at this point; we've already stated that DKIM itself is mandatory reading, plus it seems redundant to say that after the "incorrectly penalizes" remark.

Moreover, ADSP does indeed make a difference if a message has no signature or a failed signature, so that part seems wrong to me.

And finally, if the point of adding such a remark is to enable policy discussions, but policies are out of scope, then it seems like adding it is a bad idea.

> and author subdomain {DKIM 12} or a totally different domain"

I'm on the fence on this one.  Does anyone else have an opinion?

> reception at some providers

Do you have some specific text you want to propose here?  I couldn't imagine any based on this comment.

> discarded if sent via a MLM.

Is this inbound or outbound?  I assume inbound given the title of the section.  But again I couldn't concoct text in my head to match your remark.  Can you propose some?

> would be nice to do a reminder here specific to MLM.

It says to sign the entire message.  There was previously text in there that made specific recommendations about what to sign, like "sign any fields the MLM added or changed" or "sign the parts for which you want to take some responsibility", but the text that's there now won in the end.

> if present in the message, if they are not present DKIM should not mention

The text after the list in the current RFC4871bis Section 5.5 handles this topic nicely, I believe.

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 8 May 2011 10:17:29 -0400

> Which MLMs do this?  I've never heard of that.

mj2 does all sorts of MIME smashage, although as far as I can tell nobody 
but Mozilla and I use it any more.  It's fairly common to flatten 
formatted text down to plain text either in the MLM or with a prepass like 
demime.  But we already know there are more ways that lists can break 
signatures than we can list, so I don't see any point in listing more of 
them.

> I'm on the fence on this one.  Does anyone else have an opinion?

It's an example, no need to change it.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Mon, 9 May 2011 04:12:04 +0000

On 5/8/11 19:21 , "Murray S. Kucherawy" <[email-masked]> wrote:

>> From: [email-masked]
>>[mailto:[email-masked]] On Behalf Of Franck Martin

Sorry, but I saw it more as an exercise for me to better understand the
spec and to look into email policies.

>Which MLMs do this?  I've never heard of that.

Well, not necessarily the MLM but it seems sendmail in the process may
change QP to 8bits. I thought it would be worth mentioning.

>I don't think it's necessary to add at this point; we've already stated
>that DKIM itself is mandatory reading, plus it seems redundant to say
>that after the "incorrectly penalizes" remark.

You mention that a message that fails signature must be considered like no
signature a bit later in the document, so why not here too?

>
>Moreover, ADSP does indeed make a difference if a message has no
>signature or a failed signature, so that part seems wrong to me.

noted
>
>And finally, if the point of adding such a remark is to enable policy
>discussions, but policies are out of scope, then it seems like adding it
>is a bad idea.
>

It is a best practice document so the full realm of possibilities should
be included.
>imagine any based on this comment.

Yes it is hard, because we don't want to endorse any product/service. Let
me try.

"Some MTA senders and receivers can enter in bilateral agreements or via a
third party to receive out of band reports on failed signatures."

>Is this inbound or outbound?  I assume inbound given the title of the
>section.  But again I couldn't concoct text in my head to match your
>remark.  Can you propose some?

I thinking outbound. As this document is to give postmasters a quick
start, then it is good to mention if you choose ADSP, there is "no way"
the message can go via a mailing list and survive. I thought it was
possible before reading this RFC that you could tweak a MLM in a manner
that ADSP would not break, but I realize while possible it is absolutely
impractical and as you say a cooperating MLM better drop the message out
front.

What I'm worried is that it does not set a mindset with other email
policies that can be created.

>It says to sign the entire message.  There was previously text in there
>that made specific recommendations about what to sign, like "sign any
>fields the MLM added or changed" or "sign the parts for which you want to
>take some responsibility", but the text that's there now won in the end.

I had recently the experience with Ironport old version, which had a
tendency to hard sign List- headers even if not present. Recent versions
do not do that, and I think they got confused by the DKIM RFC, but if now
this is fixed...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 8 May 2011 23:16:35 -0700

> From: Franck Martin [mailto:[email-masked]]
> Sent: Sunday, May 08, 2011 9:12 PM
> To: Murray S. Kucherawy; [email-masked]

It doesn't make general sense to list all possibilities in something that's supposed to espouse a best practice.  Although you're right that it could be any domain, I think the best practice when it comes to creating mail streams is the subdomain option.

> third party to receive out of band reports on failed signatures."

That's true, but is it advice specific to the MLM environment?  And is 5.2 the right place to talk about this?

> policies that can be created.

I think it's safer to let the MLM operator decide, since that person knows whether or not the list software will tend to break signatures on messages it re-sends.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 10 May 2011 07:35:59 -0700

> It doesn't make general sense to list all possibilities in something that's supposed to espouse a best practice.  Although you're right that it could be any domain, I think the best practice when i…

Agreed, that seems to be the best currently-deployed practice.

> That's true, but is it advice specific to the MLM environment?  And is 5.2 the right place to talk about this?

It'd fit nicely into a separate BCP on handling signature failures -- perhaps after there's more widespread operational experience with draft-ietf-dkim-reporting?

> I think it's safer to let the MLM operator decide, since that person knows whether or not the list software will tend to break signatures on messages it re-sends.

Or if they don't know, this will encourage them to find out.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html