Send Actual SMTP

It’s rare I find mail that violates the SMTP spec (rfc5321 and rfc5322). I’ve even considered removing “send mail from a correctly configured mail server” from my standard Best Practices litany.

But today I got mail asking me to respond to a survey.

This whole email is a mess of problems, and it’s claiming to be from the California Secretary of State.  It’s also discussing the June Primary, which isn’t the election we just had. The from address doesn’t reassure me, they’re claiming to be: VotersChoice.SoS.Ca.Gov@mailservices6.com. The mail is being sent to the address I gave California when I registered as an overseas voter, but those lists are public.

In the course of trying to decide if this was real or was just some way to steal private information, I discovered this particular mail server isn’t actually sending real SMTP.

X-Amavis-Alert: BAD HEADER SECTION, Non-encoded non-ASCII data (and not UTF-8) (char 9C hex): Received: \x{9C}by v1.mailservi

Now, quite honestly, I suspect this is actually legitimate mail. A few google searches and I discover mailservices6.com belongs to California Survey Research Services, Inc. They manage data collection for a lot of different government agencies. Looking at information around them this is exactly the kind of vendor that I expect a government agency to use.

I have to wonder, though, how well their email surveys actually perform. They’re not sending actual SMTP. The non-ASCII character is in their own internal handoff to a server running an obsolete version of Sendmail. While our mail server is somewhat forgiving of non-SMTP mail not all mail servers are. Even if that isn’t enough to tank their delivery, there are multiple similar but not identical domain names in the body of the message. The link to ‘research.net’ doesn’t actually go to research.net, it points to yet another random domain name. Put all this together with the unsolicited nature of the email I’d be amazed if any of their mail was reaching the inbox at the consumer ISPs.

Looks like I’ll be keeping the “and make sure you send SMTP” in the list of recommendations, because there are still groups out there who are not sending valid SMTP. If my mail is to be believed, some of them are being paid by the state of California to do so.

Email addiction survey
Ready. Set…

Related Posts

Who didn't invent email, part 2

Back in 2014, Steve wrote an article discussing Shiva Ayyadurai,and his claims that he was the inventor of email. In that article he links to a number of articles from Techdirt. Earlier this year, Shiva sued Floor64, the parent company of Techdirt, as well as Michael Massnick the Founder, CEO and editor and Leigh Beadon, a writer for Techdirt. (Original Complaint pdf from ReCAP). Ars Technica has a good article on Shiva and his claims.

The complaint asserts that the defendants defamed Shiva in their articles, caused him economic harm and inflicted emotional distress on him.
Today the judge dismissed the case (Memorandum and Order, pdf from ReCAP) against Michael and Leigh.  The legal standard for punishable defamatory statements is there must be a way to prove them true or false. The judge ruled that since there is not a single definition of email, that there is no way to definitively prove Techdirt’s statements as true or false.
No one disputes the Shiva coded a system that encompasses the features we expect of any desktop or web based mail client. As many people have mentioned, the fact he was 14 and put together a complex program is impressive in and of itself. No one is disputing what he did accomplish.
To my mind the fundamental core of email is interoperability. It’s that I can sit in my lab at the University of Wisconsin, type a message, hit send and have someone in Boston receive the message. I can sit here in my office in California and write to my client in the the UK. The bits of the email client, which define email according to Shiva, are not email. They’re important for usability, but they’re not what makes  email email.
According to Ars Technica, Shiva is going to appeal the dismissal.
EDIT: Techdirt has posted an article on the lawsuit and the dismissal.
 

Read More

The perfect email

More and more I’m moving away from consulting on technical setup issues as the solution to delivery problems. Delivery is not about the technical perfection of a message. Spammers get the technical right all the time. No, instead, delivery is about sending messages the user wants. While looking for something on the blog I found an old post from 2011 that’s still relevant today. In fact, I’d say it’s even more relevant today than it was when I wrote it 5 years ago.
authenticated
Email is a fluid and ever changing landscape of things to do and not do.
Over the years my clients have frequently asked me to look at their technical setup and make sure that how they send mail complies with best practices. Previously, this was a good way to improve delivery. Spamware was pretty sloppy and blocking for somewhat minor technical problems was a great way to block a lot of spam.
More recently filter maintainers have been able to look at more than simple technical issues. They can identify how a recipient interacts with the mail. They can look at broad patterns, including scanning the webpages an email links to.
In short, email filters are very sophisticated and really do measure “wanted” versus “unwanted” down to the individual subscriber levels.
I will happily do technology audits for clients. But getting the technology right isn’t sufficient to get good delivery. What you really need to consider is: am I sending email that the recipient wants? You can absolutely get away with sloppy technology and have great inbox delivery as long as you are actually sending mail your recipients want to receive.
The perfect email is no longer measured in how perfectly correct the technology is. The perfect email is now measured by how perfect it is for the recipient.

Read More

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.

Read More