Re: remote load management, was orbs.org nonsense
If, however, you admit that it causes problems for sendmail installations, and you admit that a lot of sites use sendmail, then you'll probably agree that defining "good netizen" would include "limiting outgoing connections to a particular MX" ... to some reasonable number (heck, you can detect what the foreign MTA is when you connect usually ... ) I've been thinking for quite a while of some sort of hack to qmail to do remote load management, the idea being that we want to open almost but not quite enough connections to each remote system to make the remote fall over. Possibilities for guessing the appropriate limit per remote might include: - sniff the SMTP banner for known lame MTAs - measure the round trip time, for the response to HELO, stop connecting when it becomes "too much", either an absolute limit or N times more than it used to be - pay more attention to "421 come back later" type messages -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869 [EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
Re: remote load management, was orbs.org nonsense
For your #1: this would be similar to the Linux kernel approach to DMA on hard
drives ... enable by default, except on those drives we have in database of broken
drives.
As for #2 and #3: this adds overhead, of course, but could inherently reduce
overhead down the road, as long as the algorithm is simple. Something like a
simple:
(pseudo:)
if (hosts[current].connections hosts[current].max_connections)
{
/* ... open connection ...
... read response ...
... record response latency as current_latency ... */
if (response_val == 421
|| current_latency best_latency * (1 + latency_percentage))
{
hosts[current].max_connections = hosts[current].connections;
/* could be connections -1 but this will keep trying to up the # */
} else {
best_latency = min(best_latency, current_latency);
/* ... do delivery ... */
}
}
I hope this satisfies someone ... :-P
"John R. Levine" wrote:
I've been thinking for quite a while of some sort of hack to qmail to
do remote load management, the idea being that we want to open almost
but not quite enough connections to each remote system to make the
remote fall over.
Possibilities for guessing the appropriate limit per remote might include:
- sniff the SMTP banner for known lame MTAs
- measure the round trip time, for the response to HELO, stop connecting
when it becomes "too much", either an absolute limit or N times more than
it used to be
- pay more attention to "421 come back later" type messages
