Jay Lee wrote:
Rodrigo Severo wrote:
Ben Kennedy wrote:
Maybe on a 4xx it would make sense. I can't see how it would with a
5xx,
though. If you have 2 MXs and they don't agree on who is a valid user
(for example), you have bigger problems.
My fault. You are right. There is no good reason to try a second MX
if I get a 5xx error.
There still remains the 4xx error situation and the "Connection timed
out" => "deferred" situation. Why not try a second MX in these
situations?
If it's "turned off", then Courier would try and fail and move on to
the
next one, as it currently does, so what's the difference?
Yes you are right again. I mentioned this because I had this problem
with a very old Courier version I was running some time ago. Old
problem already solved.
But again ther still remains the server too busy situation where I
end getting a "Connection time out". Wouldn't it be good to try a
second MX here?
It's my understanding that Courier would defer the message for awhile
after the 4xx (which is exactly what a 4xx error is asking it to do)
and then re-evaluate the MX records. So if there were two mx records
of the same weight, it would eventually try the 2nd one.
And if the two mx records aren't of the same weight, why not try the
other one? As I said before, this alternative behaviour could be optional.
In other words, I don't believe Courier "caches" the DNS lookup
between attempts but I could easily be wrong on this. Sam?
If your are right, I believe I already have half my problem solved.
Let's wait for Sam's answer.
Also, I believe a heavy load server should be configured to refuse
connections when load is high rather than accept only to defer with
4xx errors due to overtaxed resources.
I entirely agree with you.
Courier does this per the MAXDAEMONS and MAXPERIP settings. If your
pushing your system resources and running into timeouts, this number
should be lowered.
Please be sure I would do it if my server were getting timeouts because
of to many connections opened to it. The problem here is that a server I
don't manage is presenting this problem. In a better world I would talk
to the sys admin at the other side and everything would be solved. I
tried. I failed. I have to do something here, sadly.
If the connection is refused rather than deferred, then a well behaved
server will then try the next MX record.
I think this is the behaviour of Courier. But I have a doubt here: does
Courier tries the NEXT MX record, as in it keeps a list , tries the
first then the second and so on or Courier tries ANOTHER MX record, as
in it asks for the MX records again and randomly picks a MX record?
Could you please clarify Sam?
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
