[Mailman-Users] attachments in archives have wrong extensions

[Mark Sapiro]

DW wrote:
>
>When users send email to any of my lists with attachments, they go 
>through fine. But when someone tries to go back and get an attachment 
>from one of the archives, they almost always find that the link to the 
>attachment has a bad extension, and the web browser doesn't know what to 
>do with it. If you do a "save as" and rename it with the proper 
>extension, the attachments seem to be intact and ok. But most users 
>don't know to do this, an it is causing us problems.
>
>Any solution to this?
>
>Here is an example of a file that was posted as MyFile.zip:
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: IFQSysFlights.zip
>Type: application/x-zip-compressed
>Size: 206816 bytes
>Desc: not available
>Url : 
>http://my.mailman.server/mailman/private/testlist/attachments/20050916/132776cc/MyFile-0001.bin

The scrubber makes the extension from the content-type (shown as Type:
above). If this doesn't agree with the attachment's extension, the one
'guessed' from content-type is used. Here are comments from Scrubber.py

 # If the filename's extension doesn't match the type we guessed,
 # which one should we go with?  For now, let's go with the one we
 # guessed so attachments can't lie about their type.

The problem in your case is that application/x-zip-compressed is not a
registered type (no 'x-' types are). See
ftp://ftp.iana.org/assignments/media-types/

One possible solution is to use an MUA that will call a .zip file
"Content-Type: application/zip" which is a registered type, but this
probably is not a practical solution.

Another possibility is to change the scrubber to use the file extension
if any.

--
Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan