A co-worker that I'm trying to get converted over from using our old Qpopper POP server to my beta Courier 0.42.2 setup immediately complained that attachments no longer worked right. He does lots of Photoshop image processing work for us, and people often send him images as attachments (please, no comments about how other avenues would be better, Lord knows I've tried) and it's vital to his work that he be able to click on an attachment and have it come up properly or to save the attachment and be able to double-click the saved attachment and have it come up properly, etc. and so on.

I took a look and immediately found the problem (or, one of them) - he had forwarded 2 e-mails to me from another co-worker, and that co-worker had sent them from Eudora on Windows using uuencode as the attachment encoder. I looked at the original message in the mail spool on the POP server and compared it to the one in the user's "cur" Maildir on the new Courier server, and found this in the headers:

--------------------------------------------------------------------------- POP/correct:

------------ Content-Type: image/jpeg; name="Thanksgivingpals.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-Transfer-Encoding: x-uuencode Content-Disposition: attachment; filename="Thanksgivingpals.jpg"

begin 600 Thanksgivingpals.jpg M_]C_X``02D9)1@`!`@$`2`!(``#_X1S417AI9@``34T`*@````@`!P$2``,` [...]

--------------------------------------------------------------------------- Courier/incorrect:

------------------ Content-Type: image/jpeg; name="Thanksgivingpals.jpg"; x-mac-type=4A504547; x-ma c-creator=4A565752 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Thanksgivingpals.jpg" X-Mime-Autoconverted: from x-uuencode to 7bit by courier 0.42

begin 600 Thanksgivingpals.jpg M_]C_X``02D9)1@`!`@$`2`!(``#_X1S417AI9@``34T`*@````@`!P$2``,`

---------------------------------------------------------------------------

Why did Courier attempt to alter the attachment encoding in the first place? ("X-Mime-Autoconverted: from x-uuencode to 7bit by courier 0.42")

Also, if it claims it "Autoconverted from x-uuencode to 7bit", why did the rest of the attachment remain untouched, i.e. it's still there as a uuencoded section? No actual conversion took place ...

How can I fix/stop this from happening? This is a real show-stopper for me.

(I've got "opt BOFHBADMIME=accept" in .../courier/etc/bofh, but that's about it. No "MIME" setting anywhere - from my reading of submit(8), I didn't think that would make any difference anyway.)

Thanks,

- Greg