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

Gordon Messmer wrote:

> Rodrigo Severo wrote:
>
>>
>> scorsese rodrigo # telnet brsmtp04.br.abnamro.com 25
>> Trying 200.208.15.131...
>
> ...
>
>> mail from: <FAKE1@fabricadeideias.com>
>>
>> and here the connection hangs.
>
>
> OK, so to summarize: You are seeing Courier connect to an MX and
> begin a conversation, which then times out. You want Courier to retry
> this message using an alternate MX, possibly one of lower priority, in
> response to this situation.

Yes that is it. Obviously I don't want to change the time Courier waits
for the next delivery retry. I only want to change the MX is uses for
the retry.

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

>
> However, it is interesting to note that in section 4.5.4.1 of RFC
> 2821, you find the suggestion:
> A client SHOULD keep a list of hosts it cannot reach and
> corresponding connection timeouts, rather than just retrying queued
> mail items.
>
> This suggested item *might* indicate that the best thing to do in the
> face of a timeout would be to record that the host is unreliable, and
> exclude it during the next connection attempt. Eventually you might
> run out of MXs, in which case you'd probably have to eliminate the
> list and start trying the highest priority MXs again.
>
Well, I believe this is exactly what I am suggesting. It seems to me
that this behaviour is more robust and not abusive at all. As you
discoverd, RFC 2821's authors seems to agree with me.

> Having said that, I think that such a feature would be almost entirely
> worthless. If such a thing were implemented, you *might* see messages
> eventually get to systems which currently do not work, but you'd still
> see unacceptably long delays in the delivery of each message to that
> system. Every message would still end up going through the long
> process of elimination and delayed retries. Users would still not be
> happy.

There would be long delays but the delays would be smaller than they are
with the current behaviour of Courier. Sadly the only solution to
eliminate the delays completely would be to fix the MTA at the other
end. In a better world this would be possible. In our real world we can
do the best we can: modify Courier behaviour and reduce delivery delays
as short as we can.

I won't try to guess if users would be happy or not. I'm not a
*soothsayer. But I know that with this new behaviour I would have
greater chances of delivering messages in shorter times. And I would
also know that I did everything that was reasonable possible to make
things as good as I could. In real life that's as good as it gets most
times.
*

>
> I think that the best thing to do is to ask the remote server admins
> to work with you to resolve the problem. If they do not, explain to
> your users that the destination server is unreliable, and the persons
> responsible are uncooperative. As they say, "it takes two to tango".
> You can not magically make servers run by other people work correctly.
> If those servers do not accept messages, both your users and theirs
> should be pressuring their admins to look at the problem.

I entirely agree with you. This has been tried. I might even try it
again. But this is not a good reason not to improve Courier behaviour if
we can. I see there are two independent paths of actions. I believe both
shall be used. Trying to fix other people's MTAs: necessary despite not
highly productive. And trying to improve my tools - in this case Courier
- as much as it's reasonable possible.

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.

Sam, if you understood my suggestion, please consider it.


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