I think the rev8 version of section 6.5 is much better, but I have a
change proposal with the background reasoning listed below it:
o proposed change:
------------------
The basic rule for choosing fields to include is to select those
fields that constitute the "core" of the message content with high
authenticity value and high targets for malicious attacks.
Included in the core are the required fields as defined in
RFC5322 section 3.6.
Common examples of "core" fields with addresses and fields listed
in order of authenticity strength and introduction:
o From (RFC5322 and DKIM REQUIRED; see Section 6.4)
o Date (RFC5322 REQUIRED)
o Message-id
o Subject
o To, Cc
For replies and resent mail, the "core" fields may include:
o Reply-To
o References
o Resent-Date, Resent-From, Resent-To, Resent-Cc
o In-Reply-To,
For messages signed by Mailing List Managers, the "core" fields may
include:
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
List-Owner, List-Archive
------------------
o Background reasoning:
In 2nd paragraph, 1st sentence:
The basic rule for choosing fields to include is to select those
fields that constitute the "core" of the message content.
I think for most mail system experts "core" can be understood but also
comes with different reasonable levels of what constitutes "core",
especially when it comes to gateways, transformations and the most
common fields to display.
The section does follows up with examples of the core not expected to
fail or fail authenticity only with malicious intent. But a few of
the "core" fields can change such as Subject and Reply-to with
industry acceptable MLM streams.
So it may help separate the core using order of importance with
including text regarding required RFC5322 headers as stated in RFC5322
section 3.6 (3rd paragraph, 1st sentence)
The only required header fields are the origination date field
and the originator address field(s).
These would be Date: and From:
I also think the Replay Attack sentence (as worded) is not necessary
and I think important Message ID should be added back in as it is a
critical important authenticity field especially in the area of
duplicate mail detection.
Message-id is required by all message creators and/or added by
submission servers and its a fundamental expected in all mail
networks. The commonality has been a construct of:
local-unique-serialize-id @ originating-host-domain
The basic requirement is that only the LHS is locally unique at the
original host and together, worldly unique.
This is never expected to be modified or stripped which will
constitute a new message. Mail Dupe detections are very fundamental in
all mail systems (regardly if they use it or not) and they use a
message-id as a fundamentally input. IBM even has a patent on using
authenticated Message-ID feedback verification method:
http://www.google.com/patents/about?id=NXSGAAAAEBAJ
So in my strong opinion, the RFC5322 Message-ID is a traditional
strong original mail authenticity identity and should be included in
the "core" group.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html