Scott Morizot wrote:
On 24 Jun 2005 at 12:48, Rodrigo Severo wrote:
I agree completely. It isn't bind randomness strategy per si that
creates the distortion. Nor is Courier's MX choosing strategy either.
It's the *interaction* of bind randomness strategy and Courier MX
choosing strategy that produces the distortion.
Which reinforces my point, I think. If the administrator of the mail
servers behind the MX records wants to ensure that all of their same
priority MX'ed mail systems are attempted, they should put together their
MX lists appropriately.
As far as I understand Sam expected that DNS caches (specially bind)
would return randomized lists of MXs servers as a way to guarantee that,
in case of temporary delivery failures, Courier would try others top
priority MXs. Unfortunatelly, bind randomizes it's answers in a way that
the goal of Courier trying other top priority MXs in a near equally
distributed fashion isn't accomplished.
Personally, I wouldn't mix a lot of same *and*
different priority MX records in the MX list. I would either use all the
same priority or establish different priorities to create essentially a
backup system and overload the A record for the first MX'ed system. I've
done both and been satisfied with the results.
I might agree with you that this might be the best way to setup one's
domain MX records. I haven't really thought about it much. But the point
here is that Courier have to deal with domains that eventually have a
mix of a lot of same *and* different priority MX records in the MX list.
There aren't much options on this point. It might be good to Courier be
able to deal with it better than it's doing right now.
BTW let me say that you have just clarified to me an important detail of
this issue. It will only happen if and only if there are a mix of a lot
of same *and* different priority MX records in the MX list. This makes
it an issue in fewer cases than I previously saw.
But the more you describe the issue, the less it looks like something that
should be resolved at the point of the sending system.
About the question *where* it should be solved, I really think the right
answer is in Courier's side. It's Courier that's expecting answers in a
way that no current DNS cache that I am aware of provide.
There is also the question *if* it should be solved. Remembering that
this issue affects a smaller set of setups than I previously imagined
I'm wondering if it might be better to:
a) not to deal with it at all because there might be so few cases that
there is no reason to bother (I not sure this is a good line of thinking
but a possible one for sure) or
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;
instead of changing the way Courier chooses MXs for every situation as
it's current implementation is quite appropriate most of the times.
Regards,
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
