[
https://issues.apache.org/jira/browse/EMAIL-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Harbulot updated EMAIL-105:
---------------------------------
Attachment: ssl-starttls.patch
Here is a patch that attempts to fix a few points regarding SSL, TLS and
STARTTLS.
- STARTTLS should be usable, even without an authenticator (EMAIL-106)
- The wording of the documentation of {{setTLS}} was talking about "when TLS is
needed". This can be confusing, especially with the additions to JavaMail 1.4.2
("required"). It's the client that tries to use STARTTLS (the server can be
configured to refuse authentication when it's not used).
- JavaMail 1.4.2 provides a few new parameters, in particular:
-- {{mail.smtp.starttls.required}} in addition to
{{mail.smtp.starttls.enable}}, to make the client disconnect if the server
doesn't support STARTTLS.
-- some new parameters to configure the SSL socket factory (which can be used
both for SSL/TLS on connection or via STARTTLS)
-- {{mail.smtp.ssl.checkserveridentity}} is false by default in JavaMail, but
checking the server identity is necessary to ensure the security of the SSL/TLS
connection (whether on connection or via STARTTLS).
> Clarify names for SSL and TLS
> -----------------------------
>
> Key: EMAIL-105
> URL: https://issues.apache.org/jira/browse/EMAIL-105
> Project: Commons Email
> Issue Type: Improvement
> Reporter: Bruno Harbulot
> Attachments: ssl-starttls.patch
>
>
> The API offers two categories of settings for the configuration of SSL/TLS:
> {{setSSL}} and {{setTLS}} (and respective associated methods).
> The names are quite misleading, as this doesn't really oppose SSL and TLS. A
> number of e-mail applications make this mistake, but "TLS" is used here to
> mean "using STARTTLS" and "SSL" is used here to mean "SSL or TLS, upon
> connection".
> The difference is that:
> - With "SSL" (as incorrectly named here), the SMTP client connects to the
> SMTP server on a dedicated port and starts the SSL/TLS handshake upon
> connection. This is then followed by "normal" SMTP traffic on this SSL/TLS
> layer.
> - With "TLS" (as incorrectly named here), the SMTP client connects to the
> SMTP server on the same port as it would do for plain-text SMTP, exchanges a
> few SMTP commands, including [STARTTLS (RFC
> 3207)|http://tools.ietf.org/html/rfc3207 ], and then starts an SSL/TLS
> handshake to upgrade to a secure channel.
> This is not so much a difference between SSL and TLS, but rather a difference
> regarding when the connection is turned into a secure one.
> The difference between SSLv3 and TLS 1.0 is mostly a version difference,
> where SSLv3 is the predecessor of TLS 1.0.
> You can have an TLS 1.0+ upon connection, using the "SSL" setting, without
> using {{STARTTLS}} (it's a version configuration up to the {{SSLEngine}} or
> {{SSLSocketFactory}}).
> Similarly, although it's not written in the specification, some servers seem
> to accept an SSLv3 handshake (instead of its successor version: TLS 1.0)
> after {{STARTTLS}}.
> I'd suggest deprecating {{setSSL}} and {{setTLS}} and replacing them with
> {{setOnConnectSSL}} and {{setStartTLS}} (or similar), respectively.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
