On 7/23/2022 1:17 AM, Laura Atkins via mailop wrote:
On 23 Jul 2022, at 05:18, Bill Cole via mailop <mailop@mailop.org> wrote:
On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400)
Luis E. Muñoz via mailop <mailop@lem.click>
is rumored to have said:
On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote:
I question your assertion that "bounces for X sender doesn’t mean
that it shouldn’t be mailed for Y sender". If recipient R has a
history of blocking many senders, continuing to send from other
senders is not worth it in the long run for the ESP. Just as
receivers reject with errors such as "this account is receiving
email at a rate that...", the ESP could respond to its client with
"this receiver has a history of bounces / rejections / complaints
that is incompatible with our policies...".
If only we had a framework for error codes in SMTP that carry useful
semantics...
I agree, it would have been nice if the authors of 821 and 822 had
considered this use case and provided us with semantics.
Unfortunately, the semantics described in those RFCs (and their
successors) only talk about what to do with the message that is
rejected. There are no semantics or recommendations about what to do
with future messages to the addresses that failed to accept the mail.
I recently had occasion to review the text for basic SMTP reply code and
was intrigued to be reminded that it does not actually and definitively
state that a given address does not exist. Not a relevant concern,
here, but another example of information not provided.
There are many reasons a particular address does not work and many of
those reasons have nothing to do with the handling of other addresses at
that site.
To the extent that a bulk sender wants to formulate a broader
assessment, across addresses, that's their private heuristic, based on
all manner of non-standardized information. It's not something that can
be built into an SMTP reply model.
d/
ps. But yes, it is really remarkable just how little the authors of 821
and 822 anticipated being needed, 40 years later...
pps. It is common to hear complaints about how little the originators of
Internet tech considered security. Comments almost never note that the
hardware of the day could not support large-scale use of encryption...
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
