You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Amichai Rothman (JIRA)" <se...@james.apache.org> on 2007/03/13 17:33:09 UTC
[jira] Created: (JAMES-777) Race condition and randomness in
configured hello name
Race condition and randomness in configured hello name
------------------------------------------------------
Key: JAMES-777
URL: https://issues.apache.org/jira/browse/JAMES-777
Project: James
Issue Type: Bug
Components: James Core, Remote Delivery, SMTPServer
Affects Versions: 2.3.0
Reporter: Amichai Rothman
The RemoteDelivery mailet suffers from a race condition in determining the helo name to use in its SMTP sessions. If the SMTPServer happens to be fully initialized before RemoteDelivery is initialized, the helo name, which is set by the SMTPServer's initialization code as a mailet context attribute, is used correctly.
However this is not guaranteed by the code, as a race condition can cause this attribute to be accessed by RemoteDelivery before SMTPServer initialized it. In this case, the default domain attribute is used instead. This attribute, in turn, is set randomly to whatever happens to be the first element of the iterator on the server names set. This is a HashSet so the iterator order is not well defined, and effectively this chooses a random entry in the servernames (plus IP addresses if autodetectIP is set to true in the configuration).
To sum it up, the helo name used by RemoteDelivery is randomly selected as either the configured SMTP helo name, any of the configured servernames, or any of their IP addresses.
note: the "TODO: CHANGE ME!!!" comment in RemoteDelivery.java appears to have predicted part of this problem (though the randomness of the default domain attribute may have consequences elsewhere).
While this by itself may not sound too critical, it unfortunately can cause a DNS mismatch between the helo name (or address) and the actual server lookup, which many spam mechanisms consider enough for the server to be put it on a very popular spam blacklist, resulting in denial of service (spam-filter-wise) of the entire mail server.
recommendation:
1. fix the default domain randomness (for example, taking the first form the server names list, in the order they appear in configuration, would give a consistent and backward compatible solution. The effects of the default domain attribute should be documented as well.
2. If possible, make a proper wait/notify mechanism for RemoteDelivery to start only when SMTPServer is fully initialized.
3. Otherwise, skip the race condition and/or heuristics and just give RemoteDelivery it's own explicit helo name configuration parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-777) Race condition and randomness in
configured hello name
Posted by "Amichai Rothman (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482677 ]
Amichai Rothman commented on JAMES-777:
---------------------------------------
#1 and #2 imply that it is necessary to make this a separate, independent, configuration option. Anything else will either be bad design (introducing dependency where it shouldn't be), or an ugly workaround (#1) which cannot guarantee the server functioning properly, and so is pointless. Having a server *usually* working well is the mark of an unstable product, and should be avoided altogether.
So we're left with #3, which is indeed an independent configuration option which should properly solve the problem. Will this configuration currently override the other two (I didn't see this in the code)?
> Race condition and randomness in configured hello name
> ------------------------------------------------------
>
> Key: JAMES-777
> URL: https://issues.apache.org/jira/browse/JAMES-777
> Project: James
> Issue Type: Bug
> Components: James Core, Remote Delivery, SMTPServer
> Affects Versions: 2.3.0
> Reporter: Amichai Rothman
>
> The RemoteDelivery mailet suffers from a race condition in determining the helo name to use in its SMTP sessions. If the SMTPServer happens to be fully initialized before RemoteDelivery is initialized, the helo name, which is set by the SMTPServer's initialization code as a mailet context attribute, is used correctly.
> However this is not guaranteed by the code, as a race condition can cause this attribute to be accessed by RemoteDelivery before SMTPServer initialized it. In this case, the default domain attribute is used instead. This attribute, in turn, is set randomly to whatever happens to be the first element of the iterator on the server names set. This is a HashSet so the iterator order is not well defined, and effectively this chooses a random entry in the servernames (plus IP addresses if autodetectIP is set to true in the configuration).
> To sum it up, the helo name used by RemoteDelivery is randomly selected as either the configured SMTP helo name, any of the configured servernames, or any of their IP addresses.
> note: the "TODO: CHANGE ME!!!" comment in RemoteDelivery.java appears to have predicted part of this problem (though the randomness of the default domain attribute may have consequences elsewhere).
> While this by itself may not sound too critical, it unfortunately can cause a DNS mismatch between the helo name (or address) and the actual server lookup, which many spam mechanisms consider enough for the server to be put it on a very popular spam blacklist, resulting in denial of service (spam-filter-wise) of the entire mail server.
> recommendation:
> 1. fix the default domain randomness (for example, taking the first form the server names list, in the order they appear in configuration, would give a consistent and backward compatible solution. The effects of the default domain attribute should be documented as well.
> 2. If possible, make a proper wait/notify mechanism for RemoteDelivery to start only when SMTPServer is fully initialized.
> 3. Otherwise, skip the race condition and/or heuristics and just give RemoteDelivery it's own explicit helo name configuration parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-777) Race condition and randomness in
configured hello name
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482718 ]
Stefano Bagnara commented on JAMES-777:
---------------------------------------
The code is the following:
------------------
Iterator i = getInitParameterNames();
while (i.hasNext()) {
String name = (String) i.next();
if (name.startsWith("mail.")) {
defprops.put(name,getInitParameter(name));
}
}
-------------------
When the thread is ran it initialize with the HELLO_NAME but *then* it calls a:
------------------
props.putAll(defprops);
-------------------
wehere props is a properties so the defprops keys will replace the HELLO_NAME.
> Race condition and randomness in configured hello name
> ------------------------------------------------------
>
> Key: JAMES-777
> URL: https://issues.apache.org/jira/browse/JAMES-777
> Project: James
> Issue Type: Bug
> Components: James Core, Remote Delivery, SMTPServer
> Affects Versions: 2.3.0
> Reporter: Amichai Rothman
>
> The RemoteDelivery mailet suffers from a race condition in determining the helo name to use in its SMTP sessions. If the SMTPServer happens to be fully initialized before RemoteDelivery is initialized, the helo name, which is set by the SMTPServer's initialization code as a mailet context attribute, is used correctly.
> However this is not guaranteed by the code, as a race condition can cause this attribute to be accessed by RemoteDelivery before SMTPServer initialized it. In this case, the default domain attribute is used instead. This attribute, in turn, is set randomly to whatever happens to be the first element of the iterator on the server names set. This is a HashSet so the iterator order is not well defined, and effectively this chooses a random entry in the servernames (plus IP addresses if autodetectIP is set to true in the configuration).
> To sum it up, the helo name used by RemoteDelivery is randomly selected as either the configured SMTP helo name, any of the configured servernames, or any of their IP addresses.
> note: the "TODO: CHANGE ME!!!" comment in RemoteDelivery.java appears to have predicted part of this problem (though the randomness of the default domain attribute may have consequences elsewhere).
> While this by itself may not sound too critical, it unfortunately can cause a DNS mismatch between the helo name (or address) and the actual server lookup, which many spam mechanisms consider enough for the server to be put it on a very popular spam blacklist, resulting in denial of service (spam-filter-wise) of the entire mail server.
> recommendation:
> 1. fix the default domain randomness (for example, taking the first form the server names list, in the order they appear in configuration, would give a consistent and backward compatible solution. The effects of the default domain attribute should be documented as well.
> 2. If possible, make a proper wait/notify mechanism for RemoteDelivery to start only when SMTPServer is fully initialized.
> 3. Otherwise, skip the race condition and/or heuristics and just give RemoteDelivery it's own explicit helo name configuration parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (JAMES-777) Race condition and randomness in
configured hello name
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer resolved JAMES-777.
---------------------------------
Resolution: Duplicate
See JAMES-738
> Race condition and randomness in configured hello name
> ------------------------------------------------------
>
> Key: JAMES-777
> URL: https://issues.apache.org/jira/browse/JAMES-777
> Project: James
> Issue Type: Bug
> Components: James Core, Remote Delivery, SMTPServer
> Affects Versions: 2.3.0
> Reporter: Amichai Rothman
>
> The RemoteDelivery mailet suffers from a race condition in determining the helo name to use in its SMTP sessions. If the SMTPServer happens to be fully initialized before RemoteDelivery is initialized, the helo name, which is set by the SMTPServer's initialization code as a mailet context attribute, is used correctly.
> However this is not guaranteed by the code, as a race condition can cause this attribute to be accessed by RemoteDelivery before SMTPServer initialized it. In this case, the default domain attribute is used instead. This attribute, in turn, is set randomly to whatever happens to be the first element of the iterator on the server names set. This is a HashSet so the iterator order is not well defined, and effectively this chooses a random entry in the servernames (plus IP addresses if autodetectIP is set to true in the configuration).
> To sum it up, the helo name used by RemoteDelivery is randomly selected as either the configured SMTP helo name, any of the configured servernames, or any of their IP addresses.
> note: the "TODO: CHANGE ME!!!" comment in RemoteDelivery.java appears to have predicted part of this problem (though the randomness of the default domain attribute may have consequences elsewhere).
> While this by itself may not sound too critical, it unfortunately can cause a DNS mismatch between the helo name (or address) and the actual server lookup, which many spam mechanisms consider enough for the server to be put it on a very popular spam blacklist, resulting in denial of service (spam-filter-wise) of the entire mail server.
> recommendation:
> 1. fix the default domain randomness (for example, taking the first form the server names list, in the order they appear in configuration, would give a consistent and backward compatible solution. The effects of the default domain attribute should be documented as well.
> 2. If possible, make a proper wait/notify mechanism for RemoteDelivery to start only when SMTPServer is fully initialized.
> 3. Otherwise, skip the race condition and/or heuristics and just give RemoteDelivery it's own explicit helo name configuration parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-777) Race condition and randomness in
configured hello name
Posted by "Amichai Rothman (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487249 ]
Amichai Rothman commented on JAMES-777:
---------------------------------------
Thanks - that should do it. I still think it's confusing to have this many variables involved in a single configuration string... ppl who'll lose the race (condition) will have all sorts of problems, and waste much time investigating them as I have (and apparently others before me), until they find this workaround... much time, frustration and code has been, and will be, wasted by this. A simple well documented heloName parameter in RemoteDelivery could solve all this cleanly. But the working workaround is a good start :-) I'll be waiting for it's release...
> Race condition and randomness in configured hello name
> ------------------------------------------------------
>
> Key: JAMES-777
> URL: https://issues.apache.org/jira/browse/JAMES-777
> Project: James
> Issue Type: Bug
> Components: James Core, Remote Delivery, SMTPServer
> Affects Versions: 2.3.0
> Reporter: Amichai Rothman
>
> The RemoteDelivery mailet suffers from a race condition in determining the helo name to use in its SMTP sessions. If the SMTPServer happens to be fully initialized before RemoteDelivery is initialized, the helo name, which is set by the SMTPServer's initialization code as a mailet context attribute, is used correctly.
> However this is not guaranteed by the code, as a race condition can cause this attribute to be accessed by RemoteDelivery before SMTPServer initialized it. In this case, the default domain attribute is used instead. This attribute, in turn, is set randomly to whatever happens to be the first element of the iterator on the server names set. This is a HashSet so the iterator order is not well defined, and effectively this chooses a random entry in the servernames (plus IP addresses if autodetectIP is set to true in the configuration).
> To sum it up, the helo name used by RemoteDelivery is randomly selected as either the configured SMTP helo name, any of the configured servernames, or any of their IP addresses.
> note: the "TODO: CHANGE ME!!!" comment in RemoteDelivery.java appears to have predicted part of this problem (though the randomness of the default domain attribute may have consequences elsewhere).
> While this by itself may not sound too critical, it unfortunately can cause a DNS mismatch between the helo name (or address) and the actual server lookup, which many spam mechanisms consider enough for the server to be put it on a very popular spam blacklist, resulting in denial of service (spam-filter-wise) of the entire mail server.
> recommendation:
> 1. fix the default domain randomness (for example, taking the first form the server names list, in the order they appear in configuration, would give a consistent and backward compatible solution. The effects of the default domain attribute should be documented as well.
> 2. If possible, make a proper wait/notify mechanism for RemoteDelivery to start only when SMTPServer is fully initialized.
> 3. Otherwise, skip the race condition and/or heuristics and just give RemoteDelivery it's own explicit helo name configuration parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-777) Race condition and randomness in
configured hello name
Posted by "Amichai Rothman (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480492 ]
Amichai Rothman commented on JAMES-777:
---------------------------------------
I'm not very familiar with the code, but the problematic part I got to when researching this issue looks identical in 2.3 src distribution, trunk, and the branch (I hope I looked in the right place).
> Race condition and randomness in configured hello name
> ------------------------------------------------------
>
> Key: JAMES-777
> URL: https://issues.apache.org/jira/browse/JAMES-777
> Project: James
> Issue Type: Bug
> Components: James Core, Remote Delivery, SMTPServer
> Affects Versions: 2.3.0
> Reporter: Amichai Rothman
>
> The RemoteDelivery mailet suffers from a race condition in determining the helo name to use in its SMTP sessions. If the SMTPServer happens to be fully initialized before RemoteDelivery is initialized, the helo name, which is set by the SMTPServer's initialization code as a mailet context attribute, is used correctly.
> However this is not guaranteed by the code, as a race condition can cause this attribute to be accessed by RemoteDelivery before SMTPServer initialized it. In this case, the default domain attribute is used instead. This attribute, in turn, is set randomly to whatever happens to be the first element of the iterator on the server names set. This is a HashSet so the iterator order is not well defined, and effectively this chooses a random entry in the servernames (plus IP addresses if autodetectIP is set to true in the configuration).
> To sum it up, the helo name used by RemoteDelivery is randomly selected as either the configured SMTP helo name, any of the configured servernames, or any of their IP addresses.
> note: the "TODO: CHANGE ME!!!" comment in RemoteDelivery.java appears to have predicted part of this problem (though the randomness of the default domain attribute may have consequences elsewhere).
> While this by itself may not sound too critical, it unfortunately can cause a DNS mismatch between the helo name (or address) and the actual server lookup, which many spam mechanisms consider enough for the server to be put it on a very popular spam blacklist, resulting in denial of service (spam-filter-wise) of the entire mail server.
> recommendation:
> 1. fix the default domain randomness (for example, taking the first form the server names list, in the order they appear in configuration, would give a consistent and backward compatible solution. The effects of the default domain attribute should be documented as well.
> 2. If possible, make a proper wait/notify mechanism for RemoteDelivery to start only when SMTPServer is fully initialized.
> 3. Otherwise, skip the race condition and/or heuristics and just give RemoteDelivery it's own explicit helo name configuration parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-777) Race condition and randomness in
configured hello name
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482053 ]
Stefano Bagnara commented on JAMES-777:
---------------------------------------
#3: in v2.3 branch (prepared for 2.3.1) and in trunk you can add <mail.smtp.localhost>something</mail.smtp.localhost> to your RemoteDelivery configuration.
#2: they are separate components and cannot be synchronized without introducing dependency: dependency is not easily added using our current architecture
#1: there is a loop that wait 1 minute before initializing the RemoteDelivery: this has been added to avoid the racing issue in most cases. Your system must be really busy to not initialize the smtpserver in 1 minute.
> Race condition and randomness in configured hello name
> ------------------------------------------------------
>
> Key: JAMES-777
> URL: https://issues.apache.org/jira/browse/JAMES-777
> Project: James
> Issue Type: Bug
> Components: James Core, Remote Delivery, SMTPServer
> Affects Versions: 2.3.0
> Reporter: Amichai Rothman
>
> The RemoteDelivery mailet suffers from a race condition in determining the helo name to use in its SMTP sessions. If the SMTPServer happens to be fully initialized before RemoteDelivery is initialized, the helo name, which is set by the SMTPServer's initialization code as a mailet context attribute, is used correctly.
> However this is not guaranteed by the code, as a race condition can cause this attribute to be accessed by RemoteDelivery before SMTPServer initialized it. In this case, the default domain attribute is used instead. This attribute, in turn, is set randomly to whatever happens to be the first element of the iterator on the server names set. This is a HashSet so the iterator order is not well defined, and effectively this chooses a random entry in the servernames (plus IP addresses if autodetectIP is set to true in the configuration).
> To sum it up, the helo name used by RemoteDelivery is randomly selected as either the configured SMTP helo name, any of the configured servernames, or any of their IP addresses.
> note: the "TODO: CHANGE ME!!!" comment in RemoteDelivery.java appears to have predicted part of this problem (though the randomness of the default domain attribute may have consequences elsewhere).
> While this by itself may not sound too critical, it unfortunately can cause a DNS mismatch between the helo name (or address) and the actual server lookup, which many spam mechanisms consider enough for the server to be put it on a very popular spam blacklist, resulting in denial of service (spam-filter-wise) of the entire mail server.
> recommendation:
> 1. fix the default domain randomness (for example, taking the first form the server names list, in the order they appear in configuration, would give a consistent and backward compatible solution. The effects of the default domain attribute should be documented as well.
> 2. If possible, make a proper wait/notify mechanism for RemoteDelivery to start only when SMTPServer is fully initialized.
> 3. Otherwise, skip the race condition and/or heuristics and just give RemoteDelivery it's own explicit helo name configuration parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-777) Race condition and randomness in
configured hello name
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480467 ]
Norman Maurer commented on JAMES-777:
-------------------------------------
I think this is allready fixed in 2.3.1 branch and trunk
There is the possiblity to set a smtp prop to set the helo name. The use of the servername should removed in an nonbackward compatible release
> Race condition and randomness in configured hello name
> ------------------------------------------------------
>
> Key: JAMES-777
> URL: https://issues.apache.org/jira/browse/JAMES-777
> Project: James
> Issue Type: Bug
> Components: James Core, Remote Delivery, SMTPServer
> Affects Versions: 2.3.0
> Reporter: Amichai Rothman
>
> The RemoteDelivery mailet suffers from a race condition in determining the helo name to use in its SMTP sessions. If the SMTPServer happens to be fully initialized before RemoteDelivery is initialized, the helo name, which is set by the SMTPServer's initialization code as a mailet context attribute, is used correctly.
> However this is not guaranteed by the code, as a race condition can cause this attribute to be accessed by RemoteDelivery before SMTPServer initialized it. In this case, the default domain attribute is used instead. This attribute, in turn, is set randomly to whatever happens to be the first element of the iterator on the server names set. This is a HashSet so the iterator order is not well defined, and effectively this chooses a random entry in the servernames (plus IP addresses if autodetectIP is set to true in the configuration).
> To sum it up, the helo name used by RemoteDelivery is randomly selected as either the configured SMTP helo name, any of the configured servernames, or any of their IP addresses.
> note: the "TODO: CHANGE ME!!!" comment in RemoteDelivery.java appears to have predicted part of this problem (though the randomness of the default domain attribute may have consequences elsewhere).
> While this by itself may not sound too critical, it unfortunately can cause a DNS mismatch between the helo name (or address) and the actual server lookup, which many spam mechanisms consider enough for the server to be put it on a very popular spam blacklist, resulting in denial of service (spam-filter-wise) of the entire mail server.
> recommendation:
> 1. fix the default domain randomness (for example, taking the first form the server names list, in the order they appear in configuration, would give a consistent and backward compatible solution. The effects of the default domain attribute should be documented as well.
> 2. If possible, make a proper wait/notify mechanism for RemoteDelivery to start only when SMTPServer is fully initialized.
> 3. Otherwise, skip the race condition and/or heuristics and just give RemoteDelivery it's own explicit helo name configuration parameter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org