[ietf-dkim] ISSUE: Updating Section 6.5: Recommended Signature Content
hsantos at isdg.net
Fri Apr 29 17:56:25 PDT 2011
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.
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
> 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
More information about the ietf-dkim