Re: [courier-users] Re: Automatically use secondary MX host if primary

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/.../courier-users