> -----Original Message----- > From: Rodrigo Severo > Sent: Tuesday, June 21, 2005 2:08 PM
[ Snip ] > >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. You're speaking utter nonsense. If the connect fails to the primaries (e.g. because the primaries are powered off), THEN you connect to the secondaries. Your problems are an artifact of the primary accepting the connection, starting the SMTP dialog, and then failing once a successful connection has been made. That was not the expectation when the MX/SMTP scheme was developed, which anticipated that if a server accepted a connection, then it would complete the dialog with either a successful delivery or a failure code. SMTP is designed around extraordinarily long timeouts (hundreds of seconds). It is explicitly mentioned in RFC1123 that a strategy for managing load is to accept a connection but delay the "220" message for up to 300 seconds, rather than reject the connection. The reason for this is as suggested above: the MTA treats connection failures separately from errors and timeouts. > >>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 ;) What you've totally failed to do is explain why YOUR particular approach to deal with YOUR particular broken systems should BREAK systems that opt to behave as originally anticipated: lower priority MXs should only be used if the higher priority ones cannot be reached. > >*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. Why? Because the people who manage the broken servers would get upset? Here's a hint for them: FIX THEIR SERVERS! We've established that THEIR servers are broken. > Rodrigo 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
