Sending Stuffed Files

For more info see Plain Talk about Getting and Sending Stuffed Files

What do I use?

[Q] I'm sending Zipped files from Mac to PC world the arrivals are "" - OK if you have Expander but not OK if you don't. Does this sound like a reinstall -or- trash pref's file -or- what?

[A] It sounds like you might be confusing compression and encoding. Binary files need to be encoded somehow for sending as email attachments. The ".hqx" suffix indicates that the file is getting BinHex encoded. To avoid this, all you have to do is pick a more appropriate encoding method from the "Encoding:" pop-up (or if you mostly send files to Windows users, set it in the preferences). I'd suggest Base 64 for this purpose.

No reinstalling or preference-trashing is necessary.

PC Users Can't Open Them

[Q] I have been trying to send Jpegs and Gif images to various people as attachments. All they get is the image name, with an extension of "sit" after it. I know that the "sit" extension is for us Mac people. They can't open them. Most of the people are using a pc I know.

[A] When sending binary attachments to DOS/Windows users, it's probably best not to compress files (this is where the ".sit" comes from) and to use Base64 encoding. (just noticed another change in v3 -- I think "Base 64" changed to "Base64".)

If you want to compress attachments, there is a free product called StuffIt Expander for Windows that's available from the Aladdin Web site, but then you have to get your correspondents to use it. For me, that tends to be too much of a chore. The easier thing for your typical Windows user is for you to use a product like ZipIt (shareware) that enables you to create PKZip archives on your Mac. Then you can send the Zip archive (again, with compression turned off).

What will open PICTs on WinDoze?

[Q] When I send an image in PICT format to my PC friends , they can't open it with their Windows software. What will open PICTs on WinDoze?

[A] Paint Shop Pro and All Screen 95 (both shareware) use PICT format. It was with all screen that I sent the W95 screen shot the other day. It saved the image as a .PCT which could be opened up on the Mac with no trouble at all.

[A] HQX is not stuffed; it is BinHex. There is a popup menu just below the Stuff check box; you need to choose an encoding scheme other than BinHex; I'd recommend Base 64.

Do I have to compress?

[Q] When I send an attachment to someone, Emailer insists that the file must be compressed. No matter what I try, I cannot get the file to be sent without being compressed. It doesn't matter if I select "No Encoding" I will get a dialog box saying I can't do that. What am I doing wrong?

[A] We're talking about two things here: 1) encoding, and 2) compression.

Encoding: All files sent as attachments that are not plain text files must be encoded somehow, because the Internet won't transmit enough bits to send a binary file without any encoding. For mail going to a Mac user, use BinHex; for mail to PC users, Base64 is often the best. Unix and many other users (including the Mac Stuffit Expander) also understand Uuencode.

[Clarification] Emailer also requires text files to be encoded. This is because there may be high-ascii characters in the file.

Compression: Compression is purely optional; it saves time and bandwidth, but is not required to send an attachment. If you are compressing a file, the compression occurs <before> the encoding. Emailer uses Stuffit compression, I believe. If you are sending a large file (>32K) to someone it's usually polite to compress it. PC users, however, cannot (without some effort on their part) decompress files compressed using Emailer's default compression technique. You can mail them an executable image (in my copy it's called SITEX10.EXE)--uncompressed of course, but encoded--that will decompress Stuffit archives, if they are willing and knowledgeable enough to run that extra step on the arriving attachment. Or, you can compress the file in "zip" format <before> attaching it, using ZipIt (Mac shareware/freeware); most PC users know how to unZIP files. For Mac users (who are usually more into their computers), the default compression technique, Stuffit, works just fine, and will decompress automatically on reception.

[Clarification] Most cross-platform graphic formats (e. g., GIF, JPEG) are already compressed; further compression doesn't save anything, and might even increase the size of the file being send.

What is the standard zip program for the pc?

[Q] I am in need of the Mac application that will zip a number of graphic files so that the pc users I am sending these .jpg files will be able to unzip them. What is the standard zip program for the pc and where do I get it?

[A] If they're friends send them Stuffit Expander for WinDoze, otherwise, look for ZipIt.


From NetBITS#016/29-Jan-98

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 <> 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.

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.)

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]


Highlights Index