Considerations for a New Bounce Code System | Port25 Solutions, Inc.
Fred Tabsharani

By port25admin

Considerations for a New Bounce Code System

On behalf of Port25, I would like to introduce our friend Mr. Ken Vaughn a PowerMTA admin for many years. He’s been kind enough to accept a role as a contributor to The Industry Pulse and is our guest blogger this week. He just penned this article on considering a new bounce code system: Please welcome Mr. Ken Vaughn. Thanks.

bouncecodes-481x230So you checked your logs and saw a 5.7.1 bounce code – that email bounced because it’s SPAM, right? Well…… maybe!? According to RFC 3463, *.7.1 is reserved for “Delivery not authorized, message refused”. Typically, that means your message was bounced as SPAM. But your message might not have even been analyzed. For instance, if your message bounced back from Yahoo that 5.7.1 code could mean that your sending IP is on the Spamhaus PBL. And so we can muddy the waters as quickly as possible, 5.7.1 isn’t the only code that you’ll see if your message was bounced as SPAM. You might see 5.0.0 with a more detailed explanation deeper in the header. Confused yet? You should be. And that is exactly how the ISPs want it.

What is going on?
When you send an email you need to know what happened to it on the receiving end: Was it delivered? Was it rejected? Was the recipient’s mailbox full? Is the address even valid? The way this is handled is through the use of Enhanced Mail System Status Codes (RFC 3463) – commonly called “bounce” codes. The problem is that while this RFC exists, not everyone follows it. Not even the most important codes – 5.1.1 and 5.1.2, both indicators that the email address is invalid – are not handled consistently across the board.

What should be done?
Despite what some would have you believe, email isn’t dying as a marketing vehicle. Recent acquisitions in the ESP/MAC markets indicate that the industry believes that email is as strong as ever. Big name players are buying up the premier email marketing firms as quickly as they can. Maybe with such big names finally owning the engines that drive legitimate email marketing we can put some pressure on the major ISPs to use a simplified and standardized set of bounce codes to make processing returned email easier, thus benefitting both sender and receiving ISP. To that end, the following proposal is humbly submitted to the community in hopes that it can be a kickoff point.

Simple Codes
In addition to the myriad variants on the standard and enhanced status codes, I’d like to see ISPs start adding a new piece of data to the bounce headers. Since legitimate email marketers tend to make strict decisions regarding list management, ISPs should return simple codes to allow those decisions to happen without the need for constant evaluation of ISP-dependent header codes. The following tables cover two scenarios – one for aggressively simplifying the bounce codes to handle the most important issues and one that is more moderate while still being simpler than the current system:

Aggressive Bounce Code Reduction Plan
This plan aggressively reduces bounce codes and is based on the concept that bad email addresses and SPAM bounces are the most important for an ESP/MAC to understand, allowing everything else to fall into one bounce category. As such it only follows the 2(OK)/4(Temporary)/5(Permanent) structure but uses different sub-codes within the Permanent bounces.

Screen Shot 2014-01-07 at 7.43.24 PM






Moderate Bounce Code Reduction Plan
This plan follows the basic outline of RFC 3463 while reducing the detail level of each section
Screen Shot 2014-01-07 at 7.43.50 PM









It’s a start
It isn’t a perfect solution, sure, but it’s a start. ESPs and MACs need to start pushing ISPs to standardize and simplify bounce codes for mass-sent email. And the ISPs should get excited about this concept because it stands the best chance of reducing their overhead when processing from certified ESPs/MACs.

9160 Guilford Rd // Columbia, MD 21046 // (410) 750-SMTP