bshannon
commented
5 years ago We could probably do better, but there's a limit to what we can do since JavaMail is largely at the mercy of the JDK and which exceptions it throws for different SSL errors. Since the JDK hasn't standardized exceptions for all the different cases, I don't want to try to interpret the JDK exceptions and turn them into JavaMail exceptions. Many of the details of what went wrong at the SSL/TLS level are going to need to defer to the JDK exceptions.
But there are definitely cases where JavaMail knows, at a high level, what went wrong, and those could probably be reflected in more specific JavaMail exceptions. I would probably try to do this as an implementation-specific feature before proposing new standard exception classes.
dincciftci
Is your feature request related to a problem? Please describe. JavaMail can be used to create an encrypted connection to IMAP and SMTP servers using STARTTLS.
There are various errors that can be encountered when such a connection is attempted, based on the properties passed in when creating a
javax.mail.Sessionobject and the configuration of the email server that is being connected to. For example, the mail transport can be configured to require STARTTLS, such that the connection attempt (using an implementation of Session::connect, such asSMTPTransport::connect) will fail if the server being talked to does not support TLS.Currently, the API for the various overloaded
connectmethods defines two main errors:Based on the
connectmethods' current contracts, it is not possible for us to programmatically determine the root causes of many of the errors related to TLS. Based on the exception thrown by JavaMail, we can make an educated guess-- but this guess is not based on a contract in the interface, and can easily break through future changes in the relevant codepath in JavaMail.We would like a contract in the interface (e.g.
TLSUnavailableExceptionis thrown when the server doesn't support TLS) because this will let the consumers of JavaMail triage errors more accurately in a programmatic way. For our software, this will translate to user-visible errors in the part of the product that uses JavaMail.For background, our software lets the user configure some of the TLS-related parameters when the user wants our software to talk to an SMTP server. It is important to communicate errors back to the user when the error is actionable for them e.g. when they have whitelisted a single cipher for use with TLS, but the server they are talking to does not support it.
Right now, we can programmatically look for a
javax.mail.MessagingExceptionwhose first-level nested exception is ajavax.net.ssl.SSLHandshakeExceptionwhose exception message mentions the phrasecipher suitesin order to determine that this is the problem. This approach is more of a heuristic based on the current behavior of JavaMail and can break in the future, because it's not part of the interface definition.Ideally, the
connectmethod would define an Exception type in its interface that is guaranteed to be thrown in this scenario.Describe the solution you'd like The various Session::connect method overloads should define specific Exception types that they will throw when encountering specific TLS-related problems. A shortlist of scenarios that should be considered:
ssl.checkserveridentitysetting)ssl.ciphersuitessetting)ssl.protocolssetting)Describe alternatives you've considered Documenting the current behavior when such errors are encountered, adding automated tests for them in JavaMail them to ensure the behavior doesn't change, and capturing the behavior in the documentation.
Additional context Example stack traces from specific scenarios: TLS is required, but the mail server does not support it:
The certificate presented by the mail server can not be trusted:
The mail server fails identity check:
The client and the server don't have any supported TLS versions in common:
The client and the server don't have any supported ciphersuites in common: