Bounces

There’s something about bounces

I’ve shared a version of this image repeatedly. I think it was only my Facebook friends that got the stick figure screaming in frustration, though.

New Deliverability Resource

The nice folks over at Postmark shared a new deliverability resource last week. The SMTP Field Manual. This is a collection of SMTP responses they’ve seen in the wild. This is a useful resource. They’re also collecting responses from other senders, meaning we can crowdsource a useful resource for email deliverability folks.

Share your average bounce rates

The question came up on slack this morning about bounce rate benchmarks. What are the normal / average bounces that different ESPs see? Does region matter? What’s acceptable for bounce rates?

Undelivered mail without a bounce

A few weeks ago I wrote a blog post focusing on one small part of bounce handling. Today I want to talk about delivery failures that aren’t bounces. This is really the biggest issue for companies who have written their own bulk sending servers. Modern bulk MTA appliances and ESPs correctly handle these types of bounces. However, when you’re troubleshooting it’s important to know that sometimes there won’t be a SMTP level bounce.

What’s a bounce?

Bounces and bounce handling is one of those topics I’ve avoided writing about for a long time. Part of my avoidance is because there are decades of confusing terminology that hasn’t ever been really defined. Untangling that terminology is the first step to being able to talk sensibly about what to do. Instead of writing a giant long post, I can break it into smaller, more focused posts.

Engagement drives deliverability

Return Path released an white paper today offering the Secrets of Successful Senders. I don’t think any of my readers will be surprised that it boils down to identity, reputation, and engagement. Return Path treats these as separate things and I understand why they do. I think however, that the identity and reputation are supporting players to the overarching issue of engagement.

When I’m dealing with clients and troubleshooting deliverability problems and offering solutions, I focus on the root cause. To me the root cause is almost always a data problem. Either there’s a problem with data collection or there’s a problem with data maintenance. These problems result in mail going to people who don’t really want or care about it.
Yes, identity is important. But, realistically, anyone mailing through a decent ESP has SPF and DKIM in place, at least on some level. There may be better ways to authenticate, but the boxes are checked.
Yes, reputation is important. But here’s the thing, reputation just means that the ISP knows how users are going to react to an email. Reputation isn’t some nebulous concept made up by ISPs. It’s an actual measurement. It quantifies the history of an IP or a domain or a mail stream and says we know that this IP sends wanted mail. We know that this domain sends mail our users ignore. It’s a history. Past performance does indicate future results.
Identity says who a sender is. Reputation tells us that sender’s history of sending. Those are the two factors that enable ISPs to make delivery decisions. Mail comes in and the ISP looks at it. They use identity to determine what reputation to assign to a mail. Reputation drives delivery, whether into the inbox or the bulk folder.

March 2017: The Month in Email

It’s that time again… here’s a look at our last month of blog posts. We find it useful to recap each month, both to track trends and issues in email delivery and to provide a handy summary for those who aren’t following along breathlessly every single day. Let us know if you find it useful too!

As always, I wrote about email filters. It’s so important to recognize that filters aren’t arbitrary — they’re detailed instructions that help meet specific user needs, and the more you are cognizant of that, the better you’ll be able to work with them. Additionally, filters aren’t perfect and likely never will be. False positives and false negatives are frustrating, but as long as spam is still a viable business for spammers, they’ll continue to figure out how to work around filters. As such, we can’t expect filters to be 100% accurate in determining what constitutes wanted and unwanted mail.
Part of this, of course, is due to the problem of fraudulent signups. Companies aren’t particularly vigilant about address acquisition and hygiene, and as a result, they’ll claim you “signed up” for their email when you did not. Some people believe that a confirmed opt-in (COI) will solve this problem, but our experience is companies are reluctant to leave revenue on the table, and that they will continue to mail to addresses that have not confirmed.
Address sharing and co-reg is also part of the problem. As we saw in the extensive RCM data breach, many major brands continue to work with third-party senders to send mail in ways that are quite clearly spam. And in more criminal activity, I looked at the rise of botnets and how some of those criminals were brought to justice. In other justice news, there’s been an indictment in the Yahoo breach and another CASL enforcement action.
I wrote a post about bounce handling and “relaying denied” error messages, which are quite rare. It’s useful to have an understanding of these and other error messages, since bounces are sometimes indicative of a larger technical issue, such as when AOL accidentally bounced all messages for a short period last week. Speaking of AOL, we noted that there’s no official timeline for the move from Verizon addresses to AOL addresses following the 2015 acquisition, but it may be worth considering asking your customers to update their addresses.
Spam and filters aren’t the only factors of course. It can be challenging to figure out the multiple factors that make up the black box of delivery. And of course, the most important part of delivery continues to be engagement, engagement, engagement.
I wrote a few posts this month on why I do what I do, and why it’s so important to me. First, I wrote about A Day Without A Woman, and my choice not to participate in offering advice and guidance for that day. The truth is that I enjoy sharing what I know and helping people solve problems. I was honored to be named one of 11 Innovators in Email, and I know that my volunteer work in the industry and my unpaid blogging work is a big part of that. It may sound corny, but I really do believe we are on the front lines of the fight of good vs. evil online, and despite the distractions of politics and world events, we must all continue to do our part.

AOL accidentally hard bounces valid mail

Last night (Mar 29, 2017) between about 8pm Eastern and 9:30pm Eastern AOL suffered a technical issue. Every email sent to them received a “Recipient address rejected” reply. One example of the error message:
Mar 29 20:45:12 p2-lvmail11 lsb1-99-208-250/smtp[22251]: A88DFC2DBE9: to=<redacted@aol.com>, relay=mailin-01.mx.aol.com[64. 12.91.195]:25, delay=0.18, delays=0.01/0/0.14/0.03, dsn=5.1.1, status=bounced (host mailin-01.mx.aol.com[64.12.91. 195] said: 550 5.1.1 <redacted@aol.com>: Recipient address rejected: aol.com (in reply to RCPT TO command))
The issue was brought to AOLs attention and things were fixed rapidly after that. An AOL representative has stated that these were invalid replies and that addresses do not need to be removed from future emails.
Most of the ESPs are aware of this and are working to restore any bounced addresses to their users. At some places this requires manual intervention, so it’s taking some time to get all the addresses restored.
This is one of the reasons that our best bounce handling recommendations are not to remove an address for a single bounce – sometimes the ISPs have technical problems. Like the time a routing failure meant a major ISPs MX machines couldn’t reach their authentication servers to get the list of active users. Or the time all an ISPs MXs were removed from DNS. A lot of the internet is still managed manually, and despite extensive safeguards put in place bad things can, and do, still happen. Usually these problems are resolved quickly and mail starts flowing again.
Morning advice: Do not deactivate addresses that bounced at AOL last night.

Relaying Denied

I’ve got multiple clients right now looking for insights about bounce handling. This means I’m doing a lot of thought work about bounces and what they mean and how they match up and how different ISPs manage delivery and how different ESPs manage delivery and how it all fits together. One thing I’ve been trying to do is contextualize bounces based on what the reason is.
Despite what people may thing, spam filtering isn’t the only reason an email fails to deliver. There are lots of other reasons, too. There is a whole category of network problems like routing issues, TCP failures, DNS failures and such. There are address issues where a recipient simply doesn’t exist, or is blocking a particular sender. There are spam and authentication issues. The discussion of all these issues is way longer than a blog post, and I’m working on that.
One of the interesting bounces that is so rare most people, including me, never talk about is “Relaying Denied.” This is, however, one of the easier bounces to explain.
Relaying Denied means the mail server you’re talking to does not handle mail for the domain you’re sending to.
Well, OK, but how does that happen?
There are a couple reasons you might get a “Relaying Denied” message, most of them having to do with a misconfiguration somewhere. For whatever reasons, the receiving server doesn’t handle mail for a domain.
DNS records are incorrect. These can be due to a number of things

Vague reports of Yahoo problems

A number of people, on different forums, have been asking if anyone is seeing a higher bounce rate than usual with Yahoo. Not sure exactly what’s going on here. As I understand it, folks are talking with Yahoo about it. If I hear anything more, I’ll share.
For now, though, if you’re seeing a small increase in Yahoo bounces (or other weirdnesses) others are seeing something odd, too.

Bounce handling is hard

Sometimes I find it hard to find a new topic to write about. I decide I’m going to write about X and then realize I did, often more than once. Other times I think I can blog about some issue only to realize that it’s too complex to handle in a quick post. There are concepts or issues that need background or I have to work a little harder to explain them.
One thing I haven’t blogged about before is bounce handling. That particular topic falls into the other category of posts that take a lot of time to write and need a significant amount of work to make sense. I was even joking with my fellow panel members at EEC a few months ago about how that’s a post that so needs to be written but I’m avoiding it because it’s so hard. There’s so much to be conceptualized and explained and I realize it’s not a blog post but multiple blog posts, or a white paper or even a book.

So let’s start with some simple definitions. Those of you who work at ISPs are probably thinking of bounces in terms of accept than reject, that’s not exactly what I’m talking about here. I’m writing these for senders, who usually call rejects during the SMTP transaction bounces.

Changes coming to Verizon email

Last year Verizon bought AOL. As part of that merger some @verizon.net email is being migrated to the AOL backend. FAQs published by Verizon say this change is only affecting users in FL, TX and CA. Users will still have @verizon.net addresses but the backend and filtering will be managed by AOL.
This shouldn’t have a huge impact on commercial senders. However, one thing I did notice while reading through the FAQ is this:

Asynchronous Bounces

There are three ways that an email can fail to be delivered:

Yahoo DMARC articles worth reading

There are a bunch of them and they’re all worth reading.
I have more to say about DMARC, both in terms of advice for senders and list managers affected by this, and in terms of the broader implications of this policy decision. But those articles are going to take me a little longer to write.
How widespread is the problem? Andrew Barrett publishes numbers, pulled from his employer, related to the number of senders using @yahoo.com addresses in their commercial emails. Short version: a low percentage but a lot of users and emails in raw numbers.
What can mailing list managers do? Right now the two answers seem to be stop Yahoo.com addresses from posting or fix your mailing list software. Al has posted how he patched his software to cope, and linked to a post by OnlineGroups.net about how they patched their software.
A number of people are recommending adding an Original Authentication Results header as recommended in the DMARC.org FAQ. I’m looking for more information about how that would work.
For commercial mailers, there doesn’t seem to be that much to do except to not use @yahoo.com address as your header-From address. Yes, this may affect delivery while you’re switching to the new From address, but right now your mail isn’t going to any mailbox provider that implements DMARC checking.
One other thing that commercial mailers and ESPs should be aware of. Depending on your bounce handling processes, this may cause other addresses to bounce off the list. Once the issue of the header-From address is settled, you can reactivate addresses that bounced off the list due to authentication failures since April 4.

Example bounces due to Yahoo p=reject

There are a number of different bounces that people are reporting due to Yahoo publishing a DMARC record of p=reject. I decided to put some of those bounces here so confused users could find out what they needed to do.
Comcast

Increase in bounces at Y!

I’ve been seeing reports over the last few days about an increase in bounces at Yahoo. Reliable people are telling me they’re seeing some increase in “invalid user” bounces.
You may remember Yahoo announced an overhaul of their mail product back in December. Reliable sources tell me that this is more than just interface revamp. In the back end, Yahoo! is removing older products with few users and security problems. This fits in with the changes CEO Mayer has been making with the company: slim down and stop supporting unprofitable products.
It makes sense that while engineers are looking at the guts of the email program and cleaning up the cruft, they will also disable long unused email addresses. This will result in higher unknown users for some senders.
What’s interesting to me is that the reports are somewhat sporadic. Some senders are seeing a huge percentage of bounces, some are seeing the normal percentage. I expect this difference isn’t anything more than how actively a sender purges based on engagement. Senders that purge unengaged addresses are going to have already removed a lot of the addresses Yahoo! is now purging from their database. Senders that keep sending to their whole list, are going to see a lot of unknown user bounces.
I’ve asked a few folks and people who’ve responded told me that spot checks showed all the addresses turning up as invalid had no engagement for long periods of time.
If you are seeing a lot of bounces at Yahoo! over the last few days, you need to remove those addresses from your lists. I also recommend looking at the engagement statistics of these newly purged recipients. This will tell you, approximately, what an abandoned address profile looks like. You can use that information to make good decisions about purging unengaged users at other ISPs as well. Not only does this lower costs, because you’ll be sending to less non-responsive email addresses, it will also improve delivery at many ISPs.

Thoughts on bounce handling

This week’s Wednesday question comes from D.

What are your thoughts on bounce handling
Read More

Mail problems at AOL

We cannot help endusers troubleshoot AOL connection problems. Please do not call. Please do not write. You need to talk to AOL. We are not AOL. We cannot help you.

Broken record…

The Return Path In the Know blog listed 4 reasons mailing those old addresses is a bad idea.
Ashley, the author, is completely right and I endorse everything she said. (Although I’d really like to hear what happened to the customer that added back all those addresses. What was the effect on that campaign and future email marketing?) As I was reading the article though, I realized how many times this has been said and how depressing it is that we have to say it again. And again. And again.
A number of folks have told me that the reason they don’t pay any attention to delivery professionals is because we don’t provide enough real data. They can show that sending mail to old addresses costs them nothing, and makes them real money.
That’s not really true, though. We do provide data, they just don’t like it so they don’t listen to it. Return Path publishes lots of numbers showing that mailing unengaged recipients lowers overall delivery. I can provide case studies and data but companies that are committed to sending as much mail as possible throw up many reasons why our data isn’t good or valid.
The biggest argument is that they want hard numbers. I do understand this. Numbers are great. Direct and clear answers are wonderful. But delivery is a squishy science. There are a lot of inputs and a lot of modifiers and sometimes we can’t get exactly one answer. The data is noisy, and difficult to replicate. One of the reasons is that filtering is a moving target. Filters are not, and cannot be, fixed. They are adaptive and are changing even between one hour and the next.
Delivery experts are about risk management. They are the parents requiring everyone in the car wear seat belts, even though the driver has never had an accident. They are the fire department enforcing fire codes, even though it’s the rainy season.
Risk management isn’t about the idea that bad things will absolutely happen but rather that it is more likely that a bad thing will happen in some cases.
In this case, it’s more likely that delivery problems will happen when mailing old addresses. And if those addresses aren’t actively contributing to revenue, it’s hard to argue that their presence on a list is more beneficial than their absence.
But I repeat myself. Again.

AOL bounces and false positives

A number of people have been seeing an increase in AOL bounces over the last few days. Some of these are the new rejection 554/421 CON:B1 message. This is, basically, you’ve topped our thresholds, back off.
The other one is a bit more interesting. The error message a lot of people are seeing is 554/421 RLY:SN. Senders should only be getting this error message when they are sending email from a banned address.

Bounces, complaints and metrics

In the email delivery space there are a lot of numbers we talk about including bounce rates, complaint rates, acceptance rates and inbox delivery rates. These are all good numbers to tell us about a particular campaign or mailing list. Usually these metrics all track together. Low bounce rates and low complaint rates correlate with high delivery rates and high inbox placement.

Data hygiene and bouncing zombies

There are a number of folks who tell me there can be no zombie addresses on their lists, they aggressively remove any address that bounces. The problem is that zombie addresses don’t bounce, at least not always. And even when ISPs say they have a policy to bounce email after a certain period of time with no access, that’s not always put into practice.
How do I know that ISPs don’t always deactivate addresses on the schedules they publish? Because I have seen addresses not be deactivated.
I have addresses in a lot of places that I go for long periods of time not checking. It’s rare that they’re taken from me or reject mail – most of the time they’re special test addresses I use when diagnosing issues. This post is based on my experiences with those addresses and how abandoned addresses are treated at some ISPs.
For Gmail I have two examples of addresses not being deactivated.
In July 2011, we set up a test address to look at how Gmail was handling authentication. We sent a matrix of different test emails to it, with valid and invalid SPF and DKIM signatures. We pulled the data from the account. I don’t know for certain when the last time I logged in, but it was August or September of last year. So we have an address that has been dormant since September 2011.
I just sent mail to the account and google happily accepted it.
Mar 2 07:03:22 misc postfix/smtp[11770]: 11CA12DED3: to=<wttwtestacct@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.127.27]:25, delay=1.8, delays=0.25/0.02/0.56/0.93, dsn=2.0.0, status=sent (250 2.0.0 OK 1330700602 x8si8608852pbi.66)
I have another google account (apparently) that my records show I set up sometime in 2010. The login info was saved October 2010. I don’t know when the last time I logged in was, but given I’d forgotten the existence of the account it’s a good bet that it has been more than a year. That account is also accepting mail as of today.
Mar 2 07:06:25 misc postfix/smtp[11836]: 8D90C2DED3: to=<phphendrie@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.127.27]:25, delay=1.6, delays=0.26/0.02/0.68/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK 1330700785 a8si4075740icw.96)
For Hotmail I also have quite a bit of history and information. I signed up for my first Hotmail account in 1997. That was an account I used the address to post to usenet, but I didn’t actually use it for mail. I’d check it occasionally (usually when someone said in the newsgroup that they were going to email me) but it wasn’t an address I used regularly. As I moved from posting regularly in usenet, I started checking that account even less.
For a while, if I went more than 6 months checking my Hotmail account they would make me “re-claim” it. What would happen when I’d log in is I’d get a message along the lines of “well, we disabled this account due to inactivity, do you want it back?” I’d say yes, have to go through the setup process again and it would be my account. Mail was deleted during the disabling, and I am guessing they rejected anything new going to that account. I went through this dance for 4 or 5 years. I even had my calendar set to remind me to login every 6 months or so. There was some sentimental value to the address that kept me logging in. I have that same username at every major free ISP: Gmail, Hotmail, Yahoo and AOL, so it’s “my” address.
About 6 or 7 years ago, that behavior changed. I stopped getting the request to reclaim my account. Instead I could just log in. I’d still have mail (mostly spam as the address is on *lots* of lists and millions CDs). I still check it irregularly. I don’t have any idea when the last time I checked it was, but I think it’s been since at least November and probably longer back than that. Hotmail is still accepting mail for that address as well.
It’s anecdotal evidence, at best, but it ‘s the type of evidence that is acceptable even when it’s anecdotal. There are some addresses that are abandoned for long periods of time at the free mailbox providers and they’re are not all automatically pulled from the ranks of active addresses.
What does this mean for senders? It means that data hygiene has to go beyond just removing addresses that bounce. ISPs are not disabling addresses consistently enough for marketers to be able to trust that all addresses on their list are active just because they are accepting email.
This is the root of the recommendation to put in a hygiene program, this is why senders need to look at who is actually engaged with their brand and make some hard decisions about shooting zombies in the head.

Bounce handling simplified

I am a strong believer that bounce handling should be designed to remove addresses that have no human on the other end while not removing addresses that have a real recipient on the other end.
Bounce handling should be designed to appropriately manage your subscriber base. Delivery problems are the consequence if you don’t do that. They shouldn’t be the reason you bounce handle, though.
Context matters.
My experience tells me that senders that think about the impact of their sends can do things that “break the rules” while still being respectful of their subscribers and still see good delivery.

What's the best ESP?

I often get clients and potential clients asking me to tell them what the absolute best ESP is.
“You’re an expert in the field, which ESP will give me the best inbox delivery?”
The thing is, there isn’t an answer to that question.
ESPs have expertise in sending large amounts of mail. All have staff that manage and monitor MTAs. Most have staff that provide advice on delivery issues. Many have staff that handle abuse complaints, FBLs and blocks.
What they don’t have is magic delivery fairies or bat phones into postmaster desks.
Simply moving mail to an ESP won’t give you delivery. For the most part, delivery is the responsibility of the sender, whether they send mail through an in house system or through an ESP.
Delivery is primarily about how recipients react to a particular mail stream. Send mail recipients want, interact with and relate to and you usually see good delivery. The IP addresses or infrastructure contribute but do not dominate the equation. Sending from an ESP won’t fix poor content, irrelevant mail or unengaged recipients.
I can hear everyone now shouting at their screen “What about shared IPs!!!?!?!” Yes, yes, if you use an ESP with shared IP addresses and the ESP gets a bad customer you may see poor delivery for a time because one of their other customers was bad. It’s a fact, it happens. Plus, if you use an ESP with dedicated IPs and the ESP gets a bad customer you may see poor delivery for a time because one of the other customers was bad and their IP is near yours.
So clearly the answer is to bring email in house. That way no other company can affect your delivery, right? Yes. Kinda.
Are you willing to invest money in hiring email and DNS savvy sysadmins? Invest money in a MTA designed to handle bulk mail? Invest in an expert who not only understands bounce handling, but can explain to your developers what a good bounce handling system must do? Invest in someone who can manage authentication like DKIM? Who can handle delivery issues and understands how to talk to ISPs? Invest in development to write a FBL processor?
For some companies, the internal investment is the right answer, and bringing mail in house makes business sense.
For a lot of companies, though, they just want to use email to communicate with customers. They don’t want to have to invest in multiple staff members (as it’s very rare to find a single person with all the various skill sets needed) to just send a weekly newsletter, or daily sales email. They need a tool that works, they don’t need to know how to sign up for a FBL, they don’t need to know how to handle bounces. They can outsource that work and focus on the communication value.
Finding the best ESP starts with finding out how you want to use email.
Question 1: What role does email play in my business?

Don't think bounce handling is important?

James from Cloudmark has his own insight on spamtraps.

The importance of data hygiene

Over the weekend, one of the major ISPs purged a lot of abandoned accounts from their system. This has resulted in a massive increase in 550 user unknown bounces at that ISP. This ISP is one of those that uses bounces to feed into their reputation system and the purge may cause otherwise good senders to be blocked temporarily.
Talking to clients and other industry folks, it looks like the addresses that have newly bounced off had zero activity for at least 6 months. Nothing. Nada. No clicks. No opens. No interaction.
This is why data hygiene is so critical. Just because the emails are being accepted at the ISP, and even showing inbox placement at the mailbox monitoring companies does not mean that there is actually someone reading your email. Failure to look at overall data means that when an ISP bulk deletes abandoned accounts then bounces will increase. While I don’t expect this to have any real, long term effect on sender reputation I do expect that some senders with a lot of cruft on their list will see some short term delivery problems.
Companies that run re-engagement campaigns saw a whole lot less bouncing and even less blocking as a result of the purge. They were removing addresses that were non-responsive all along and thus didn’t have major deadwood on their list.
Ongoing data hygiene shows you what your list really is, not your list plus abandoned accounts. The addresses that the ISP purged? They were not valuable anyway. No one was reading that mail for at least 6 months.
If you did see a spike in bounces this weekend at a major ISP, you should really look at engagement. If some percentage of recipients at one ISP are actually non-existent, then it’s likely that about that same number are non-existent at other major ISPs as well. What are you going to do to identify and remove those dead addresses from your lists?

AOL transmitting 4xx error for user unknown

AOL is currently returning “451 4.3.0 <invaliduser@aol.com>: Temporary lookup failure” in some cases when they really mean “550 user unknown.” This message from AOL should be treated as 5xx failure and the message should not be retried (if at all possible) and the failure should be counted as a hard bounce for list management purposes.
This is something broken at AOL’s end, and the guys with the magic fingers that keep the system running are working to fix it. Right now there doesn’t seem to be an ETA on a fix, though.
Even if you are a sender who is able to stop the retries, you may see some congestion and delays when sending to AOL for the time being. Senders who don’t get the message, or who are unable to stop their MTAs from retrying 4xx mail will continue to attempt delivery of these messages until their servers time out. This may cause congestion for everyone and a noticeable slowdown on the AOL MTAs.
AOL blog post on the issue
HT: Annalivia

20% of email doesn't make it to the inbox

Return Path released their global delivery report for the second half of 2009. To put together the report, they look at mail delivery to the Mailbox Monitor accounts at 131 different ISPs for 600,000+ sends. In the US, 20% of the email sent by Mailbox Monitor customers to Return Path seed accounts doesn’t make it to the inbox. In fact, 16% of the email just disappears.
I’ve blogged in the past about previous Return Path deliverability studies. The recommendations and comments in those previous posts still apply. Senders must pay attention to engagement, permission, complaints and other policy issues. But none of those things really explain why email is missing.
Why is so much mail disappearing? It doesn’t match with the philosophy of the ISPs. Most ISPs do their best to deliver email that they accept and I don’t really expect that ISPs are starting to hard block so many Return Path customers in the middle of a send. The real clue came looking at the Yahoo numbers. Yahoo is one of those ISPs that does not delete mail they have accepted, but does slow down senders. Other ISPs are following Yahoo’s lead and using temporary failures as a way to regulate and limit email sent by senders with poor to inadequate reputations. They aren’t blocking the senders outright, but they are issuing lots of 4xx “come back later” messages.
What is supposed to happen when an ISP issues a 4xx message during the SMTP transaction is that email should be queued and retried. Modern bulk MTAs (MessageSystems, Port25, Strongmail) allow senders to fine tune bounce handling, and designate how many times an email is retried, even allowing no retries on a temporary failure.
What if the missing mail is a result of senders aggressively handling 4xx messages? Some of the companies I’ve consulted for delete email addresses from mailing lists after 2 or 3 4xx responses. Other companies only retry for 12 – 24 hours and then the email is treated as hard bounced.
Return Path is reporting this as a delivery failure, and the tone of discussion I’m seeing seems to be blaming ISPs for overly aggressive spamfiltering. I don’t really think it’s entirely an ISP problem, though. I think it is indicative of poor practices on the part of senders. Not just the obvious permission and engagement issues that many senders deal with, but also poor policy on handling bounces. Perhaps the policy is fine, but the implementation doesn’t reflect the stated policy. Maybe they’re relying on defaults from their MTA vendor.
In any case, this is yet another example of how senders are in control of their delivery problems. Better bounce handling for temporary failures would lower the amount of email that never makes it to the ISP. This isn’t sufficient for 100% inbox placement, but if the email is never handed off to the ISP it is impossible for that email to make it to the inbox.

Odd Yahoo Bounces

A number of people are reporting seeing a new bounce from Yahoo. “smtp;553 Mail from x.x.x.x not allowed – [10]”. My clients have been asking and other people have been asking about this. It seems that something is changing at Y! More information as I hear it.