8 messages in net.sourceforge.lists.courier-users[courier-users] Re: Problems with S/M...| From | Sent On | Attachments |
|---|---|---|
| Regular Expression | Nov 28, 2000 12:26 am | |
| Sam Varshavchik | Nov 28, 2000 2:45 pm | |
| Simon Josefsson | Nov 29, 2000 7:41 am | |
| xeg...@xeger.net | Nov 29, 2000 5:51 pm | |
| xeg...@xeger.net | Nov 29, 2000 6:10 pm | |
| Sam Varshavchik | Nov 29, 2000 7:46 pm | |
| xeg...@xeger.net | Nov 29, 2000 8:44 pm | |
| Sam Varshavchik | Nov 30, 2000 2:46 pm |
| Subject: | [courier-users] Re: Problems with S/MIME and Courier ESMTP daemon | |
|---|---|---|
| From: | Sam Varshavchik (mrs...@courier-mta.com) | |
| Date: | Nov 28, 2000 2:45:09 pm | |
| List: | net.sourceforge.lists.courier-users | |
Regular Expression writes:
Has anybody else had problems while sending digitally signed S/MIME messages via Courier's SMTP server? It accepts them and delivers them just fine, but it somehow modifies the message body so that the digital signature no longer works and the message shows up as altered--thereby making digital signatures worthless! It's quite aggravating.
The mail client I'm using *is* Outlook, but signed messages go through just fine with other SMTP servers, so it looks like Courier is at fault here.
The problem, apparently, is that S/MIME requires certain MIME headers to occur in a particular order, and S/MIME bitches loudly if these headers are reordered or changed.
Unfortunately, mail relays rewrite or modify headers all the time. Most just prepend an extra Received header. Some will append a Message-ID: header or a Date: header if one is missing. Some will automatically wrap long header lines into a smaller physical line size. Additionally, MIME does not impose any actual relative position of multiple MIME headers, so they can be freely reordered.
Courier chooses to rewrite mail headers more often than other MTAs, and its rewriting tends to be more aggressive, hence you'll see this problem more often with Courier, but, given enough time, you'll eventually get S/MIME corruption with other mail servers too.
I am not sure if S/MIME allows only the message content to be signed, or if mail headers must be included in the crypto signature. If they must, S/MIME will then appear to be a fundamentally broken standard that should not be used. PGP/GPG-signed messages are recommended instead.
Adding "MIME=none" to $sysconfdir/esmtpd might help, somewhat. This will suppress most, but not all, MIME rewriting for mail received via SMTP (but not the command line sendmail submitter).
-- Sam