Julian Mehnle wrote: > Hector Santos wrote: > >> Right. Does this add "signer" reputation weight for the injected >> 5322.From? > > Probably not.
How do you know what the heuristic systems are doing? > AFAICT mipassoc.org doesn't verify DKIM sigs on list > messages, it does..... It verifies, adds an Authentication-Results: header, strip the original signature, add a fooder and a [list] to the subject and resigns. > and even if it did, a verified DKIM sig (such as one created by > the original author of the message) doesn't tell anything about the > legitimacy of the use of the From identity. Not sure what that means Julian. >> Personally, -1 on suggesting a h=from:from, because you are assuming >> that operators are actually defining a h= tag. If its blank, its >> falls back to the semantics written - use the LAST header found. > > No. h= must not be empty. The spec explicitly forbids this. You misunderstood. What that means is that the signing function MUST add a h= to the 5322.DKIM-Signature line for the 5322.headers it decides to hash and bind to the signature. The operators with their DKIM implementation can set what headers to sign or they can choose NOTHING and allow the default behavior for the implementation. In other words, the operator can set (in whatever way the software does it): RequiredHeaders From:To:Date:Message-Id:Organization:Subject Now the signing engine will follow this. If not set, then it has its own default rules. The recommendation is presented in RFC 4871. What you are suggestion is that implementation had their defautlt to include From:From, like above: RequiredHeaders From:From:To:Date:Message-Id:Organization:Subject > As for a possible change in RFC 4871bis, if you look at page 41 of > 4871bis-01 (page 36 in RFC 4871), it already has this nice little note: > > | INFORMATIVE NOTE: A header field name need only be listed once > | more than the actual number of that header field in a message at > | the time of signing in order to prevent any further additions. > | For example, if there is a single Comments header field at the > | time of signing, listing Comments twice in the "h=" tag is > | sufficient to prevent any number of Comments header fields from > | being appended; it is not necessary (but is legal) to list > | Comments three or more times in the "h=" tag. > > I suggest replacing "Comments" with "From". That should solve the > problem. I did notice this too and thought the same idea. :) What the specs need in whatever IETF method you guys like to do things: 1) Semantics that DKIM-compliant MTA doing stonger RFC 5322 checking and at a minimum, checking for multiple 5322.From (and possible even 5322.Subject). 2) To close the loophole to #1 (legacy software), the DKIM verifier SHOULD void messages with 5322.From which are not bound to the signature. 3) To close the loophole to #1 (legacy software), the DKIM signer MAY consider adding a h=from:from to the DKIM-Signature. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html