Date: Sun, 9 May 2004 06:33:57 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Edwin Groothuis <edwin@mavetju.org>, freebsd-questions@freebsd.org Subject: Re: Problem transporting signed emails Message-ID: <20040509033356.GA38228@gothmog.gr> In-Reply-To: <20040509015705.GA48222@k7.mavetju> References: <20040509015705.GA48222@k7.mavetju>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2004-05-09 11:57, Edwin Groothuis <edwin@mavetju.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040509033356.GA38228>