Sam Varshavchik wrote:Jerry Amundson writes:
Sam Varshavchik wrote:
Jerry Amundson writes:
I set ARCHIVEDIR to capture everything being delivered. The captured data file has the original MIME boundaries in place, and when copied to a maildir has a perfectly readable attachment.
Check whether the original message has trailing CRs. If so, it means that when the message was originally received via SMTP, lines were terminated with CRCRLF, instead of CRLF. Garbage in, garbage out.
None. The highest numbered character in the file is ~ (0x7E).
So? I didn't ask about the highest character, just about spurious CR characters.
And I answered "None."
Throw me a bone here, I'm taking shots at possible things that might be causing the problem.
The last character of the file is a NUL - but I see that in many of the data files also..
The =0D did not appear out of thin air. Furthermore, NUL characters in E-mail messages are also invalid.
So? :-)
Would that trigger Courier to re-encode a message that was already q-p? Obviously not. As I mentioned earlier, I see NUL's as the last char of many data files.
Actually, a DEL character would trigger the rewriting. I just looked it up. That's the explanation - DELs are triggering the rewriting.
But this code has been in place right from the beginning.
pgp00000.pgp
Description: PGP signature
