[ietf-dkim] Final update to 4871bis for working group review
bmcdowell at paypal-inc.com
Thu Jul 7 09:51:06 PDT 2011
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.org [mailto:ietf-dkim-
> bounces at mipassoc.org] On Behalf Of Scott Kitterman
> Sent: Thursday, July 07, 2011 12:44 PM
> To: ietf-dkim at 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-bounces at mipassoc.org
> > > [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Scott Kitterman
> > > Sent: Thursday, July 07, 2011 6:32 AM
> > > To: ietf-dkim at 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
> 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-
More information about the ietf-dkim