ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Final update to 4871bis for working group review

2011-07-07 12:27:40
Will your "assume one more From than listed in h=" lead to failed verifications 
on messages that actually follow the advice in the RFC to list duplicate 
headers in their h= values?


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott Kitterman
Sent: Thursday, July 07, 2011 12:44 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review

On Thursday, July 07, 2011 12:22:20 PM Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott 
Kitterman
Sent: Thursday, July 07, 2011 6:32 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Final update to 4871bis for working group
review

I'm working with someone on an implementation and I think we're
going to assume one more From than listed in h= when verifying to
ensure nothing has been added.

This intentionally causes the verifier to assume what the signer
really meant when it signed a message using a single From: field.
That may look safe but it isn't what DKIM actually says.

We might do this for libopendkim somewhere down the line, but it would
default "off".

In any case, interesting idea.

It only assumes that the signer signed all the From: fields present in the
message (note: I said one more than in h=, not two).  I think it's fair to say
that if someone is sending messages with multiple From: fields (or
Date:/Subject:) and trying to sign something less than all of them they are
fairly deep into unsupported territory and shouldn't find any result
surprising.

I agree it's not exactly what is specified in the protocol, but this is an
implementation design issue.  I think it's safe.  If the DKIM protocol says I
can't do something like this, then I think we have a problem with the current
"describe it and let implementors deal with it" plan.

Scott K
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-
rules.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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