ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

2010-10-06 07:46:50

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

<Prev in Thread] Current Thread [Next in Thread>