The Physics of the Email Universe

We talk a lot about rules and best practices in email, but we’re mostly talking about “squishy” rules-of-thumb that are based on simplified models of how mail systems, spam filters, recipients, postmasters and blacklist operators behave. They’re the biology, ecology and sociology of the email ecosystem.
There’s another set of rules we tend to only mention in passing, if at all, though. They’re the steely, sharp-edged laws that control the email universe. They’re the RFCs that define how email works and make sure that mail systems written by hundreds of different people across the globe all work and all interoperate with each other.
Building a message from Zeros and Ones
RFC 5322 – Internet Message Format
This tells you everything you need to know about crafting a simple email, with a subject line, a sender, some recipients and a simple plain-text message. It’s also the foundation of all fancier emails. If you’re creating emails, this is where to start.
A little more than plain ASCII
RFC 2047 – MIME Part 3: Message Header Extensions for Non-ASCII Text
RFC 2047 is one small part of the MIME (Multipurpose Internet Mail Extensions) suite of protocols that allow you to include pictures and attachments and prettily formatted text and comic sans in your email. This part defines how you can put things other than the plainest of plain text in your subject lines or in the “friendly from” of your message. It’s what allows you to put Hiragana, or Cyrillic, or umlauts, or cedillas, or properly matched double quotes in your subject line. It also let’s you put hearts or smiley faces or other little pictograms there – but nothing this useful is going to be perfect.
RFC 2045 – MIME Part 1: Format of Internet Message Bodies
This shows how to send an image, or a plain text mail in a different character set, or an HTML mail. It doesn’t tell you how to send plain text and HTML, or to send HTML with embedded images, or a message with an attached document. For that you need…
Finally, Modern Email
RFC 2046 – MIME Part 2: Media Types
This builds on RFC 2045 to allow you to have many different chunks in a message – this is what you need if you want to send “proper” HTML mail with a plain text alternative, or if you want embedded images or attachments.
Getting From A To B
RFC 5321 – Simple Mail Transfer Protocol
A message isn’t much use unless you send it somewhere. RFC 5321 explains the mysteries of actually sending that message over the wire to the recipient. If you need to know about the different phases of a message delivery, what “4xx” and “5xx” actually mean, why there’s not really any such thing as a hard or soft bounce defined, just temporary or permanent failures, or anything else about actually sending mail or diagnosing mail delivery, this is your starting point.
The Rest Of The Iceberg
I’ve only touched on the very smallest tip of the email iceberg here. There’s much, much more – both in RFCs and ad-hoc non-RFC standards. If you’re interested in more, this is a decent place to start.

Related Posts

Six best practices for every mailer

People get into all sorts of details when talking about best practices. But so much of email depends on the type of email and the target market and the goals of the sender. It’s difficult to come up with universal best practices.
I’ve said in the past that I think that best practices are primarily technical. I don’t believe there is a best frequency or a best time to send mail or a best image to text ratio.
My top 6 best practices every marketer should be doing (and too few are).

Read More

Email filters

What makes the best email filter? There isn’t really a single answer to that question. Different people and different organizations have different tolerances for how false positives versus false negatives. For instance, we’re quite sensitive to false positives here, so we run extremely conservative filtering and don’t block very much at the MTA level. Other people I know are very sensitive to false negatives and run more aggressive filtering and block quite a bit of mail at the MTA level.
For the major ISPs, the people who plan, approve, design and monitor the filters usually want to maximize customer happiness. They want to deliver as much real mail as possible while blocking as much bad mail. Blocking real mail and letting through bad mail both result in unhappy customers and increase the ISP’s costs, either through customer churn or through support calls. And this is a process, filters are not static. ISPs roll out new filters all the time, sometimes they are an improvement and sometimes they’re not. When they’re not, they’re pulled out of production. This works both for positive filters like Return Path and negative filters like blocklists.
Then there is mail filtering that doesn’t have to do with spam. Business filters, for instance, often block non-business mail. Permission of the recipient often isn’t even a factor. Companies don’t often go out of their way to block personal mail, but if personal mail gets blocked (say the vacation plane ticket or the amazon receipt) they don’t often unblock it. But when you think about why a business provides email, it makes perfect sense. The business provides email to further its own business goals. Some personal usage is usually OK, but if someone notices and blocks personal email then it’s unlikely the business will unblock it, even if the employee opted in.
In the case of email filters, the free market does work. Different ISPs filter mail differently. Some people love Gmail’s filters. Other people think Hotmail has the best filtering. There are different standards for filtering, and that makes email stronger and more robust. Consumers have choices in their mail provider and spamfiltering.

Read More

Think before you mail

I get quite a bit of unsolicited mail. I mean, sure, we all get a lot of spam, but that’s not the unsolicited mail I’m talking about. I’m talking about from people and companies in the email space. They want to make sure I’ve seen their new whitepaper or article about delivery. Or they have a question about something I’ve written here. Or they are looking to hire me.
All of these things are great. I love hearing from readers, either in comments or in email. We have a valid (unfiltered) contact address here on the blog. My email address(es) aren’t difficult to find. I want to talk to people.
Sometimes some of the people who contact me do actually send spam. It’s bulk, it’s impersonal, it’s not about me or my perspective it’s about them trying to sell something (themselves, their newest product, their company) to anyone who is buying.
If it’s clear it’s a one off I’ll generally just move the mail out of my inbox and forget about it. Sometimes, though, there are hints that this is more than just a one time mail. The email will have an unsubscribe link, or it’s the third or fourth time I’ve gotten mail from that sender or it will be from a PR company. I deal with them in different ways. Sometimes I’ll offer a different email address that I route better, or I’ll just filter the mail based on some unique bit of the header.
The ones that really get me, though, are when the senders argue with me that I should feel special to get their bulk mail. “It was individually sent to you!” “I sent it because you’re such a great resource and wanted to say thank you!” But it was bulk mail, mail dozens of other people got (hint: the email / delivery industry is very small. we talk to each other all the time, if you send mail to more than one of us, we’re going to talk about it).
I have no problem with you inviting me to your event. Or telling me about the latest or greatest thing you wrote. I don’t even mind the occasional one-off bulk mail. But if you are sending mail to a specific person, put in the 20 seconds to personalize it and make it feel like it’s special for me.
A few moments to think and personalize before you send that email will make your recipient much more open to your pitch. This is as applicable to one off mail as it is to bulk.

Read More