Mailing lists and bounce handling (or not handling bounces) today

December 16, 2020

Traditionally, if you ran a proper mailing list you were supposed to remove addresses if they started bouncing (or being rejected). The need to automate this was the major reason behind email tricks like Variable envelope return path (VERP), where email to every separate address is sent with a unique envelope sender (and so has to be sent in a separate transaction, instead of letting you batch together multiple 'RCPT TO' addresses at a single destination). There's always been a little bit of an open question about how rapidly you should remove failing addresses, because things happen, but the traditional view (one I've echoed myself) is that you shouldn't let bouncing addresses linger for long.

Then we started having incidents like GMail's major failure yesterday:

It appears that a whole bunch of people are about to discover the downside of various GMail failure modes, and also a bunch of other people are going to stop treating SMTP 5xx bounces as reasons to remove people from mailing lists and so on.

(Since ~4pm Eastern we're seeing GMail '550 no such account' on well established GMail addresses for some but not all deliveries.)

If GMail is going to randomly reject well established email addresses for a third of a day or so every so often, why should you be in any rush to remove failing GMail addresses from your mailing lists? This is even (and especially) the case if the bounces claim that the address doesn't exist; as we've just seen, this rejection reason itself is unreliable from one of the biggest email providers on the planet.

Today, the only thing an email bounce means is 'I'm not accepting this particular piece of email from you right now'. Probably the receiving email system will continue to reject that particular email if it's resubmitted in the future, but not always. There is certainly no strong reason to believe that different email in the future won't be accepted.

If bounces are mysterious, random, and not necessarily predictive of future results, it's pretty reasonable to not use them for anything. It would be nice if people attempt to draw inferences from patterns in bounces (such as 'this email address has never accepted any of our email'), but that takes much more work, tracking of information, and tuning than pretty much ignoring bounces.

(Of course if places like GMail start scoring your email badly if you keep repeatedly sending email that they bounce, then people will go to the work. For GMail. Not necessarily for anyone else.)

I'm not really fond of this result. I would like bounces to be a reliable sign that addresses should be removed from lists, and I would like mailing lists (and databases of email addresses) to remove addresses that bounce. But I can't say that bounces are such a clear reliable sign any more.

Comments on this page:

By Andrew at 2020-12-17 01:25:20:

Of course, what happened to Google is that their system for figuring out whether users exist or not died, and apparently in a way that caused most of the consuming systems to decide confidently that the answer was "no".

Written on 16 December 2020.
« How to make Grafana properly display a Unix timestamp
Limiting the Nouveau kernel driver's messages via removal »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Dec 16 22:56:52 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.