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-boun...@mipassoc.org [mailto:ietf-dkim- > > boun...@mipassoc.org] On Behalf Of Scott Kitterman > > Sent: Thursday, July 07, 2011 12:44 PM > > To: ietf-dkim@mipassoc.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-boun...@mipassoc.org > > > > [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman > > > > Sent: Thursday, July 07, 2011 6:32 AM > > > > To: ietf-dkim@mipassoc.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
