On Oct 6, 2010, at 3:01 PM, Scott Kitterman wrote:
"Dave CROCKER" <dhc(_at_)dcrocker(_dot_)net> wrote:
On 10/6/2010 8:00 AM, Steve Atkins wrote:
It also changes what DKIM means,
...
Either the message has a valid DKIM signature, or it does not. If the
signature is valid, then the signing domain takes responsibility for the
message, subtly malformed or not. Just because the message lacks a Date:
header or has bare linefeeds doesn't mean that the signing domain isn't
responsible for it.
THis is a particularly clean and precise attention to DKIM's job, nicely
filtering out issues that are not part of DKIM's job.
In particular, it makes the multiple From: issue entirely irrelevant to DKIM.
In a normative sense, perhaps, but in real world terms, it doesn't. Since
this does away with "It's not valid 5322, so it can't be valid DKIM", it puts
the question of how implementors should deal with such things back on the
table.
They can deal with it however they like - but as far as the DKIM validator is
concerned there's either a valid DKIM signature, or there isn't, so it's the
associated code (where DKIM plugs into the rest of the mail handling engine)
that'll need to be aware of it.
Were I writing the signer, though, or the code surrounding the validator I'd
appreciate some mention of this gotcha in the spec so I know I need to deal
with it.
I'd like to see us include a general helpful note to implementors about
covering the case where a duplicate header field is added after signing.
+1
The more helpful the spec can be to implementors, the better, and this is a
grubby corner.
Maybe this is an added item for security considerations?
Likely, yes.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html