This is a discussion on [openssl.org #1400] spurious CRs in S/MIME clearsigned mails - Openssl ; [email@example.com - Wed Jan 17 20:15:49 2007]: > > Right: Outside of some very basic cases, like English Ascii text, > OpenSSL isn't enough MIME-aware to be usable alone. There is still a > need for pre- and post-processing around ...
[firstname.lastname@example.org - Wed Jan 17 20:15:49 2007]:
> Right: Outside of some very basic cases, like English Ascii text,
> OpenSSL isn't enough MIME-aware to be usable alone. There is still a
> need for pre- and post-processing around OpenSSL before a proper mail
> can be fed to an MTA. The presence of "MIME-Version:" header is one
> problem, and there are others.
> But a complete solution to this problem would probably be to
> integrate full MIME-awareness, a big part of an MUA, inside OpenSSL.
> Charsets, all other MIME types, subtypes, parameters, a set of options
> for the user to control this, some smart defaults, and the like...
> That's big work.
> Today OpenSSL is more or less enough for quick and dirty (not 100%
> standards compliant) scripts, for simple cases.
That's all it was ever designed for. The "smime" application in SMIME
format is really a sample utility providing just enough functionality to
handle minimal cases. It was never intended to be a full blown S/MIME
client. Apart from the MIME parsing it lacks certain features such as a
certificate and capabilities database.
At the time the internal MIME parsing/generation was written (some years
back) there wasn't any usable MIME parser/generator which would
correctly handle the multipart/signed type. They'd end up reencoding the
thing and corrupting the signature.
Some of the S/MIME clients at the time also did rather strange things
and some still do. For example:
If blank lines were absent in certain places (where they shouldn't
matter) one for example would show a "signed" icon and blank email.
Others give bogus "tampered" messages when the message isn't what is
deemed to be correct for an arbitrary value of "correct".
The only way to get anything like reliable operation was to examine the
messages such clients produced themselves and cut and paste the results
followed by rather a lot of interop testing to see what form they'd all
The resulting output was sufficient to pass an "S/MIME compliance test"
ages ago but I don't think the site is still around.
Anyone wanting additional functionality would be advised to either use
the smime application in DER or PEM mode and handle the MIME externally
or better still write a custom code using the documented S/MIME API.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org