+1. Issues come when senders try to keep the same fromHeader or DKIM authentication while making changes or acting as a malicious forwarder. Since you’re not doing either of those and changing the domain in the DKIM authentication to take ownership of the message I don’t think there is anything unusual to be concerned of.
Best, Emanuel On Tue, Jun 16, 2026 at 10:33 AM Bron Gondwana <brong= [email protected]> wrote: > On Mon, Jun 15, 2026, at 16:37, william.weiner= > [email protected] wrote: > > Bron, > > Thanks for confirming the originator framing. > > On the nonce: the SES message ID is a natural fit. It is already opaque to > outsiders, it is the S3 object key, and it is a direct lookup into storage > we already have -- no extra bookkeeping. One thing worth noting: a nonce > past the 30-day retention window is a transparency statement, not a gap. > The S3 object is gone by design at that point. That is a privacy feature. > > On Message-ID: yes, we do rewrite it. We also scrub References and > In-Reply-To, rewriting them to our own domain namespace. Thread identifiers > in the originating provider's format would otherwise propagate sender and > provider information across the relay boundary. > > On the considerations text: intentional re-origination by a > privacy-preserving intermediary should be acknowledged as a legitimate > deployment pattern, so that an assumed missing chain is not read as evasion > by downstream deployment or reputation guidance. There are many people who > want this level of privacy in their email. Recipient privacy is a > first-class use case. Happy to propose text if that would help move it > forward. > > > I really don't think there's any text required at all, but if there was it > would belong in draft-herr-dkim2-bcp. > > You're basically creating a brand new message out of some cherry-picked > parts of a message which came into your system. It's not "the same email" > in any meaningful sense, and you're deliberately NOT providing a chain of > custody through your systems - the opposite of what DKIM2 (or indeed ARC, > or even just the Received headers) is designed to do. > > So you're doing something completely different to DKIM2; up until you send > the message out into the rest of the world again, in which case it's a new > message and you quite rightly take ownership of it. > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC > [email protected] > > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
