Every once in a while we’ll see a rejection from Yahoo that says RFCs 554 5.0.0 Message not accepted due to failed RFC compliance. What does that mean and what can we do about it? It really does mean exactly what it says on the label: there’s something about the message that is not in compliance with any number of RFCs and are not going to accept the message in its current state. When...
A question came up on the email geeks slack channel (Join Here) about SenderID. They recently had a customer ask for SenderID authentication. We’ve written about it a few times: (Hotmail moves to SPF Authentication and Until it stops moving) but we’ve not actually stated the reasons why in a post. SenderID was basically SPF version 2. It tried to use the same mechanism as SPF to...
We mention RFCs quite a lot, both explicitly (RFC 6376 is the specification for DKIM) and implicitly (the 822.From aka bounce address aka return path). And we have local copies of a bunch of them to make them easy to refer to (SMTP, MIME, Carrier Pigeons …). They use quite a lot of jargon and implicit information and metadata that’s not really explained terribly clearly anywhere...
A bit of a refresh of a post from 2011: Six best practices for every mailer. I still think best practices are primarily technical and that how senders present themselves to recipients is more about messaging and branding than best practices. These 6 best practices from 2011 are no longer best, these days, they’re the absolute minimum practices for senders. If you can’t manage to do...
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...
A client asked me earlier this week what SLAs ISPs provided for email delivery. The short answer is that there isn’t a SLA and that the only guarantee is that the email will get there when it gets there. But as I was mentioning this to Steve, he pointed out that there was a recent change in the RFCs for email. In both RFC 821/2 and RFC 2821/2 (the original email related RFCs and the update...
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...
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...
This morning I received notification that the IETF had approved RFC5321 and RFC5322. These two RFCs are standards track and are updating the current email standards RFC821/822 and RFC2821/2822. MailChannels has a description of the changes between 2821/2822 and 5321/5322. While the new RFCs obsolete the old ones, they are more a clarification than actual changes to the protocols. Dave Crocker had...
RSS - Posts