james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf Hauser (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (JAMES-304) secure remote delivery opportunistically or even allow make TLS mandatory
Date Sun, 07 Aug 2005 21:08:37 GMT
    [ http://issues.apache.org/jira/browse/JAMES-304?page=comments#action_12317933 ] 

Ralf Hauser commented on JAMES-304:

Re 1) I downloaded the 1.3.2. source and in com.sun.mail.smtp.SMTPTransport.SMTPTransport

     * Constructor used by this class and by SMTPSSLTransport subclass.
    protected SMTPTransport(Session session, URLName urlname,
				String name, int defaultPort, boolean isSSL) {

you see it.

"Backward compatible": Yes and no: Since STARTTLS wasn't supported beforehand, I don't think
there was any support for this session property before. On the other hand, I don't think spurious
extra session properties would cause any harm.

1b) Right, I guess you don't need to consider 465 on a server-to-server basis.

2) The german research only points out the frequency of self-signed certificates, i.e. that
a majority of sites do not expend the effort/money necessary to obtain a certificate issued
by a CA that you for example would find in the sun cacerts file.
The text-book approach is to manually analyze the quality of such certificates, import them
into cacerts and restart james - not really feasible by the multitude of domains the users
of your James eventually might send mail to, thus most probably leading to DoS situations.
Just accepting certificates without ever considering their issuing authority will always work
and not have that DoS issue, but from a security point of view is not entirely satisfactory
either since an active man-in-the-middle could assume a proxy role.
How I would like it to work.
a) Allow to configure whether
  i) all self-signed certificates should be accepted (still better than always ignore the
  ii) status quo - only good certificates should be allowed and otherwise mail should be bounced
(this is very strict and probably not practical, but some people might rather have no service
than no security)
      Most MTAs today in this case fall back into no confidentialty at all, but in this case
I prefer option i)
  iii) one could add various additional options such as allow self-signed certifcates for
servers of certain ip-ranges, white-/black-list domains, ... but I guess this is for later
b) Implementation of i) probably requires writing an own Trust-Manager that doesn't do a full
PKIX cert-path. In order to get this trust manager used, you'll probably create your own socket-factory
and configure that via the "mail.socketFactory.class" System property (hopefully soon thread-safe
as a Session property as per http://archives.java.sun.com/cgi-bin/wa?A2=ind0506&L=javamail-interest&F=&S=&X=2E4B33519680236197&Y=ralfhauser@gmx.ch&P=1481)
 set to other than the "javax.net.ssl.SSLSocketFactory" class.

> secure remote delivery opportunistically or even allow make TLS mandatory
> -------------------------------------------------------------------------
>          Key: JAMES-304
>          URL: http://issues.apache.org/jira/browse/JAMES-304
>      Project: James
>         Type: Improvement
>   Components: Remote Delivery
>     Versions: 2.1.3
>  Environment: all - I use RH Linux 9
>     Reporter: Ralf Hauser
>      Fix For: 2.2.1

> It would be great to have james at least opportunistically attempt to secure its user's
outgoing mails with STARTTLS.
> How would one do this?
> 1) first a delivery-host must be found that can do this:
>    --> see http://tlstest.sf.net
>    The ch/zhwin/tlstest/TLSTestAPI.java.canDomainTLS() can do this (in v1.2)
> 2) The real delivery still needs to be secured - unfortunately, so far, I only see a
broken idea how to do this in http://www.portaljava.com/home/modules.php?name=Forums&file=viewtopic&p=20492
> anybody with better ideas (especially since there, they mess a lot with system-wide properties,
so I am afraid that afterwards, the secure pop and smtp to MUA will no longer work)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message