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 ways
some have suggested?
> * if the primary host gives you a temporary error, should you fall back to
> the next MX? how fast, immediately or wait a while? if you wait a while,
> maybe the temporary error will go away?
Make it configurable.
> * what if a fallback gives you a temp error? should you reset your MX
> preference to the primary? how soon?
Make it configurable.
> * if any host gives you a permanent error, should you try all other hosts?
> (this may be answered in some rfc, i dunno)
Make it configurable.
> * there's clearly a difference between a "connect refused", "host not
> responding", "host answers but disconnects without notice", all these kind
> of error conditions. how should they be handled wrt MX?
Make it configurable.
> * how often do you check for an updated MX list? every time you send the
> mail? if so, should you keep track of what the preferences used to be?
Make it configurable.
> 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.
> btw, in case you weren't aware, your "make qmail more acceptable to users"
> argument isn't going to impress people around here.
Sounds like the debate I have with the FreeBSD people over their refusal to
support ATAPI devices attaced as master on an IDE channel just because the
specifications described it as a slave device ... at a time before secondary
IDE was common place (Linux and MS Windows work fine with master ATAPI).
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.
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.
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.
If you can write a "bounce/relay" type of program that listens on a port and
for each connection coming in, connects to another specified host and port,
and passes all traffic both ways, but in the case of a connection refusal by
the target host, gives a connection refusal to the incoming connection it
gets, then I am proven wrong (and will have use for your code).
People want things that work well and work right. Unfortunately there is
disagreement on what both of those things mean. I see both sendmail and
qmail as fitting neither, but qmail is closer. In choosing which mail
server I will run on the new servers I am working on, I have to evaulate how
easy or difficult it will be to make things work as I need them to work.
I've probably ruled out FreeBSD (but I will see if 4.0 fixes things). I
have not ruled out qmail at all because qmail is probably easy to hack. But
indeed, this issue has added to what I will need to do with qmail to make it
"workable" (as I define 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]
