Hello Roumen,
On Tuesday, October 17, 2006 at 17:52:34 +0200, Roumen Petrov via RT wrote:
> Please could you defail used software.
The simplest failing setup is:
-a) Sending Linux Debian Woody box:
- OpenSSL 0.9.8d (built from tarball)
- Exim 3.35-1woody2
- Qpopper 4.0.4-2.woody.1
-b) Recipient Windows box:
- Windows 2000 sp4
- MS Outlook Express 6.00.2800.1106
On the Debian box, the mail is generated and sent with:
| $ echo "some text" > textfile
| $ openssl smime -sign -text \
| -signer ~/.smime/certificates/26f06522.0 \
| -inkey ~/.smime/keys/26f06522.0 \
| -in textfile \
| -out mailfile \
| -to testuser \
| -from "Bruno Kozlowski <[EMAIL PROTECTED]>" \
| -subject "test smime"
| $ /usr/sbin/sendmail -t < mailfile # symlink to exim
On the Windows box, MSOE fetches the mail directly from the Linux
box, thru POP3, and fails signature verification. Following EOLs at each
step:
-1) OpenSSL generated mailfile has mixed EOLs: Most lines have LF, some
lines CRLF (the 3 signed lines):
| $ wc -l mailfile
| 34 mailfile
| $ cat -A mailfile | grep -c "\^M"
| 3
-2) Exim's spool preserved same mixed EOLs:
| # cat -A /var/spool/exim/input/1GarhL-0001Ve-00-D | grep -c "\^M"
| 3
-3) Delivered to testuser's mailbox with same mixed EOLs:
| # cat -A /var/spool/mail/testuser | grep -c "\^M"
| 3
-4) Fetched to MSOE inbox as CRLF for most lines, and CRCRLF for the 3
signed lines:
| $ cat -A Bote\ de\ rception.dbx | grep -c "\^M\^M\\$"
| 3
-5) The message exported as *.eml gives mixed CRLF and CRCRLF
(I gzipped and attached this .eml file for your experiments):
| $ cat -A test\ smime.eml | grep -c "\^M\^M"
| 3
-6) MSOE claims this message was falsified.
-7) If I modify "test smime.eml" file to remove the 3 spurious CRs,
canonicalizing all line endings to CRLF, then open the file in MSOE:
Signature verification succeeds.
Note I described the simplest setup, but various others produces the
same CRCRLF problem. Like with an intermediate Exim smarthost, with
Win98, or with a Redhat sending box (OpenSSL 0.9.8d, but unknown MTA).
OTOS many others setups filter out spurious CRs, and so eliminate any
consequence of the problem. Like with fetchmail on the path.
Also note that OpenSSL verification seemingly works OK in all cases:
LF, CRLF, CRCRLF, and even CRCRCRCRCRCRCRLF, in any mix from line to
line, and running on Linux or Windows. Always successfull.
> During the past weekend I have time to setup a test network:
Thank you very much for your interest, Roumen. I suppose that in
your setup the spurious CRs are filtred out at some stage?
> In case of version >= 0.9.7d mail are generated with and without
> openssl smime -crlfeol option.
This -crlfeol option doesn't seem to help. It's not much documented
(CHANGES file only), but the intended effect seems to be to end all
lines in CRLF. Strangely some lines still end in LF alone: The To, From,
and Subject headers, and the base64 lines encoding the smime.p7s file.
I believe that all written EOLs should be consistent: All LF by
default (on LF platforms); All CRLF with -crlfeol.
Bye! Bruno.
--
/* Bruno Kozlowski <[EMAIL PROTECTED]> */
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
