Alessandro Vesely wrote:
Rodrigo Severo wrote:
b) try to detect the specific situation when this problem occurs with
simple non-obstrusive code and use a more convoluted strategy to choose
MXs only then;
That apparently implies saving host status information.
Storing host status only when the MTA detects a problem makes sense.
Additionally, it can be further restricted to the case when the target
MX is not the only one with its weight. To reduce the amount of new
problems introduced by the new strategy, the host status can be deleted
when the set of MXes changes, when the target MX changes address, when
a timeout expires, and similar euristic criteria. In such environment,
connection timeout failures can be distributed evenly among sibling MXes.
Is that the kind of solution we're talking about?
Possibly, but there are others.
I think the solution you mentioned can provide the most robust MX
choosing strategy we can hope for. But it strikes me as demanding a lot
of work to implement and requiring us to take a lot of decisions during
implementation that could leave us at bad places in case of mistakes. In
other words, the best solution if well done but particulary difficult to
do well.
He is an idea of mine in pseudocode:
-----------------------------------------------------------------
if (number of MXs in MXList > 1)
{
create NewMXList from MXList
(NewMXList will get only the top priority MXs from MXList)
if (number of MXs in NewMXList > 1)
{
randomize(NewMXList)
}
MXList = NewMXList
}
-----------------------------------------------------------------
This code could be included right after mxlist creation inside the
sendesmtp function. Even before the check for broken MX records, if I am
not mistaken.
I think such a solution would give us results almost as good as the ones
we get from the solution you mentioned and it's certainly much easier to
be done right.
This solution also has a few side-effects than seem good to me. I am not
sure they are really all good so I list the ones I am aware of here so
others can think about.
1. Frees Courier from the current bind dependency in terms of DNS cache
used (we bring the responsability of MX randomization to Courier and we
guarantee that this randomization is done in a proper way for Courier
needs).
2. Provides some load-balancing for destination domains (top priority
MXs will be accessed in a more random way than the current one).
3. Reduces the number of domains Courier will refuse to deliver messages
to because of RFC 1035 violations (only top priority MXs will be RFC
1035 checked). I think this is ok as we are only interested in the top
priority MXs anyway.
Well, there is obviously a third and much more concrete option: the one
Sam effectively provided in Courier 20050626. My first impression after
a quick look at it is that this solution is uneffective but I can't
elaborate more on it now as I need more time to better understand it and
it's implications.
Thanks for your kind words and considerations,
Rodrigo Severo
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
