On Oct 18, 2010, at 5:50 PM, John Levine wrote: >>> difference between a green bar SSL page and one with no SSL. I don't want >>> to mess with the MUA at all, but rather use DKIM to help decide what >>> messages to show her and which messages to consign to the junk folder. > >> 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. 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.
A "threat" isn't the only way to consider this. There's a strong correlation between badly structured emails (SMTP, MIME, HTML) and email that the recipient doesn't want to see. > No DKIM -> no threat -> no special treatment. I don't know how to > make this any clearer. That's why sorting modules don't worry about > it now. > > 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. I think even a SHOULD might be a bit strong, but it's certainly worth mentioning as something that an architectural module either upstream or downstream of the DKIM verifier should be aware of. OTOH, we already have a SHOULD that tells MUA writers to splatter the d= field somewhere in the GUI where the user can't ignore it, so we're a long way away from anything like a sensible separation of responsibility in the DKIM spec already. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
