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
