Alessandro Vesely wrote:
Correct. And the way that it fails to verify is h=from:from.
The only way that DKIM can consistently account for this exploit is by
amending section 5.5 "Recommended Signature Content", and spell what
fields MUST/SHOULD be duplicated in the h= tag.
-0.5.
This is a kludge. Its good to help, possibly, existing systems that
is capable of defining the N+1 h=from values in their setup. The
problem is you don't know if they can.
The real solution is to fix up section 5.4 general paragraph regarding
signing and
verifying the last header because it ignored the exception in regards
to 5322.From which fundamentally there can only be one.
It needs to add the exception clause to that paragraph or in a follow
up paragraph.
Both verifiers and signers MUST make sure its DKIM input, especially
the headers it will bind, are technically correct.
Only DKIM can do that to close legacy loopholes.
The h=from:from "kludge" should be seen as a temporary solution until
verifiers and signers catch up with the Double From problem. It can't
depend on other mail bots to do this.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html