Question: How do you deal with attaching files to email?
Question: How do you deal with attaching files to email? Many of you have asked about how to attach files to email so that the recipient receives them reliably. Louis-Philippe Thouin <[email protected]> said it most succinctly: "This is an oldie, but where can one find exhaustive information on how mail attachments are treated by different client and server (ISP) mail programs?"
Answer: There are dozens of possible combinations of email clients, attachment methods, and encoding systems. As far as we’ve seen, it’s always a matter of experimentation to get the right mix in any given situation.
The root of the problem is how email itself is sent. Email is just a stream of data with a recipient and certain standard headers on the front. MIME (Multipurpose Internet Mail Extensions) was developed to create a uniform method of encapsulating attached files into this data stream. However, it appears that each mail client (like Eudora, Netscape Messenger, Claris Emailer, and so forth) handles MIME slightly differently. There are also differences in which encoding formats are supported by different mail clients. You’d think there would be at least one standard in common, but that’s still to come.
<http://www.fwb.gulf.net/~dwsauder/mime.html>
Before MIME, you could attach files only when working within proprietary mail systems (like QuickMail, cc:Mail, or Microsoft Mail) or commercial online services (AOL, CompuServe, and others). If you wanted to include a file in email going over the Internet or between different mail systems or services, you would encode it and then paste it into the body of a mail message. Many older mail programs limited message size, which resulted in some amazing attempts to send large files in multiple pieces and reassemble them on the other side.
Encoding a file was necessary only for binary data, which, as you might recall from previous issues of NetBITS, is data that includes bytes which aren’t pure text. Binary data is eight bits long and can represent a number from 0 to 255. ASCII data is described typically as seven bits, or values from 0 to 127. You would encode a binary file using either uuencode (a Unix standard) or BinHex (a Mac standard). Both methods take a stream of binary numbers and turn them into a longer stream of ASCII numbers. A decoder reverses the process. (Another reason to encode data was that most mail servers wouldn’t handle binary data in mail messages and would corrupt the attachment.)
<http://www.dnai.com/~wussery/attach.html>
<http://www.natural-innovations.com/boo/ binhex.html>
Now that we’re in modern times, you’d think that this was all a thing of the past. In fact, it persists to an alarming degree, explaining the quantity and variety of mail we’ve received on the subject. Here’s a simple example. If I’m using Eudora Pro on a Mac, I have four options for encoding attachments: BinHex, Uuencode, AppleSingle, and AppleDouble. The two Apple options are methods of sending a Macintosh file, with its two forks, as a binary attachment. If I send a file encoded with AppleSingle to a Netscape Messenger user, they’re stymied. Netscape Messenger doesn’t understand how to reassemble a MIME attachment that identifies itself as AppleSingle. Likewise, if I send a uuencoded file, the recipient is still stymied. Even more irritating is that uuencode is fairly universally supported – but it’s not an option in the freeware Eudora Light on the Mac, though Eudora Light under Windows does support it. You see the problem.
A couple of years ago, I was regularly sending Microsoft Word files to my editor at Adobe Magazine, part of Adobe Systems. At that time, Adobe used cc:Mail with a gateway server that handled Internet mail and interacted with the proprietary cc:Mail servers. No matter what combination of encoding formats I tried and no matter what my recipient did, the files rarely came through intact. Fortunately, Adobe switched to Qualcomm’s Eudora mail client, and my problems disappeared.
Our recommendation for solving this problem is to create a test file of the sort in question that you can send using a variety of methods to your recipient. Have that person report on which files (it’s a good idea to name the files with the name of the encoding format you’re using so your recipient can keep them straight) come through successfully and keep careful notes. Sometimes, and this is sad, FedEx is the fastest method of sending an electronic file (with help from a floppy disk) and making sure it arrives in the same form it left your machine.
All that said, MacUser Magazine last year published a comprehensive chart listing which encoding formats to use based on the sending and receiving email programs. It may be a bit out of date but is still useful. [GF]
<http://www.zdnet.com/macuser/mu_0297/handson/ table.html>