An attachment handling system for the alpine mail client

I like almost everything about alpine, the fine open source mail client from the University of Washington. The one place it seemed lacking was in its handling of attachments. It used the metamail system developed years ago by Bell Communications Research, Inc. (Bellcore) and the developers resisted requests to include special attachment handling in its code. Other clients appeared to do a better job but I have found that they require constant updating to provide for the many additions arriving almost every day from my correspondents , and each seems to be using the latest and greatest. I now realize that keeping the attachments so separated let me individually address each attachment on my own terms. This allows me to rapidly add filters to address "new" formats in a fully controlled manner without "adjusting" or "patching" alpine itself. I have written a back end script that works with the metamail mailcap (my personal .mailcap) to directly handle those attachments that cannot be vectored directly to a viewer by mailcap. I have also found that some correspondents have their machines incorrectly set up and sometimes send mis-identified file types or sub types. Others may be actually nefarious. Because of the possibility of nefarious senders, I often send attachments through my own filter to verify and read the contents. I also verify that alpine's ability to pass named parameters to my filters is disabled (it is by default. see config setting: " [ ] Enable Mailcap Parameter Substitution "). As most, if not all, of the display programs require an actual display and do not play well with remote access, the actual handling is sorted by whether we are local or remote.

Most common formats are easily handled directly by mailcap vectors. Faster machines sometimes have problems with the target attachment being deleted before it is read but this is easily avoided by using a sleep command in the mailcap invocation such as, “application/type; command %s \; sleep 5”.

Specialized file formats or those needing special parameters require more preparation work that is provided in the customized octet-stream handler, octet-stream. Various viewers are invoked by my custom octet-stream according to the output of the Linux "file" command. This allows detection and quarantining of binaries and executables. Parameters can be applied to filtering programs if needed to process safely. If the file cannot be handled, a message is left briefly on the alpine terminal suggesting alternative action. Alpine sends the attachments along to the script via a temporary file created in /tmp/ with the user's permissions. If the handler selected needs or uses filename extensions to take actions, (example: File-Roller, a de-archiving program) the necessary extensions can be added to that temporary file's name. See the zip, gzip, and bzip2 handlers in octet-stream.

New file types can easily be added as discovered. A particularly dirty one was the “tnef” (Transport Neutral Encapsulation Format) added to mailers by some Microsoft software as a method to archive and compress email attachments. This was handled in an iterative crawl through such extracted files using octet-stream. This script train uses the tnef decoding binary I stored in /usr/local/bin/. There is a man page. For older versions use tnef --help The latest release can be found at: http://sourceforge.net/project/showfiles.php?group_id=57057.

Other additions include the handlers called from octet-stream vectors for Microsoft Office 2007+ .docx, .pptx, and .xlsx files, respectively, in OO. Open Office V3.0 now handles these in the raw and doesn't need the OdfConverter referenced in the script, but I used OO V2.4 and it surely needed some help. My script includes the older code as commented out.