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 about
15 or so years ago, and maybe it's time to clarify some of the behaviors
we've been talking about. i would suggest that we form another list and
attempt to draft some sort of standard or RFC - not necessarily to decide on
fixed behaviors that are really issues of policy, but to better define the
various possible situations so that MTA developers can easily compare what
their MTA does in a certain situation. no, i'm not going to be the one to
lead that effort, but i'll gladly participate :)
> 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.
yes, in this particular case, the firewall is the issue - it's pretty
broken. but the discussion is over what qmail should do. qmail has no idea
that there's a firewall in between.
> > 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?
it would be nice to have a state diagram that shows what paths the program
might take depending on how far the SMTP transaction gets. at least then
you'd know what the program does and (i guess) you could modify its behavior
appropriately.
> 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.
"failure" is a subjective term.
> 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?
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 it. the firewall is
clouding the issue.
> 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.
agreed.
> 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.
the issue is more than that - it's "to what lengths should qmail go to work
around the failure?"
shag
=====
Judd Bourgeois | CNM Network +1 (805) 520-7170
Software Architect | 1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED] | Simi Valley, CA 93065
Quidquid latine dictum sit, altum viditur.
