[
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 STARTTLS)
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&[EMAIL
PROTECTED]&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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
