You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Vincenzo Gianferrari Pini <vi...@praxis.it> on 2003/09/25 18:04:22 UTC
RE: From email address validation
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" <tr...@xxx.yyy>
to certify that the sender truly has the following address (reverse-path):
aaa.bbb@xxx.yyy
and that the message has the following message headers:
Subject: ...........
From: "..........." <aa...@xxx.yyy>
To: "'..........." <cc...@www.zzz>
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" <tr...@xxx.yyy>
-----------------------------------------------------------------------------------------
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 (trusted-server@xxx.yyy 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: trusted-server@xxx.yyy
Sender: aaa.bbb@xxx.yyy
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:noel@devtech.com]
> 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
> trusted-sender@praxis.it.
>
> The RFC 2822 headers would then include:
>
> Sender: <tr...@praxis.it>
> From: <vi...@praxis.it>
>
> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: From email address validation
Posted by Serge Knystautas <se...@lokitech.com>.
> This is the server signed message probe. Have a look on this message (the smime signature icon, the Signature.txt attachment etc.) and please report. Obviously, as I imagine that the replies will not come back at the speed of light, each one of us may see if somebody else has already replied a feedback related to a particular MUA product/version, in order to avoid jamming this list with duplicated reports.
>
> Next week I will summarize the results in this list.
Mozilla Thunderbird sees this as a valid signature.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: From email address validation
Posted by Matthew Pangaro <ma...@lokitech.com>.
On Thu, 25 Sep 2003 18:23:22 +0200
>This is the server signed message probe. Have a look on this message
>(the smime signature icon, the Signature.txt attachment etc.) and
>please report. Obviously, as I imagine that the replies will not come
>back at the speed of light, each one of us may see if somebody else
>has already replied a feedback related to a particular MUA
>product/version, in order to avoid jamming this list with duplicated
>reports.
Webmail from CommunigatePro 4.1.3 sees it as properly signed.
--
Matt Pangaro
Lokitech >> software . strategy . design
http://www.lokitech.com
p. 1.301.656.5501
m. 1.301.728.6906
e. mattp@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: From email address validation
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
> 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?
>
This is the server signed message probe. Have a look on this message (the smime signature icon, the Signature.txt attachment etc.) and please report. Obviously, as I imagine that the replies will not come back at the speed of light, each one of us may see if somebody else has already replied a feedback related to a particular MUA product/version, in order to avoid jamming this list with duplicated reports.
Next week I will summarize the results in this list.
Thanks,
Vincenzo