Noted on the Yahoo history - the CEO's indifference was made possible by the
absence of BCP protection, not excused by it. The lesson holds even if the path
was deliberate.
On ARC: you just confirmed that the mailing list problem was real enough to
invent an entirely new mechanism for it, and ARC failed in deployment because
it was too complex for consistent implementation. Leaving re-originator
behavior undefined in the BCP risks the same pattern: DKIM2 deploys, receiver
policy authors fill the gap with their own rules, those rules diverge, and
correcting the divergence after the fact is harder than one BCP sentence now.
The history argues for writing it down, not for hoping the outcome is different
this time.
Specific text has already been proposed. GitHub Issue #2 at dkim2wg/spec
contains the proposed Section 5.x definition and the Section 6.1 receiver
guidance. If the WG is willing to review it, I am ready to discuss.
William Weiner
Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com)
From: John Levine <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Date: Mon, 27 Jul 2026 20:34:45 -0600
Subject: [Ietf-dkim] Re: R: Re: R: Another question: introducing DKIM2 for
non-DKIM2 originators
It appears that William Weiner < mailto:[email protected] >
said:
>-=-=-=-=-=-
>
>Pietro's reading is correct: EMail Parrot and similar services start a new
>DKIM2 chain at i=1, and the spec
>handles that cleanly. No new protocol mechanism is needed. The BCP question is
>narrower - whether receivers should
>have normative guidance on evaluating that pattern as the category grows.
As I may have said a few dozen times, the answer is still no.
>The DMARC parallel is the direct precedent - and the lesson is not that Yahoo
>acted in bad faith. Yahoo was
>getting hammered with spoofed @yahoo.com phishing and p=reject was the only
>tool the spec gave them. The BCP had
>not defined a compliant path for mailing lists, so Yahoo had no option that
>protected their users without breaking
>lists.
Nope. Yahoo could have left their DMARC record alone and adjusted their own
mail
servers to reject mail with a Yahoo return address and no Yahoo DKIM signature.
But it was slightly easier to change the DMARC record and as their CEO said at
at the time, she did not care that it broke all the mailing lists.
As I presume you're aware, we invented ARC to try to provide a way for mailing
lists to say what they did, so receivers could look back and see if the message
was originally signed and DMARC aligned. But ARC turns out not to work (see the
recent discussions in the DMARC WG) because they're tricky enough that even
Google gets them wrong. DKIM2 is basically ARC but with each intermediate step
showing its work so you don't have to trust them.
Anyway, we're going in circles here. Please propose specific text for the DKIM2
draft and we can see if there is any support for adding it. If so we can add
it,
if not, we can stop.
R's,
John
_______________________________________________
Ietf-dkim mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
