> -----Original Message-----
> From: Sam Varshavchik
> Sent: Tuesday, June 21, 2005 12:11 PM
> >>So, until modern technology advances to such a point, the
> >>only logical
> >>thing to do is attempt to deliver E-mail repeatedly, and follow the
> >>preferred logic for making each delivery attempt: pick a
> >>primary MX at
> >>random, if you can't connect it to it, pick a secondary MX
> >>at random, and so on.
> > I have to admit I am starting to come around to understanding
> > Rodrigo's viewpoint on this, however. What is the *downside* of
> > having Courier retry a different (same-priority if exists, or next
> > lowest, as usual) MX rather than the same
> >*potentially*-broken one, after the usual interval?
> If there are multiple primary MXs set, Courier should already
> pick one at random with each delivery attempt.
And, contrary to the implication, it would be a BAD idea to include logic
that selects lower priority ("secondary") MXs for the subsequent attempts
unless (all) the higher priority ones cannot be contacted.
Why?
Well, how do you know that the _list_ of MXs hasn't been changed between
attempts? And if it has, presumably the recipient had a reason for so
doing.
Multiple MXs with priorities are largely an artifact of unreliable
multi-path networks (i.e. dial-ups). In this day and age, the chances of
usefully using secondary MXs seems to me to be slight, except in a few
specialized cases.
Malc.
-------------------------------------------------------
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
