Gordon Messmer wrote:
Rodrigo Severo wrote:
Gordon Messmer wrote:
If I understand the smtp client's execution model, that doesn't
happen now. A timeout after the session has started is treated as a
temporary failure, and the message is deferred. The client will
only try additional MXs if the connection is refused or timed out
during the initial connection attempt. Once the session is begun,
flow control does not return to the MX selection stage, and changing
that would probably be difficult in addition to bad behavior.
Sorry but why people keep saying that trying a different MX after
waiting the appropriate time would be bad behaviour? Apparently this
is a simple concept which I'm the only one who can't grasp.
Probably because what you've been suggesting hasn't been clear to most
of the people that you're talking to. What I think they're trying to
tell you is that:
* It would be bad behavior for one smtp client session to immediately
jump to another MX in the face of a temporary failure, rather than
defer the message and wait.
I agree with you. Please be assured that I am not suggesting anything
like this. My suggestion is that Courier should still defer the message
the usual time. I am asking that Courier tries a different MX at the
next try, *no matter the cause of the previous temporary failure*.
* Currently, each smtp client evaluates the MX list from scratch, so
there's no means to jump to an "alternate" MX if a primary is having
trouble.
* Given the current execution model, suggesting that the client use an
alternate in such a situation would imply that the same SMTP client
try the alternate MX, although I think you're suggesting something else.
Refrasing my suggestion, let's assume the following situation: there is
a domain with 3 different MXs. I get temporary errors during message
delivery. I'm suggesting that Courier reachs each one of the 3 different
MXs once during the first 3 delivery attemps. At the fourth delivery
attempt Courier would reach one of the top weighted MXs again.
Anyway, this is the first time someone seems to have understood my
suggestion. Thanks for your attention and consideration. Sometimes
it's really difficult to communicate some new(?) concept in a mailing
list with highly skilled technicians.
Speaking only for myself: we (royal "we") get stuck on specific
implementation details and frequently don't see alternatives.
I don't know if Sam will be inclined to accomodate this specific
change. It certainly seems like it would be a fix for very few, very
broken sites, and not of general interest. If it's important to you
that you can communicate with this one broken site, you can probably
pay someone to implement the feature. It shouldn't be terribly
difficult, but there may be less expensive (in terms of both time and
money) ways of resolving the problem.
These are possible solutions. I'm taking the time to discuss this matter
here as I believe such a change would increase Courier's robusteness.
It's hard to effectivelly measure the impact of this change. You say
there would be "very few, very broken sites" in such a situation. I
really can't say. My point is that I can't see any cons in doing so in
terms of message delivery. There might be some con in terms of necessary
changes of present code. I can't say either.
Anyway I think it should be considered.
Thanks again for your attention,
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