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.
+1. However, the rat hole is when we are not specific and leave it open ended. The proposed text can be: Verifiers MUST make sure only check valid RFC 5322 messages are verified. Specifically verifiers MUST check for multiple 5322.From headers in the message and if found, the verifier MUST invalidate the signature [and reject|discard the message]. If we remain focus with this specific issue on hand - multiple 5322.From, which is critical in the mail infrastructure in every network and is used for every Online or Offline MUA, and today related to DKIM with the required 5322.From hashing, this is one specific invalid mail case that can be easily addressed and doesn't have to be a rat hole nor delay 4871bis progress to draft standard. The funny thing is, I am not even a hacker and I was able to take an archived 5322 message text file, prepend a 5322.From line and resubmit back into the stream with perfect DKIM validity and resigning by another MTA/MLM. It was too easy and I am not smart enough to determine what real hackers can imagine to come up with. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html