Ang Loon wrote:
Rodrigo, I took a peep at the esmtp sources a while
ago because I was facing the same 4xx thing - it
doesn't look that hard to tweak the logic yourself and
recompile if you really really had to. (I do realise
it would be a compromise but..)
It isn't perfect but it can be a rea
Rodrigo, I took a peep at the esmtp sources a while
ago because I was facing the same 4xx thing - it
doesn't look that hard to tweak the logic yourself and
recompile if you really really had to. (I do realise
it would be a compromise but..)
Ben Kennedy wrote:
>>You couldn"t be more right. My prob
Malcolm Weir wrote:
Your problems are an artifact of the primary accepting the connection,
starting the SMTP dialog, and then failing once a successful connection has
been made.
Also known as: some problem occured. SMTP is designed to deal the best
possible way with eventual problems during me
> -Original Message-
> From: Rodrigo Severo
> Sent: Tuesday, June 21, 2005 2:08 PM
[ Snip ]
> >BUT... It's been at least to wait_for_retry intervals since PrimaryA
> >exhibited its problem issue, and Courier (and sendmail,
> Qmail, Postfix,
> >etc.) cannot presume that the people who ru
Malcolm Weir wrote:
-Original Message-
From: Rodrigo Severo
Sent: Tuesday, June 21, 2005 1:03 PM
And, contrary to the implication, it would be a BAD idea to include
logic that selects lower priority ("secondary") MXs for the
subsequent
attempts unless (all) the
Rodrigo Severo writes:
Sam Varshavchik wrote:
Rodrigo Severo writes:
If there are multiple primary MXs set, Courier should already pick
one at random with each delivery attempt.
Sam, are you saying that two consecutive delivery attempts by Courier
will try to deliver the message to two d
David Gomillion wrote:
What you're suggesting here makes some sense, but you have to think
about it from a bigger-picture perspective. Basically, you're trying to
change stateless SMTP handling based upon MX records into a stateful
system that remembers broken MXes and acts on that knowledge.
> -Original Message-
> From: Rodrigo Severo
> Sent: Tuesday, June 21, 2005 1:03 PM
> >And, contrary to the implication, it would be a BAD idea to include
> >logic that selects lower priority ("secondary") MXs for the
> subsequent
> >attempts unless (all) the higher priority ones cannot
> Ben Kennedy wrote:
>
> >Sam Varshavchik wrote at 9:02 am (-0400) on 21 6 2005:
> >
> >
> >
> >>So, until modern technology advances to such a point, the
> only logical
> >>thing
> >>to do is attempt to deliver E-mail repeatedly, and follow
> the preferred
> >>logic for making each delivery
Sam Varshavchik wrote:
Rodrigo Severo writes:
If there are multiple primary MXs set, Courier should already pick
one at random with each delivery attempt.
Sam, are you saying that two consecutive delivery attempts by Courier
will try to deliver the message to two different MXs, no matter t
Malcolm Weir wrote:
-Original Message-
From: Sam Varshavchik
Sent: Tuesday, June 21, 2005 12:11 PM
So, until modern technology advances to such a point, the
only logical
thing to do is attempt to deliver E-mail repeatedly, and follow the
preferred logic for making each deliv
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
Ben Kennedy wrote:
Sam Varshavchik wrote at 9:02 am (-0400) on 21 6 2005:
So, until modern technology advances to such a point, the only logical thing
to do is attempt to deliver E-mail repeatedly, and follow the preferred
logic for making each delivery attempt: pick a primary MX at random
> -Original Message-
> From: Sam Varshavchik
> Sent: Tuesday, June 21, 2005 12:11 PM
> >>So, until modern technology advances to such a point, the
> >>only logical
> >>thing to do is attempt to deliver E-mail repeatedly, and follow the
> >>preferred logic for making each delivery attemp
Ben Kennedy writes:
Sam Varshavchik wrote at 9:02 am (-0400) on 21 6 2005:
So, until modern technology advances to such a point, the only logical thing
to do is attempt to deliver E-mail repeatedly, and follow the preferred
logic for making each delivery attempt: pick a primary MX at random,
Ben Kennedy wrote:
I have to admit I am starting to come around to understanding Rodrigo's
viewpoint on this, however. What is the *downside* of having Courier
retry a different (same-priority if exists, or next lowest, as usual) MX
rather than the same *potentially*-broken one, after the usual
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 refus
Sam Varshavchik wrote at 9:02 am (-0400) on 21 6 2005:
>So, until modern technology advances to such a point, the only logical thing
>to do is attempt to deliver E-mail repeatedly, and follow the preferred
>logic for making each delivery attempt: pick a primary MX at random, if you
>can't conne
Rodrigo Severo writes:
Sam Varshavchik wrote:
There's nothing that Courier can do here. Courier will not disconnect
and reconnect to some other MX. Courier will only try to contact the
next MX if it didn't connect at all to the first MX.
Why? If Courier contacted a MX and the connection
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 th
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 Cour
Rodrigo Severo wrote:
Sam Varshavchik wrote:
Rodrigo Severo writes:
Sam Varshavchik wrote:
If there are equal priority MXes each attempt should go to a random
MX.
As I already said, if this is the current behaviour of Courier
that's good. What I am suggesting here is that, if all t
Joe Laffey wrote:
On Tue, 21 Jun 2005, Sam Varshavchik wrote:
Rodrigo Severo writes:
scorsese rodrigo # telnet brsmtp04.br.abnamro.com 25
Trying 200.208.15.131...
Connected to brsmtp04.br.abnamro.com.
Escape character is '^]'.
220 Welcome
ehlo scorsese.fabricadeideias.com
250-br.abnamro.com
Sam Varshavchik wrote:
Rodrigo Severo writes:
Sam Varshavchik wrote:
If there are equal priority MXes each attempt should go to a random MX.
As I already said, if this is the current behaviour of Courier that's
good. What I am suggesting here is that, if all top priority MXs were
alre
On Tue, 21 Jun 2005, Sam Varshavchik wrote:
Rodrigo Severo writes:
scorsese rodrigo # telnet brsmtp04.br.abnamro.com 25
Trying 200.208.15.131...
Connected to brsmtp04.br.abnamro.com.
Escape character is '^]'.
220 Welcome
ehlo scorsese.fabricadeideias.com
250-br.abnamro.com
250-SIZE 6291456
25
Phillip Hutchings wrote:
1. Courier gets some 4xx error. There are other MXs available but as
far as I can Courier tries the same MX several times if not all the
time so message delivery is unnecessarily delayed or delivery even
fails. Wouldn't it be better to try other MXs (same or differ
Rodrigo Severo writes:
Sam Varshavchik wrote:
If there are equal priority MXes each attempt should go to a random MX.
As I already said, if this is the current behaviour of Courier that's
good. What I am suggesting here is that, if all top priority MXs were
already tried, why not step to
Sam Varshavchik wrote:
Rodrigo Severo writes:
1. Courier gets some 4xx error. There are other MXs available but as
far as I can Courier tries the same MX several times if not all the
time so message delivery is unnecessarily delayed or delivery even
fails. Wouldn't it be better to try other
1. Courier gets some 4xx error. There are other MXs available but
as far as I can Courier tries the same MX several times if not all
the time so message delivery is unnecessarily delayed or delivery
even fails. Wouldn't it be better to try other MXs (same or
different weights) in a round ro
Rodrigo Severo writes:
1. Courier gets some 4xx error. There are other MXs available but as far
as I can Courier tries the same MX several times if not all the time so
message delivery is unnecessarily delayed or delivery even fails.
Wouldn't it be better to try other MXs (same or different we
Jay Lee wrote:
One difficulty here is that you're offering suggestions to "improve
Courier" rather than actually explaining what your problem is. That's
somewhat offensive to a developer, see:
http://www.catb.org/~esr/faqs/smart-questions.html#id3001405
I'm not claiming I found a bug. I'm s
One difficulty here is that you're offering suggestions to "improve
Courier" rather than actually explaining what your problem is. That's
somewhat offensive to a developer, see:
http://www.catb.org/~esr/faqs/smart-questions.html#id3001405
http://www.catb.org/~esr/faqs/smart-questions.html#goal
Rodrigo Severo writes:
I think this is the behaviour of Courier. But I have a doubt here: does
Courier tries the NEXT MX record, as in it keeps a list , tries the
first then the second and so on or Courier tries ANOTHER MX record, as
in it asks for the MX records again and randomly picks a MX
Ben Kennedy wrote:
Rodrigo Severo wrote at 7:12 pm (-0300) on 20 6 2005:
Why should Courier contact a secondary MX if it was perfectly able to
reach the primary?
Two possible reasons that came to my mind right now are: a 4xx error and
a "Connection time out" => "deferred" situation.
Jay Lee writes:
It's my understanding that Courier would defer the message for awhile
after the 4xx (which is exactly what a 4xx error is asking it to do) and
then re-evaluate the MX records. So if there were two mx records of the
same weight, it would eventually try the 2nd one. In other wo
Jay Lee wrote:
Rodrigo Severo wrote:
Ben Kennedy wrote:
Maybe on a 4xx it would make sense. I can't see how it would with a
5xx,
though. If you have 2 MXs and they don't agree on who is a valid user
(for example), you have bigger problems.
My fault. You are right. There is no good reas
Rodrigo Severo writes:
You couldn't be more right. My problem is that I have, by contract, to
send several emails to this client and my messages aren't getting
Now there's the root of the problem.
You should not be relying on E-mail as a reliable delivery mechanism. It is
not.
pgpEHriw
Rodrigo Severo wrote at 7:12 pm (-0300) on 20 6 2005:
>> Why should Courier contact a secondary MX if it was perfectly able to
>> reach the primary?
>
>Two possible reasons that came to my mind right now are: a 4xx error and
>a "Connection time out" => "deferred" situation.
There is a fault in
Rodrigo Severo wrote:
Ben Kennedy wrote:
Maybe on a 4xx it would make sense. I can't see how it would with a
5xx,
though. If you have 2 MXs and they don't agree on who is a valid user
(for example), you have bigger problems.
My fault. You are right. There is no good reason to try a secon
Sam Varshavchik wrote:
Rodrigo Severo writes:
Sam Varshavchik says:
If Courier cannot contact the primary MX it will automatically
contact the secondary MX.
Is there any reason for Courier only try to contact a secondary MX if
it can't contact the primary at all?
Why should Courier co
Ben Kennedy wrote:
Maybe on a 4xx it would make sense. I can't see how it would with a 5xx,
though. If you have 2 MXs and they don't agree on who is a valid user
(for example), you have bigger problems.
My fault. You are right. There is no good reason to try a second MX if I
get a 5xx error
Rodrigo Severo writes:
Sam Varshavchik says:
If Courier cannot contact the primary MX it will automatically contact the
secondary MX.
Is there any reason for Courier only try to contact a secondary MX if it
can't contact the primary at all?
Why should Courier contact a secondary MX if it
Rodrigo Severo wrote at 4:19 pm (-0300) on 20 6 2005:
>Wouldn't it be a good approach to try other MXs after any kind of error:
>failed connection, 4xx error, 5xx error etc?
Maybe on a 4xx it would make sense. I can't see how it would with a 5xx,
though. If you have 2 MXs and they don't agree
Sam Varshavchik says:
If Courier cannot contact the primary MX it will automatically contact the
secondary MX.
Is there any reason for Courier only try to contact a secondary MX if it
can't contact the primary at all?
Wouldn't it be a good approach to try other MXs after any kind of error:
fa
44 matches
Mail list logo
