On Mon 2025-09-22 17:51:46 -0400, Bron Gondwana wrote: > Current thinking is that DKIM2 will sign EVERY HEADER except a > specified set of trace headers, meaning that even adding another > previously unknown header without declaring that you did so in a > signed delta header would break the signature.
This clearly won't work for unobtrusive signatures, unless the specified
set of trace headers is very large indeed. For example, a message that
arrived in an MS Exchange mailbox today (presumably through some spam
filters, and also a mailing list) and was read by Thunderbird currently
shows the following list of header field names:
Authentication-Results
Authentication-Results-Original
Cc
Content-Type
Date
Delivered-To
DKIM-Signature
Errors-To
From
In-Reply-To
List-Help
List-Id
List-Post
List-Subscribe
List-Unsubscribe
Message-Id
MIME-Version
Precedence
Received
Received-SPF
References
Return-Path
Sender
Subject
To
X-BeenThere
X-Envelope-From
X-EOPAttributedMessage
X-EOPTenantAttributedMessage
X-Forefront-Antispam-Report
X-Last-TLS-Session-Version
X-Mailer
X-Mailman-Version
X-Microsoft-Antispam
X-Microsoft-Antispam-Mailbox-Delivery
X-Microsoft-Antispam-Message-Info
X-Mozilla-Keys
X-Mozilla-Status
X-Mozilla-Status2
X-MS-Exchange-AtpMessageProperties
X-MS-Exchange-CrossTenant-AuthAs
X-MS-Exchange-CrossTenant-AuthSource
X-MS-Exchange-CrossTenant-FromEntityHeader
X-MS-Exchange-CrossTenant-Id
X-MS-Exchange-CrossTenant-Network-Message-Id
X-MS-Exchange-CrossTenant-OriginalArrivalTime
X-MS-Exchange-Organization-AuthAs
X-MS-Exchange-Organization-AuthSource
X-MS-Exchange-Organization-ExpirationInterval
X-MS-Exchange-Organization-ExpirationIntervalReason
X-MS-Exchange-Organization-ExpirationStartTime
X-MS-Exchange-Organization-ExpirationStartTimeReason
X-MS-Exchange-Organization-MessageDirectionality
X-MS-Exchange-Organization-Network-Message-Id
X-MS-Exchange-Organization-SCL
X-MS-Exchange-Processed-By-BccFoldering
X-MS-Exchange-Transport-CrossTenantHeadersStamped
X-MS-Exchange-Transport-EndToEndLatency
X-MS-Office365-Filtering-Correlation-Id
X-MS-PublicTrafficType
X-MS-TrafficTypeDiagnostic
X-Spam-Checker-Version
X-Spam-Language
X-Spam-Level
X-Spam-Status
X-Virus-Scanned
The e2e verification would discard the overwhelming majority of these
headers. It's not clear to me that a recipient who wants to see what
the sender originally put in the message would be well-served by
mechanism that required them to undo a series of diffs, as opposed to
just seeing the original message clearly, with original headers intact
and unchanged.
> Yes, this is the major issue - combing the work will slow one/both.
> On the flip side, being able to use the same signature and delta
> tracking all the way from first sender to final receiver (so you can
> verify everything at every level) would be really nice.
I guess I'm not sure that delta-tracking is particularly useful for e2e
verification (though it might well be for DKIM purposes).
From this discussion, it seems to me like the costs of aligning the
proposals are probably higher than the benefits.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
