Alessandro Vesely wrote in <[email protected]>: |On 02/06/2025 23:29, Dave Crocker wrote: |> On 6/2/2025 2:07 PM, Alessandro Vesely wrote: |>> |>> So an implementation can either apply DKOR only to messages that have |>> a single recipient, or split messages to multiple recipients so as to |>> force them to be sent to a single recipient at a time. The latter |>> choice may require more fiddling than is desirable. |> |> As discussing at the last IETF meeting -- and many times before -- |> single-addressee email is already the norm. | |This may be the norm in discussions, but in practice it is not. I \ |just sent a message from Gmail to three of my addresses, two on tana.it \ |and the third to a different domain with the same MX. The were received \ |in *two* transactions, not three. The copy sent to a different domain \ |even arrived via a different host, but the two copies to the same domain \ |were sent in one transaction.
Naah, and if VERP would be IETF standardized on the SMTP level lots of I/O could be saved. For example postfix bundles VERP-enabled (but VERP meaning not on SMTP level, of course) in groups of a few, instead of sending all in one go. The numbers given for this list here were impressive, compare single recpient to groups of (i think) six to about seventy .. in a single transaction! All the workgroups, mailing-lists, etc. All the web interfaces which send out notifications. In combination with all the mega mailbox providers! And this is today. Maybe lots of things flow back to email which are now somewhere else, noone can say whether this wonderful and reliable protocol gets back traction if certain problems are solved. In fact it always seemed to me the IETF enforces such run-away- to-somewhere-else's. Noone ever answered the question why "SMTP is different" and has to stick with STARTTLS instead of Implicit TLS. I mean: even for the protocol-alien MTA-STS and such you still have to go over that. A billion times a day! Honestly: there can only be one answer: - No easy TLS availability announcing as in other protocols by means of the protocol and its "internet accompanion" DNS. - Even with (complicated, protocol-alien) TLS availability announcement additional, synchronous TCP roundtrips via STARTTLS; not even a try to create dedicated ports as in all other protocols. - No standardization effort to bundle recipients but with dedicated return paths even if the technology exists for soon thirty years, and despite the high reputation of the creator, and the deep penetration of the technology as such in all aspects of the email ecosystem. - Forceful destruction of decade long established communication channels aka their configuration via harmless SHOULDs in SPF (RFC 7208), or ignorance of mailing-list operation patterns (yes, there is Murray Kucherawy's RFC 6377, yes, yes; and Dave Crocker always says "it is not DKIM's but DMARC's fault"; and Murray Kucherawy says "DMARC is not even an IETF standard"). That is: without accompanying tools / standards to let the infrastructure continue to work --- third party ideas, mitigations and software is required *to this very day*! - With two of three proposals for an iterated DKIM the entire SMTP infrastructure will be heart-attack-constrained to become single-recipient. For not a single ever described technical reason. So many intelligent people. And, even more: so much experience! The planets of the SMTP sun are really different to other protocols of the IETF: they are deliberate misconceptions. This surely belongs to art@, i copy it. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
