Gordon Messmer wrote:
Rodrigo Severo wrote:
scorsese rodrigo # telnet brsmtp04.br.abnamro.com 25
Trying 200.208.15.131...
...
mail from: <[EMAIL PROTECTED]>
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/listinfo/courier-users
