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.
* 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.
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.
-------------------------------------------------------
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
