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]
