You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not sure if this is an Issue, but I was having a problem with a mail relay that was receiving a STARTTLS instruction and failing as a result, as follows:
DEBUG: setDebug: Jakarta Mail version 1.6.5
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Oracle]
DEBUG SMTP: useEhlo true, useAuth false
DEBUG SMTP: trying to connect to host "smtp.myisp.com", port 25, isSSL false
220 pure ESMTP joy (smtp02)
DEBUG SMTP: connected to host "smtp.myisp.com", port: 25
EHLO mydomain
250-smtp.myisp.com Hello mydomain [169.n.nn.nnn]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-CHUNKING
250-STARTTLS
250 HELP
DEBUG SMTP: Found extension "SIZE", arg "52428800"
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "PIPELINING", arg ""
DEBUG SMTP: Found extension "CHUNKING", arg ""
DEBUG SMTP: Found extension "STARTTLS", arg ""
DEBUG SMTP: Found extension "HELP", arg ""
DEBUG SMTP: use8bit false
STARTTLS
454 TLS currently unavailable
I thought that setting TransportStrategy.SMTP would be sufficient to avoid TLS, but in the end, I also had to set the "mail.smtp.starttls.enable" to "false" to get the email sent:
This can happen with very old (and insecure!) mail servers that not only don't support TLS, but also don't understand the attempt to upgrade the connection to TLS (as it is optional for TransportStrategy.SMTP). These servers would only support unencrypted or the very outdated SSL connections, which you can achieve by forcing to not even try to upgrade the connection, which is what that property you mention is for, "mail.smtp.starttls.enable".
It is by design (see #105) to have the connections fail for legacy server that don't support this, so that you as a user have to explicitly indicate that you don't want or need this security. This is in fact documented in the Javadoc entry for TransportStrategy.SMTP:
/** * (..) * <p> * Implementation notes: * <ul> * (..) * <li>STARTTLS is enabled by setting "mail.smtp.starttls.enable" to true.</li> * <li>STARTTLS plaintext fallback is enabled by setting "mail.smtp.starttls.required" to false.</li> * </ul> */
And its public method setOpportunisticTLS:
/** * Determines whether TLS should be attempted for SMTP plain protocol (optional if offered by the SMTP server). If not set and no property was provided, this value defaults to true. * <p> * Setting this flag to false causes the {@link TransportStrategy#SMTP} to revert back to the legacy behavior. * <p> * Setting <code>null</code> will revert to property value if available in config or default to true */
So rather than setting the property manually, you can use TransportStrategy.SMTP.setOpportunisticTLS(false).
It does also have a clarification in the website documentation, here.
However, I agree it is easy to be missed. If you have suggestions to improve this I'm all ears!
Hi there
I am not sure if this is an Issue, but I was having a problem with a mail relay that was receiving a STARTTLS instruction and failing as a result, as follows:
I thought that setting TransportStrategy.SMTP would be sufficient to avoid TLS, but in the end, I also had to set the "mail.smtp.starttls.enable" to "false" to get the email sent:
It now works very well, but was I missing something in the documentation or did I hit an issue?
The text was updated successfully, but these errors were encountered: