Problem transporting signed emails

[Giorgos Keramidas]

On 2004-05-09 11:57, Edwin Groothuis <edwin at 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