This is a discussion on Re: [openssl.org #1400] spurious CRs in S/MIME clearsigned mails - Openssl ; Hello Lloyd, On Monday, January 15, 2007 at 23:32:33 +0100, Lloyd Parkes via RT wrote: > The larger problem is that the smime command doesn't generate valid > S/MIME output. Right: Outside of some very basic cases, like English Ascii ...
On Monday, January 15, 2007 at 23:32:33 +0100, Lloyd Parkes via RT wrote:
> The larger problem is that the smime command doesn't generate valid
> S/MIME output.
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.
Serious MUAs do it another way: Example Mutt prepares itself the
MIME entity to be signed, uses "smime -outform DER" to get a raw binary
result, and does the final MIME encapsulation itself.
My method, with default "smime -outform SMIME" but pre- and
post-processing, is in some way intermediate between the two. Easy
enough to be hand-made, but standards compliant result.
> What I need is standards conforming S/MIME (if there is such a thing).
> I don't want any extras from the system and I want something that
> helps be speak SMTP.
But how would you send a French text (in Latin-1 charset) with an
audio/wav attachment? Impossible today with only OpenSSL and an MTA.
> I would like to replace the -crlfeol command line flag with
> -canonical. Without this flag, 'openssl smime' should generate lines
> with the local platform dependent eol and all the headers it generates
> now. With the -canonical flag, it should generate valid S/MIME output.
> All lines will be CRLF terminated (headers and base64) and the
> 'MIME-Version' header will not be emitted.
If I'm not mistaken, your usage case doesn't need CRLF lines in the
final mail. You could do with whatever local EOL, because MTAs do the
necessary local-to-CRLF transform during the SMTP sending operation. You
only need "MIME-Version:" removal. And I don't really see why link both
features in one option: A unix user may want CRLF lines (to share *.eml
files readable for Windows, main usage case of -crlfeol) but still want
"MIME-Version:" in the final generated message.
I would more see keeping -crlfeol alone, acting consistently on all
lines. And invent another mechanism to have "MIME-Version:" in the final
mail, but not in parts. Either a new option, or something like (rough
idea): Generating "MIME-Version:" when outputing to -out file
(presumably a final complete mail), but not when outputing to implicit
stdout (presumably a part piped to another round of OpenSSL, think
"smime -sign | smime -encrypt -out final.eml").
/* Bruno Kozlowski
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org