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.
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 :)
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
