Scott Morizot wrote:
On 24 Jun 2005 at 8:30, Rodrigo Severo wrote:
As far as I can understand this would result in much less than
reasonable load balancing for MX records.
I still couldn't get a comment from Sam on this matter but I really
think that Courier's current strategy for MX choosing isn't very
reasonable as it relies on the randomness of the list provided by bind.
It's fast but rather uneffective.
I don't usually comment, but since this is continuing, I guess I will.
First I'll state the obvious. If you have something specific in mind you
want the software to do to meet some particular personal itch, then feel
free to modify your implementation so it does it.
I believe you haven't understood my "personal itch", as you called it: I
want Courier to deal the best way it reasonable can in face of temporary
delivery failures when there are more than one top priority MX available.
This can be seen as a "personal itch" but I really don't think it to
would be a good description of my goals at all.
With that said, I can't
begin to imagine why, as the administrator of a system *sending* email,
it's my responsibility to provide load balancing services to the
recipients.
I bet you haven't followed the discussion from the begining. As a quick
resume, the load-balancing talk entered the discussion as a side-effect
of the information Sam provided that Courier relies on the random order
DNS answers are usually seem as having as the mechanism that makes
Courier try different MXs with same priority at all.
Let me explain this again with other words: if DNS answers aren't in a
reasonable random internal order Courier might even not try different
top MXs after certain temporary delivery errors but instead it will get
stuck trying to deliver the message to the same MX over and over again.
Anyway, I want my MTA to implement the appropriate email standards and
handle message routing. I do *not* want it to also be a load balancer or
any other completely different type of software or device. If I also want
something in a different category, I'll set it up or acquire it.
Up to here we agree completely.
Sam's
approach certainly strikes me as the correct one and the one I desire.
After a lot of time spent on this matter I tell you that I firmly
believe there is room for important and probably simple improvements in
Courier on the matter of MX choosing strategies.
The
MTA should ask the resolver for MX records. In the absence of MX records,
use any A records. Use the first record the resolver returns.Everything
else is the concern of a different type of software.
If there are more than one top priority MX I don't think that most of
the times choosing the same one is a good decision, and let me assure
you, this is what the current implementation of Courier is doing. When
everything is working fine, everything is working fine. When we get some
kind of temporary delivery error with the first top priority MX messages
get stucked in the queue, sometimes never trying some other top priority
MX available at all and sometimes trying other top priority MX only
after a disproportional amount of retries to the same first top priority MX.
Let's see this example:
10 brsmtp02.br.abnamro.com
10 brsmtp04.br.abnamro.com
15 naxpf001.abnamro.com
15 naxpf002.abnamro.com
15 naxpf003.abnamro.com
15 naxpf011.abnamro.com
15 naxpf012.abnamro.com
15 naxpf013.abnamro.com
30 plum03ap.abnamro.com
30 walnut001ap.abnamro.com
In this case brsmtp02.br.abnamro.com has 9 out of 10 chances of being
contacted and brsmtp04.br.abnamro.com have the remaining 1 out of 10
chances. If we are using bind as DNS cache. As far as I can tell other
DNS caches would induce even worstly distributed chances. The reason DNS
cache choice is mentioned here will be explained below, please keep reading.
The requirement in the standard is that all MX records
of the lowest priority be tried before giving up (and preferably all MX
records are tried, though the standard doesn't actually mandate that).
I agree with you. And let me assure you that Courier is doing exactly
this in case it gets no connection whatsoever to some top priority MX:
it tries to contact the next top priority MX. Fine.
The problem I am trying to solve is that in case of a temporary delivery
failure, Courier keeps trying to contact the same top priority MX over
and over again. I believe that in such a situation, it should try to
contact other top priority MX also. It is this simple.
The DNS talk got in the conversation because Sam explained to me that he
believes this is Courier behaviour. He also explained that to get this
behaviour he relies on the randomness of the answers DNS servers and by
extension, DNS caches provide. He also explained to me that he believes
that bind provides such random answers. I found out that he is
unfortunatelly wrong about bind answers. Bind uses a method to produce
randomness for it's answers (random-cyclic as they call it) that simply
don't provide the intented behaviour for Courier.
It
is not a requirement that the MTA attempt to 'randomize' MX records if
presented with multiple MX records of the same priority. And I would
categorize that as undesirable extraneous behavior in my MTA.
I agree with you again. I am not claiming that Courier should randomize
MX records per si. I am claiming that Courier should try other top
priority MXs in case of temporary delivery failure while talking to the
first top priority MX. MX records randomization is just a suggestion on
how to get the intended behaviour. I have no special preference for this
particular implementation. Please feel free to suggest another one.
I would like to thank you for your comments and observations,
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
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
