Re: Sending Emails vs. Links

From: Carmen Paulino <clpsf_at_sbcglobal.net>
Date: Fri 18 Mar 2005 09:11:49 -0600

In a recent post, I forwarded some advice about the workings of HTML and
plain text email from a developer my firm has partnered with for the last 9
years. She was surprised that most of the information she provided was so
incorrectly, and yet so *authoritatively* rebutted. She asked me to post the
following response. It provides both credible authority and technical
foundation for the information she provided, and validly reiterates the main
issue: that<killing> HTML does not really stop you from actually downloading
it, and therefore does not save bandwidth.

She has intermediated in this discussion because both HTML and plain text
email are frequently misunderstood. She believes that we should make choices
based on accurate knowledge, rather than hype and misinformation, and this
is her sole purpose here.

First, let me establish her credits. My business partner is well known
throughout the software industry. Formerly with Microsoft in the <<early-ish
days>>, she has since served as technical advisor and consultant architect
to GTE, Coca-Cola, Ericsson, MCI, E*Trade, the U.S. Postal Service, et al.
She is currently a volunteer developer on the FireFox/Thunderbird Project,
WiX, Nant, and Nunit, among others. She is a member of the Internet Mail
Consortium, W3C and WSI. Two of these organizations govern the information
she provided [and which, if I say so myself, was somewhat ungraciously
rebutted].

She also addresses Meredith Hamilton's suggestions at the bottom. This is
necessarily long, but ultimately provides white paper quality information
that I - a total technical unsophisticate - find very informative and
useful. I hope you will as well.

Carmen

ITEM 1--------

I said: <<When you disable HTML email, you are not changing the effect of
bandwidth. Your email client does not know if the email contains HTML
formatting until AFTER it has been downloaded. An email's header does not
contain information on the format, so you have no choice but to download.>>

Reply was: <<Not true - if you specify your smtp server not to deliver to
your e-mail client anything other than plain text, then it will not.>>

My Response: What is missing in this reply is a disclosure that this
suggestion is an EXCEPTION to the rule, and it really does not apply in this
discussion. The Exim mail server for UNIX (which I expect is what Mr. Connor
is alluding to) does - as he says -- allow content filtering. But that
feature is *built into that particular mail server itself.* It is
PROPRIETARY to the Exim software. It is not a standard. Thus, persons who
use the Exim software would have that capability. I would venture to say
that few of you are using Exim, an original project of Cambridge University,
England.

THE TECHNICAL EXPLANATION: An SMTP server does not govern what you
receive. It governs what you send [although this is a purposely simplistic
explanation; it is actually much more complex]. When you download mail, you
go through a POP server. RFC2476 governs SMTP (sending email) and RFC2449
governs POP (receiving email). [RFC's are the official rules and guidelines
for Internet software developers and the like.]

Neither of these RFC's sets a standard protocol for filtering content from
an email. There are technical and other very significant reasons for this,
outside the scope of this writing. While it is possible that an SMTP server
can add the functionality to filter out content, it would affect the email
that you send, NOT the email that you receive (this segment of the
discussion has been about email *recipients* (not senders) who say they
disable HTML to save bandwidth).

A most probable [non-proprietary] SMTP server that would allow for such a
thing is sendmail. But it is also the most complicated of all SMTP servers
to run. I suspect most of you run on mDaemon, SLMail or Exchange Server
(unless you have a dedicated IT staff).

Another Reply was: <<Also, if you have a G-Mail account for instance,
external images will not be shown until you have accepted them to be shown,
therefore saving your bandwidth. I could go on and on.........>>

This <example> has nothing to do with my original explanation. It does,
however, relate to paragraph number 3, where I said that newer email clients
[i.e., those produced after 2001] will not download externally-linked items.
GMail was produced after 2001.

THE TECHNICAL EXPLANATION
RFC1872 "Multipart/Related" sets the standard for embedding images into the
email itself. This was done to close security breaches in email clients: it
stops Trojan infected images from being downloaded, web bugs from tracking
valid email accounts, java applets from being embedded, etc

All *current* email clients use RFC1872 to send graphics, including Outlook,
Outlook Express, Mozilla and my favorite, Thunderbird. There is nothing new
about this; this has been the protocol for a very long time.

SOURCES: If you're interested in learning more about this, here are the
official sources - each of which is the basis for my remarks:

Link to RFC2476: http://www.ietf.org/rfc/rfc2476.txt
Link to RFC2449: http://www.ietf.org/rfc/rfc2449.txt
Link to RFC1872: http://www.faqs.org/rfcs/rfc1872.html

ITEM 2--------

I Said: When you disable HTML email, you are actually reading the "MULTIPART
/ ALTERNATIVE" section of the email... if it is present. Some bad email
clients do not transmit this and then you end up seeing junk on the screen.
Remember that more than 80% of the email being transmitted is in HTML format
with a Multipart Alternative for reading plain text.

Reply Was: Multipart MIME. Also not true, the html code does get downloaded
but, again, the images do not.

My Response: There is no Multipart/Mime standard. Let me reiterate: there is
no Multipart/MIME standard. The RFC for this, and for all Multiparts, is
RFC1872 (link is above).

TECHNICAL EXPLANATION
**You will arrive at the syntax for this explanation by placing the
following in the header:

Content-Type: multipart/alternative; boundry="----=_NextPart_SomeUniqueId"

**Before each boundry type, we get an informational header. For text, which
all email clients understand we see:

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

**For HTML, which is optional we see:

Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Email clients read headers before they download items, but as you can see
from the above syntax samples, they can only understand that a Multipart
message is being transmitted. Because there are several types of
Multipart -- an attachment is one such example - an email client can't know
which of the Multipart types are in play unless and until it actually
processes (downloads) the entire message.

Email servers work the same way... they only read the headers. The rest of
the message is the body, and servers don't "as a norm" interpret body data.
The rationale for designing the system this way (i.e., to read only headers)
was to allow development of more advanced email functionality without
forcing people to upgrade their servers every time a new function was
introduced.

Exception: There are some products that can change an email server's
functionality, such as spam filters, content filters, and virus checkers.
These products do read the body of email messages and require updates as
email evolves (e.g., TrendMicro, Norton, etc.).

ITEM 3--------

I Said: When you disable HTML email you do avoid downloading externally
linked items, such as stylesheets and images. Newer email clients don't
download these items unless you tell them to. The email consortium
recommends that people embed the images and external items in the email,
which allows them to be displayed without user interaction. This means that
while you may not be aware of it, you ultimately download these items even
though you are reading plain text.

Reply Was: <<Half true. What 'email consortium' are you talking about? They
are VERY irresponsible suggesting that images be embedded - I would like to
see how long their ISP will stand that for.>>

My Response: The SMTP Protocol and the POP Protocol belong to the IETF
(Internet Engineering Task Force), which is located at www.ietf.org. The
Internet Mail Consortium is called the Internet Mail Consortium and they
control email standards. They are located at www.imc.org. Just about every
company in the world that professionally develops email programs or
subsystems is a member (such as, Microsoft, and even myself).

For whatever it's worth, the standards board doesn't really care what ISP's
think, unless the ISP is a voting member. That's just the way our industry
works. If ISP's want to influence the creation or rejection of an RFC, they
become a member and vote. This is why so many ISP's *are* members, ergo, the
ISP's themselves voted for the protocol.

ITEM 4--------

I Said: Those are proponents (like myself) of the opinion that a company
that doesn't format its email into a nice presentation (such as HTML
allows), is not presenting itself in the best light.

Reply Was: Your choice, I cannot argue, other than the fact that I have seen
some awful html creatives that actually do very little for a company's
image.

My Response: From my point of view, image is everything; if you do not
portray a good image and effective branding - including in your email - then
perhaps you shouldn't do it until you can. A poor presentation (e.g., skewed
layout and formatting) can influence your readers to block further emails
from you. From personal experience, more people have opted for HTML than for
plain text in the numerous systems I've built for clients. So while you
personally may not like HTML, the focus should be on what your audiences
want.

================

ITEM 5. Meredith's Suggestion -----------------

Meredith said: <<I think I'm missing something here. I see three, rather
than two options. Link, HTML email and Plain Text email. Why not send the
article in a plain text format that does not reconfigure itself or hog
bandwidth?>>

My Response: You are correct on the three issues. When I stated that the
best practice is to ask users if they would like to receive plain text or
HTML, I did not mean to imply that you should always use
Multipart/Alternative.

If the user wants text, then you should ONLY send text. But if the user
wants HTML then you should ALWAYS send both as Multipart/Alternative.
Especially if you're unsure if the user will forward the email to someone
else who may not be able to read HTML.

If you are sending a link then you should use text. If you are sending an
article, you should first be sure what it is you want to accomplish. For
example, if you send plain text, then you will lose all of the formatting,
external hyperlinks, emphasis and other elements that you may want to
portray in the email. You should decide whether this is what your audiences
expect from your company. If you decide to offer HTML, then of course, you
should ask your audience to opt in.





Received on Fri Mar 18 2005 - 09:11:49 CST