"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.
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. Maybe
this is an added item for security considerations?
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html