On Sat, Mar 22, 2025 at 10:54 AM Michael Thomas <m...@mtcc.com> wrote:
> I'm about half way through the audio session and just finished the > rationale for a single rcpt-to. I'd like to turn that rationale on it's > head: if this is pretty much the way the world operates now (which I have > no reason to doubt), why are we going out of our way to codify it with as a > protocol level MUST? If this is such an edge case, why should DKIM care? > From the session it seems that the (only?) rationale is "it's simpler". > Simpler for whom though? It doesn't seem simpler for ESP since they already > do a single rcpt-to or most other use cases beyond the mailing lists that > still batch things together. > > The reason I keep harping on this is that I don't understand the value of > picking fights that need not be picked, cf the advice in 5321 that Barry > brought up. I doubt I will be the only person who reads this and have alarm > bells going off about changing the email architecture, and why it's necessary. > So if it's really such a marginal problem why are we spending a lot of time > requiring a change that doesn't seem like it needs to be mandated? > I don't see it as changing the email architecture. At the SMTP level, use of multiple recipients on common content can still be encouraged, in the same way that SMTP itself is insecure. But on the modern Internet, you basically have to use STARTTLS if you want to talk to anyone. EMAILCORE has settled on the notion that SMTP doesn't need to say that, but an Applicability Statement does. That's in development now in that WG. (There's a massive thread cluster over there if you care to read about the relevant debate.) DKIM++, by the same token, doesn't have to directly challenge the "multiple recipients" guidance of SMTP. Instead, it can say, "If you want to get your mail through modern authentication barriers, multiple recipients are incompatible with that goal". -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org