ok real quick let me say that i think we've beat this horse good and dead
into the ground. that said, however, i think there's been a lot of useful
discussion about an issue that really hasn't been researched in the light of
modern SMTP systems. that is, the whole notion of MX records started
Racer X wrote:
publishing an MX host that is never reachable seems pretty broken to me. it
may be technically permitted, i suppose it's not explicitly forbidden
anywhere, but publishing the record is like saying "what if 2 plus 2 equals
5?" interesting concept but pointless to bother with
David Dyer-Bennet writes:
What is the appropriate MTA behavior in this case? It seems clear
to me that what everybody would want in this situation is for an
MTA to fail over to the secondary MX.
If their MX records are incorrectly configured, their email isn't
going to go through. Why
David Dyer-Bennet writes:
Russell Nelson [EMAIL PROTECTED] writes on 27 September 1999 at 16:44:19 -0400
Should we be giving any consideration to the question of whether, on
the average, secondary MXs are less reliable than primary? I don't
think we should; I don't think we
On Mon, 27 Sep 1999, Russell Nelson wrote:
David Dyer-Bennet writes:
It doesn't work fine in the scenario I outlined at the beginning of my
message. In that situation, the mail will sit on the qmail system
until it expires, when there's a perfectly good secondary MX system
sitting
Russell Nelson wrote:
David Dyer-Bennet writes:
What is the appropriate MTA behavior in this case? It seems clear
to me that what everybody would want in this situation is for an
MTA to fail over to the secondary MX.
If their MX records are incorrectly configured, their email isn't
Russell Nelson wrote:
David Dyer-Bennet writes:
[snip]
It doesn't work fine in the scenario I outlined at the beginning of my
message. In that situation, the mail will sit on the qmail system
until it expires, when there's a perfectly good secondary MX system
sitting there waiting
Russell Nelson wrote:
[EMAIL PROTECTED] writes:
Now you can just requeue the mail and try again later. If you do, then
you are presuming that perhaps it will be fixed later on, but before the
expiration of the mail.
It's reasonable to retry a host if you can make a connection to
[EMAIL PROTECTED] writes:
Now you can just requeue the mail and try again later. If you do, then
you are presuming that perhaps it will be fixed later on, but before the
expiration of the mail.
It's reasonable to retry a host if you can make a connection to it,
but cannot talk SMTP to it.
On Thu, Sep 23, 1999 at 11:09:08PM -0400, Russell Nelson wrote:
Because it's reasonable to expect that other MX records will work for
1+2, but not for 3. If the lowest priority MX record is screwed up,
why aren't the others as well?
If one MX has a screwed up binary, it is likely that other
On Thu, 23 Sep 1999, Russell Nelson wrote:
Because it's reasonable to expect that other MX records will work for
1+2, but not for 3. If the lowest priority MX record is screwed up,
why aren't the others as well?
How does the way the 1st MX fails to accept the message affect the working
of
Essentially what we're dancing around is the issue of deliberate
misconfiguration in an effort to save sysadmin time: "It's hard work to
set up split DNS. Why not just have a low numbered MX record for
internal hosts, and a higher numbered record for external hosts? It
works for sendmail,
How does the way the 1st MX fails to accept the message affect the working
of other MXes (in a general case)?
if the first MX allows a connection to port 25, there is an implied
assumption that there is a program listening on port 25 that speaks SMTP.
therefore, the sender should attempt
Racer X wrote:
How does the way the 1st MX fails to accept the message affect the working
of other MXes (in a general case)?
if the first MX allows a connection to port 25, there is an implied
assumption that there is a program listening on port 25 that speaks SMTP.
therefore, the
Jon Rust wrote:
Essentially what we're dancing around is the issue of deliberate
misconfiguration in an effort to save sysadmin time: "It's hard work to
set up split DNS. Why not just have a low numbered MX record for
internal hosts, and a higher numbered record for external hosts? It
Pavel Kankovsky wrote:
Because it's reasonable to expect that other MX records will work for
1+2, but not for 3. If the lowest priority MX record is screwed up,
why aren't the others as well?
How does the way the 1st MX fails to accept the message affect the working
of other MXes (in
Pavel Kankovsky writes:
On Fri, 17 Sep 1999, Russell Nelson wrote:
Because you claimed that it was speaking SMTP. Upon examination, it
isn't. Your MX records are false. Why should I send your server any
mail at all, since it may not be the right server at all?
1. The host is
Greg Owen [EMAIL PROTECTED] writes on 19 September 1999 at 09:18:55 -0400
But before I go, in response to Racer X:
the more i think about this, the more i think that
fallback MX records aren't really necessary anymore.
There are several reasons I think they are still
David Dyer-Bennet wrote:
Greg Owen [EMAIL PROTECTED] writes on 19 September 1999 at 09:18:55 -0400
But before I go, in response to Racer X:
the more i think about this, the more i think that
fallback MX records aren't really necessary anymore.
There are several
The Raptor tech we talked with said one has to use the
filters to prevent listening ports from being reached
on untrusted interfaces.
I believe I've found the info required to fix the problem at my
firewall. http://www.raptor.com/cs/FAQ/entv5basictrafficmethods.html is a
description
Pavel Kankovsky wrote:
1. The host is dead = it does not send any datagrams =
it does not speak SMTP.
2. The host is alive but no process listens on SMTP port = it refuses
TCP connections = it does not speak SMTP.
3. The host is alive, some process listens on SMTP port but something
Russell Nelson wrote:
[EMAIL PROTECTED] writes:
Russell Nelson wrote:
A host that persistently refuses to run the SMTP protocol on the SMTP
port cannot be said to be running SMTP.
So why not fall back to another one that does?
Because you claimed that it was speaking
On Fri, 17 Sep 1999, Greg Owen wrote:
But the Xerox servers aren't accepting a connection. The apparent
accepted connection is a side effect of the Raptor proxy firewall. If that
firewall wasn't in the way, they'd just refuse connection and qmail would
back off to the next MX
Make it configurable.
ok, i get the point. i would say that it IS configurable in that different
MTA's can handle it however they want. making it configurable at an even
lower level would seem to be a rather difficult project and not something
you could do without at least patching and
Racer X wrote:
ok, i get the point. i would say that it IS configurable in that different
MTA's can handle it however they want. making it configurable at an even
lower level would seem to be a rather difficult project and not something
you could do without at least patching and
Racer X wrote:
part of the problem, for me at least, is that it is impossible to guarantee
that secondary MX's will, in fact, accept mail for the domain they are
supposed to be MX'ing for. i'd rather hold the mail for a couple days in my
queue and deliver it directly to the host than pass
Sorry? Did I miss an earlier message? Where does it say
it's a violation?
Quoting RFC821:
One important reply is the connection greeting. Normally, a
receiver will send a 220 "Service ready" reply when the
connection is completed.
But the Xerox servers aren't
If Qmail did it "the same way", it would make Qmail more
acceptable to users.
Ouch - even that one is beyond me ;)
If qmail did anything the same way as other MTA's --- well, I'm not so sure
I can express it. We're here because qmail doesn't do anything like other
MTA's - it's one of
I was provided some information on how to modify the Qmail
code to address this issue, but being a non-programmer, I
decided not to go butchering the code. Here's the details...
Karl,
I've looked through qmail-remote.c and, the long and short of it is,
the design makes it
Russell Nelson wrote:
A host that persistently refuses to run the SMTP protocol on the SMTP
port cannot be said to be running SMTP.
So why not fall back to another one that does?
Tell them to fix their SMTP servers, don't work around their
breakage.
Isn't the design philosophy of the
Racer X wrote:
so qmail is within its "legal" boundaries in the way it handles MX records.
without an RFC that specifies different behaviors for different situations,
MX handling will always be a gray area. for instance:
Would it be within its "legal" boundaries to handle it differently in
[EMAIL PROTECTED] writes:
Russell Nelson wrote:
A host that persistently refuses to run the SMTP protocol on the SMTP
port cannot be said to be running SMTP.
So why not fall back to another one that does?
Because you claimed that it was speaking SMTP. Upon examination, it
isn't.
On Thu, Sep 16, 1999 at 08:38:25AM -0400, Greg Owen wrote:
Not that its my job to defend them, but I don't think its a lack of
brains. Their system allows the actual end mail host owners, who are often
Not only that - but I recall seeing this exact strategy mentioned in a book
on
Jason Haar writes:
On Thu, Sep 16, 1999 at 08:38:25AM -0400, Greg Owen wrote:
Not that its my job to defend them, but I don't think its a lack of
brains. Their system allows the actual end mail host owners, who are often
Not only that - but I recall seeing this exact strategy
On Thu, Sep 16, 1999 at 05:14:57PM -0400, Russell Nelson wrote:
It's still wrong. At *very* least it's a violation of the SMTP
protocol. Where's the SMTP banner?
Sorry? Did I miss an earlier message? Where does it say it's a violation? I
thought this entire matter was due to it being an
Jason Haar writes:
On Thu, Sep 16, 1999 at 05:14:57PM -0400, Russell Nelson wrote:
It's still wrong. At *very* least it's a violation of the SMTP
protocol. Where's the SMTP banner?
Sorry? Did I miss an earlier message? Where does it say it's a violation?
Quoting RFC821:
Sorry? Did I miss an earlier message? Where does it say it's a violation?
I
thought this entire matter was due to it being an area not formally
mentioned in the RFCs - as it isn't mentioned, neither Qmail or
Sendmail/et
al are right or wrong. My point was that "everyone else" does it a
Quoting RFC821:
One important reply is the connection greeting. Normally, a
receiver will send a 220 "Service ready" reply when the connection
is completed. The sender should wait for this greeting message
before sending any commands.
The table below lists
When will qmail decide to back off the primary MX and try to use
lower priority MX hosts?
In particular, if the primary MX allows a connection and immediately
drops it, will qmail ever decide to try the next MX?
I'm seeing this problem right now with two systems:
Greg Owen [EMAIL PROTECTED] wrote:
When will qmail decide to back off the primary MX and try to use
lower priority MX hosts?
When it decides that the primary is permanently down.
In particular, if the primary MX allows a connection and immediately
drops it, will qmail ever decide
But it seems that qmail isn't backing off, probably
because it gets a connect rather than getting a refusal.
Should qmail be backing off? Is accepting+dropping connections
documentably wrong, that I should complain to them about it?
What's the deal?
Part of the
Greg Owen writes:
When will qmail decide to back off the primary MX and try to use
lower priority MX hosts?
When it cannot contact the primary MX.
In particular, if the primary MX allows a connection and immediately
drops it, will qmail ever decide to try the next MX?
No,
Should qmail be backing off? Is accepting+dropping connections
documentably wrong, that I should complain to them about
it? What's the deal?
Yes, it's wrong. Why are they advertising an MX if they never intend
to allow connections to it?
It looks like my firewall is
: RE: When will qmail back off to the next MX?
But it seems that qmail isn't backing off, probably
because it gets a connect rather than getting a refusal.
Should qmail be backing off? Is accepting+dropping connections
documentably wrong, that I should complain to them about
Russell Nelson writes:
Should qmail be backing off? Is accepting+dropping connections
documentably wrong, that I should complain to them about it? What's the
deal?
Yes, it's wrong. Why are they advertising an MX if they never intend
to allow connections to it?
They have a
On Wed, 15 Sep 1999, Greg Owen wrote:
Xerox, and some other sites I've seen, use MX records to make mail
routing administration easier. The mail store machine is the top priority,
but only Xerox machines can reach it.
Well, then they've screwed up or they're lazy. If only Xerox
46 matches
Mail list logo
