> 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 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.
i do agree that fallback MX handling is an issue of policy and not function.
> > an RFC would be the ideal way to answer these. doing it "like everyone
else
> > does" isn't valid. doing it "the way sendmail does" is even worse.
>
> Agreed. But in some cases I have found things can work better by
violating
> RFCs. I don't like to distribute software that violates the RFCs, unless
it
> would do so only if the administrator gets to choose to do so, and is
aware
> that such a choice is a violation. I have no qualms about distributing or
> using any software that works that way.
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.
> Sticking to standards does have an important purpose. Deviating from them
> should never be done lightly. But it should not be ruled out, either. In
> many cases, such deviations have to be done to fully evaluate a proposed
> change in the standards. And sometimes, old standards are not re-visited
> because de-factor standards born out of deviant usage have established
> themselves and there is no pressure to formalize them when other standards
> work is more pressing.
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.
> 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.
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.
> I don't know of any protocol that specifically says that accepting a
> connection and then summarily dropping it with no output has any
particular
> meaning in that standard. But I would readily classify this as a failure
> not unlike a connection refusal. I recognize this because I happen to
know
> that there are cases where this is unavoidable. One example is that the
> UNIX socket API is a deficient standard for lacking the ability to allow
> user space processes to act on an incoming connection in a way that is
seen
> as a connection refusal.
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?"
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.
