> -----Original Message----- > From: John Levine [mailto:[email protected]] > Sent: Monday, October 18, 2010 5:50 PM > To: [email protected] > 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
