Following the ideas discussed in this thread, I developed an AddServerSignature mailet
that:
1) Checks if the user was SMTPAuthenticated, his reverse-path is != "<>", the username
part of it is the same as the SMTPAuthenticated user, checks if the reverse-path
appears as one of the addresses in the From header.
2) If everything is ok, adds a Signature.txt attachment to the original message and
then signs everything with a server certificate, following the SMIME guidelines,
getting a new signed MimeMultipart.
3) Creates a new MimeMessage copying all the headers from the original one, sets its
contents to the signed MimeMultipart above.
4) Adds a Sender header with the mail address of the "trusted-server" signer.
The attachment is used to better specify the meaning of the signature; an example
follows:
-----------------------------------------------------------------------------------------
The message this file is attached to has been signed on the server by "Trusted Server"
<[EMAIL PROTECTED]>
to certify that the sender truly has the following address (reverse-path):
[EMAIL PROTECTED]
and that the message has the following message headers:
Subject: ...........
From: "..........." <[EMAIL PROTECTED]>
To: "'..........." <[EMAIL PROTECTED]>
Cc: null
Reply-To: null
Date: Tue, 23 Sep 2003 17:49:22 +0200
The signature envelopes this attachment too.
Please check the signature integrity.
"Trusted Server" <[EMAIL PROTECTED]>
-----------------------------------------------------------------------------------------
I managed to use a free Thawte certificate, with a chain certificate whose root is
automatically trusted by most MUAs.
The cryptolibraries used are both jdk1.3+, using also the BouncyCastle jars, whose
licencing is ASF compatible.
I deployed for a few days the mailet in my production system (matching myself and a
few coleagues with SenderIs), and it has worked very nicely. The message is also
nicely readable by non SMIME aware MUAs.
The mailet is totally ready and working. I was going to finalize the javadoc, write an
extensive wiki and commit everything to CVS to have you guys try it and feedback, when
I discovered a problem with Outlook Express (*not* with Outlook 2000), that IMO kills
all this idea of a server signed SMIME message :-(
The problem arises from the fact that the email address in the certificate ([EMAIL
PROTECTED] in the example above) is by definition unique and as such different from
the From header address. The SMIME rfc2311 (see http://www.ietf.org/rfc/rfc2311.txt)
doesn't tell anything against that (by the way, this is the reason why I added the
Signature.txt attachment above). Outlook 2000 accepts nicely the message and checks if
the *content* of the message has not been tampered with, and if the certificate is
trusted, ignoring completely all the headers. Instead it turns out that Outlook
Express (version 6.00.2800.1123) doesn't like the From header (not the reverse-path)
being different from the email addresss in the certificate, and shows a "frightening"
warning with a gothic red on black background with the following text:
The digital ID's e-mail address does not match sender's
Signer: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
IMO having a MUA behaving like this would be unacceptable, although I'm not sure if it
is a problem in Outlook Express or a check missing in Outlook 2000. So I undeployed
the mailet, and I think this whole approach doesn't work :-(
I'm reporting all this though because it is useful for all of us to know how the
things are concerning this topic. Obviously I will reconsider it if you guys people
think that the mailet may be useful in some cases (filtered by a RecipientIsLocal
matcher for instance, where the local recipients are internal to a company and the
MUAs are under control etc.). Any suggestions/opinions are welcome.
In order to better understand the situation of MUAs and SMIME, I think it would be
worth to know the behaviour of the various MUAs around. Right now we know that:
1) Outlook 2000 SP-3 9.0.0.6627 is OK (doesn't check the From header)
2) Outlook Express 6.00.2800.1123 is KO (checks the From header)
I will send shortly to this same thread a probe message with a server side signature
done by my mailet (so you can also see how it looks like). Please send a feedback
about how your other different MUAs (Netscape, Eudora, Lotus Notes etc.) behave: is
the message reported as being OK as for integrity, trust and everything else or not?
Thanks,
Vincenzo
> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: domenica 24 agosto 2003 5.58
> To: James-Dev Mailing List
> Subject: RE: From email address validation
>
>
> Guys,
>
> With respect to verifying that the sender is really the sender, there are
> two basic means. One is a digital signature, the other is MAIL
> FROM AUTH=,
> which is part of SMTP AUTH. In something of an ironic coincidence, I just
> heard back from Bill Shannon regarding JavaMail support for MAIL
> FROM AUTH=,
> and will CC the mailing list on my response.
>
> MAIL FROM AUTH= is used to pass on the identity of the
> authenticated sender
> in a chain of authenticated trust. Unfortunately, not only does JavaMail
> not support this now, but we have missed the window to get it
> into J2EE 1.4.
> We can try fixing this on our end by extending the MimeMessage
> and replacing
> the SMTP transport. The other caveat is that it requires an
> unbroken chain
> of authentication, so it has limited applicability on the
> Internet at large.
>
> Vincenzo has proposed that if SMTP AUTH is used the server could use a
> "server" certificate to sign the message, verifying that the
> server believes
> the sender to be authentic:
>
> > if (i) SMTPAuth is on, and (ii) the "From" user is the same as the
> > SMTPAuth-enticated user, a "Sign" mailet could sign the message
> > using a single common "server" certificate, certifying that the
> > sender email address was not forged.
>
> One of the checks performed on digitally signed e-mail is that the sender
> address be one of the authorized addresses within the public certificate.
> So it seems to me that in order to properly use a "server signed"
> certificate approach, we need to have the signing mailet set the RFC 2822
> Sender: header to the address for the server certificate. So what I might
> get would be e-mail from Vincenzo, but sent (and signed) by
> [EMAIL PROTECTED]
>
> The RFC 2822 headers would then include:
>
> Sender: <[EMAIL PROTECTED]>
> From: <[EMAIL PROTECTED]>
>
> Neither of which should be confused with the reverse-path provided to MAIL
> FROM.
>
> This seems roughly right from my quick reading of the RFCs. RFC 2633,
> section 3.1 says "A MIME entity that is the whole message
> includes only the
> MIME headers and MIME body, and does not include the RFC-822 headers." A
> practical suggestion within the WG was that as a way to protect
> the headers
> "the full 822 messsage is wrapped and protected in S/MIME. Then, outer
> headers for the S/MIME message are added that suffice for message
> delivery."
> This may be why most products of this nature are paired; at each
> end of the
> transfer are agents that employ S/MIME encoding, hiding it from an MUA.
>
> One benefit of doing this should be that we not only provide the server's
> warrant of trust in the sender's indentity, but can also certify that the
> message content has not changed since it left the server.
>
> But I haven't gone too deep into the details. S/MIME is pretty involved.
> If we're going add S/MIME support to James, I suggest that we get in touch
> with http://www.bouncycastle.org/, and ask them to help out.
> They have both
> code we can use (perfectly compatible license) and expertise in
> the domain.
>
> --- Noel
>
> ref: S/MIME Working Group
> http://www.ietf.org/html.charters/smime-charter.html
> RFC 2633 (S/MIME v3) http://www.ietf.org/rfc/rfc2633.txt
> Interet Mail Consortium on S/MIME:
> http://www.imc.org/smime-pgpmime.html
> RSA S/MIME FAQ: http://www.rsasecurity.com/standards/smime/faq.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
