SMTP Level Rejections

While discussing a draft of a Deliverability BCP document the issue came up of what rejections at different phases of the email delivery transaction can mean. That’s quite a big subject, but here’s a quick cheat sheet.
At initial connection
Dropped or failed connection:

  1. your reputation with the receiver is so bad that they don’t want to see any email from you, ever
  2. their mail server is badly overloaded and can’t accept any connections right now
  3. the server you’re connecting to isn’t a mail server – this is common with bad email addresses

Temporary (4xx) failure:

  1. your reputation with the receiver is poor or unknown and they’re waiting for more information before they’ll accept your mail
  2. the mail server is overloaded and can’t accept any new mail right now
  3. your reputation is “grey”, the mail server is overloaded and it’s accepting mail preferentially from other senders right now
  4. there is something technically wrong with your mailserver, such as non-existent reverse DNS, and your mail won’t be accepted until you fix that

Permanent (5xx) failure:

  1. a 554 response can mean “there’s no mailserver here”. If someone has set up a mailserver specifically to reject connections this way, it’s probably been done for a domain that has a lot of bad delivery attempts. That might mean that the recipient email address is one that’s commonly used for fake signups, or it may be a common thinko address (e.g. something.com vs something.net)
  2. they’ve explicitly blocked all mail from your mailserver due to a poor reputation – this is a common way of implementing DNS blacklist based blocking

Any time

  1. when a mailserver is shut down, it may drop existing sessions with a 421 response
  2. if you violate SMTP – send a bad command, bad parameters, lines too long – you might get 5xx responses at any time

After HELO or EHLO

  1. a syntactically bad or obviously forged (e.g. yahoo.com) HELO hostname – unless you’re a spammer or have a badly misconfigured server, this probably shouldn’t happen

After MAIL FROM

  1. mail from a domain (or, in theory, return path) might be blocked here, but it’s more likely to be rejected at RCPT TO time

After RCPT TO
This is a favorite point to apply reputation based filtering, for several reasons. It’s the first point at which you know who the intended recipient is, and that’s a very useful thing to record to help with diagnosing spam filtering false positives. So even the mailserver has decided it’s going to reject a message, based on the IP address it’s being sent from, waiting until the RCPT TO to reject if will give better diagnostics. There may be special recipient addresses that are exempt from global filtering (such as role addresses), so that filtering can’t be applied until this step. Also, some mailing list managers historically don’t handle rejections before RCPT TO gracefully – they’ll keep retrying and won’t unsubscribe the user forever.
If a mailserver waits until after this point it either has to accept the entire email or unceremoniously crash the connection (which violates SMTP and will provoke a redelivery attempt, so is rarely seen).
Temporary (4xx) failure:

  1. the server is out of resources, and just needs you to come back later
  2. the server is low on resources and mail from you isn’t as important as mail from other senders right now,
  3. the overall volume of mail you’re sending has exceeded short term limits the receiver is applying to you (based on reputation) and it’s deferring mail so as to throttle your traffic
  4. there’s a temporary problem (DNS blacklist resolution, perhaps) in looking up your reputation
  5. your reputation is “grey”, the mailserver hasn’t decided whether your mail is likely to be wanted or not, and it’s letting a small fraction of your mail through, to see how recipients respond
  6. your reputation is “grey” or there isn’t enough information about you to make a delivery decision, so your mail is being deferred in the hope that there’ll be a clearer reputation decision when you try to redeliver it
  7. some combination of all the above

Permanent (5xx) failure:

  1. the recipient doesn’t exist – sometimes a bad address is just a bad address
  2. the source (IP address or domain) of the email has a poor reputation and mail is blocked
  3. there’s a per-recipient block on this email

After DATA

  1. the content of the message “looks like spam” – either because it looks similar to recently received unwanted messages or based on heuristics such as those used by spamassassin
  2. URLs in the message have a poor reputation (or resolve to IP addresses with poor reputation)
  3. DKIM signatures will be checked at this point, so if the mail would have been delivered due to DKIM-based whitelisting and the DKIM signature doesn’t validate that may cause rejection here
  4. DMARC failures
  5. virus or malicious content filters
  6. any of the reasons given for RCPT TO – some filters may defer any rejection until after data, either so as to be able to analyze the content of rejected messages, or because they use a simple architecture that does all it’s filtering at once,
  7. score-based filtering – based on combining everything the mailserver knows about this message, including the content

There’s probably something I’ve missed – call it out in the comments – but these are some of the things I think about when working out why a message has been rejected with an unhelpful error message.

Using Google to taunt coworkers
Spam is not a valid marketing strategy

Related Posts

ISPs speak at M3AAWG

Last week at M3AAWG representatives from AOL, Yahoo, Gmail and Outlook spoke about their anti-spam technologies and what the organizations were looking for in email.
This session was question and answers, with the moderator asking the majority of the questions. These answers are paraphrased from my notes or the MAAWG twitter stream from the session.
What are your biggest frustrations?
AOL: When senders complain they can’t get mail in and we go look at their stats and complaints are high. Users just don’t love that mail. If complaints are high look at what you may have done differently, content does have an effect on complaints.
Outlook: When we tightened down filters 8 years ago we had to do it. Half of the mail in our users inbox was spam and we were losing a steady number of customers. The filter changes disrupted a lot of senders and caused a lot of pain. But these days only 0.5% of mail in the inbox is spam.  Things happen so fast, though, that the stress can frustrate the team.
Gmail: Good senders do email badly sometimes and their mail gets bulked. Senders have to get the basic email hygiene practices right. Love your users and they’ll love you back.
What’s your philosophy and approach towards mail?
AOL: There is a balance that needs to be struck between good and bad mail. The postmaster team reminds the blocking team that not all mail is bad or malicious. They are the sender advocates inside AOL. But the blocking team deals with so much bad mail, they sometimes forget that some mail is good.
Yahoo: User experience. The user always comes first. We strive to protect them from malicious mail and provide them with the emails they want to see. Everything else is secondary.
Gmail: The faster we stop spam the less spam that gets sent overall. We have highly adaptive filters that can react extremely quickly to spam. This frustrates the spammers and they will give up.
Outlook: The core customer is the mailbox user and they are a priority. We think we have most of the hardcore spam under control, and now we’re focused on personalizing the inbox for each user. Everyone online should hold partners accountable and they should expect to be held accountable in turn. This isn’t just a sender / ESP thing, ISPs block each other if there are spam problems.
What are some of your most outrageous requests?
We’ve been threatened with lawsuits because senders just don’t want to do the work to fix things. Some senders try to extort us. Other senders go to the advertising execs and get the execs to yell at the filtering team.
Coming to MAAWG and getting cornered to talk about a particular sender problem. Some senders have even offered money just to get mail to the spam folder.
Senders who escalate through the wrong channels. We spent all this money and time creating channels where you can contact us, and then senders don’t use them.
Confusing business interests with product interests. These are separate things and we can’t change the product to match your business interest.
What are your recommendations for changing behaviors?
Outlook: We provide lots of tools to let you see what your recipients are doing. USE THE TOOLS. Pay attention to your recipient interaction with mail. Re-opt-in recipients periodically. Think about that mail that is never opened. Monitor how people interact with your mail. When you have a problem, use our webpages and our forms. Standard delivery problems have a play book. We’re going to follow that playbook and if you try to get personal attention it’s going to slow things down. If there’s a process problem, we are reachable and can handle them personally. But use the postmaster page for most things.
Gmail: Get your hygiene right. If you get your hygiene right, deliverability just works. If you’re seeing blocking, that’s because users are marking your mail as spam. Pay attention to what the major receivers publish on their postmaster pages. Don’t just follow the letter of the law, follow the spirit as well. Our responsibility, as an ISP, is to detect spam and not spam. Good mailers make that harder on us because they do thinks that look like spammers. This doesn’t get spammer mail in more, it gets legitimate mail in less. Use a real opt-in system, don’t just rely on an implied opt-in because someone made a purchase or something.
Yahoo: ESPs are pretty good about screening their customers, so pay attention to what your ESPs are saying. Send mail people want. Verify that the email addresses given to you actually belong to people who want your mail. Have better sender practices.
What do you think about seed accounts?
The panel wasn’t very happy about the use of seed accounts. Seeds are not that useful any longer, as the ISPs move to more and more personalized delivery. Too much time and too many cycles are used debugging seed accounts. The dynamic delivery works all ways.
When things go wrong what should we do?
AOL: Open a ticket. We know we’ve been lax recently, but have worked out of our backlog and are caught up to date. Using the ticketing system also justifies us getting more headcount and makes everyone’s experience better. Also, don’t continue what you’re doing. Pausing sending while you’re troubleshooting the issue. We won’t adjust a rep for you, but we may be able to help you.
Gmail: Do not jump the gun and open a ticket on the first mail to the spam folder. Our filters are so dynamic, they update every few minutes in some cases. Be sure there is a problem. If you are sure you’re following the spirit and letter of the sender guidelines you can submit a ticket. We don’t respond to tickets, but we work every single one. When you’re opening a ticket provide complete information and full headers, and use the headers from your own email address not headers from a seed account. Give us a clear and concise description of the problem. Also, use the gmail product forum, it is monitored by employees and it’s our preferred way of getting information to the anti-abuse team. Common issues lots of senders are having will get addressed faster.
Outlook: Dig in and do your own troubleshooting, don’t rely on us to tell you what to fix. The support teams don’t have a lot of resources so use our public information. If you make our job harder, then it takes longer to get things done. But tell us what changes you’ve made. If you’ve fixed something, and tell us, our process is different than if you’re just asking for a delisting or asking for information. When you’ve fixed things we will respond faster.
How fast should users expect filters to respond after making changes?
Filters update continually so they should start seeing delivery changes almost immediately. What we find is people tell us they’ve made changes, but they haven’t made enough or made the right ones. If the filters don’t update, then you’ve not fixed the problem.

Read More

Questions on Google lawsuit post

A couple questions in the previous discussion thread about the Google privacy case. Both concern permission granted to Google to scan emails.
Google’s stance about this is fairly simple.
Gmail users give explicit permission for their mail to be scanned.
People who send mail to Gmail users give implicit permission for their mail to be scanned.
The plaintiff’s lawyers are alleging that some subset of gmail users – specifically those at Universities that use Google apps and ISP customers like CableOne – did not give explicit permission for their mail to be scanned by Google. They’re also arguing no senders give permission.
In addition to the lack of permission, the plaintiffs lawyers are arguing that Google’s behaviour is in violation of Google’s own policies.
Google thinks scanning is part of the ordinary course of business and they’re doing nothing wrong.
This is an interesting case. I think anyone who knows about email understands that the people who run the mail server have the ability to read anything that goes through. But a lot of us trust that most postmaster and admin types consider it unprofessional to look at mail without a decent reason. There are good reasons an admin might need to go into a mail spool.
Automated filtering is simply a part of life on the internet these days. Mails have to be scanned for viruses, spam and, yes, they are scanned for targeted advertising. I’m not convinced Google is outside the norm when they say that any emails sent through Google is personal information given too Google and therefore Google can use that information in accordance with their policies.

Read More

Does email have a guarantee of delivery?

A client asked me earlier this week what SLAs ISPs provided for email delivery. The short answer is that there isn’t a SLA and that the only guarantee is that the email will get there when it gets there.
But as I was mentioning this to Steve, he pointed out that there was a recent change in the RFCs for email. In both RFC 821/2 and RFC 2821/2 (the original email related RFCs and the update in the early 2000’s) the RFCs stated that once a receiving MTA accepted an email that that MTA was required to either delivery the mail or generate an asynchronous bounce. While this isn’t a standard SLA, it does mean that a 2xy response after DATA meant the email would either be delivered to the user or be sent back to the sender. Despite the RFC requirements some receivers would still drop mail on the floor for various reasons, sometimes intentionally and sometimes not.
RFC 5321/2, the current SMTP standard, still says that once a server accepts the mail it must not lose that mail ‘for frivolous reasons.’ The RFC goes on to admit, though, that in recent years, SMTP servers are under a range of attacks and dropping mail on the floor is not frivolous in those cases.
 

Read More