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