On 2022-07-23 at 15:34:39 UTC-0400 (23 Jul 2022 15:34:39 -0400)
John Levine via mailop <jo...@taugh.com>
is rumored to have said:
It appears that Bill Cole via mailop
<mailop-20160...@billmail.scconsult.com> said:
If only we had a framework for error codes in SMTP that carry useful
semantics...
We do. That's what the enhanced error codes are for. See RFCs 1893 and
5248. A lot of them are quite informative, e.g. 5.2.2 mailbox full,
5.7.13 user account disabled, 5.5.3 too many recipients, or
5.7.28 mail flood detected.
Why, yes, I WAS quite aware of those... :)
Recipient systems don't have a whole lot of incentive to provide those
codes
because they correctly believe that most senders will ignore them, and
some
senders will use them to try to game their filters.
It is an academic issue at this point, IMHO, but I believe that the fear
of senders 'gaming' filters is not justified by evidence with volume, at
least not in modern times. It is very annoying to witness when it
happens, but the senders who try are not those who send a lot of wanted
mail, so simpler cheaper tactics make sense.
I believe it is mostly an academic issue at this point because I don't
see any real hope of MS/Google/Oath/GMX/etc. and Sendgrid/Constant
Contact/MailChimp/Epsilon all agreeing on the precise meanings and
proper reactions to extended reply codes. I don't see how doing better
on either side would make sense to the relevant parties by a strict
cost-benefit analysis. It is also complicated in theory by the privacy
law implications others have pointed out, and it is always cheaper to
keep doing what has always been good enough than to consult lawyers on
how you can do better without legal trouble.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
