Subject: Re: [ietf-dkim] MLM and C14N

From: Hector Santos <[email-masked]>
Date: Mon, 16 May 2011 01:41:55 -0400

Barry Leiba wrote:

>> A real live LIST organism (stream) is adding an extra line (two bytes,
>> <CR><LF>) after the header and before the body probably all its life
> 
> It's an outlier, off in the weeds.  This is not a common situation all
> around the Internet.  And in any case, the MLM document isn't the
> place to define a new algorithm.

Adding a new algorithm was not the main suggestion. I agree it would 
be a unwelcome kludge and would be a more general DKIM C14N issue.

But as a MLM vendor/developer, noting the existence of some MLM 
behaving with the extra line above issue is useful and I believe if we 
wish MLM vendors/developers to fix any of their edge case "bugs," it 
would very useful and informative to have this DKIM/MLM 
incompatibility quark documented.

IMO, not documented it keeps with the status quo - no fixes, no one 
learns, no synergism is address the MLM/DKIM conflict.  As a result, 
originating DKIM signed messages submitted to a non-DKIM aware mailing 
list with no changes to the message content distribution except for 
the extra line noted above will continue to yield invalid signatures 
at down link members DKIM receivers.  I believe that "insight" if 
added to the MLM I-D would be very informative to readers of the 
document which would include MLM developer considering all the DKIM 
incompatibility issues.

-- 
Hector Santos
http://www.santronics.com

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Sunday, May 15, 2011 10:42 PM
> To: IETF General Discussion Mailing List
> Subject: Re: [ietf-dkim] MLM and C14N
> 

This document will never be done if we need to enumerate every known message content adjustment an MLM does or might do.

The set that's there includes the most common ones, and I think that's both sufficient and appropriate to get the point across.

I think it's reasonable to assume one reading this document, and RFC4871[-bis], will be sufficiently "skilled in the art" to understand there are other changes possible that fall into the same discussion without having to list them all.

The fact that you're talking about the MLM that serves the ietf-smtp list doesn't make it special, in my opinion.  It's still a corner case.

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 May 2011 14:33:35 -0400

Hector Santos wrote:
> Hector Santos wrote:
> 
>> The document editor and others believe this is a MLM BUG.  It could 
>> be, but we don't know if its really an normal attempt to add HEADER 
>> text that was empty:
>>
>> Create List Message for Distribution:
>>
>>      Body = EMPTY;
>>      Body +=  AppendText(GetHeaderNoticeForList()) + CRLF;
>>      Body +=  AppendText(GetMessageBody()) + CRLF;
>>      Body +=  AppendText(GetFooterNoticeForList()) + CRLF;
>>
>> We just don't know. Of course, for programmers, one can easily see 
>> that there is a "mite" there where extra CRLF will be added.  We 
>> recognized it with the ending CRLF but "forgot" that list header text 
>> was also possible.  The key point is for "40" years, it wasn't a 
>> problem until a new kid in the block came and now demands MLMs adjust 
>> to work with it
> 
> As a follow up, the above is very conceivable when you also consider 
> the addition of List-* [headers] which is normally done with templates:
> 
>       Head = EMPTY;
>       Head = GetMessageHeaders();
>       Head += GetListHeaders();
> 
>       Body = EMPTY;
>       Body +=  GetHeaderNoticeForList()+CRLF;
>       Body +=  GetMessageBody() + CRLF;
>       Body +=  GetFooterNoticeForList() + CRLF;
> 
>       Mail = Head + CRLF + Body;
> 
> Of course, regardless of DKIM, to be aesthetically "clean" in 
> displays,  it should perform trailing CRLF checks to avoid extra lines:
> 
>       Head = EMPTY;
>       Head = GetMessageHeaders();
>       Head += TrimCRLF(GetListHeaders());  // no extra CRLF
> 
>       Body = EMPTY;
>       TextHeader = TrimCRLF(GetHeaderNoticeForList()); // no extra CRLF
>       if (TextHeader != EMPTY) Body += TextHeader +CRLF;
>       Body +=  GetMessageBody();
>       TextFooter = TrimCRLF(GetFooterNoticeForList()); // no extra CRLF
>       if (TextFooter) Body += CRLF+ TextFooter + CRLF;
> 
>       Mail = Head + CRLF + Body;
> 
> So its easy to see that a MLM not being 100% in its "clean" header and 
> footer text additions to the header and body is possible without being 
> label as a "BUG" or bad until something that deals with the purity of 
> integrity and C14N comes into play.
> 
> The MLM I-D *SHOULD* at least acknowledge that an extra line is 
> conceivable.
> 

Base on possible code analysis , here is what I recommend:

current text in section 3.3:

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

proposed changed (starter text):

    Minor body changes:  Some lists prepend or append a few lines to each
       message to remind subscribers of an administrative URL for
       subscription issues, or of list policy, etc.  These few lines can
       have extra blank lines or empty text with only CRLF characters
       which under normal circumstances would be trimmed or pruned.

The goal is to give the MLM audience reading this document insights 
into their long running current code which may need some modern CRLF 
trimming considerations, if any, even if the MLM is non-DKIM aware or 
a list is setup by the admin not to DKIM resign mail submissions.   No 
need to mention C14N kludges or new C14N (i.e. STRIP) proposals.

-- 
Hector Santos, CTO