Jeff Potter writes:
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?
Only by changing the code. Although it's not recommended to have lines of text that contain \rs, they are technically valid.
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
Since the message is corrupted, from a MIME viewpoint, there is absolutely no guarantee what any mail server may end up doing with it.
In SMTP, if a message line ends in "\r\n" does it get treated as just a single "\n"?
This is outside of scope of SMTP.
Courier, when it receives a message via SMTP, replaces the trailing \r\n with a \n, internally.
When sending message via SMTP Courier adds them back in.
If a uuencoded part is using "\r\n" as line delimiters, should Courier be stripping the "\r" as well as the "\n"?
When it is stored locally, yes.
But any \rs in the middle of the line are left untouched.
pgpggJESq5h3h.pgp
Description: PGP signature
