Configuring Mail Clients to Send Plain ASCII Text

What is wrong with sending HTML or MIME messages?

There are now six main reasons for NOT doing this:

1. Many E-mail and Usenet News reader programs, usually the mail and news reader programs that come with browser packages, allow users to include binary attachments (MIME or other encoding) or HTML (normally found on web pages) within their E-mail messages. This makes URLs into clickable links and it means that graphic images, formatting, and even color coded text can also be included in E-mail messages. While this makes your E-mail interesting and pretty to look at, it can cause problems for other people who receive your E-mail because they may use different E-mail programs, different computer systems, and different application programs whose files are often not fully compatible with each other. Any of these can cause trouble with in-line HTML (or encoded attachments). Most of the time all they see is the actual HTML code behind the message. And if someone replies to the HTML formatted message, the quoting can render the message even more unreadable. In some cases, the message is nothing but strange looking text. For this reason, many mailing lists especially those that provide a digest version, explicitly forbid the use of HTML formatted e-mail. See   examples section.

When you send an attachment, like a word processor file, to have it appear on the other end as the exact same type of file the recipient must have hardware and software that can read that file. For example, if you attach a Microsoft Word file, and the recipient of your message is using a word processor that can't open MS Word files, that person isn't going to be able to open your attachment and they are less than likely to be very happy about it.

2. HTML or MIME messages are larger and more wasteful than simple text messages. Using HTML or MIME in E-mail messages makes the messages larger in size by a mimimum of two thirds to more than twenty times. These will take longer to download and they take up more storage space than standard plain text E-mail messages.

E-mail storage is important because many people retain copies of messages they receive and in the case of mailing list digests , the individual messages are combined in one large message and sent to the user at the end of the day. Some mailing list programs fail to format the digest correctly if HTML messages appear. In addition, many mailing lists archive the messages for periods of 6 months or more to enable users to search for particular past postings.

3. HTML or MIME messages leave or include unwanted files (attachments) on the machines of the recipients of these messages.

4. Embedded HTML or MIME attachments are the number one method of spreading virus, worm or Trojan programs.

For instance, the Forgotten worm was written in Visual Basic Script and spread without any attachment. Instead, the worm code was embedded into the HTML formatted message body.

The I Love You worm program exploited an ActiveX vulnerability and was executed just by viewing or previewing the e-mail message without opening any attachment.

Likewise, embedded code could exploit some MS Office vulnerability as with Office ODBC Vulnerabilites and Specially Formed Script in HTML Mail can Execute in Exchange 5.5. 

HTML messages can trigger dialups to the Internet if they contain links to specific images called "web bugs" that are used to track message and advertiser viewing. See Web Bug FAQ.  MIME encoded attachments with file extensions (BAT, COM, DOC, EML, EXE, HTA, JS, PPT, SHS, VBE, VBS, WSH, XL#) have been the most common method of sending viruses, worms and Trojan programs because their code will be executed by Windows and associated viewers or other MS programs when the attachment is opened. Windows uses the extension to determine what the default action on a file will be. For instance, a .txt file will open in Notepad and a .html file will open in Internet Explorer.

Uncommon, but no less dangerous are file extensions (386, ACM, ACV, ADT, AX, BIN, BTM, CLA, CPL, CSC, CSH, DEV, DLL, DOT, DRV, HLP, HTM, HTT, INF, INI, JSE, JTD, MDB, MP#, MPP, MPT, MSO, OBD, OBT, OCX, OLE, OV#, PIF, PL, PM, POT, PP#, PPS, PRC, RAR, RTF, SCR, SH, SHB, SMM, SYS, VSD, VSS, VST, VXD, WSF, XL#, XLB, XTP).

5. HTML quickly fills the memory of PDAs (Personal Digital Assistants like the Palm Pilot). In addition, many HTML messages are also completely unreadable on most PDAs.

6. Some e-mail recipients may have set their background to something other than white, may have chosen a typeface which they find most readable and adjusted its size in accordance with their visual acuity, normal viewing distance, monitor size and screen resolution. All this fine tuning is completely erased by HTML e-mail.

Plain text is how your messages should be formatted when sending E-mail to mailing lists and Usenet newsgroups or to any other recipient. Though this rule is not yet cast in "Netiquette"  stone, it is a good policy to follow if you want quick and informative responses to your questions and wish to avoid being "flamed" as a clueless newbie.
HTML is meant for the WWW; not for mailing lists, Usenet newsgroups postings, proper business E-mail correspondence and preferably not for personal E-mail unless the recipient is expecting it.

MIME encoded mail is generally used to send attachments that consist of pictures, sound files, spreadsheets, word-processing documents, zip files, or other binary files to recipients that have and use the same operating system, the same word processing program and a common E-mail program such as Eudora, Pegasus, Netscape, or Outlook.

MIME attachments are not wanted on mailing lists, Usenet newsgroups postings, business E-mail correspondence, and preferably not for personal E-mail unless the recipient is expecting it.

If you must send an attachment, then before you send the message with the attachment, ALWAYS send the recipient a message telling them you are about to send them an attachment. This will, at least, let them know to expect a message with an attachment from you.

An exception to the "no MIME attachments rule" can be made for PGP (Pretty Good Privacy), GPG (Gnu Privacy Guard), or other "Digital ID" signed e-mail. In this case, individuals, mailing lists, and Usenet newsgroups that use signed e-mail are probably expecting it. See MIME Security with Pretty Good Privacy (PGP) . For more background information see Netiquette Guidelines (RFC1855)  To see what actual HTML/MIME mail looks like in UNIX Pine, see  examples section.