BLOG

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.

2 comments

  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.

Comment:

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

  • ReturnPath on DMARC+Yahoo

    Over at ReturnPath Christine has an excellent non-technical summary of the DMARC+Yahoo situation, along with some solid recommendations for what actions you might take to avoid the operational problems it can cause.No Comments


  • AOL problems

    Lots of people are reporting ongoing (RTR:GE) messages from AOL today.  This indicates the AOL mail servers are having problems and can't accept mail. This has nothing to do with spam, filtering or malicious email. This is simply their servers aren't functioning as well as they should be and so AOL can't accept all the mail thrown at them. These types of blocks resolve themselves. 1 Comment


  • Fixing discussion lists to work with new Yahoo policy

    Al has some really good advice on how to fix discussion lists to work with the new Yahoo policy. One thing I would add is the suggestion to actually check dmarc records before assuming policy. This will not only mean you're not having to rewrite things that don't need to be rewritten, but it will also mean you won't be caught flat footed if (when?) other free mail providers start publishing p=reject.No Comments


Archives