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.
Is there some way I could strace a process delivering this data to one of the non-"8BITMIME" sites? (For my testing I use "netscape.net"...)
jerry
-- Jerry Amundson Publishing Business Systems, Inc. [EMAIL PROTECTED] 2611 Hamline Avenue North (651) 639-2730 Voice Suite 100 (651) 639-0306 FAX St. Paul, MN 55113
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
