Re: Problem transporting signed emails
On Sun, May 09, 2004 at 11:49:38AM +0100, Matthew Seaman wrote: > On Sun, May 09, 2004 at 11:57:05AM +1000, Edwin Groothuis wrote: > > > 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. > > % openssl smime -sign -binary ... I got it. When feeding it to sendmail, it added an empty line after the content-type line, mostly likely because it was saw the ^M and didn't interpret it as an empty line. Running the output of openssl through "tr -d '\r'" and then feeding into sendmail resulted in a valid signature. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem transporting signed emails
On Sun, May 09, 2004 at 11:57:05AM +1000, Edwin Groothuis wrote: > 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. % openssl smime -sign -binary ... perhaps? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
RE: Problem transporting signed emails
Giorgos Keramidas said on Sunday, 09 May 2004 03:34 UTC: > Try base64-encoding the signed message, instead of > piping it through as text/plain. That would mean that only S/MIME capable mail clients could read the resulting email, wouldn't it? When I S/MIME sign an email (such as this one) even the most crufty old mailers can display the message body, without any understanding of MIME generally or S/MIME signatures. PGP operates similarly when signing but not encrypting. The original poster might want to focus on fixing or not using software which corrupts the line endings. Since S/MIME targets SMTP and SMTP (unlike unix) wants CR LF line endings, my guess is when you have a problem CR LF is being translated to CR CR LF or CR LF CR LF. Dave Hart [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Problem transporting signed emails
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]"
