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