Most of the very big senders, the ones sending to hundreds or millions of
people at a time, use VERP.
Often combined with private header fields that carry additional information. Of
course you can't rely on getting the headers back in all cases, but you usually
do.
Depending on what is known about the domain MXs they open a set of
connections and send the mail.
Aka MX rollup. Unfortunately MX rollup runs afoul of things like systems that
only allow the specification of a single domain in a session. Caching
RCPTDOMAINMAX values may help with this, and make use of MX rollup more
automatable.
It's somewhat temping to add some sort of "the MXes pointing at this server
can be rolled up" indicator to the limits specification, but since it's not
a limit it doesn't really fit. If done it needs to be a separate EHLO
announcement.
Most of the bulk mail is sent with one RCPT TO:. This is true for marketing
mail
but even more true for transactional mail.
There's also per-recipient customization in the mix, both for personalization
and display tracking.
When our MLS is going thru a submission distribution, it has a transport to
SMTP or create UUCP-ready files option. The former method gets to learn
from
the SMTP receiver RCPT responses where a permanent 5yz result could
unsubscribe
the user after a number of consecutive different message times. Any
permanent
negative results with the intention of just being a limit could be
interpreted
as a user does no longer exist.
I may have agreed with you a decade ago. But that’s not true for modern bulk
senders. Bounces are classified and sorted. We are long past the days where
any
permanent negative result is interpreted as a user no longer exists.
(https://wordtothewise.com/2019/11/theres-something-about-bounces/)
Packages like Simimai exist for a reason.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp