signed messages in S/MIME format corrupted by sendmail
Sven Menke
I seem to have some trouble sending digitally signed e-mails in S/MIME
format with the sendmail program of postfix. An example is taken from
the openssl smime man page:
openssl smime -sign -in in.txt -text -signer mycert.pem \
-from st...@openssl.org -to someone@somewhere \
-subject "Signed message"| sendmail someone@somewhere
An e-mail sent this way will not longer pass the verify step with
openssl because postfix changes the line breaks which are '\r\n' in
the S/MIME standard to '\n'.
Is it possible to configure postfix in a way that it does not change
'\r\n' to '\n'?
Thanks much for any hint!
With Best Regards,
--Sven
Wietse Venema
No, and this is on purpose.
When receiving or delivering UNIX files, the line terminator is
newline.
When receiving or delivering SMTP mail, the line terminator is
CRLF.
When retrieving mail with POP or IMAP, the POP/IMAP server should
provide the proper line endings. Note: the POP/IMAP server is not
part of Postfix.
I won't comment on the wisdom of insisting on non-UNIX line endings
within a UNIX environment.
Wietse
Sven Menke
thanks much for your reply - it triggered a test I made with the
non-postfix sendmail which also changes '\r\n' to '\n' as I expected
now from your reply, but digitally signed messages can still be
verified. So I looked a bit closer in the problem, since it's
apparently not the '\r\n' -> '\n' replacement that makes the postfix
sendmail messages invalid.
There's another difference I overlooked in my original post and that
is the insertion of an additional '\n' after the line:
Content-Type: text/plain
of the S/MIME signed message.
The Content-Type line is not the only one in the original file
followed by two '\r\n', but the only one receiving an additional '\n'
in the end ...
How can I avoid postfix from inserting that extra '\n'?
Thanks a lot for your time!
With Best Regards,
--Sven
Wietse Venema writes:
> Sven Menke:
Victor Duchovni
> There's another difference I overlooked in my original post and that
> is the insertion of an additional '\n' after the line:
>
> Content-Type: text/plain
This is insufficient context. Please provide full source for an
input message where Postfix inserts an additional blank line after a
Content-Type header.
> > > openssl smime -sign -in in.txt -text -signer mycert.pem \
> > > -from st...@openssl.org -to someone@somewhere \
> > > -subject "Signed message"| sendmail someone@somewhere
When I run smime(1) as above, with "in.txt" containing "hi\n", the
message has no CRLF terminated lines, rather it contains only "LF"
terminated lines.
When I generate in.txt via:
$ printf 'Hello, World!\r\n' > in.txt
The primary message headers and signature are still just LF terminated,
with the signed text encoded as:
------A5701126FE82F0C190BD683BAFDB7793$
Content-Type: text/plain$
$
Hello, World!^M$
$
------A5701126FE82F0C190BD683BAFDB7793$
It appears to me that the input is expected to be LF terminated. From
the smime(1) manpage:
...
-binary
normally the input message is converted to "canonical" format which
is effectively using CR and LF as end of line: as required by the
S/MIME specification. When this option is present no translation
occurs. This is useful when handling binary data which may not be
in MIME format.
...
This means that the signature is computed as though the text were CRLF
terminated, even though the text is output with LF termination as is
appropriate for Unix text files. So this looks rather like pilot error...
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Victor Duchovni
> thanks much for you reply! As I pointed out previously, openssl
> apparently can handle both '\r\n' and '\n' as line terminators - so
> that's not the problem.
The content of the canonicalized signed input is OpenSSL version
dependent. With 0.9.7a it is LF terminated. With 0.9.7g it is CRLF
terminated (even though the primary headers and signature are not!).
I consider the 0.9.7g behaviour to be a regression, but it should be
harmless.
> cat >test.in<<EOF
> Hello World!
> EOF
This is not consistent with the message contents below. Either the
file generation or the message below are modified evidence. This
has no additional blank lines after "Hello World!".
> openssl smime -sign -in test.in -out test.out -signer usercert.pem -inkey userkey.pem -text
>
> The original test.out looks like this:
>
> MIME-Version: 1.0
> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----207926EBC599A6EA7ACC5430D508CE76"
>
> This is an S/MIME signed message
>
> ------207926EBC599A6EA7ACC5430D508CE76
> Content-Type: text/plain^M
> ^M
> Hello World!^M
> ^M
> ^M
>
> ------207926EBC599A6EA7ACC5430D508CE76
Where did the 2 extra blank lines after "Hello World!" come from? This
is not the input file you claim to have started with.
> After sending this via postfix/sendmail (I have Debian 3.1 with postfix-2.1.5)
> the message reads:
> MIME-Version: 1.0
> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----207926EBC599A6EA7ACC5430D508CE76"
> Message-Id: <200603130842...@pcldeb2.mppmu.mpg.de>
> Date: Mon, 13 Mar 2006 09:42:05 +0100 (CET)
> From: me...@mppmu.mpg.de (Sven Menke)
> To: undisclosed-recipients: ;
>
> This is an S/MIME signed message
>
> ------207926EBC599A6EA7ACC5430D508CE76
> Content-Type: text/plain
>
>
> Hello World!
Postfix 2.1.0 - 2.2.9, and 2.3 snapshots through 2.3-20060307 add an extra
blank line after the header when sendmail -t is used to submit a message
and the blank line that terminates the header is CRLF rather than LF.
This recently identified issue will be resolved in 2.2.10 and in an
upcoming 2.3 snapshot. The specific release time is not yet set. If you
need a patch for 2.1/2.2 now, see the recent posts by Leandro Santi in
the postfix-devel archive.
Instead of patching Postfix, figure out why your smime(1) command is
generating CRLF terminated output. Mine (0.9.7) certainly does not.
Sven Menke
thanks again for replying!
Victor Duchovni writes:
> On Mon, Mar 13, 2006 at 10:02:24AM +0100, Sven Menke wrote:
>
> > thanks much for you reply! As I pointed out previously, openssl
> > apparently can handle both '\r\n' and '\n' as line terminators - so
> > that's not the problem.
>
> The content of the canonicalized signed input is OpenSSL version
> dependent. With 0.9.7a it is LF terminated. With 0.9.7g it is CRLF
> terminated (even though the primary headers and signature are not!).
> I consider the 0.9.7g behaviour to be a regression, but it should be
> harmless.
I have 0.9.7e and this is CRLF terminated.
> > cat >test.in<<EOF
> > Hello World!
> > EOF
>
> This is not consistent with the message contents below. Either the
> file generation or the message below are modified evidence. This
> has no additional blank lines after "Hello World!".
my fault - I forgot two blank lines in my example script here - but
they don't matter. With and without the blank lines (as many as you
wish) the result is the same: postfix corrupts S/MIME conformant
messages!
> > openssl smime -sign -in test.in -out test.out -signer usercert.pem -inkey userkey.pem -text
> >
> > The original test.out looks like this:
> >
> > MIME-Version: 1.0
> > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----207926EBC599A6EA7ACC5430D508CE76"
> >
> > This is an S/MIME signed message
> >
> > ------207926EBC599A6EA7ACC5430D508CE76
> > Content-Type: text/plain^M
> > ^M
> > Hello World!^M
> > ^M
> > ^M
> >
> > ------207926EBC599A6EA7ACC5430D508CE76
>
> Where did the 2 extra blank lines after "Hello World!" come from? This
> is not the input file you claim to have started with.
again - just take the output and pipe it through sendmail and never
mind the blank lines after Hello World! - they are not the problem ...
>
> > After sending this via postfix/sendmail (I have Debian 3.1 with postfix-2.1.5)
> > the message reads:
> > MIME-Version: 1.0
> > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----207926EBC599A6EA7ACC5430D508CE76"
> > Message-Id: <200603130842...@pcldeb2.mppmu.mpg.de>
> > Date: Mon, 13 Mar 2006 09:42:05 +0100 (CET)
> > From: me...@mppmu.mpg.de (Sven Menke)
> > To: undisclosed-recipients: ;
> >
> > This is an S/MIME signed message
> >
> > ------207926EBC599A6EA7ACC5430D508CE76
> > Content-Type: text/plain
> >
> >
> > Hello World!
>
> Postfix 2.1.0 - 2.2.9, and 2.3 snapshots through 2.3-20060307 add an extra
> blank line after the header when sendmail -t is used to submit a message
> and the blank line that terminates the header is CRLF rather than LF.
ah thanks - that explains it. And indeed if I convert the CRLF to LF
before piping the openssl output to sendmail no newline is added.
>
> This recently identified issue will be resolved in 2.2.10 and in an
> upcoming 2.3 snapshot. The specific release time is not yet set. If you
> need a patch for 2.1/2.2 now, see the recent posts by Leandro Santi in
> the postfix-devel archive.
many thanks for fixing this!
With Best Regards,
--Sven
Wietse Venema
> Postfix 2.1.0 - 2.2.9, and 2.3 snapshots through 2.3-20060307 add an extra
> blank line after the header when sendmail -t is used to submit a message
> and the blank line that terminates the header is CRLF rather than LF.
Try snapshot 20060313. It fixes this and message expiration
after "postsuper -r".
Wietse