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
