8 things that make your mail look like spam

In the comments of last week’s Wednesday question John B. asked

Can you elaborate on specifics of “configure machines to not look like spam ware”?

There are a lot of things that spamware does that is different from a lot of standard MTAs. Here are a list of things that may make your mail look like it is running spamware to a receiving server.

  1. Using weird values for HELO/EHLO, like a bare IP or “localhost.” Both a bare IP and a non fully qualified domain name are violations of the SMTP spec. This is something a lot of poorly written spamware does, and there is no valid reason for a server to be doing either.
  2. Rotating HELO/EHLO values. Some poorly written software is configured to use a HELO/EHLO value pulled from the mail from address. If there are multiple domains sending mail from a MTA, this can cause different SMTP sessions to have different HELO/EHLO values. There is also spamware that will rotate through HELO/EHLO values as a way to avoid filters.
  3. Ignoring or incorrectly processing bounce messages. Spamware is notoriously bad about complying with the SMTP spec. For  instance, some spamware never retries on a 4xx response, but always retries on a 5xx response. This behaviour drove some receiving MTAs to overuse 4xx responses. However, correctly managing rejections is a feature of well configured software.
  4. Have incorrect time. There is a famous bit of spamware from the late 90s written by someone who didn’t understand timezones. There was a forged received line in the spamware that used EST -600 as a timezone. EST is never -600, and a lot of filters became quite sensitive to time issues. Make sure your server knows what time it is and correctly reports that time when sending mail, especially if there is an internal handoff.
  5. Domain fruit salad in the headers. There is spamware out there that will use a different domain for every part of the header. One domain in the Mail From: another in the visible From: a third in the rDNS, a fourth in the HELO value, a fifth in the internal handoffs, a sixth in the messageID, a seventh in the abuse reporting line, an eighth in the List-unsubscribe value. While there are valid technical reasons not to have every domain in the headers be identical, there are places where they should match, and spreading so many domains through the headers makes a sender look like it’s either spamware or a spammer trying to avoid filters.
  6. Hidden text in the body of the message. Spammers hide text in the body of the message, either in very-light-grey on white text, or in HTML style comments. There’s no problem with having a few comments in the HTML of a message but when those comments are longer than the actual text of the message, then there’s a problem.
  7. Fake, broken or otherwise invalid HTML tags. Spammers use fake HTML tags to confuse filters. They’re also notoriously bad about using correct tags. Make sure all HTML in the message is valid HTML.
  8. Encoding plain text in Base64. Another fabulous (well, not really) spammer trick is to use Base64 encoding to hide their plain text. This means a lot of filters are sensitive to encoding practices. Some filters even crack the encoding to see if there is anything that needs encoding in the email. If there isn’t, then the encoding is treated as filter evasion.

That’s a short list of things that legitimate mailers should never do. There are others, but the underlying issue is to comply with the SMTP spec and don’t do things that attempt to bypass and avoid filters.


  1. Karl says

    I’d have to think back . . . I can think of one email tool I have used where the email included the text version as well as the html version via mime. Are you saying that sending both text and html/mime versions in an email is more likely to get flagged?

  2. laura says

    No, proper multipart/alternative with a plain text part that mirrors the HTML part is not a spam sign. In fact, HTML only mail is much more likely to look like spam than multipart/alternative.

    The type of hiding I’m talking about is long swathes of text in HTML comments rather than multipart.


Your email address will not be published. Required fields are marked *

  • Lost in the mists of time

    Over on the Farsight Security blog Joe St. Sauver talks about some of the early days of online abuse, on usenet. Laura and I were on the periphery of early usenet abuse, mostly as users, but Usenet (and IRC) around then were the places we both started with email abuse.No Comments

  • Ongoing Yahoo delays

    I've been hearing from folks over the last few days that they're seeing an uptick in deferrals from Yahoo! The deferrals are not uniform. ESPs report they're seeing some, but not all, customers affected. Other ESPs aren't seeing any changes. It's not just you. But it would be very worthwhile to dig into engagement and other stats. It's possible this is a new normal at Yahoo! and they're tightening filters to catch mail that doesn't fit their standards but was previously difficult to filter.No Comments

  • AOL starts using Sender Score Certification

    Good news for Sender Score Certified IPs. Return Path recently announced that AOL has joined the list of ISPs offering preferential treatment to certified IPs.  1 Comment