Normally your email program is supposed to decode such files automatically, but often it won't. So, you can save the email to a file (save it to a temporary file named, for example, "xxx" -- it's OK to look at its contents!), and then run unbinhex on it:
newton> unbinhex xxxThis command doesn't produce any output to the screen, but unpacks up to 4 new files (check for your newest files using the command ``ls -alrt'') with related names but different suffixes, e.g.,
newton> ls -alrt | tail -rw-r--r-- 1 smith 21367 Nov 16 10:12 Mtg_minutes.data -rw-r--r-- 1 smith 1367 Nov 16 10:12 Mtg_minutes.desc -rw-r--r-- 1 smith 128 Nov 16 10:12 Mtg_minutes.info -rw-r--r-- 1 smith 458 Nov 16 10:12 Mtg_minutes.rsrcThe real attached file is the one with the .data suffix; it is typically a Word or Excel document, or a JPEG photo. But it can actually be anything at all, so use the file command to determine just what it is (e.g., ``file Mtg_minutes.data'').
The *.desc file is just email text added by the sender. The *.info and *.rsrc files are Mac-specific stuff (the icon and Mac filetype) that you can delete.
To complicate matters, some folks send attachments which get encoded in two ways, so that they must doubly-decoded! ``unbinhex'' will undo the BinHex encoding, but for the other encoding (uuencoding) you must use uudecode. Then, if the final product is a file named with the suffix .gz or .tar or .Z or .zip, it is in compressed and/or archived form, and must be unpacked using (respectively) gunzip, tar, uncompress, or unzip.