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 rebuilding. that is, i don't
> think you could just have a simple qmail control file that detailed MX
> handling unless all the policies were already built into the source anyway.
It really wouldn't be that hard to implement a configurable way to fallback.
One simple boolean would cover a lot of cases, that being whether or not a
dropped connection is to be treated just like a connect that was not made.
More involved configuration would allow choosing discrete behaviour over the
different failure cases, but that may be a bit extreme.
> that's fine except in this case there IS no rfc to provide a baseline.
> there's "the way sendmail does it", which is in a sense a de facto standard,
> but it's only a standard because way back when, Eric Allman made some
> decisions about MX handling and for better or worse we're stuck with his
> decisions.
Then Dan gets to do it however he wants, and for whatever reason he wants.
Which is probably the case as it stands.
It just bugs me when people say a connection refused is a broken server and
a connectiond dropped is not.
> qmail is deviating from the established standard and handling things its own
> way. is it better or right? i don't know, there really hasn't been enough
> discussion.
Well, if we do discuss it, I'd prefer to move the discussion forward to how
the decision will really affect the proper delivery of mail, rather that why
such and such server is a bad server.
> > There is also another saying common in computers and networking,
> especially
> > in regard to conformance to standards: Be conservative in what you
> produce
> > and be liberal in what you accept.
> >
> > I have interpreted that to mean that if something does not conform to the
> > standard, but I also don't have to go out of my way to detect and
> understand
> > what is meant, I _may_ (and some would like this to be _should_) go ahead
> > and accept it with the obvious semantics.
>
> the first part i agree with. the second part i'm not so sure about. my
> take on it is that programs should be prepared to handle any input.
> "handle" does not mean process necessarily, it just means that for any
> input, the program should have defined behavior. this means that the
> program has a very limited set of inputs and very well defined behaviors.
> if the inputs are bad, the program refuses the input.
There should be a defined behaviour for different kinds of failures on the
part of servers being connected to for mail delivery. Most certainly it
should not crash if the connection just gets dropped. The question is what
should be the reasonable range of choices for things it may do.
> i do NOT believe that "liberal" means "should attempt to rectify problems
> automatically." report the problem, sure, and don't crash because the input
> is too big or malformed, but don't attempt to fix the problem. GIGO.
Is a connection refused a problem to be rectified?
Is a connection dropped a problem to be rectified?
> how fast does it have to be dropped to be "summarily" dropped? 1 second?
> 5? 30? at what point does the connection become "established, but timed
> out, will try later" instead of "connection refused or immediately dropped?"
What was in my mind by "summarily dropped" was the receiving server closing
the TCP connection before outputting anything at all. I didn't consider time
to be a factor unless the drop occurs after the point in time in which the
sending server times out due to an idle connection. But the sender will be
doing the connection dropping, so it won't see anything else.
There are a lot of failure scenarios that can occur. Connection refused.
Connection timed out. Various network failures (no route, no interface).
Communications timed out. Communications severed (peer dropped, network
failures, etc). In general I would tend to prefer to treat them all the
same unless there is some compelling reason to do otherwise. Such reasons
can be protocol standards or just a reasonable argument in favor of some
other way to do it.
--
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]
