Re: [courier-users] MX randomizing: trying to understand thesources.

On 24 Jun 2005 at 10:42, Rodrigo Severo wrote:
> 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.

You're right. I didn't 'tune in' until DNS entered the discussion. I
watched the thread for a while, but didn't go back to read earlier
messages.

> 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.

> 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.

Thanks for reiterating the issue for lazy readers like me.

I can see the problem. On the other hand, a list of MX records of the same
priority actually advertises that you don't care which one the sender
chooses. It's all the same to you. Implicit in that statement is the
promise that they will all act the same if they respond at all. If one of
them is broken and providing a different response than the others, the
presumption is that it's the responsibility of the receiving admin to
remove it from the list of available systems. What you're proposing really
seems to me like a subtle alteration in the meaning of an MX record. It's
not truly, 'Pick any of these of the same priority. I don't care.' It
becomes, 'I want attempts distributed among them all so an error on one
(that leaves it responsive, but returning a temporary error) doesn't stop
mail delivery.' A broken system is a broken system and needs to be taken
offline until fixed. What if it broke and was returning a permanent error?
Then retries wouldn't even enter the picture.

So even though I understand the issue being raised now, I still don't
really agree it's appropriate to attach more meaning to an MX record. If
Sam comes up with a slick, cool way to randomize an MX list without
impacting performance at all I don't have any strong objection. But I do
see it attaching more meaning to the MX record. Now you do care which one
you pick. Caring that it's random or that it is tries them all (other than
when one or more is unresponsive) is still caring.

Scott



-------------------------------------------------------
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/.../courier-users