I don't think so, but I'll definitely test it. If it does, then we won't do it
that way.
Scott K
On Thursday, July 07, 2011 12:51:06 PM McDowell, Brett wrote:
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