Dealing With Attachments

From: Kent Landfield <kent_at_hypermail-project.org>
Date: Wed, 10 Jun 1998 15:09:13 -0500 (CDT)
Message-Id: <199806102009.PAA05223_at_landfield.com>

I think we need to come to some sort of consensus as to how attachments should work in Hypermail. Here is a start at describing the functionality and usage of attachments along with some proposals to be discussed.

Linking Attachments to messges:

---

    I wrote in the futures piece recently:

        o Need to have the enclosure filenames tied somehow to the 
          file it is linked from for removal and incremental updates.

    At present there is no linkage between the attachments and the     message they are a part of. This is a problem for a removal or     converter process. These processes must read each and every     message entirely to determine if there is an attachment and what     their storage names are. For that matter, so does incremental     mailbox updating.

• Proposal 1: Recognizing Attachments

       I propose that we use printcomment to indicate if a message
       contains attachments.  It should be in the message information 
       content block at the top of the message.



           <!-- received="Wed Jun  3 13:58:57 1998 CDT" -->

           <!-- sent="Tue, 02 Jun 1998 11:52:05 -0700" -->

           <!-- name="Kent Landfield" -->

           <!-- email="kent_at_landfield.com" -->

           <!-- subject="Test for Attachments" -->

           <!-- id="357449D5.932A5A5D_at_landfield.com" -->

           <!-- inreplyto="" -->

           <!-- attachment="filepath1" -->

           <!-- attachment="filepath2" -->

           ...


           <!-- attachment="filepathN" -->


      Besides making it much easier for removal or converter 
      processes, standard incremental mailbox updates will be 
      able to recognize that there are attachments and use the 
      existing filenames or remove them prior to generating new 
      ones. 

KNOWN BUG: At present if you have an archive that you are periodically 
           updating via a mailbox and are not overwiting the archive, 
           the bin* files are not reused but are recreated anew. This 
           leaves the previous bin* files in the archive directory and 
           orphaned.

Attachment Formats

---

• Proposal 2: Saving Attachments (Nigel Metheringham)

       The content-transfer-encoding stuff should be undone and the 
       things saved as binary (not base64 etc).

    This is being done today in 2.0b2 except that the names are generated     in such a fashion that there is no filetype suffix (no .gif, .jpg, ...)     being used.

Attachment Suffix Usage:

---

• Proposal 3: Attachment File Suffix Usage (Craig Summerhill)

       If the MIME type is known, adding an extension to the file when 
       it is saved to disk would aid a browser in processing the file 
       with a helper application upon retrieval.

Attachment Security issues:

---

• Proposal 4: Attachment File Modes (Craig Summerhill)

       For security reasons, *all* binary attachments should be 
       written to disk with file permissions of 444 or equivalant 
       read-only access and should *never* allowed to be executable.

    (Kent's personal bias) This should not be a configurable item. It     should be hardcoded and enforced. If someone really wants to change     it then they can go into the source and do so. We should not enable     them to screw themselves up accidentally by not thinking or by not     understanding...

Attachment naming:

---

    This is an area that might need discussion. The choices and issues     are: (if I missed any, please let me know)

1. Name the attachment storage file by using the basename of the filepath specified in the message as the original filename.

             <a href="budget.doc">budget.doc</a>

           Concerns:

             Need to worry about uniqueness, does a valid name exist and
             what to fall back to in the event there is no decernable 
             information supplied. Need to also assure that only the
             base filename is used (/etc/passwd would be passwd). 

           Benefits:
 
             Matches the name the user sent it as thus reducing the need
             for someone downloading the attachment to have to rename it.

        2. Generate a filename that is based on the message it is 
           attached to.

             <a href="bin0001-1.doc">budget.doc</a>

           Attached from 0001.html and it is the first attachment and it
           is of suffix type .doc.

           Concerns:
   
             Need to verify that there is valid suffix information or
             need to look it up in a mime.types file.  Downloaders may
             need to rename the file before it can be used.
          
           Benefits:
 
             This makes it easy to see what goes with what by just looking 
             at a directory listing.

        3. Generate a random name assuring at a minimum that the file 
           suffix is of the same type of the attacment file. (.gif, ..)

             <a href="binxyzzy.doc">budget.doc</a>

           Concerns:
       
             Same as #2 above.

           Benefits:

             Easiest to implement.

There is no proposal for attachment naming at this point. The table is open for discussion. I'd like to see some sort of concensus so we can implement it one way once and for all. It also makes documenting it much easier. :)

While I am in favor of all the proposals made here, the proposals are just proposals and are open for discussion .

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: kent_at_landfield.com             http://www.landfield.com/
Email: kent_at_nfr.net                   http://www.nfr.net/
Please send comp.sources.misc related mail to kent_at_landfield.com
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/

Received on Wed 10 Jun 1998 10:10:32 PM GMT