On the Linux platform, OpenSSL generating an S/MIME clearsigned mail
introduces spurious CRs at the end of some lines of the output.
Depending on mail transport conditions, those CRs can break signature
verification in MSOE on MS-Windows.

Example: I want to clearsign "some text". Under Linux with
OpenSSL 0.9.8d, I type:

| $ echo "some text" > textfile
| $ openssl smime -sign -text -signer ~/.smime/certificates/26f06522.0 \
| -inkey ~/.smime/keys/26f06522.0 < textfile > mailfile

The resulting mailfile has mixed EOLs: Most lines end in LF, but
3 lines end in CRLF:

| $ cat -A mailfile | grep "\^M"
| Content-Type: text/plain^M$
| ^M$
| some text^M$

Those are exactly the 3 signed lines: It seems that EOL
canonicalization somewhat leaked to the output mailfile.

Note: If I drop -text option, and feed openssl with a prepared MIME
part (mini-header, empty line, text), the same spurious CRs do appear.

One problem is that saving a text file with CRLF on a LF platform is
probably not really approriate. Mixed CRLF and LF is surely not.

Bigger consequence: Depending on MTA/MDA/POP3 tools transporting the
mail, those spurious CRs can be filtred-out or survive. Sending such
mails to Windows platform happens to result in CRCRLF. And with such
EOL, Outlook Express fails signature verification, claiming the message
was falsified. If anything filtred-out the spurious CRs, verification

Problem seen on OpenSSL 0.9.8d and 0.9.7e. Seemingly 0.9.6 (unknown
letter) had no problem.

Bye! Bruno.
/* Bruno Kozlowski */

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org