By MarketingSherpa Technology Columnist Alexis D. Gutzman

I remember the first time I heard about “the sniffer.” I was interviewing the VP of Marketing for one of the major email-marketing-services vendors. How, I asked him, did they know which version of a message to send to each member of a list?

He told me they had a sniffer, which would automatically sense whether a recipient could receive HTML (which looks like a Web page in your inbox), and deliver that, or if not, deliver plain text (like this newsletter). When I asked for details, he told me it was proprietary technology, but I could talk to the CTO.

How sexy! A sniffer! What a scoop I would have!

I had visions of software that somehow overcame the basic problem of email; which is that it is a one-way communication from the sender to the recipient, unless the recipient chooses to make it a dialogue.

Email is different from the Web. When a visitor goes to a Web site, Internet Explorer or Netscape send the Web site information about the visitor. Any cookies that were planted by the Web site on a previous visit, along with the language of the visitor (US English, for example), the Web browser type and version (Internet Explorer 5.5, for example), and other information about the visitor’s computer. On the Web, even viewing a Web page requires a bit of a dialog behind the scenes between the software requesting the page and the software delivering the page. There is nothing comparable that goes on when you send email.

THE SHORT INTERVIEW WITH THE CTO

I looked forward to my interview with the CTO, sure that they had devised a clever end-run around the inherent one-way nature of email. As it turned out, the conversation was short:

"How does your sniffer work, since email doesn’t pass back any information about the recipient, the way the Web server knows about the visitor?"

"We don't actually have a sniffer. We just use that term so that marketing can explain it better to customers."

No sniffer? Of course there is no sniffer. Yet just about every broadcast email vendor uses the term, because it is great marketing!

SOLVING THE DELIVERY PROBLEM

However, just because there is no proprietary technology to sense which version to deliver does not mean that you can not be sure that you get the right version of each message to the each recipient.

It turns out that the email software vendors have largely solved this problem by sending your email with a MIME type of “multipart/alternative.” To learn how this works, read the tech notes at the end of this article.

GLITCHES IN DELIVERY TO CONSUMERS: THE AOL PROBLEM

Letting the recipient’s software decide which version to open works extremely well unless the software that your readers use is AOL, Lotus Notes, or Eudora.

AOL is the most common consumer-grade email software. Ask IT for reports on what percent of your list is using AOL. If you are B2C it will probably be high. For B2B lists it should be low, unless your targets are small business, in which case it will be high.

A year ago deciding whether to send a plain-text version of email to all AOL addresses on your list, regardless of whether they had requested HTML or not, was a no-brainer. AOL got text, everyone else got what they asked for. Today the answer is not so easy.

AOL is not really one email software anymore. AOL 7 behaves like the most sophisticated email software. With it, recipients can see full-blown HTML email. AOL 4, on the other hand, only shows text. According to AOL (we interviewed them in late March), the majority of their members are already on AOL 7; the rest are evenly divided between AOL 5 and AOL 6.

Fortunately, if you have already been sending HTML email to AOL addresses, then IT should be able to give you a report of what percentage of your AOL readers who opened the message are on AOL 7, AOL 6, and AOL 5. The remaining percentage of your AOL readers are not getting the messages, are not opening the messages, or are using AOL 4 or below. Make the call about which version to send to your AOL addresses based on this information.

DELIVERY PROBLEMS TO CORPORATE AMERICA: LOTUS NOTES

If your audience is at Fortune 500 companies or in government, then you need to be aware that many of these companies and government office rely on Lotus Notes to receive email.

Unfortunately, Lotus Notes doesn’t cooperate with multipart/alternative email. When your lovely HTML newsletter arrives in the their mailboxes, they will not see the pretty pictures and fonts, they’ll see the HTML code. They do not have a choice.

DELIVERY PROBLEMS TO GRAPHIC ARTIST AND TEACHERS: EUDORA

Eudora is an email client that is in common use by Mac users and, to some degree, small businesses. Eudora users can configure their email software not to process the HTML, again, for security reasons. If your audience is graphic artists or school teachers, for example, you have probably heard from them that the email you sent did not look right.

Fortunately, both Lotus Notes users and Eudora users are used to seeing this ugly email, and they know to look for the link at the very top to open the HTML version of the message in their browsers. Make sure it is there!

Another option is to send text-only email to your entire list, if a considerable part of your readers fall into any of these groups. The superiority of HTML over text email has not been demonstrated in all contexts.

If you offer two versions, consider adding “recommended for Lotus Notes and Eudora users” next to the text-only checkbox on your opt-in form.

CRM PROVIDES A MORE ELEGANT SOLUTION

Some email services vendors; usually those that are offering CRM or very-nearly CRM; make a point of tracking enough technical information about a recipient and storing that with the email address so that they can send the right version in the first place. This can solve the AOL, Lotus Notes, and Eudora problems, but you have to want the other CRM services that these vendors provide in order to justify the premium cost.

TEXT, HTML, AND OPEN RATES

You have probably noticed that text email loads immediately, but HTML email takes a moment to load. The images in the HTML message are pulled off the Web server at the moment the message is opened. This is typically how email services vendors calculate open rates: they count how many times an image that only appears in a particular message is requested from the Web server.

The problem with counting the people who open the image is that anyone reading the text version of the message will never request the image.

Also, anyone who deletes the message without opening will never request the image.

Open rates are something every marketer and publisher wants to know, but at this point, there is no way to know what percent of those who do not request the image are seeing the text version, what percent are seeing the HTML version as raw HTML (using Lotus Notes or Eudora), and what percent have passively opted out of your mailing by deleting without opening.

NO SNIFFER IS NO PROBLEM

As you can see, even though there is no sniffer, you can use multipart/alternative email to make reasonably sure that recipients see the best version their software can show them.

If you want more technical details about anything discussed in this article, read through the Tech Notes below.


***TECH NOTES***

As you know, email is different from the Web. The difference is in the protocols.

THE HTTP PROTOCOL

The Web relies on HTTP (hyper-text transport protocol). HTTP is a handshake protocol.

First, the browser sends certain information to the Web server in a predictable format behind the scenes:

* the language of the browser (en-us for US English)
* the contents of any cookies planted by the requested site during previous visits
* the Web browser and version

Then the Web server sends back the page requested, often created in part in response to the information the browser sent. For example, "Welcome Back, Alexis" would be based on data sent in the cookie.

After each component that the browser needs to build the entire page, the browser sends back a little confirmation telling the server that it got the last component, and that it is okay to go ahead and send the next component. A more recent version of HTTP eliminates some of these confirmation messages, resulting in faster load times, but most major sites do not use it.

SMTP PROTOCOL BY CONTRAST

Email uses a different and less conversational protocol: SMTP (simple mail transport protocol). The only conversation that takes place in SMTP is between the sender's server and the recipient's server. What follows is the conversation between two mail servers, server1.todomain.com and smtp.yourserver.com (the recipient’s and the sender’s). I added line numbers so I could walk you through it.

The Arrows to the right and left tell you which way the data is going. The sender's mail server does not even get to sending the message until line 10.

All the receiving mail server tells the sending mail server is "OK" on line 7, meaning that your domain is not one from which it is refusing mail, "Address OK." on line 9, and absence of a bad-to-address message on line 11. If there is a problem with the recipient’s address, or the mailbox is full, line 11 is where you will find out.

1 --> Sending email to: address@todomain.com
2 <-- DNS lookup succeeded, found 4 acceptable mail servers for todomain.com
3 --> Attempting to connect to: server1.todomain.com (210.64.0.0)
4 <-- Connected to: server1.todomain.com (210.64.0.0)
5 <-- 220 server1.todomain.com -- Server ESMTP (PMDF V5.2-33 #42260)
6 --> HELO smtp.yourserver.com
7 <-- 250 server1.todomain.com OK, [200.100.144.12].
8 --> MAIL FROM:
9 <-- 250 2.5.0 Address Ok.
10 --> RCPT TO:
11 <-- 550 5.7.1 : address@todomain.com
12 --> QUIT

If you are the administrator of a list, you are probably used to seeing very long reports in your inbox full of lines of text like that above.

So, while SMTP is a conversation between mail servers, it is not a conversation between mail clients, the way a Web visit is a conversation between your desktop computer and the Web server. The sender need never (and probably will never) know what email client software the recipient is using.

THE MAGIC OF THE MIME TYPE

A MIME type is associated with every file on your computer. It basically tells the operating system what software to use to open the file. Common MIME types are text/html, image/gif, and text/doc.

The MIME type of email that delivers the right version to the right client is multipart/alternative. Older and text-only email clients will not recognize this MIME type. That is okay. This has been factored into multipart/alternative. What multipart/alternative is is a two-part message (each of which has its own MIME type). At the top, there is a plain text message, complete with a MIME type of text/plain, just what plain-text email clients expect to see. After that, there is an HTML version of the same message.

HTML-capable email clients know to skip over the plain-text version, and jump down to the text/html MIME type. They simply display the HTML version, and the recipient never knows that there are actually two versions of the email message in the inbox.

For those whose email clients can not open the HTML version, at the bottom of the plain-text version of the email, they will see the HTML from the HTML version, but by then they have read the entire text version.

If you want to see what multipart/alternative mail looks like (thus, what your Lotus Notes and Eudora users might be seeing), open just about any broadcast email you receive in HTML format, and go into the message properties (usually an option off the File menu on your email client). Then view the message source.