Re: Dealing With Attachments

(grrr, once again accidentaly replied to the person instead of the list...)

Kent Landfield wrote:

> 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.

[cut]

> <!-- attachment="filepath1" -->
> <!-- attachment="filepath2" -->
> ...
> <!-- attachment="filepathN" -->

I'm in favour for this one. No matter how we solve the file naming issue, this must be the only reasonable way to do it, imho. It also allows us to change file naming method in the future without breaking old archives.

> * Proposal 2: Saving Attachments (Nigel Metheringham)
>
> The content-transfer-encoding stuff should be undone and the
> things saved as binary (not base64 etc).

Decoding base64 (and all other encoding types) is of course the last it should do, and it already does. One bug in the base64 decoder was fixed yesterday.

As a matter of fact, Hypermail has very little knowledge about the content of the attachments it decodes and it treats them all the same. In the current solution it doesn't even inline jpeg or gif pictures...

> * 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.

This is one of the main reasons for the patch I posted yesterday. It keeps the enclosed name, with a possible prefix letter, and therefore the suffix from the attachment info will be used properly. Of course, the algorithm for trying different names if the original attempt already is occupied can be greatly enhanced to do almost anything.

I must admit to Andew Kuchling's suggestion that we should also let the user specify a list of mime types which should not be stored at all. His good example is that vcard crap.

> 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.

My vote goes to this.

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.

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 ?

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).

-- 
          Daniel Stenberg  -  Software, Network and Unix
    GSM: +46 - 708 - 31 77 42   http://www.fts.frontec.se/~dast