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 sender should attempt delivery.
Given that port 25 is established to be the standard port for SMTP, and is
shared for any other protocol, it is very reasonable to assume that the
protocol that should be conducted is SMTP. It would then follow that if a
connection was in fact achievable, then the destination host apparently does
intend to converse SMTP. A configuration of firewalls that causes the
connection to happen even though the destination is not willing (perhaps at
this time) to converse SMTP, is misleading at best. The firewall is
certainly badly implemented, and I would consider it to be broken.
> the connection is never disconnected "immediately." assuming the connection
> succeeds it must stay connected for some minimum length of time. it could
> drop after 1 second with no traffic, or the SMTP transaction could get
> halfway done and then the connection times out. let's say you send EHLO,
> MAIL FROM, RCPT TO, and all is well, and you start your DATA but you never
> get an ok from the remote. does that mean you should fall back to the next
> MX?
Does it mean you should not?
There are legitimate scenarios NOT involving broken firewalls, in which a
server could be trying to converse SMTP, but failing to do so for reasons
that may persist for an undetermined length of time. The internet protocols
were designed under a philosophy of making reasonable attempts to work
around failures. The host that fails to converse SMTP (despite the intent
to do so in the configuration, as view by the MX records in the DNS) is a
failure in the network.
A way to work around that failure is to try another MX host, if more than
one is present, guided by the priority information given. It may not be
mandatory to do so, but doing so is a way to work around failure. An
implementation that does not fall back to another MX is an implementation
that is not attempting to work around failure.
> anyway, until an RFC or something clarifies exactly different situations
> should be handled i don't think it's particularly worthwhile to pick on
> qmail for 1) "not doing it like sendmail does," and 2) not handling a broken
> configuration in the way the breakers expect it to. say what you will about
> qmail, the DNS configuration IS broken (and no i don't care how many people
> do it that way - "everyone speeds" but that doesn't make it legal). until
> we can agree that, yes, someone was lazy and should fix the DNS first, i
> don't see the point in changing qmail's behavior.
Doing things a certain way because sendmail does it that way is certainly
not a reasonable guide. Indeed, doing things a different way may well be
preferrable.
Which scenario are you referring to when you say "the DNS configuration IS
broken"? Are you referring to the scenario where the firewall is broken,
and just tossing this in to confuse the issue? Since when is having more
than one MX record for a host to be considered "broken" when one of the
hosts might be down?
Just because one scenario which Qmail could "work around" happens to be a
scenario which is either configured or implemented broken, does not mean
that no other scenarios can exist which would involve the same issue. Just
because one scenario represents a case which is not an interim failure does
not mean that every scenario is likewise.
Hosts do sometimes go down. They do sometimes fail. They do sometimes have
problems which, while not entirely crashing, do prevent the completion of a
protocol at ANY step along its defined path, including before and
immediately after the TCP connection is established. Even Qmail could fail
in such a way when running on a machine which has an interim problem
providing Qmail with the resources to complete execution (e.g. memory
exhausted). It's a failure. You might call it "broken" if you want. The
issue is whether or not it is worthwhile to attempt to work around the
failure.
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
