On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: >>> That this is not in 4871 seems to be mostly a WG assumption that >>> should be made explicit. >> >> I think several of us thought it was in there, but on review it apparently >> was indeed lost somewhere along the way. We've certainly, as I understand >> it, been proceeding from that assumption for a very long time. >> >> I like the idea of saying so explicitly in 4871bis, and applying it both to >> signers and to verifiers. > > Agreed. Though frankly I couldn't care less about signers. It's always > the verifier that really counts. > >> I don't like the idea of being any more specific than that. That >> is, I don't want to create specific text for specific cases we know >> about because that means anything we don't list could be perceived >> as less critical. A blanket admonishment to implementers is >> sufficient and appropriate. > > Right. We could attempt to enumerate the 1,000 edge-cases we know > today and then re-bis 4871 for the additional 1,000 edge-cases we > learn tomorrow, or we could simply say that invalid 2822 messages > MUST never verify and call it a day.
To comply with that MUST every DKIM verifier would have to include a full 5322 verifier. That's a fairly high bar. It also changes what DKIM means, operationally, as I know that most email nodes don't check for well-formed emails today rather they parse them with a fairly robust parser. Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. I don't see how adding all that functionality and cost to a DKIM verifier does anything at all to add any value. If anything, it seems it'll just increase the rate at which a DKIM verifier fails to verify a DKIM signature contrary to the expectations of both sender and recipient. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
