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