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.

Related Posts

Thoughts on Gmail and the inbox

Over the last few months more and more marketers are finding their primary delivery challenge is the Gmail inbox. I’ve been thinking about why Gmail might be such a challenge for marketers. Certainly I have gotten a lot of calls from people struggling to figure out how to get into the Gmail inbox. I’ve also seen aggressive domain based filtering from Gmail, where any mention of a particular domain results in mail going to the bulk folder.
It’s one of those things that’s a challenge, because in most of these cases there isn’t one cause for bulk foldering. Instead there’s a whole host of things that are individually very small but taken together convince Gmail that the mail doesn’t need to be in the inbox.
A pattern that I’m starting to see is that Gmail is taking a more holistic look at all the mail from a sender. If the mail is connected to an organization, all that mail is measured as part of their delivery decision making. This is hurting some ESPs and bulk senders. I’ve had multiple ESPs contact me in the last 6 months looking for help because all their customer emails are going to bulk folder.
Gmail’s filtering is extremely aggressive. From my perspective it always has been. I did get an invite for a Gmail account way back in the day. I moved a couple mailing lists over to that account to test it with some volume and discussion lists. I gave up not long after because no matter what I did I couldn’t get gmail to put all the mail from that list into the tag I had set up for it. Inevitably some mail from some certain people would end up in my spam folder.
Gmail has gotten better, now they will let you override their filters but give you a big warning that the message would have been delivered to spam otherwise.
Gmail_NotSpam
What are mailers to do? Right now I don’t have a good answer. Sending mail people want is still good advice for individual senders. But I am not sure what can be done about this ESP wide filtering that I’m starting to see. It’s possible Gmail is monitoring all the mail from a particular sender or ESP and applying a “source network” score. Networks letting customers send mail Gmail doesn’t like (such as affiliate mail or payday mail, things they mentioned specifically at M3AAWG) are having all their customers affected.
I suspect this means that ESPs seeing problems across their customer base are going to have to work harder to police their customers and remove problematic mail streams completely. Hopefully, ESPs that can get on the Gmail FBL can identify the problem customers faster before those customers tank mail for all their senders.

Read More

Abuse it and lose it

Last week I blogged about the changes at ISPs that make “ISP Relations” harder for many senders. But it’s not just ISPs that are making it a little more difficult to get answers to questions, some spam filtering companies are pulling back on offering support to senders.
For instance, Cloudmark sent out an email to some ESPs late last week informing them that Cloudmark was changing their sender support policies. It’s not that they’re overwhelmed with delisting requests, but rather that many ESPs are asking for specific data about why the mail was blocked. In December, Spamcop informed some ESPs that they would stop providing data to those ESPs about specific blocks and spam trap hits.
These decisions make it harder for ESPs to identify specific customers and lists causing them to get blocked. But I understand why the filtering companies have had to take such a radical step.
Support for senders by filtering companies is a side issue. Their customers are the users of the filtering service and support teams are there to help paying customers. Many of the folks at the filtering companies are good people, though, and they’re willing to help blocked senders and ESPs to figure out the problem.
For them, providing information that helps a company clean up is a win. If an ESP has a spamming customer and the information from the filtering company is helping the ESP force the customer to stop spamming that’s a win and that’s why the filtering companies started providing that data to ESPs.
Unfortunately, there are people who take advantage of the filtering companies. I have dozens of stories about how people are taking advantage of the filtering companies. I won’t share specifics, but the summary is that some people and ESPs ask for the same data over and over and over again. The filtering company rep, in an effort to be helpful and improve the overall email ecosystem, answers their questions and sends the data. In some cases, the ESP acts on the data, the mail stream improves and everyone is happy (except maybe the spammer). In other cases, though, the filtering company sees no change in the mail stream. All the filtering company person gets is yet another request for the same data they sent yesterday.
Repetition is tedious. Repetition is frustrating. Repetition is disheartening. Repetition is annoying.
What we’re seeing from both Spamcop and Cloudmark is the logical result from their reps being tired of dealing with ESPs that aren’t visibly fixing their customer spam problems. Both companies are sending some ESPs to the back of the line when it comes to handling information requests, whether or not those ESPs have actually been part of the problem previously.
The Cloudmark letter makes it clear what they’re frustrated about.

Read More

IP reputation and email delivery

IP reputation is a measure of how much wanted mail a particular IP address sends.  This wanted mail is measured as a portion of the total email sent from that IP. Initially IP reputation was really the be all and end all of reputation, there was no real good way to authenticate a domain or a from address. Many ISPs built complex IP reputation models to evaluate mail based on the IP that sent the mail.
These IP reputation models were the best we had, but there were a lot of ways for spammers to game the system. Some spammers would create lots of accounts at ISPs and use them to open and interact with mail. Other spammers would trickle their mail out over hundreds or thousands of IPs in the hopes of diluting the badness enough to get to the inbox. Through it all they kept trying to get mail out through reputable ESPs, either by posing as legitimate customers or compromising servers.
These things worked for a while, but the ISPs started looking harder at the recipient pool in order to figure out if the interactions were real or not. They started looking at the total amount of identical mail coming from multiple IP addresses. The ISPs couldn’t rely on IP reputation so they started to dig down and get into content based filtering.
As the ISPs got better at identifying content and filtering on factors other than source IP, the importance of the IP address on inbox delivery changed. No longer was it good enough to have a high reputation IP sending mail.
These days your IP reputation dictates how fast you can send mail to a particular ISP. But a high reputation IP isn’t sufficient to get all the mail in the inbox. It’s really content that drives the inbox / bulk folder decisions these days.
 
Generally IPs that the ISP has not seen email traffic from before start out with a slight negative reputation. This is because most new IPs are actually infected machines. The negative reputation translates to rate limiting. The rate limiting minimizes people getting spam while the ISP works out if this is a real sender or a spammer.
Some ISPs put mail in the inbox and bulk foldering during the whitelisting process. In this case what they’re doing is seeing if your recipients care enough about your mail to look for it in the bulk folder. If they do, and they mark the mail as “not spam” then this feeds back to the sender reputation and the IP reputation.
If you’re seeing a lot of bulk foldering of mail, it’s unlikely there’s anything IP reputation based to do. Instead of worrying about IP reputation, focus instead on the content of the mail and see what you may need to do to improve the reputation of the domains and URLs (or landing pages) in the emails.

Read More