Conference abbott::mailworks-unix

1351.0. "Attachment type problems" by TAMARA::OSM4S::Neumann (Stan Neumann) Tue Feb 18 1997 11:48

A couple of problems have appeared recently that generally
relate to bodypart tagging and decoding:

1) Starting with V2.0.2, MailWorks now supports full fileanames on
   attachments for local delivery, X.400 delivery, and SMTP/MIME.
   It does *not* yet carry filenames in the UUEncoded encoding
   used when sendMime is turned off (which is the default).  The
   filenames used with UUEncoding are of the form Enclosure1, Enclosure2,...
   
   The effect of this is that some mail clients and gateways that
   recognize UUEncoding, will assign the names Enclosure1, which in
   turn means that the client that depends on the filename to recognize
   the type will not recognize the type.
   
   The workaround is for the recipient to simply save the file with
   an appropriate name, and open the file with the appropriate application.
   (Note: we should encourage the sender to state the type of file and
   the version of the application in the cover memo, so that the recipient
   knows what to do with it.)
   
   An alternative workaround in special cases is for the sender to
   manually UUEncode the file with a tool that inserts a proper filename,
   then simply attach the UUEncoded file to the message.  Note that
   this may not work if sendMime is turned on, since apparently some
   mail systems turn off their search for UUEncoding when they discover
   MIME.
   
2) The MSMail driver includes a version of TLFormat.ini to assist in the
   mapping of file types from the server tagging to the tagging that 
   MSMail requires.  The version included in the driver kit has already
   gotten out of date (and will only get more so).  The symptoms of this
   are that an MSMail recipient sees an attachment that is not recognized
   by MSMail, but if s/he saves the file to disk with an appropriate
   filename, it can be opened by the appropriate application.  (Note that
   the symptoms are almost identical to the first problem, but the cause
   is very different.)
   
   The solution is to add the appropriate file types to the TLFormat.ini file
   used by the MSMail driver.  Note that you cannot simply take the 
   file from the latest version of TeamLinks, since newer versions of TeamLinks
   often add fields not recognized by the older MSMail driver code.
   Just the individual file type entries should be copied, and some of the
   newer fields should be dropped (e.g. in the following entry for Word 6, 
   the line for Template, MIMEContentType, and PegasusType should be omitted
   when creating the entry for the MSMail driver:
   
[WINWORD6]
Desc=Microsoft Word for Windows V6.0/7.0 Document
FileExt=DOC
IosFormat=WINWORD6
IosDsab=FOREIGN
IosFileExt=DOC
Asn1=2B0C02877305014F
Template=WINWORD6.DOC
MIMEContentType=application/msword; name="TL.doc"; Type=%%peg%%
PegasusType=MS-Word-6