[ietf-dkim] Final update to 4871bis for working group review
hsantos at isdg.net
Fri Jul 8 21:06:10 PDT 2011
Douglas Otis wrote:
> Ensuring multiple header fields stipulated as occurring once not provide
> a deceptive DKIM result does not alter the intent of DKIM validation.
> It is important for DKIM compliance to ensure deceptive and invalid
> header field instances are excluded by the verification process from
> returning valid signatures. Clarifying this stipulation to establish
> proper verification layering will not raise interchange issues.
> These checks must be part of any DKIM compliance certification program
> or recipients are at risk. Language in the base specification must make
> this requirement clear. After all, it was missed and exploited with
> DKIM's implementation used by the WG mailing list, if anyone needs examples.
> It would be unwise to invest either trust or services in an easily
> exploited system.
I can imagine in the ideal DKIM integrated world where One From is
signed and the verifier will only validate One From and the Display
Renderer only using One From validated by DKIM, there would some
design considerations where the all parts will eliminate or ignore any
additional From headers, if any, that is not part of the successful
1) The signer gets a proper RFC5322 message with only one 5322.From
Signs the message and its out into the mail stream.
2) Some how, one way or another, additional 5322.From headers are
injected into the message headers, so now you have:
and it doesn't matter what order.
3) The in the ideal DKIM verifier, it will test each From:
- Hashing From=BadGuy1, the signature fails.
- It sees another from=BadGuy2, tries that in the hash, it fails.
- It sees another from=GoodGuy, tries that in the hash, it validates
and he stops here.
So the question, as I see it, is what is reported?
- Validate, but has suspicious invalid extra From?
- Validate, removes any invalid extra From? or,
- Invalidates due to extra from headers?
In my view, its possible since the verification is local, if its using
a local display renderer, it could just show the valid from and ignore
The problem that I see is when there is store and forward, i.e. pop3.
What does the POP3 server do here as it prepares the data to be
transmitted to the pop3 client? Should it strip the invalid extra from
headers? Or do we assume the POP3 client or rather the offline mail
reader will be multi-from security DKIM aware like the online system?
In short, the host system and/or verifier/receiver can do a lot here,
but I personally don't like to be playing these games and we don't
know how other software will behave, so I would prefer to just kick
out damaged mail - even when its possible to validate one of the
Hector Santos, CTO
More information about the ietf-dkim