[
https://issues.apache.org/jira/browse/JAMES-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karsten Otto updated JAMES-3681:
--------------------------------
Description:
When configuring the {{RemoteDelivery}} mailet for SMTPS via {{{}sslEnable{}}},
it ignores any timeouts set via {{timeout}} and {{connectionTimeout}}
parameters, and uses the Java Mail defaults of infinite instead. Thus when
talking to a slow or faulty server, James will never break the SMTPS
connection, slowly exhausting the remote delivery thread pool, stalling and
ultimately halting remote delivery completely.
*Analysis:* James converts its parameters to Java Mail properties
"{{{}mail.smtp.x{}}}" for the remote session. But according to
[https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html],
Java Mail expects these properties to be "{{{}mail.smtp{}}}{{{}{*}s{*}.x{}}}"
instead when using SMTPS.
*Workaround:* Provide timeout (and other) Java Mail properties explicitly in
the mailet configuration, e.g.
{code:java}
<mailet match="All" class="RemoteDelivery">
<sslEnable>true</sslEnable>
...
<mail.smtps.timeout>180000</mail.smtps.timeout>
<mail.smtp.connectiontimeout>60000</mail.smtp.connectiontimeout>
</mailet> {code}
was:
When configuring the {{RemoteDelivery}} mailet for SMTPS via {{{}sslEnable{}}},
it ignores any timeouts set via {{timeout}} and {{connectionTimeout}}
parameters, and uses the Java Mail defaults of infinite instead. Thus when
talking to a slow or faulty server, James will never break the SMTPS
connection, slowly exhausting the remote delivery thread pool, stalling and
ultimately halting remote delivery completely.
*Analysis:* James converts its parameters to Java Mail properties
"{{{}mail.smtp.*{*}{*}{}}}" for the remote session. But according to
[https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html],
Java Mail expects these properties to be "{{{}mail.smtp{}}}{{{}{*}s{*}.*{}}}"
instead when using SMTPS.
*Workaround:* Provide timeout (and other) Java Mail properties explicitly in
the mailet configuration, e.g.
{code:java}
<mailet match="All" class="RemoteDelivery">
<sslEnable>true</sslEnable>
...
<mail.smtps.timeout>180000</mail.smtps.timeout>
<mail.smtp.connectiontimeout>60000</mail.smtp.connectiontimeout>
</mailet> {code}
> RemoteDelivery mailet ignores timeout parameters for SMTPS
> ----------------------------------------------------------
>
> Key: JAMES-3681
> URL: https://issues.apache.org/jira/browse/JAMES-3681
> Project: James Server
> Issue Type: Bug
> Components: Remote Delivery
> Affects Versions: master
> Reporter: Karsten Otto
> Priority: Major
>
> When configuring the {{RemoteDelivery}} mailet for SMTPS via
> {{{}sslEnable{}}}, it ignores any timeouts set via {{timeout}} and
> {{connectionTimeout}} parameters, and uses the Java Mail defaults of infinite
> instead. Thus when talking to a slow or faulty server, James will never break
> the SMTPS connection, slowly exhausting the remote delivery thread pool,
> stalling and ultimately halting remote delivery completely.
> *Analysis:* James converts its parameters to Java Mail properties
> "{{{}mail.smtp.x{}}}" for the remote session. But according to
> [https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html],
> Java Mail expects these properties to be
> "{{{}mail.smtp{}}}{{{}{*}s{*}.x{}}}" instead when using SMTPS.
> *Workaround:* Provide timeout (and other) Java Mail properties explicitly in
> the mailet configuration, e.g.
> {code:java}
> <mailet match="All" class="RemoteDelivery">
> <sslEnable>true</sslEnable>
> ...
> <mail.smtps.timeout>180000</mail.smtps.timeout>
> <mail.smtp.connectiontimeout>60000</mail.smtp.connectiontimeout>
> </mailet> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
