-----Original Message-----
From: John Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Monday, October 18, 2010 5:50 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] detecting header mutations after signing
Why do we think such a sorting module can't/won't have the
intelligence to do the RFC5322 Section 3.6 checks?
Sheesh, I think I've answered this at least three times now.
Well gosh, I sure do appreciate your patience in dealing with the rest of us
fools that might not share your view or have something else to offer.
In the
absence of a DKIM signature, there is no reason to worry about doubled
headers since there is no reason to think one is "real" and the other
"fake". They're only a threat when they provide a way to make a DKIM
signed message render differently from what the signer expected.
But some agents, maybe even many of them, do via some mechanism decide that one
is the "real" one and make a filtering decision based on it. It might be as
simple as an MUA electing to render the first one it finds, for some value of
"first".
As I've also said before, either DKIM has a SHOULD about doubled
headers, or the equivalent advice goes into the folklore about what
you have to do make DKIM useful. Personally, I think the latter would
be a cruel joke on future implementors, but apparently other people
feel differently.
And just like when you said it the first time, I still don't share your view
that a Security Considerations section of a Draft Standard document can be
classified as "folklore".
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html