On 2022-07-23 at 04:17:30 UTC-0400 (Sat, 23 Jul 2022 09:17:30 +0100)
Laura Atkins via mailop <la...@wordtothewise.com>
is rumored to have said:
On 23 Jul 2022, at 05:18, Bill Cole via mailop <mailop@mailop.org>
wrote:
[...]
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.
Right, but had the anti-spam world been less obsessed with concealing
sources and methods in the misty past we might have all actually used
the extended reply codes in a somewhat consistent way as designed to
send useful signals to senders about how to handle specific cases.
I don't have a solution for undoing the past 25 years. Maybe the big
players can agree on a set of extended replies and stick to it enough
that 'good' ESPs find it useful to pay attention to it. I do not have
the sort of skills to even guess if that can be done. Probably a job for
M3AAWG or some other cabal of 800-lb gorillas, if it can ever work at
all.
And on the receiving side it’s not much better. All too many
receiving mailservers don’t use the codes specified in the RFCs and
decide to use their own implementation. A very large ISP, for
instance, uses “451 this message will never deliver” as part of
their repertoire of bounces. Another widely used filter rejects
everything with 571 5.7.1 and in order to determine what the problem
is, the sender needs to visit a webpage to search for a specific code
in the text string of the bounce.
Yes, there are still oddballs out there doing ungovernable things with
reply codes. This is much less of an issue today than it used to be, as
the behemoths have eaten up most of the email that used to be delivered
by mail servers managed in 1/10th of a sysadmins' job. It is generally
safe to accept standard codes at their face value and even to infer
meaning beyond the current message in some cases. It may help to have
skilled staff whose job it is to suss out the meaning of some edge cases
and decide whether to accommodate oddballs or to let them fail. It can
be liberating to accept some mail not working because the recipient has
made a poor choice of email provider. It may help to have skilled staff
whose job it is to speak human-to-human with those people at receiving
sites that have made quirky reply code choices.
Again, anyone saying this is simple doesn’t understand the
complexities involved at scale and hasn’t thought about the
implications of what they’re asking senders to do.
Of course it's not simple. That's why skilled staff tends to be
well-compensated.
Consider the case where Microsoft spits out a incorrect and false 550
user unknown (which happens every couple years). What you’re
suggesting is that when this happens the next time, Gmail block every
gmail user from ever sending to those hotmail users at any point in
the future. That’s what you’re asking for.
I don't think I said that, this time... You may be recalling one of my
rants on this from over a decade ago. Today's facts on the ground are
different.
However, there's a lot of open space between trusting that every 550
means the user died and trusting that the 5th time a particular RCPT
gets a '550 5.1.1' reply with a diversity of senders is hard evidence of
the address being bogus. The traditional discussion list tools (Mailman,
ezmlm, etc.) have worked out a basic model that doesn't suck: keep
trying for a while, maybe even send an explicit probe via different
means, but don't just keep trying a probably-dead forever.
Unfortunately, it doesn’t take into account the actual realities of
sending at scale.
Many of which are grounded in how much businesses are willing to spend
on reaching customers at scale on a sustained basis. B2C ESPs (and their
clients, indirectly) have become addicted to cost scaling sub-linearly,
and that only works so far before things start looking sloppy to
receiving sites.
I am convinced that the business models of some ESPs are inconsistent
with generally acceptable sending behavior and profitability. As
businesses tend to draw the line at being unprofitable, the hard
problems of being good at scale get ignored because ultimately an ESP
can make money sending some proportion and types of spam, at least for
some time. That can look to ESPs and their business partners like a
viable choice. It's where they all live...
Better ESP behavior isn't free, and I would never dream of arguing that
it doesn't come with diseconomies of scale. For example, the lists I
work with (all strict COI) have almost no overlap in membership, so if
one bounce-triggered list unsub fails to unsub the same address from all
of the lists on the same system, no one notices because the address
isn't on any other list. Scale makes carelessness more visible to
individual sites, so in the Sendgrid class with thousands of customers
sending to millions of addresses an ESP needs to DO BETTER on average
than a boutique ISP with a few dozen Mailman lists with sub-thousand
user counts to maintain an acceptable reputation.
Doing better includes serious KYC practices, which means skilled staff
tasked with avoiding certain revenue. Very unpopular with ESPs. Better
bounce handling may also ultimately demand skilled staff to look at edge
and corner cases. However, simply taking reply codes as meaning what
they are supposed to mean per existing specifications and acting
reasonably on those meanings for sites known to reply sanely would be a
good first step.
This is actually a problem, one I’m working with various folks in
the industry to address in a way that preserves the functionality of
email.
Glad to hear that. I do not envy that work.
--
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
