Dan's Web Tips | E-mail

Dan's Web Tips:

E-Mail

[<== Previous] | [Up] | [Next ==>]

E-Mail isn't really part of the Web, per se, but it is often used in conjunction with it, as in giving users of a Web site a means of contacting the Webmaster. Thus, I've got a few tips on e-mail too, especially as it relates to the Web and HTML (including the fact that you should avoid sending your e-mail in the form of HTML!).

Useless Trivia: On her first album, Britney Spears had a song called "E-Mail My Heart". (Incidentally, at one point the sign-up form on her Web site had "Year of Birth" in a pulldown menu which starts at 1965, so if you're older than that, you don't exist as far as her marketing people are concerned.) I don't know what the proper MIME type or encoding format is for e-mailing your heart (or any other body organ), but there is a MIME type for e-mailing your entire body: matter-transport/sentient-life-form. (See RFC 1437.)

Always give people a way to contact you!

The Web is an interactive medium. People may want to write you to congratulate you for the brilliance of your Web design, to ask questions about the subject of your site, or to point out a link that doesn't work. Don't make it hard for them. Put your e-mail address on every page, as an <A HREF="mailto:you@yoursite.com"> link that users can click on to send you mail. You may also want to use a CGI form to get feedback, but even then add a plain mailto link too, since sometimes those CGI things malfunction. (Whenever I hit a non-functional feedback form, it leaves me mystified about just how I'm supposed to contact them to tell them their form doesn't work!)

There are many sites now that advise you not to have any email addresses in plain text anywhere in your site, because of spammers who harvest those addresses. They advise using various techniques to obscure or "munge" all addresses to foil spammers, which unfortunately also have the effect of inconveniencing legitimate correspondents as well. I, myself, refuse to do any such things; I won't give in to spammers or any other form of terrorists, and let them change the way I conduct my life; that would be letting the bad guys win.

As an aside, I have encountered, several times within a short period, cases of people using some sort of "address munging" when quoting their email address within a newsgroup or e-mail list message, like "...If you have any opinions about this, email me at johndoeMYSHIRT@example.comMYPANTS -- remove my shirt and pants first." -- however, their messages were posted with their full, untrammeled email address in the FROM line of the message as configured in the mail or news program they used to post it. This makes the "munging" in the message body completely pointless and just makes the writer look silly.

However, the silliest "address munging" I've seen is in the text of articles in print publications -- that is, on paper. Does the author think that spammers will use OCR scanners to harvest their address? Actually, the likely cause is that articles are often written for both electronic and paper publication, and the author wasn't taking any chances of letting his un-munged address get online, even if this had the side effect of silliness in the paper version.

But back to providing means of contact instead of obscuring them... Another place you can put your e-mail address is in the HEAD section of your pages with this tag:

<LINK REV=made href="mailto:me@mysite.com">

This construct, supported by the official HTML specs, lets compliant browsers provide a means of letting the user send mail to the site's author. Unfortunately, while the relatively obscure Lynx and WinMosaic browsers support this, the popular Netscape and Internet Explorer browsers fail to do so. (Mozilla supports it, along with other LINK tags.) Maybe someday more widely-used browsers will, and it doesn't hurt to put in this line for the use of any browser that gets with the system and supports it.

If you have your own domain name (see my section on domain names), you should get a memorable e-mail address in that domain, like webmaster@yourdomain.com. Check with your Internet provider about getting such a mailbox set up, or simply a mail alias that forwards such mail to the place you actually check your mail. It looks much more professional to have an address in your own domain than one with an Internet provider or online service instead. (Especially since, in about 9 out of 10 cases I've encountered of Web site owners using an ISP-based e-mail address instead of one in their own domain, the provider is AOL... to many serious Internet users, having @aol.com in your address is like attaching a sign to your shirt that says "I'm an Idiot!" One of the inexplicable things I continually encounter, in advertisements and in the contact information for columnists in publications, is "Email me at frobbitzky@aol.com, or see my Web site at www.frobbitzky.com!" If you've got your own domain, why not use it consistently?)

And while I'm at it, what's the deal with all the national TV ads that give the URL of the company, then follow it with "AOL Keyword: FooBarBaz"? That's basically a 10 or 15 year regression... in the "bad old days", somebody wishing to get information out where all online users could see it had to get accounts on lots of different proprietary services and list addresses in various incompatible forms because there wasn't any one place or addressing scheme that was accessible to everybody. That was the mess that the Web was designed to clean up, by creating a universally-accessible network with a single consistent addressing system, the URL. Anybody who follows a perfectly good URL with a proprietary keyword from AOL seems to want to revert to those days of yore. Silliest of all is the NFL, which gives their address as "nfl.com... or AOL keyword nfl.com." Why add the .com part to the AOL keyword... it has no structural meaning in that system, unlike in the domain name system.

How Do I Put A Subject Line in a Mailto Link?

This is a commonly-asked question. Until recently, the answer was, "you can't, at least not in a way that's compliant with the specs and compatible with all browsers." Now, while there are still compatibility problems with old browsers, the method implemented in the current popular browser versions has now been documented in an official standards-track RFC document.

The syntax is:
<A HREF="mailto:jdoe@somewhere.net?subject=Hello">

While the existence of an RFC on it makes this construct no longer "nonstandard," you should note that there are still some browsers out there that will choke on complex mailto links, maybe losing the message altogether. Thus, some caution is desirable in using this syntax, and it's probably still best to avoid it. Supposedly (though I haven't verified it myself), AOL's browser is among those which can't cope with this construct, even though it's based on MSIE.

Another problem is that many people who use the above syntax try to insert subject lines with spaces and other special characters, like "mailto:jdoe@somewhere.net?subject=How are you doing?!?". This is invalid, even under the new specs, since spaces and most other nonalphanumeric characters are disallowed or have reserved meanings when used in URLs. Browsers might ignore everything after the first space in such an URL. The solution is to use hexadecimal escape sequences: %20 for a space, for instance. This results in "subject=How%20are%20you%20doing%3F%21%3F". Less elegant-looking code, but at least it works (to the extent that mailto subjects work at all). You can even put in line breaks that way (useful when you're adding a 'body=' parameter in addition to the subject) using %0D%0A (CR followed by LF). (You add multiple parameters by using an ampersand to separate them, but in HTML documents the ampersand is already a reserved character, so you must encode it with &amp;. Many people find this a tricky point to understand, as it involves a different level of encoding than the hexadecimal encoding noted above. The hexadecimal encoding is used to insert characters that would otherwise be invalid in a URL. The ampersand encoding is used to encode characters that are supposed to be in a URL, but are invalid in HTML. Is that clear?)

Another approach to take is to put the subject as a TITLE attribute in the link code, like <A HREF="mailto:jsmith@here.com" TITLE="Hello!">. There are a few browsers that support this, though most of the popular ones don't. There's a long running debate in comp.infosystems.www.authoring.html about whether this usage is the logical way to supply a message subject or not, depending on whether people think the "TITLE" attribute is supposed to describe the link itself or the resource being linked to.

Yet another option is to add the subject in parentheses within the mailto link: "mailto:jdoe@here.net(Hello)". This doesn't actually supply a subject line, but it appends your subject to your address where it will show up in the "To" line. It works because parenthesized expressions are ignored by mailers, so your mail arrives at the address specified by the rest of the "To:" line. You have to be pretty alert to notice the parenthetic notes in the destination header of your messages instead of in the subject where you're used to finding such things.

I can see why people want to supply this information in mailto links; it can get pretty frustrating when somebody comments on your Web page and doesn't tell you which Web page they're commenting on. At least, that's frustrating when, like me, you maintain lots of different Web pages. Let this be a lesson to the reader; when you're commenting on somebody else's Web page, be sure to mention exactly what you're commenting on!

Another note on mailto: URLs: Don't use them as the ACTION URL of a FORM. This does not work reliably in all browser versions, and even when it works it doesn't work very well; it doesn't give the sender any confirmation screen indicating that their message was sent, and it sends the data to the end-user as an ugly mish-mosh. Thus, if you want to have the user fill out a Web form and have the information from it e-mailed to you, it's much better to use a CGI script (either one you write yourself, if you can, or a "standard" one already in place on your provider's server, if there is one) as the form destination. This can be made to output the user's entries to you in a readable format, and present the user with a "thank-you" screen, things you can't do with mailto: actions.

Don't send HTML-ized, or other non-ASCII, e-mail except to people you know can handle it and want it that way!

This isn't actually a "Web tip", but since I've used other parts of this Web site for my pet peeves, here's another. The universal standard for E-Mail has always been plain ASCII text, and that's the only format that is guaranteed to be meaningful to all of the different mail reading programs in use. Other sorts of attachment formats are nice for sending things back and forth between people who support the format being used, but when you're sending to somebody about whom you're not sure what formats are acceptable, always stick to plain text.

Unfortunately, some mail programs, like Microsoft Outlook Express, are now defaulting to sending mail in HTML format, even though, 99% of the time, there's absolutely no need to do so. Most such messages gain nothing from being in HTML instead of plain text; in fact, I find some of them less readable than plain text messages, since some of these mail programs set overly small font sizes compared to the usual font on my mail reader.

Also, don't use lines longer than about 70 characters, if you can help it. Well-behaved mail programs word-wrap their outgoing mail at that point; if you're not using a well-behaved mail program you might have to hit Enter at the appropriate spots. If you don't have line-breaks, and send each paragraph as a long line, some mail readers will make the user scroll right to read the message, and might truncate the line and lose some of the content if it's longer than the internal buffer the program uses. (The standards set an absolute maximum of 998 characters for an email line, but some programs exceed even this, causing data loss in many mail reading programs.)

UPDATE: The infamous series of e-mail viruses which have hit over the last few years, starting with "Melissa", continuing and escalating with "Worm.ExploreZip" and "Bubble Boy", then the mid-2000 burst of "I Love You", "Joke", and "Janet's Resume", and in 2001 the ubiquitous "Sircam", among others, give all the more reason to distrust "fancy" mail formats. Some of these are Visual Basic scripts, some are MS Word macros, and some don't even have to be opened to strike, due to Microsoft Outlook's "feature" of displaying parts of messages (including enhanced content) as "summaries" before you even open them. Plain ASCII may be more boring, but it can never put a virus on your system! Ironically, there were many urban legends and hoaxes about e-mail viruses circulating at a time when e-mail was still almost always plain-text and hence not vulnerable to viruses. This created a "Boy Who Cried Wolf" effect which caused people to distrust warnings of the very-real viruses that are now surfacing in e-mail. (And it turns out that users of Microsoft programs are at even greater risk due to that software's famous tendency of ignoring MIME type headers -- this lets virus authors sneak in executable content with "innocent" header types like image/jpeg, getting past the parts of the software that block or warn about dangerous content, but then have the brain-dead Microcrud notice that it's got a .exe filename, and run it, virus and all.)

And, to give yet another reason to avoid non-plain-text mail, spammers have started to use HTML mail with embedded image references to CGI scripts that signal to the spammer's server that the message was successfully received, thus letting them put your address on a "hot prospects" list of known-valid addresses for further use. You can avoid this by disabling "fancy mail" display if your mail program supports this.

Don't Overquote or Underquote!

When replying to a message, include just enough quoted material to establish the context of your reply, neither more nor less. The opposite extremes are both bad:

1) Replies Without Quotes

If you send a reply that doesn't quote any of the message you're replying too, or quotes so little of it that it's difficult to tell what the quote means in context, then it can be hard to understand what the reply means, since the recipient may have received lots of earlier messages and not be sure which one this is replying to. If your message says:

     Sure... that's a great idea!

the person who gets it may have no idea what you think is a great idea.

2) Replies Quoting Entire Original Message

Some people (encouraged by email programs that default to doing this) attach the entire message they're replying to to their reply, sometimes including all headers and trailers. If the message they're replying to is itself a reply, there may be multiple recursive sets of quoted messages attached to the original message. Messages can get really huge this way, and include lots of irrelevant stuff like multiple repetitions of signature blocks at the bottom of messages.

Instead, you should be selective in what you quote. Keep what is necessary to show what you're replying to (and maybe a few more levels of this to show what they were replying to), like this:

     > > What's black and white and red all over?

     > That's a really old one... A newspaper, of course.

     Funny... I always thought it was a blushing zebra.

Note the multiple levels of quoting, indicated by the presence of one ">" mark at the left side for each quote level. The traditional standard for quoting is to put your reply beneath the quoted material. Big flame wars sometimes break out on mailing lists and newsgroups over people quoting the opposite way (reply first and then quote), which is referred to as "Jeopardy-style" because the answer precedes the question. Myself, I'm less obsessed with whether the quote or the reply comes first than with the excessiveness of quoted material used by many people nowadays. The two often go together, though, as the traditional style of putting the response after the quote did tend to encourage brevity of quoting, since the use of a long quote forced a lot of scrolling to get past it to the response.

See extensive commentary about these and other e-mail format issues in my new Mail Format Site.

When sending files to people, in general, go for the lowest common denominator!

This one isn't really a "Web tip" either, or even an "e-mail tip". But the previous tip leads me to extend the concept further and remind people that, in all cases when they're trying to get a file to somebody else, they should use the most generic possible format to ensure that the recipient can handle it. This applies whether you're sending the file through the Web, e-mail, FTP, or on a floppy disk.

What leads me to write this is that a few years back I got a disk in the mail with articles for use in a newsletter I edited, but found the files unreadable. They were apparently in Microsoft Word format, but a newer version of Word than that supported by any of the several programs I had (at that time) that could import Word files. Thus, the files come out as garbage in every program I tried. (Since then, I've upgraded my system and have the latest Word, so I've finally been able to access such files (though I'm afraid to, with some MS-Word-macro viruses spreading around...). I'm having tougher luck trying to read an attachment somebody else e-mailed me in WordPerfect format; WordPad won't open that, I don't have WordPerfect, and the old DOSMAN utility which I wrote years ago with file-viewing capabilities including WordPefect hasn't kept up with the latest revisions, so the file comes up as a mess there too.)

Avoid creating such headaches for your recipients by using more standard, generic formats. If the files you're sending are text, save them as straight ASCII, not a specialized word processor format. Choose "Save as Text" in your word processor. Or, if it's essential that your formatting (bold, italics, etc.) be preserved, you can try exporting in MS RTF (Rich Text Format), which is widely supported as an import format, and doesn't seem to have as many version incompatibilities as MS Word format. Safest yet is to save the file twice, as ASCII and as RTF, and send both files. (As far as I know, there's no way to embed a virus as a "macro" in ASCII or RTF, so they're much safer formats than MS Word in this regard, too.)

If the files you want to send are graphics, you're best off using GIF or JPEG format, since they're the most widely-supported formats. (However, some people avoid GIF due to the unfortunate Unisys patent flap; PNG is a new format being championed as a replacement, superior in some ways, but unfortunately support for it isn't as great yet.) But don't use .bmp if you can help it; that's a non-compressed format, so files can be really huge!

If you're sending data from a spreadsheet or database, try exporting it as a comma-delimited text file. This can usually be imported by most other software.

If you're providing the files on floppy disk, the "safest" format these days is PC 3.5" high density (though if you're sending it to somebody with a really ancient machine, he might possibly need low density, or even a 5.25" disk, though these are mostly museum pieces these days). Don't send other platform disks (Mac, etc.) unless you know the recipient has such a machine; PC disks are readable by most other platforms these days, but the reverse isn't usually true. Higher-capacity formats, such as ZIP, SyQuest, etc., exist in so many varieties that you should check whether the user supports what you have before you try to send one (though none of these are particularly common nowadays due to the widespread use of CD and DVD burners). CD-ROMs are pretty much ubiquitous these days, and are readable by multiple platforms, so if you've got a CD burner, that's the best way to send large quantities of data (about 600 megabytes fits on one CD). DVD-ROMs have even higher capacities, and are commonplace on newer machines (which can also read and write CDs, so they support both formats). But there are always going to be yet newer formats coming out (BluRay, anybody?) to obsolete the old ones, so it's a moving target.

If you have a Mac, you should know that any PC-format disks you create will have a silly "resource-fork" subdirectory that will annoy the dickens out of PC users, prompting snide comments about how "if you had a real computer, you'd be able to send me files without that silly crap on the disk!" Also, Mac files sent by e-mail attachment will often come out as "multipart" attachments with that same silly resource stuff appended. The files end up being usable at the PC end, but the user might have to go through a few extra clicks to disentangle them from their resource attachments.

Of course, if the person you're sending files to has specifically told you what format he or she wants, follow that to the best of your ability. Otherwise, however, please show some thoughtfulness by sticking to the most generic, lowest-common-denominator format for your data.

Finally, if you're giving somebody data on a physical medium such as a floppy disk, a ZIP disk, a CD-ROM, etc., be sure to label it! The recipient might leave it lying around for a while alongside other disks, and it gets pretty confusing when you've got a whole stack of disks with no label.

Don't Add those Stupid 'AOL Users Click Here' Lines to your E-Mail Messages!

It used to be a fairly commonplace thing, especially in commercial e-mail messages, to see, below a line of the message that cites a URL, a line with the same URL in a <A HREF="..."> tag, with "AOL Users Click Here". This looks really dumb-ass in all other mail programs besides AOL, which follow the standards properly and display the HTML code as raw text (because, after all, the message was sent in raw text, with the MIME type "text/plain", not as HTML, MIME type "text/html").

AOL chose to ignore the standards and have its mail reader try to interpret HTML code within plain-text messages. This is a big pain for mailing lists discussing Web authoring, as code examples wind up getting rendered instead of being visible as code the way the author intended. So this mail reader behavior is an aberration which should be condemned, not pandered to. Don't "uglify" your messages for all non-AOL users by sticking in a silly line of HTML code so they can click on your links (while most other mail readers do the sensible thing by automatically hyperlinking any URLs they find in the plain text, without interpreting any HTML code in the message). All users, even those on AOL, are perfectly capable of using copy-and-paste to put the URL in their browser.

As AOL did eventually make its program behave more like a reasonable mail client, this sort of thing isn't very common these days. Unfortunately, as of 2007, AOL has started appending a silly ad footer to its outbound messages which includes HTML tags, even in the plain-text version! Once again, AOL users end up looking silly. Switch to a better ISP!

Configure your Mail Program Correctly!

In addition to e-mail programs defaulting to sending HTMLized messages, as noted above, there also seem to be e-mail programs out there that default to an incorrect reply address in your messages. I get loads of messages with headers like:

Reply-To: <@someisp.com>

When I try to reply to these messages, my mail program tries to send my reply to the incomplete address "@someisp.com", when the actual address should be something like "user@someisp.com".

Obviously, their mail program has a configuration section for specifying a return address, but the standard installation process either skips that section or fails to adequately explain what the user is supposed to place there, and it gets filled in incompletely with the domain name but not the user name.

Don't make this mistake. Look through all the configuration sections of your e-mail program, and be sure all the user-modifyable fields, like "From" address, "Reply-To" address, user name ("John Q. Smith"), user organization ("XYZ, Inc."), etc. are filled in with correct contents. In the case of optional fields, if you choose not to use them be sure they are entirely empty, not half-filled-in like in the example above.

Note that the "From" and "Reply-To" addresses may not be the same as your username plus the full name of the server you connect to in order to retrieve your mail. Often the server name contains a hostname portion which is not necessary in e-mail addresses. For instance, I used to retrieve my mail from server1.softdisk.com, but my e-mail address was dan@softdisk.com (without the "server1"). Many people don't know better and stick the "server1" (or the equivalent from your own server name) in their e-mail address, which makes their address longer, less-elegant-looking, and more likely to become invalid if their ISP ever changes its servers. If you have any doubts about what form of your address you should be using, ask the technical support department of your ISP, as the exact details of addressing will vary from site to site.

...And, don't forget to type your e-mail address correctly!

Lots of people seem to have trouble typing their e-mail address in Web registration forms, and in creating mailto links in their Web pages. If it's not exactly correct, mail to you at that address will probably bounce! So double-check what you type.

In particular, AOL members tend to mistype their addresses, leaving out the "@aol.com" part (how is anyone outside AOL supposed to know their screen name is on AOL and not another system?), or just typing "name@aol" (leaving out the .com), or including spaces within the name ("Just Me @ aol . com"). CompuServe users neglect to change the commas in their address's "native" CompuServe format to dots when using it as an Internet address. This is not proper e-mail address syntax. Be sure you know the proper conventions for Internet mail when typing your address!

One very common "newbie" error is to stick www., or even http://www., in front of your e-mail address when you type it into a Web form, like www.myname@aol.com. While it's conceivable that somebody's e-mail address might actually have these characters in it, this is rare; usually, your real address is just myname@aol.com and you somehow got confused about the distinction between an e-mail address and a Web address.

Links

 

[<== Previous] | [Up] | [Next ==>]

 

This page was first created 25 May 1998, and was last modified 10 Oct 2010.
Copyright © 1997-2011 by Daniel R. Tobias. All rights reserved.

webmaster@webtips.dan.info