TidBITS#515/31-Jan-00 ===================== Last week's quiz sparked interest in a murky topic: what is the best encoding method to use when sending email attachments to Windows users? In response, Adam dons his hip waders to explain why the correct answer was the runner-up, and why the most common response wasn't necessarily wrong either. We also look at Keyspan's Digital Media Remote, release old versions of the Internet Starter Kit on the Web, and note the release of the SETI@home 2.0 client. Topics: MailBITS/31-Jan-00 Better than Flying by Wire Email Attachment Formats Explained Copyright 2000 TidBITS Electronic Publishing. All rights reserved. Information: Comments: --------------------------------------------------------------- This issue of TidBITS sponsored in part by: * READERS LIKE YOU! You can help support TidBITS via our voluntary <- NEW! contribution program. Special thanks this week to Weemeng Low, William Shack, and Rock Cheese & Honey for their support! * APS CD-RW: SO HOT IT'S COOL! For blazing fast CD burns, check <---- NEW! out the hot APS Tech CD-RW 12x4x32x, which can toast a complete CD in 6 minutes. Only $369.95 today! * WinStar Northwest Nexus. Visit us at . Internet business solutions throughout the Pacific Northwest. * Small Dog Electronics -- Sony Digital Mavica MVC-FD73: $489! <----- NEW! Factory refurbished Blue Apple Studio Display 21": $879! Farallon Starlet 8-port 100Base-T with 10Base-T Bridge: $95 For Details: -- 802/496-7171 * OUTPOST.COM: More than just products -- Service. Visit for a tremendous selection of products: computer hardware, software, and accessories, plus consumer electronics with FREE OVERNIGHT SHIPPING. We deliver. * WIN a FREE TRAINING VOLUME - Register to win a FREE CD-ROM or <---- NEW! video of your choice from MacAcademy. Click on video or CD-ROM on the home page. Visit: or call 800/527-1914 * New GIGABIT Switch for the ulitimate in HIGH SPEED networking! <--- NEW! Available soon from Farallon, Fast Starlet Switch 10/100/1000 provides plug-&-play 1000Mbs connectivity for network backbones & file servers. * Aladdin IntelliNews: THE NEWS YOU NEED, WHEN YOU NEED IT! <-------- NEW! Now there's no need to bounce from Web site to Web site to find the info you need - IntelliNews does it for you! Check it out now at: --------------------------------------------------------------- MailBITS/31-Jan-00 ------------------ **E.T. Search Continues with SETI@home 2.0** -- The SETI (Search for Extraterrestrial Intelligence) project has updated its SETI@home client to version 2.0, adding security features, improving proxy support, and fixing bugs to the software that utilizes distributed computer processing power to analyze data from the Arecibo radio telescope. (See "SETI Brings Space Exploration to Home Macs" in TidBITS-482_.) The new software attempts to thwart some people's efforts to improve their SETI@home rankings by checking for unauthorized changes to data files and deleting those files. As a result, new data work units require the SETI@home 2.0 software; in other words, you must update to continue participating in the project. The client also boasts better support for SOCKS and HTTP proxies, Mac OS 9 compatibility, more accurate CPU time calculation, and faster data processing if the application window is hidden using the WindowShade control. Graphically, SETI@home 2.0 features a new indicator displaying Gaussian curve analysis results. Due to an existing bug, System 7.x users not currently running the Appearance Manager will need to wait for an upcoming release. SETI@home 2.0 requires a PowerPC-based Mac with at least 24 MB of RAM and is a free 360K download. [JLC] **Old Starter Kits Now Online** -- Last week a reader commented that he couldn't find the online versions of my Internet Starter Kit books (3rd edition Mac, 2nd edition Windows 3.1) at Macmillan Computer Publishing's site due to yet another reorganization. Rather than trying to track people down there and get redirects working for the umpteenth time, I've posted the full text of these books on the TidBITS Web site. The basic discussion of the Internet is probably still more or less accurate, although the details about programs are wildly out of date. But even that old information might be useful for anyone trying to set up or troubleshoot Internet connections on an old Mac or PC. I know I refer back to the books every so often when I can't remember how to configure MacTCP or MacPPP. I hope people continue to derive utility from these books, despite their age. [ACE] **Poll Preview: They Come in Colors** -- Next week we'll be looking at Canvas 7, the latest version of Deneba's popular Swiss Army knife of graphics programs. Other than Canvas, in which Contributing Editor Matt Neuburg has long been interested, we tend not to cover graphics programs much since most of us we live in a more text-oriented world. So tell us, what are the graphics programs you use most often to edit and create graphics? We've selected some big names for the poll answers, but we also recognize that there are many other possible options, so we've started a thread in TidBITS Talk where you can tell us what other programs you use and why you like them. [ACE] Better than Flying by Wire -------------------------- by Adam C. Engst My family has always liked remote controls. Many years ago - long before every television came with a remote - my parents had a device they called a bleeper. It was a little electric switch that let them mute the television whenever an ad came on. It turned out to be irreplaceable when it finally broke, and my father's solution was somewhat twisted. He bought a choke cable (generally used for manually adjusting the fuel/air mixture for engines), then drilled a hole through the television's volume knob, inserted a nail into the knob, and attached the nail to the choke cable. When he was finished, you could push or pull the choke cable handle - conveniently attached the wall next to the couch - and the cable would lengthen or shorten, thus moving the nail and changing the television volume. It was weird, but it worked. We didn't need to move the TV often or change the volume from anywhere but the couch - and we couldn't exactly lose track of our homemade remote control. Although remotes are now standard for televisions, for years we never thought of them in the computer world. After all, you only used a personal computer when you were in front of it, so there was little need for any sort of remote control device. Infrared mice have existed for some time, and long-time Macintosh writer Andy Ihnatko has described his Frankenstein-like approaches to making robotic toys into remote control devices. Nonetheless, I had no interest in remote control of a computer until we became addicted to playing our CD collection as MP3 files on the kitchen Mac. Suddenly, we had to pause or mute music when the phone rang, or lower the volume after sitting down to dinner. **Insert Keyspan, Turnkey Solution** -- The ideal solution to our dilemma might be MacSpeech's ListenDo, which I've installed but haven't yet had time to configure to perform the kinds of tasks I want. And there's no telling if speech recognition will work well with several people talking and kitchen noises interfering with the clarity of speech directed at the computer. But what is here and does work, right out of the box, is Keyspan's $79 Digital Media Remote, generally referred to as the DMR. The USB-based DMR has two parts, a receiver that plugs into the USB port and includes an indent for the second part, a half-inch- thick, credit-card sized remote. The remote has 15 buttons, 8 of which are labelled with icons indicating start, stop, skip forward or backward, and raise and lower the volume. Another four arrow buttons sit in a diamond layout with a Select button in the middle. The final two buttons are a Menu button and a button with an asterisk on it called the Cycle button. From a hardware standpoint, the DMR operates flawlessly. Like all infrared remotes, it requires line of sight to work, although you can usually bounce the beam off an opposing wall as well. I tested it at the greatest distance easily possible at home (about 35 to 40 feet) and the receiver had no trouble picking up the signal. I could imagine trouble in a large lecture hall, but I suspect it will work in almost all situations. Since I was testing the DMR on an iBook, I didn't want to leave the receiver plugged in all the time, but Keyspan's software had no problem with our plugging in or removing the receiver on the fly. **Pretend It's a Keyboard** -- The software that comes with the Keyspan DMR is functional, but not impressive. Essentially, the DMR emulates a keyboard - anything you could type, you can map to one of the keys on the remote. By default, the DMR includes key mappings for a number of applications, plus a default mapping that's active whenever an unknown application is in front. Along with the Finder and Microsoft PowerPoint, the applications recognized by the DMR are primarily multimedia applications like QuickTime Player, SoundJam MP, and AppleCD Audio Player. You can define your own mappings for these and other applications, which is handy if you use a different MP3 player or presentation program. In the initial release, Keyspan installed two items in your Control Panels folder, a Keyspan DMR Assistant that helped with status and diagnostics and a Keyspan DMR Manager that let you define key mappings. In the recently released 1.2 version of the software, available for free, Keyspan moved the Manager application to the Preferences folder and added a Configure button to the Assistant. Keyspan also changed the key mapping interface by relegating it to a separate dialog box, rather than keeping it all in the main Manager window. Unfortunately, these changes, although helpful, don't address basic interface issues with the software. For instance, the Assistant's main window status information, which merely tells you which driver and mapper are currently active, could be relegated to a status dialog box. Also, the Manager lists the available buttons on the remote that you can define by name, ignoring the fact that only two of the 15 have names on them. The others are labeled solely with icons, so it's difficult to make the connection between the name "Cycle" and the button with an asterisk on it. A graphical representation of the remote for mapping keys to the buttons would make the software easier to use. And finally, there's a question of why the software is split into two utilities at all when, from a user standpoint, they could easily be bundled into a single control panel. **Go West, About 35 Feet** -- What I see as the hidden utility of the DMR is its possible combination with macro programs like OneClick, QuicKeys, or KeyQuencer. For instance, although you could press the Cycle button repeatedly to bring SoundJam to the front (by default, Cycle switches between applications by emulating Command-Tab), then press the Menu button (which the Keyspan software maps to Command-M or Mute by default), wouldn't it be more elegant to create a macro that switched to SoundJam and typed Command-M with a single command? And although you're limited to 15 buttons on the remote, that's 15 commands per application. So you could easily attach a macro that switches to the Finder to one of the buttons, then define 15 macros that could be activated from the buttons when in the Finder. The sky is the limit once you make that connection with a macro program - point the remote at your Mac from across the room and press a button and the Mac could tell you the time, tell you your next appointment (perhaps with help from AppleScript), or launch a specific set of applications. Nearly anything you want to do but don't need to do while sitting in front of the computer becomes feasible. Even if the software for the Keyspan DMR isn't perfect, it's hard to complain too much, since the device works fine and you're unlikely to define your own mappings all that often. If you can imagine a need for an infrared remote control device that can control any application on your Mac (or in Windows - it works with USB-equipped PCs running Windows 98 as well), you won't go wrong with Keyspan's Digital Media Remote. Email Attachment Formats Explained ---------------------------------- by Adam C. Engst Okay, we may have confused a few people with last week's quiz, where we asked "What's the best encoding to use when sending a file to a Windows user via email?" I'll get to the correct answer shortly, but first let me explain the confusion. **Terminology** -- As I explained in "Macintosh Internet File Format Primer," in TidBITS-445_, there are usually two actions that take place for Macintosh files to be transferred via email: binary packaging and transfer encoding. Binary packaging, which is the realm of formats like AppleDouble, AppleSingle, and MacBinary, deals with the problem of other platforms not understanding that Macintosh files can have both data and resource forks. Transfer encoding, which is done via Base64 or uuencode, takes an 8-bit file and converts it to 7-bit ASCII text that can survive the journey through Internet email, which only _guarantees_ safe passage for 7-bit ASCII data. The BinHex format combines both binary packaging and transfer encoding. Here's where we vexed some people. Most email programs, including Eudora, Emailer, and Outlook Express, call the process of formatting an attached file for transmission "encoding," thus conflating the binary packaging step with the transfer encoding step. That's not generally a problem for users, but caused some confusion in our quiz for people who know that Base64 (which garnered the most responses) is a transfer encoding format, whereas AppleDouble (the runner-up) is technically only a binary packaging format. Now, you might be wondering, "So if AppleDouble is a binary packaging format, how does it survive being sent in email?" The answer is that an attachment, when packaged with AppleDouble and sent via email, is _also_ automatically encoded via Base64. Under most circumstances, that Base64 encoding is transparent to users on both ends. Let me explain more about each email attachment format in turn. **The Correct Answer: AppleDouble** -- Despite the turmoil we accidently engendered, AppleDouble is the best format to use when sending attachments to Macintosh or Windows users, and particularly if you're sending the same file to Mac and Windows users at the same time. That's because AppleDouble breaks the Macintosh data and resource forks of a file apart, then attaches them separately to the message, at which point they're also Base64 encoded for transfer. When a modern Macintosh email program sees the two attachments, it decodes the Base64 and then reassembles them into a single file. When an email program on another platform sees the two attachments, it throws the resource fork away and decodes only the data fork, since other platforms don't understand Macintosh resource forks. Some have questioned my recommendation of AppleDouble over uuencode for sending files to Windows users. In reality, uuencode will work most of the time, but here's why I recommend AppleDouble over uuencode: * If you're sending a file to both Macintosh and Windows users, and that file contains a resource fork that's useful but not necessary (as can be true of Microsoft Word or Nisus Writer files, for instance), AppleDouble preserves the resource fork for Macintosh users while allowing Windows email programs to strip it transparently. In contrast, uuencode can cause headaches for Macintosh recipients because it removes the resource fork completely. * Base64, which is the transfer encoding format used by AppleDouble, is almost totally transparent to users, whereas uuencode is only usually transparent. * Uuencode is not and will never be standardized, which leaves the door open for possible decoding problems. * Finally, AppleDouble _is_ the official Internet standard for sending Macintosh files in email, and there's nothing new about it. To quote from the MacMIME specification (RFC 1740), from December of 1994: "AppleDouble is the preferred format for a Macintosh file that is to be included in an Internet mail message, because it provides recipients with Macintosh computers the entire document, including icons and other Macintosh specific information, while other users easily can extract the data fork (the actual data) as it is separated from the AppleDouble encoding." Usage of and adherence to standards is a good thing, and it's the main reason we have the Internet today. The sooner we eliminate obsolete email programs that understand only old attachment formats, the better off we'll all be, and the sooner articles like this will be unnecessary. Note that some Macintosh email programs don't use the term "AppleDouble," but instead call it "MIME," and even Eudora has moved to calling it "AppleDouble ("MIME")." That's not entirely unreasonable, since "AppleDouble" doesn't lead you to believe that it's useful for sending files to Windows users. The problem, however, is that MIME will mean something different in Windows programs (and in Outlook Express 5.0 for the Mac), since Windows has no need for binary packaging at all, so "MIME" just means "Base64 encoding" for binary files that are attached to email. The main problem with AppleDouble is that it doesn't work in a few rare cases, mostly for people behind old email gateways that don't properly support Internet standards. In that case, you'll want to use whatever you can figure out that works. **AppleSingle** -- Whereas AppleDouble splits the data and resource fork into two files for attachment, AppleSingle bundles them together into a single file (much like MacBinary, which isn't used for email). AppleSingle's utility for email attachments is minimal, with spotty support through the Macintosh email universe. The main reason AppleSingle is still around is that the MacMIME specification also says that Mac files that lack a data fork, should be sent as AppleSingle. Overall, though, AppleSingle isn't generally relevant to most people today. **uuencode** -- Again, uuencode is a transfer encoding format that throws away any resource fork information in the Macintosh file and converts the 8-bit file into 7-bit ASCII text. Although this destructive behavior with regard to the resource fork sounds bad, it actually isn't quite as awful as I've made out because no Windows applications would be able to read the resource fork of a Macintosh file, even if it was transferred. If a Macintosh document _required_ its resource fork, it wouldn't be readable in Windows anyway. And if you were to send a Macintosh application via email with uuencode encoding, the application would be destroyed, but since a Macintosh application can't run under Windows, there's no loss. The main reason uuencode still exists is historical - it was so prevalent in the days before MIME that it remains a necessary fallback when sending to folks using Windows and other platforms who haven't upgraded their email programs in several years. **Base64** -- As a transfer encoding format, Base64 is quite similar to uuencode but has the advantage of being modern and standardized. As with uuencode, if you send a Macintosh file using Base64 encoding, you'll lose the resource fork. Remember that Base64 is automatically used with AppleDouble, and if you're looking at a Windows email program, "MIME" in the context of attachment formats probably means Base64 encoding I haven't quite been able to complete testing with AOL, but it appears that Base64 is the best choice for sending attachments to AOL users. Other formats work, but not as seamlessly. We'll have results next week. **BinHex** -- As I noted above, BinHex is an amalgam of binary packaging format and transfer encoding format. It combines both forks of a Macintosh file, then turns that 8-bit file into 7-bit ASCII text for sending. BinHex remains popular for sending files via email between Macintosh users, since essentially all Macintosh email programs understand BinHex. However, BinHex works far less well when sending files to Windows users, since few Windows email programs other than Eudora can decode BinHex. Many Mac users still rely entirely on BinHex for sending files via email, and if it works for you, that's fine. However, I would encourage you to switch to AppleDouble if possible, and here's why: * Although BinHex is standardized, unlike uuencode, it's still an old format that would be good to relegate to the back burner for occasional needs so as to encourage everyone to upgrade to and support AppleDouble (most modern email programs do). * If you send a file to both Macintosh and Windows users, there's a good chance that the Windows users won't be able to decode the file if you used BinHex. * As discussed in "Calling Developers to MacBinary III" in TidBITS-444_, BinHex doesn't support the new icon badges or custom routing information that's been available since Mac OS 8.5 shipped. That information may not be crucial, but there's no reason to use encoding formats that don't support it. On the other side of the argument, BinHex includes an integral checksum at the end of the file, which means it's easier for an email program to check the attachment for corruption when BinHex is used than with other formats. **Quoted-Printable** -- Although quoted-printable, which most people have only seen via the QP button in Eudora, is a transfer encoding format, it's used not for attachments, but for high ASCII characters (special characters with diacritical marks, for instance). Since they aren't part of 7-bit (or low) ASCII, quoted- printable encodes such characters as an equal sign followed by a number. Since all other low ASCII characters remain intact, the message remains mostly human-readable despite the quoted-printable encoding. An email message with equal signs at the ends of the lines is almost certainly a quoted-printable message that hasn't been decoded, usually because the Content-Transfer-Encoding header that specifies the quoted-printable encoding is missing. This problem crops up primarily in mailing list digests, since mailing list software removes most headers from messages before combining them into a digest. The main solution to this problem is MIME digests, which maintain headers for each message within the digest, facilitating bursting the digest into a mailbox and retaining special headers that specify transfer encoding. **The Role of Compression** -- Just when you thought you had a handle on all this, I'm going to throw in another variable: compression. It's often a good idea to compress files before sending them via email. That's especially true if you're sending large files or if you want to attach many files to a single message, since compressing the files into a single archive will save space and may make them easier to work with on the other end. I say "may" because one of the developers of Mulberry, which is primarily an IMAP email program, noted that in the IMAP mentality everything lives on the server until requested by the client, so being able to pick and choose one of several attachments to download is an advantage. Compression can offer another advantage in that it may allow Macintosh files to survive transfer encoding that would normally destroy a file's resource fork. For instance, a StuffIt 5 archive stores everything in the data fork, so uuencode and Base64 won't damage it. Previous versions of the StuffIt file format could store some data in the resource fork (believe me on this, the information comes straight from the developers); moving everything to the data fork for cross-platform support was one of the main reasons Aladdin introduced the StuffIt 5 format. So, if you're using an email program that can compress files automatically before sending, uuencode and Base64 may work much better for you. Of course, if you send a compressed file to a Windows user via email, they may be able to decode the attachment fine but find themselves left with a compressed file that they can't expand. If you anticipate sending that person lots of compressed files, encourage them to download a free copy of Aladdin Expander for Windows, which can decode a wide variety of formats, much like StuffIt Expander on the Mac side. On the other hand, if you need to send a compressed file to a Windows user only occasionally, both DropStuff 5.5 and StuffIt Deluxe 5.5 can create Windows self-extracting applications (.exe instead of .sea) that your recipient could launch to expand. Another use for compressing files is if you want a Windows or Unix machine to be a go-between for two Macs with files that require resource forks. By compressing the file down to just a data fork, you can ensure that no information is lost when the file stops temporarily on an intermediate machine before moving on to the destination Mac (via a network, floppy disk, or some other transfer mechanism). Of course, this assumes StuffIt Expander is available on the destination Mac. **What You Attach** -- Throughout this discussion, I've barely skimmed the surface of the types of files you're attaching to email. It won't do your recipient any good if you choose the proper attachment format if they can't open the document inside. The variables involved with choosing the proper format are numerous, but follow these recommendations and you'll be on the right track. * If possible, ask what programs your recipient has that could open the file you're planning on sending. Then save the document in a format that you know can be opened by the recipient's programs. * Make sure to give your files appropriate filename extensions for Windows, since without a .doc extension, for instance, Windows can't figure out that a file should open in Microsoft Word. Some email programs help with this; Outlook Express can optionally add extensions automatically, and Eudora goes to some effort to provide the extension in the meta-data about the attachment, without changing the actual name of the file. * Most document formats for major productivity applications like the Microsoft Office suite, Adobe products, and so on, are fully cross-platform. If you stick to well-known applications that have Macintosh and Windows versions, conversion isn't likely to be a major issue. With files like spreadsheets and databases, sticking with the formats used by popular applications is your best bet, since the few available interchange formats are often quite limited and annoying to use. * For word processing documents, Microsoft Word format (without the Fast Save option turned on) is the usually best choice and the most likely source format, followed by RTF if either of you aren't using Microsoft Word. If all else fails, drop down to straight text, which you can send within the body of a message instead of as an attachment. As a matter of manners, if you're sending a document that's meant to be read-only, and the contents are pure text, just paste them into the body of the message rather than using an attachment. * For graphics, stick either to the native file formats of cross- platform applications like Adobe Photoshop or to standard and well-supported graphics formats like GIF, JPEG, TIFF, EPS, and PNG. * For sounds, stick to standardized formats like AIFF, MP3, and WAV. * When in doubt, keep a copy of DataViz's MacLink Plus around (apart from a brief hiatus recently, it has shipped with the Mac OS for a long time) for translating between different file formats. **Sealing the Package** -- I hope this article has thrown some light on what has traditionally been a murky subject. The question that prompted the entire topic - the best format to use when mailing files to Windows users - seems relatively simple, and in an ideal world, we wouldn't even think about it. That's in large part why I recommend AppleDouble (with its transparent Base64 encoding) for everything - it _should_ work with all modern email programs that adhere to Internet standards. The fact that it doesn't always work doesn't mean that we should rely on other formats for more than the occasional file to a user of an old email program. Rather, it means that we should work all the harder to make sure AppleDouble is supported everywhere so the entire question can fade into the depths of Internet lore, where it belongs. No one should even have to think about attachment formats, and only with full compliance with the MIME standards of AppleDouble and Base64 can we reach that point. Next week I'll finish this topic off with information about what formats today's major email programs support for sending attachments, plus the results of our tests with receiving attachments on AOL. $$ Non-profit, non-commercial publications may reprint articles if full credit is given. Others please contact us. We don't guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. This file is formatted as setext. For more information send email to . A file will be returned shortly. For information: how to subscribe, where to find back issues, and more, email . TidBITS ISSN 1090-7017. Send comments and editorial submissions to: Back issues available at: And: Full text searching available at: -------------------------------------------------------------------