Hi Sam,
I should add a bit more detail, I realize. We've got a client who's
getting email from someone else's server, where Courier is modifying
an attachment "X-Mime-Autoconverted: from x-uuencode to 7bit by
courier 0.45". The modified attachment can't be uudecoded on Windows
or Unix (but can on OS X), it appears, because of '\r' characters.
"x-uuencode" is not valid MIME encoding.
Ah, ok; so I take it Courier is gracefully fixing this by
autoconverting it to 7-bit for downstream users?
Is it possible that the autoconverting should strip \r lines as well?
I'm trying to figure out why attachments sent by this remote user to
other remote servers doesn't get garbled -- Courier is doing something
different: it's including the \r's in the autoconversion; and other
servers and users on other servers aren't having problems with these
attachments.
In SMTP, if a message line ends in "\r\n" does it get treated as just a
single "\n"? If a uuencoded part is using "\r\n" as line delimiters,
should Courier be stripping the "\r" as well as the "\n"?
If yes, Is this something you're willing to add into Courier?
(And where would I start to add this?)
The obsolete software that generates "x-uuencode" nonsense should be
upgraded or replace with something more modern, that properly
implements MIME.
The offending server is running "Sun Java System Messaging Server 6.2
HotFix 0.04" -- from Dec 2004. I feel like I have zero chance of
getting Sun to do anything.
Setting "opt BOFHBADMIME=accept" might prevent this from happening.
I'm not 100% sure. Besides, this would carry other side effects.
Nope; we already have that set to accept before this happened. :-/
Thanks!
Jeff
5 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: x-uuencode to...
