Stephen Farrell wrote:
On 05/10/10 23:54, Julian Mehnle wrote:
Recommending that one more "From" be added to h= (and hashed)
than From headers are initially placed in the message should be enough.
There is no need to change the semantics of the spec.
Assuming that "recommending" above maps to a (putative)
"MUST/SHOULD" statement in 4871bis, I'd be interested in
opinions as to whether such a change might slow progress
to draft standard, or be detrimental to current deployments.
So in terms of meeting our chartered goals, this specific
addition might have undesirable side effects were it to
represent the WG's opinion. (Much as the chairs love you
all, starting right in on a 4871ter is not attractive:-)
To address current implementations, guidelines should be considered:
1) Suggest MTA do 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 signer
MAY consider adding a h=from:from to the DKIM-Signature.
3) To close the loophole to #1 (legacy software), the DKIM verifier
SHOULD void messages with 5322.From which are not bound to the
signature.
#1 is words and a remember for MTA especially those that are with a
DKIM environment to tighten up there wares.
#2 can be done with current implementation operators. I am assuming
all or not most of DKIM signing engines will allow operators to set
"Required Headers" to sign. It would be rather inflexible if it did not.
#3 is already done by at least one open source DKIM API developed
by a large MTA vendor. Not sure how OpenDKIM is will do it, but
Murray did speak of the layer (#1) approach.
#1 and #2 will allow most implementations to close this loophole until
software vendors catch up with #3.
That said, I don't think writing #1, #2 or #3 text for 4871bis should
slow down progress to draft standard.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html