I host a few neighborhood email lists on my Linux server running the excellent GNU Mailman list server software. Part of my setup involves stripping pictures/documents from emails and storing them in the list archives instead. This way 300 neighbors don’t get a 5 MB attachment emailed out to them: if anyone wants to view the picture/document all they have to do is click on a link in the original email and it will be fetched from the archives.

Tonight I noticed that the MIME type image/pjpeg wasn’t being properly parsed by Mailman’s Scrubber.py script. Having dealt with MIME type problems before, I suspected that the problem wasn’t with Mailman itself but the operating system’s definition of the MIME type.

Sure enough, checking the /etc/mime.types file revealed there was no image/pjpeg type defined. A little more Internet hunting brought me to this post on the Mailman list, confirming the missing mime.type info as the culprit:

On Jan 6, 2010, at 8:18 AM, Ralf Hildebrandt wrote:

> * Ralf Hildebrandt :
>> I have a list where the attachments are removed and stored on the
>> mailman server itself.
>>
>> This works like a charm, but SOME image attachments of the type:
>>
>> image/pjpeg
>>
>> are stored as “attachment.bin” instead of “attachment.jpg”
>>
>> Why?
>> Example below:
>
> adding “image/pjpeg” to /etc/mime.types fixed that:
>
> image/jpeg jpeg jpg jpe
> image/pjpeg jpeg jpg jpe

This is because Mailman uses Python’s mimetypes module to generate the file
name, and I believe that consults /etc/mime.types where available. Since
before you edit Python didn’t know anythig about image/pjpeg, it assumed it was
random binary data, hence the .bin suffix.

-Barry

From what I can find out, image/pjpeg is a type that Microsoft products choose to use instead of the image/jpeg that the rest of the world uses. I guess those crazy Redmonders are just trying to keep us on our toes, eh?