Can we put the FREE!!! Myth to bed?

Really. Single words in the subject line don’t hurt your delivery, despite many, many, many blog posts out there saying they do. Filters just don’t work that way. They maybe, sorta, kinda used to, but we’ve gotten way past that now.
In fact, I can prove it. Recently I received an email from Blizzard. The subject line:
Laura — Last Chance to Claim Your FREE Copy of Warlords of Draenor — Including Level 90 Boost! Offer Expires Monday! Last Chance to Claim Your FREE Copy of Warlords of Draenor — Including Level 90 Boost! Offer Ends Monday!
We have an email with

… two instances of FREE in all caps

… 4 different exclamation points

… Offer Expires

… Last Chance

… Unsubscribe

all right there in the subject line.
And what does Spamassassin say about the mail?

X-Spam-Flag: NO
X-Spam-Status: No, score=-7.193 tagged_above=-999
required=6.31 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01,
RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_RP_SAFE=-2,
RP_MATCHES_RCVD=-1.428, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=ham
autolearn_force=no

See that first line? X-Spam-Flag: NO
See the next line: score=-7.193. Notice the negative? That’s almost 14 points less than what is needed for our installation of SpamAssassin to mark a message as spam.
Words in the subject line are not used for filtering in any sane filter.
Exclamation marks don’t trigger filters. 
FREE does not trigger filters. 
It’s time to retire the myth that spam filters pay any special attention to the subject line. They don’t. In fact, to a mail server the Subject line is just another bit of content. One that is only special because it starts with a defined field name (Subject), has a colon and contains a line terminated by CRLF. In fact, a subject line isn’t required for an email.

The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically optional. More information is contained in the table following this definition. Section 3.6, RFC5322

Section 3.6, RFC5322

Filters don’t treat the subject line any differently than the rest of the email content.
(For the Horde.)

Necessary but not sufficient
Memories of Spam in May

Related Posts

The death of IP based reputation

Back in the dark ages of email delivery the only thing that really mattered to get your email into the inbox was having a good IP reputation. If your IP sent good mail most of the time, then that mail got into the inbox and all was well with the world. All that mattered was that good IP reputation. Even better for the people who wanted to game the system and get their spam into the inbox, there were many ways to get around IP reputation.
Every time the ISPs and spam filtering companies would work out a way to block spam using IP addresses, spammers would figure out a way around the problem. ISPs started blocking IPs so spammers moved to open relays. Filters started blocking open relays, so spammers moved to open proxies. Filters started blocking mail open proxies so spammers created botnets. Filters started blocking botnets, so spammers started stealing IP reputation by compromising ESP and ISP user accounts.  Filters were constantly playing catchup with the next new method of getting a good IP reputation, while still sending spam.
While spammers were adapting and subverting IP based filtering a number of other things were happening. Many smart people in the email space were looking at improving authentication technology. SPF was the beginning, but problems with SPF led to Domains Keys and DKIM. Now we’re even seeing protocols (DMARC) layered on top of DKIM. Additionally, the price of data storage and processing got cheaper and data mining software got better.
The improvement in processing power, data mining and data storage made it actually feasible for ISPs and filtering companies to analyze content at standard email delivery speeds. Since all IPv4 addresses are now allocated, most companies are planning for mail services to migrate to IPv6. There are too many IPv6 IPss to rely on IP reputation for delivery decisions.
What this means is that in the modern email filtering system, IPs are only a portion of the information filters look at when making delivery decisions. Now, filters look at the overall content of the email, including images and URLs. Many filters are even following URLs to confirm the landing pages aren’t hosting malicious software, or isn’t content that’s been blocked before. Some filters are looking at DNS entries like nameservers and seeing if those nameservers are associated with bad mail. That’s even before we get to the user feedback, in the form of “this is spam” or “this is not spam” clicks, which now seem to affect both content, domain and IP reputation.
I don’t expect IP reputation to become a complete non-issue. I think it’s still valuable data for ISPs and filters to evaluate as part of the delivery decision process. That being said, IP reputation is so much less a guiding factor in good email delivery than it was 3 or 4 years ago. Just having an IP with a great reputation is not sufficient for inbox delivery. You have to have a good IP reputation and good content and good URLs.
Anyone who wants good email delivery should consider their IP reputation, but only as one piece of the delivery strategy. Focusing on a great IP reputation will not guarantee good inbox delivery. Look at the whole program, not just a small part of it.

Read More

Fun with Subject lines

Courtesy of Think Geek (who have some of the best use of symbols in subject lines I’ve seen).

Read More

Images in the subject line

I’ve seen this trick used by a few senders recently, with varying effectiveness.

Where do they get these pictures?
While you can scatter any images you like across the body of your message, the subject line is limited to just text. But “text” is more than just “a, b, c” – using RFC 2047 encoding you can use any character you like, including many tiny pictures.
⛄ 💰 🐘 ✈ 🎁 ☂
☀|||||||☀
Experian, Vertical Response and Bronto all have some interesting things to say about the effectiveness of using these.
Finding the right glyph can be tricky. Macs have a fairly decent glyph search engine (under Edit > Special Characters… in most applications) while Windows has a fairly mediocre one (Start > All Programs > Accessories > System Tools > Character Map > Advanced View). Both are missing some useful features, though, so I put together something better.
emailstuff.org/glyph lets you search for glyphs by name. It’ll tell you about related glyphs (“helicopter” and “airplane”, or “package” and “wrapped present”) which can help you find the right image when you don’t know it’s name. And, once you’ve chosen a glyph, it shows how to use it in various encodings (if you’re using a GUI tool or a web form to compose your emails you can probably just copy and paste, but it’s handy for manually editing messages when your composition tool isn’t unicode-friendly).
Will all your recipients be able to see these glyphs? All mail clients support utf-8 text and this sort of encoding so the only issue is whether the recipient has a font installed with the glyph in it. That’s operating system specific, rather than depending on the web browser or mail client, so if you want to test – and you probably should – you can get away with just Windows and OS X for desktop, iOS and Android for mobile.
Have fun! But don’t overdo it.

Read More