My preference would be Message-Id SHOULD be part of the top core
listing and if wish to add text to explain use cases when/why it
should|may not considered be hashing, that would be make more DKIM
engineering sense to me.
It should be the exception and not the rule to not consider a
Message-ID as part of the "core" group. So if anything,
There are tradeoffs in the decision of what constitutes
the "core" of the message, which for some fields is a
subjective concept with use cases where modifications
or removals are possible. For example, excluding fields
such as "Message-ID" may apply under certain scenario
where it is known this header may be altered, such as
under a resigner creating a new message.
Whatever.
Hector Santos wrote:
Murray S. Kucherawy wrote:
Recommend adding the following paragraph (excuse the XML markup):
<t> There are tradeoffs in the decision of what constitutes
the "core" of the message, which for some fields is a
subjective concept. Including fields such as "Message-ID"
for example is useful if one considers a mechanism for
being able to distinguish separate instances of the same
message to be core content. Similarly, "In-Reply-To"
and "References" might be desirable to include if one
considers message threading to be a core part of the
message. </t>
hmmm, "if one considers...." Oy vey.
Message-id is a "core" header in mail systems as part of the
authenticity of the message and highly used as part of dupe checking
algorithms. That is not subjective concept. It is part of robust mail
system designs. Its very vexing to me to understand how this is being
contested. What is subjective is the above text with an inference the
Message-ID is of low utility and low deployment for message
identification.
The goal for DKIM is to increase verifiable authenticity and the
Message-ID is one of those persistent header expectations. It is never
expected to be changed or removed.
Besides, where was the WG consensus for the removal in the first
place? You can't just remove something and force everyone to waste
time proving why it should be added. It was added in the first place
since the original document for good reason and remain there all these
years until this WGLC last minute.
That's just not right.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html