On 4/25/2011 10:09 PM, Murray S. Kucherawy wrote:
One could argue that the MIME fields (omitted here) constitute the core of
the message as they go to the representation of the content. However, they
haven't been precluded by the above text so it's probably fine.
I should at least explain the logic I used in deciding to exclude some items
that were in the original list, where the MIME header fields are perhaps the
most surprising:
Simply put, they are structural, not semantic.
Mess with them and the signature breaks, rather than false content getting
accepted.
So there's no incentive to worry about "protecting" them.
I'd actually like to add Authentication-Results because an agent that wishes
to claim that observed authentication meta-data should become part of the
message core certainly should sign such a field, but that's not worth
recycling at Proposed and basically RFC5451 already says that anyway.
Interesting. Hadn't thought about any "newer" fields. I think the premise,
for
this one, is that security-related fields should be included (other than
DKIM-Signature).
I suggest folks think about this carefully a bit. I'm not sure it's
automatically correct to include these, but I can't think of an argument
against, in terms of spec basics.
The only wrinkle that I /can/ think of is procedural: /adding/ isn't supposed
to
happen when going to Draft...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html