Recent Posts

Why do we "warmup" IP addresses

IP address warmup is a big issue for anyone moving to a new IP address for sending.
I’m constantly being asked how to warm up an IP. My answer is always the same. There’s no right way to warm up an IP nor is there a specific formula that everyone should follow.
What warming up is about is introducing mail traffic to receiving spam filters in a way that lets the filter know this is a legitimate email stream. This means sending small but regular amounts of mail that recipients interact with. As the filters adjust to the amount of mail from that IP, more mail can be sent over that IP. Increase the mail volume over the next few weeks until the desired volume is reached.
There are a couple things to remember about warming up.

More on spam traps

A couple weeks ago I had a discussion with Ken Magill of the Magill Report about spam traps. He had moderated a webinar about spam traps and I publicly contradicted some of the statements made about spam traps. He contacted me and interviewed me for an updated article about traps for his newsletter. The next week he had a rebuttal from Dela Quist of Alchemy Worx, taking anti-spammers (and presumably me) to task for pointing out that some folks use typos as spam traps. This week, Derek Harding of Innovyx continues the discussion about traps and how they are a reality that senders need to deal with.
Spam traps are a reality and they’re not going away at any foreseeable point in the future. No entity that actually cares about blocking spam is going to give up the information that spam traps provide them. Not A Single One. They are some of the original tools in the filtering arsenal and they have proven their use and reliability for people trying to keep inboxes useable.
Dela focused on typos in his rebuttal to Ken, but typos aren’t the real issue. The real issue is that any address acquisition technique (and I do mean any) is subject to errors. Those errors end up directing mail at people who didn’t ask for it. If there are too many errors or mail to too many of the wrong addresses, that will result in delivery problems.
Yelling at the people monitoring the accuracy of your email marketing doesn’t make your marketing any better. It doesn’t stop mail from going to the wrong people. It doesn’t actually help anything.
My focus is on helping marketers market better. My focus is on helping folks sending email get that mail to the inboxes of people who want it. I don’t really care if my clients hit traps, traps are, as Derek said, “the canary in the coal mine.” What I really want is to make sure every person who asked for mail from my clients gets that mail. Every trap on the list? That is a lost sale, a lost touch, a lost opportunity. The traps are just the addresses we know are wrong. If there are traps on a list, then it is guaranteed there are deliverable addresses that belong to someone who is not a customer. This generally means two lost customers, the one who isn’t getting the mail they asked for and the one who is getting mail they never asked for.
Traps are a way to quantify missed opportunities, but they’re not the only missed opportunities. If mail is going to traps, it’s not going to your real customers. That is why marketers should care about traps.

AOL publishes a p=reject DMARC record

Yesterday I mentioned that there were reports of a compromise at AOL. While the details are hazy, what has been reported is that people’s address books were stolen. The reports suggest lots of people are getting mail from AOL addresses that they have received mail from in the past, but that mail is coming from non AOL servers. In an apparent effort to address this, AOL announced today they have published a p=reject DMARC record.
I expect this also means that AOL is now checking and listening to DMARC records on the inbound. During the discussions of who was checking DMARC during the Yahoo discussion, AOL was not one of the ISPs respecting DMARC policy statements. I’m not surprised. As more information started coming out about this compromise, I figured that the folks attacking Yahoo had moved on to AOL and that AOL’s response would be similar to Yahoo’s.
My prediction is that the attackers will be trying to get into Outlook.com and Gmail, and when they do, those ISPs will follow suit in publishing p=reject messages. For those of you wondering what DMARC is about, you can check out my DMARC primer.

AOL compromise

Lots of reports today of a security problem at AOL where accounts are sending spam, or are being spoofed in spam runs or something. Details are hazy, but there seems to be quite a bit of noise surrounding this incident. AOL hasn’t provided any information as of yet as to what is going on.

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.

Is volume a problem?

Volume in an of itself is not a problem. Companies sending mail people want can send multiple emails a day to every user. The volume isn’t a problem because the mail is wanted.
Many senders are confused and think volume is a filtering criteria. It’s not. Send all you want; just send it to people who actually want the mail.
A lot of companies in their growth phase find they do have delivery problems as their volume ramps up. But the problem isn’t the volume, the problem is that mail programs don’t scale. Companies mailing lower volumes can get away with sloppier practices. One because the chances of hitting bad addresses increases with the number of addresses you have. But the other is that filters do take volume into account. It’s not that the volume directly causes the filters to trigger, but volume causes the filters to look harder at mail. If the reputation and metrics are good, the mail is fine and hits the inbox. If they are poor, then mail hits the bulk folder or is filtered.
Overall, volume isn’t a problem, but increasing volume can expose fundamental problems in a mail program that result in delivery issues.

A good example of 3rd party email

This morning I received a great example of a 3rd party email that I thought I’d share with all of you.

What’s so great about it?

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.
Update Feb 8, 2016: AOL users are having problems logging in. Word to the Wise cannot help you. Please do not contact us for help. Contact AOL directly.

Ignoring opt-outs

One of the marketing solutions to the spam problem is just to have recipients opt out.

The anatomy of From:

Compared with some of the more complex pieces of the email protocol the From: header seems deceptively simple. But I’ve heard several people be confused about what it’s made up of over the past couple of months, so I thought I’d dig a bit deeper into how it’s defined and how it’s used in practice.
Here’s a simple example:

There are two interesting parts.
The first is what’s technically called the display-name, but more commonly known as the “friendly from” in the bulk email industry. It has no meaning within the email protocol, it’s just text that’s displayed to the recipient to describe who an email was sent by. Because it’s just text, you can put anything you like in there, but it’s usually either the name of the person who wrote the mail or the name of the company or brand that sent it.
The second is the actual email address, the thing with an at-sign in it. Surprisingly, this isn’t used at all during the actual delivery of the email; there’s a hidden field (called the return path or the 5321.MailFrom or the envelope sender or the bounce address) that’s used instead. For person-to-person email it’s usually the same address, but for bulk mail it’s often different.
So what does the actual email address, the 5322.From, mean? For that we go to the document that specifies what email headers mean – RFC 5322, “Internet Message Format”. (RFC 5322 is the updated replacement of the older RFC 822 – and that’s why the actual email address is often called the 822.From or 5322.From when people are being precise about exactly which email address they’re talking about).
RFC 5322 says “The From: field specifies the author of the message, that is, the mailbox of the person or system responsible for the writing of the message.” and “In all cases, the From: field SHOULD NOT contain any mailbox that does not belong to the author of the message”. It’s the email address of the author of the message.
(In some cases the email may have been written by the author, but then sent on their behalf by someone else. RFC 5322 says that in that situation the email address in the From field is still the author of the message. The person who sent the message gets their own field, “Sender:”).
What is the 5322.From used for? During the delivery process it’s used for some sorts of filtering and authentication. In particular, if you’re reading about DMARC you’ll see “identifier alignment” mentioned a lot – which basically means “the only domain we care about authenticating is the one in the 5322.From”. It’s also the usual field that’s used in user-visible mail filtering such as whitelisting email addresses that are in the users address book.
In the mail client itself the most obvious use of the 5322.From is that when you hit reply, that’s the email address your reply will go to by default. The author of the mail can override that by adding a Reply-To field, containing one or more email addresses if they want different behaviour. It’s also commonly used to filter email and to group mails by author.
What’s displayed to the end user? Originally the entire content of the From: header was shown in the recipients mailbox but it’s now fairly common to display just the friendly from, with no mention of the email address at all. That started in mobile clients, where space is at a premium and the friendly from is just, well, friendlier – but it’s spread to desktop and webmail clients too. In Yahoo webmail the 5322.From isn’t displayed anywhere at all unless you find the View Full Header menu option and dig through the raw headers, and my phone doesn’t display it anywhere obvious and only recently made it possible to see it at all.