Re: Dealing With Attachments

From: Kent Landfield <>
Date: Thu, 11 Jun 1998 10:36:38 -0500 (CDT)
Message-Id: <>

# I am against all naming schemes that names the attachments in a fashion
# similar to the mails themselves or in subdirectories for each single mail.
# When I've processed a large mail archive, I'd like to be able to see all
# attachments using sensible names that allow me to manually see and use
# extracted files without digging through mails to find out which files are
# which.
# I could imagine all attachments get put in a separate sub directory though,
# instead of the same as all the HTML files. I say make it a config item.

I can live with this. Does this sound reasonable to others ?

# To another concern I've already brought up before, but I'll do it again since
# this subject makes it current again:
# config file
# Can the current (imho limited) config file system and functions deal with the
# newly suggested items such as:
# 1. A list with 'prefered' content-types when receiving/decoding
# mixed/alternative attachments
# 2. A list with content-types to be skipped (i.e not save) when decoding
# attachments.
# 3. A list with content-types of images that is prefered to get inlined - <img>
# instead of <a href>.
# 4. External programs for decoding of certain content-types/
# Content-Transfer-Encodings ?

Good list. I've added them to the attachment proposals I'll post in a bit.

As to the config file usage... There is nothing to say we can't create a special config file for dealing with certain aspects of attachments. I'm not crazy about it but it is a possibility. We can change the config file parsing if we need to. That's not a big deal. These items need to be configurable on a per-list basis and I'd really not like to see two separate config files needed for granular control of each list. We should be able to do it with one.

Possible config file additions: (Just ideas)

   # Indicate that you do or do not want to process attachments 

   hm_doattachments = [ 1 | 0 ]
   # For each type to be ignored, put an hm_ignore record for that
   # type. It is added to the list of ignored types when the config
   # file is read.

   hm_ignore = text/x-vcard
   hm_ignore = application/x-msdownload
   # ordered list, Do the first and if that is not present, 
   # do the next and if that is not present ...

   hm_multipart = text/plain text/html ...
   # Determine which image mime types should be inlined for
   # display in the message. <IMG SRC=..> instead of <A HREF=...>

   hm_inline = image/gif image/jpeg ...
   # For each type to be processed by an external application, put a 
   # hm_external record for that type. The format is, mime-type executable
   # This is added to the list of externally processed types when the config
   # file is read.

   hm_external = text/x-vcard process_vcard    hm_external = application/x-msdownload scan_for_virus

(Yes it does not make sense to have hm_ignore values for records that you want to process externally. In this case I'd say drop them on the floor. :))

This would require that the readconfigs function would need to be able to look for more than one entry of certain types of variables. Not really that big a deal. And it would be preferable to creating, documenting and managing an additional config file.

FWIW...I really don't like the idea of hypermail using external applications to decode certain types of message traffic. Yes I know.. the ways and reality of the world today.. sigh... but we need to be very careful about the security issues here. This is a can of worms that we may want to do more research on as to it's need before we open it up.

# I do have more ideas and thoughts too, but I'll just mention them shortly
# here:
# * I have a doubt that we deal with all kinds of uuencoded attachments as
# defined with 'x-uue' in the current hypermail. Other MIME resources mention a
# whole set of different names for this kind of encoding, but are they in use?
# * I would very much like to see hypermail deal with Sun's (silly) mailtool
# attachments in a manner similar to how it deals with mime attachments. It
# would be really cool if the output would be identical and the differences
# hidden from the user(s).

We should make sure we can do them in the future with what we come up with but I don't think they are a priority right now. I've added them to my Futures file.

Kent Landfield                        Phone: 1-817-545-2502             
Please send comp.sources.misc related mail to
Search the Usenet Hypertext FAQ Archive at
Received on Thu 11 Jun 1998 05:37:47 PM GMT

This archive was generated by hypermail 2.2.0 : Thu 22 Feb 2007 07:33:49 PM GMT GMT