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
