Think you know about deliverability?
Check out the tweets from my AMA webinar sponsored by Message Systems today.
Thanks to the AMA and Message Systems for having me.
Related Posts
Reminder: AMA webinar
Today is the last day to sign up for the AMA webinar hosted by MessageSystems and listen to me talk about the future of deliverability.
I hope to see you there!
Unsubscribing is hard
A comment came through on my post about unsubscribing that helpfully told me that the problem was I didn’t unsubscribe correctly.
As you know, there are usually two unsubscribe options in many of the bulk senders emails. Are you unsubscribing from the global or the offer unsub? Unless you are unsubscribing from both, you will still be on the lists.
To address the underlying question, I did unsubscribe from both links for those very few mails in my mailbox that had double unsubscribe links. I know that some spammers use multiple unsubscribe links in their emails. We routinely recommend clients not use 3rd party mailers with double unsubscribes because it’s a clear sign the 3rd party mailer is a spammer.
Given the presence of double unsubscribes I generally assume the point is to confuse recipients. By having multiple unsubscribe links the spammers can ignore unsubscribe requests with the excuse that “you unsubscribed from the wrong link.” Plausible deniability at its finest. The best part for the spammer is that it doesn’t matter which unsubscribe link the recipient picks, it will always be the Wrong One.
I’ve been dealing with spam since the late 90s, and have been professionally consulting on delivery for over 14 years. If I can’t figure out what link to use to unsubscribe, how is anyone supposed to figure out how to make mail stop?
In some cases, the unsubscribe links admitted that the address I was trying to unsubscribe was already removed from the list. They helpfully refused to let me unsubscribe again through their form. But they offered a second way to unsubscribe.
The address I was unsubscribing was the same one I was unsubscribing. Some of the emails even helpfully told me “this email was sent to trapaddress@” which is the address in the above screenshot.
I’m sure my friend will come back and comment with “why didn’t you unsubscribe by forwarding the email?” Because I was spending enough time unsubscribing as it was, and I didn’t want to have to try and navigate yet another unsubscribe process. I knew they weren’t going to stop mailing me, no matter what hoops I jumped through.
I’m not saying that all unsubscribe processes are broken, there are millions and millions of emails sent every day with simple and effective unsubscribe links. What I am saying is that there is a lot of mail getting to inboxes that users never requested nor wanted. “Just unsubscribing” from this mail Does Not Work. It just keeps coming and coming and coming.
But of course, the mail still coming is my fault, as I was unable to correctly unsubscribe. 
Email History through RFCs
Many aspects of email are a lot older than you may think.
There were quite a few people in the early 1970s working out how to provide useful services using ARPANET, the network that evolved over the next 10 or 15 years into the modern Internet.
They used Requests for Comment (RFCs) to document protocol and research, much as is still done today. Here are some of the interesting milestones.
April 1971 [rfc 114]RFC 114 A File Transfer Protocol.[/rfc] One of the earliest services that was deployed so as to be useful to people, rather than a required part of the network infrastructure, was a way to transfer files from one computer to another. In the [rfc 114]earliest versions[/rfc] of the service I can find it could already append text to an existing file. This was soon used for sending short messages, initially to a remote printer from where it would be sent by internal mail, but soon also to a mailbox where they could be read online.
August 1971 [rfc 221]RFC 221 A Mail Box Protocol, Version-2[/rfc] had this prescient paragraph: