Bron, Emanuel -- thank you both. The responses were direct and quick, and your willingness to engage with a small operator on a protocol question is genuinely appreciated. I understand the BCP draft has already been updated to reflect some of this discussion, which is exactly the process working as intended.
We are tracking DKIM2 development with the intent to be fully compliant as the spec and deployment guidance mature. With that as our posture, we want to make sure the BCP captures the re-originator category clearly enough that compliance is well-defined for services like ours. With the protocol framing settled, I want to flag a gap in draft-herr-dkim2-bcp-01. Section 5.8 is currently a stub whose heading gestures at privacy-preserving behavior. Section 6.3 leaves receiver handling of chain-less messages to local policy, with no guidance distinguishing intentional re-origination from chain evasion. As DKIM2 deployment matures and major receivers write their local policies, that gap is where a trust gradient against legitimate re-originators could quietly emerge. I will be sending proposed text for both sections directly to Todd Herr and will cc this list for the record. William Weiner Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com) On Jun 16, 2026 at 8:43 AM -0600, Emanuel Schorsch <[email protected]>, wrote: > +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 > <[email protected]> wrote: > > On Mon, Jun 15, 2026, at 16:37, > > [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]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
