On 2004-05-09 11:57, Edwin Groothuis <[EMAIL PROTECTED]> wrote: > Greetings, > > I've been playing with signed emails (S/MIME, OpenSSL etc) but am > running into an annoying problem: "openssl smime -sign" signs the > text, but it adds ^M's at the end of the lines of the original text. > When piping it through to the MTA, somewhere the ^M's are lost and > the signature of the file including becomes invalid.
[snip] > ------259958A68922550377544CEFAD9013E9 > Content-Type: text/plain^M > ^M > This is a test.^M > This is a text.^M > > ------259958A68922550377544CEFAD9013E9 > ============ 8< ==================== > > Piping this through sendmail (postfix) for delivery on the same > machine gives me the same text with the ^M's. Piping this through > sendmail for delivery on a different machine gives me the text > without the ^M's, which invalidates the signature on the email. Try base64-encoding the signed message, instead of piping it through as text/plain. The ^M characters [ascii:13] at the end of lines terminated with ^J [ascii:10] can be intepreted by network servers and/or clients as part of EOL, the end of the line. A good explanation of why this might happen is found in [Richard Stevens, "TCP/IP Illustrated", Vol. I, pp. 401]: : NVT ASCII : : The term NVT ASCII refers to the 7-bit U.S. variant of the ASCII : character set used throughout the Internet protocol suite. Each 7-bit : character is sent as an 8-bit byte, with the high-order bit set to 0. : An end-of-line is transmitted as the 2-character sequence CR : (carriage return) followed by an LF (line feed). We show this as \r\n. : A carriage return is transmitted as the 2-character sequence CR followed : by a NUL (byte of 0). We show this as \r\0. Giorgos _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
