[ietf-dkim] ISSUE: Updating Section 6.5: Recommended Signature Content

[Hector Santos]

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