Malcolm Weir wrote:
-----Original Message-----
From: Rodrigo Severo
Sent: Tuesday, June 21, 2005 1:03 PM
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?
If this is a concern,
It HAS to be a concern!
I am really not sure it HAS to be a concern, but as I said, if it is a
concern there are good ways to accomodate it.
Courier can fetch a new list at every
delivery attempt. Discard the ones it already tried and pick
the remaining top priority one.
This is FAR better than the previously stated version of the idea, where you
wandered off into lower priority ones when higher priority MXs are listed.
Look, although it obviously doesn't suit you, the semantics of the MX
priority scheme only permit you to try a lower priority when *all* the
higher priority ones cannot be reached.
RFC 2821 states otherwise:
"When the (MX) lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because of
multiple MX records, multihoming, or both. To provide reliable mail
transmission, the SMTP client MUST be able to try (and retry) each of
the relevant addresses in this list in order, until a delivery attempt
succeeds."
This is the main recomendation of RFC 2821 on the subject. Latter it
opens doors for other behaviours. The behaviour you are defending is
allowed through some of these doors. Please do not think Courier's
current behaviour is the only one accepatable, the mostly recommended
neither use any kind of authoritative argument like it. It is allowed by
RFC 2821 but it is not the main recomendation.
Courier is complaint to RFC 2821 in this matter. I am just campaigning
to include in Courier the possibility to use a method of message
delivery that is the main recomendation of this same RFC.
Consider this list:
PrimaryA MX 10
PrimaryB MX 10
SecondaryA MX 20
SecondaryB MX 20
Now, suppose you connect to PrimaryA, and time out during the dialog.
We're agreed that you must wait for a retry.
CURRENTLY, Courier randomly picks PrimaryA or PrimaryB on the second
attempt.
You'd like Courier to remember that PrimaryA had timed out, check that the
the list hasn't changed, and connect to PrimaryB.
Now, suppose that Courier did pick PrimaryB (either randomly or by storing
the list of MXs previously tried and reconciling that with the current
list).
If PrimaryB now times out during a dialog,
from what I've seen, you'd like Courier to try SecondaryA or SecondayB,
right?
BUT... It's been at least to wait_for_retry intervals since PrimaryA
exhibited its problem issue, and Courier (and sendmail, Qmail, Postfix,
etc.) cannot presume that the people who run PrimaryA haven't fixed it in
the interim. It's still listed as a highest priority MX, so the MTA is
obliged to try to use it.
By your logic secondary MXs would never be connected at all because if I
try a primary MX and fail I shall wait for my next retry. At this point
I have to retry one of the primaries again as I "cannot presume that the
people who run PrimaryA haven't fixed it in the interim" to use your own
words. Closed loop, no secondary MX get connected at all. Doesn't seems
to me as specially good logic.
I'm really in no position as to speak about the reasons other
sys admins might setup multiple MXs with priorities. The real
fact is that they still do. I'm just trying to make the best
use of it.
No, you're actually trying to modify the meaning of "priority" so it becomes
something more like "order to use".
No, I'm not trying to mess with the english language at all (despite my
erratic domain of the language).
What I'm doing is suggesting an alternative behaviour I latter
discovered is backed-up by RFC 2821. My intentions are much humbler ;)
Well, maybe I'm just a lucky guy but I have to regulary send
messages to two different domains with different
misconfigurations for which such a feature would be very helpfull.
*Shrug*
My recommendation for you would be to create a local "stealth" DNS for those
two domains, and in that flatten their MX priorities so that they're all
primaries. Courier will then randomly pick one on each attempt, and the
chance of Courier retrying the same server will be much reduced.
Of course, this is rather rude behavior, but your problem is caused by
people unwilling to fix their servers, so you're stuck with having to work
around their broken setup.
The problem with your idea is that this way I wouldn't respect MX
priorities, i.e. try the primary MXs first. This is not good.
Rodrigo
-------------------------------------------------------
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
