On Sun, Mar 23, 2025 at 5:06 PM Michael Thomas <m...@mtcc.com> wrote:
> On 3/23/25 4:47 PM, Murray S. Kucherawy wrote: > > 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.) > > That's basically what I was trying to say. We can recommand and give the > reasons why it's a good idea to do a single rcpt-to without mandating it > with a MUST. The microscopic amount of traffic that actually uses it can > still work with DKIM++ and the vast majority of traffic does it already > anyway. It's been really confusing why it was turned into a MUST like there > was some underlying security reason. > I think there's a difference between saying "all mail MUST now be sent single-recipient" and "if you are participating in DKIMbis, you MUST send single recipient". I don't think anyone is saying the former, and in fact would argue that doing so violates our charter. But I believe the latter is fair game. > 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". > > Oh DKIM++, I think I can get behind that. Sort of register deferred, post > increment on the header vs update debate :) > I think I'm just trying different names until something sticks (and, of course, it's clear which path we're following). -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
