[ On Saturday, February 22, 2003 at 19:29:14 (-0500), Greg Louis wrote: ]
> Subject: Re: [Exim] MX Record points to non-existent host
>
> That would be nice :) Look, the point you're making here is valid, I
> understand it, I agree with it, but I decline to be the only one in the
> whole damn 'net (except for people who can afford to throw away email
> from important correspondents) to stand up and try to enforce it!
Ah, well you see you will never be alone in enforcing basic minimum RFC
requirements for Internet communications. Far from it.
In this particular case we're not even talking about anything that's
even half questionable (such as maybe rejecting mail from mailers that
don't have humans answering to a <postmaster> mailbox, or which
themselves reject bounces, and especially not where sender addresses
cannot be actively verified, etc.).
The rules about MX parameters are very plain and simple rules that have
always been there, and they are there for reasons that go quite a bit
deeper than the already hinted at ability to spot the difference between
a dotted quad and a domain name, and these reasons are in fact spelled
out in quite some detail in the RFCs.
There are even some privacy issues involved (though strictly we
shouldn't care because anyone concerned about privacy should be using
end-to-end security with the likes of PGP or something). If there are
obvious problems with an MX record then how can we be sure anything
about it is even close to right -- we could end up routing e-mail to the
wrong mail server! It's one thing for the user to make a typo (I get
e-mail for wired.com quite often), but it's another thing all altogether
for the underlying software to make a routing mistake because it trusted
data that already had obvious problems with it.
Speaking of DNS problems, I don't know yet if Exim even checks that the
DNS records it gets in replies are for the domains it asked for. I just
recently fixed a bug in Smail where it wasn't cross checking the names
and was being fooled by a broken nameserver into routing mail to the NS
host instead of the MX host. I believe sendmail is still vulnerable to
such buggy replies too.
> I have found that most members of the Internet community with whom I have
> come in contact are reasonable people who recognize the necessity of
> living in the world as it is, and not in some imaginary Utopia.
Indeed -- and the RFCs we have already reflect that reality. This is
the very reason for the so-called "Robustness Principle". You won't
find such a principle written into the guidelines for very many other
communications protocol standards! However where the RFCs say "MUST"
there is, for one reason or another, usually no room for forgiveness.
You can only go so far before you make things worse instead of better.
> They
> may deplore, as I do, the need to accomodate the errors of Some Big
> Firm and its customers, but they do not (in general) airily demand that
> I antagonize our customers, our agents, our suppliers, our employees
> and my boss in a Quixotic attempt to achieve the Utopia single-handedly.
Nobody said you need to antagonize your own (and your company's own)
e-mail correspondents -- you can deal with them using the finest
kid-leather gloves you can find, if you wish and if you can.
The point is, and I will repeat it again, that you do not dare even
given them even just the impression that they can get away forever with
broken DNS, and/or buggy mailer (etc.) software, and/or and
mis-configured Internet systems.
> I wish. I've not sat down and done the arithmetic, but I'd guess we're
> looking at around five percent.
Generically I think it's closer to 3% if we believe the Men&Mice surveys
(that's for all types of MX breakage, including MX-to-CNAME). Their
sample size is quite small (5000 domains I believe), but in two other
similar sizes sample groups I've seen the same percentages and that
would suggest they're at least close. Sure, 3% of 5000 domains is a big
enough headache, but it's still easily manageable on a one-by-one,
day-to-day basis.
> In the first six days of operating
> exim with reasonably tight constraints, I accumulated several _dozen_
> user complaints of emails gone astray.
Perhaps this is more of an example of poor expectation management than
anything else.... :-)
> I will reiterate that all I want is for emails to us to arrive and
> emails from us to arrive in the greatest possible number of cases.
And that's _exactly_ what you get if you follow the RFCs. That's what
interoperability standards are all about, after all.
The minute you start tweaking things with special atrocities of your own
making then you perpetuate and reinforce mis-perceptions in those who
have broken DNS, software, configs, etc. by showing them yet again that
they can get away with their ignorance, laziness, or whatever it is.
(This is the part about Exim that I really don't like -- it gives people
far too many knobs and buttons to twist and push. Even when people know
what they're doing these options don't necessarily help anyone in the
long run. A key example is the feature which allows MX-to-IP# hacks.
Such an option should not ever exist in a standards compliant mailer.)
> As a matter of fact, I have been preaching RFC conformance to anyone
> who will listen for as long as I've been on the 'net (only 8 years or
> so, but still...) and I'm not going to stop doing so.
Yes, I know -- I'm really not ignoring that!
> But only to
> those who evince a willingness to listen. Cold-calling our customers
> is not an option.
It's not a "cold call". It's a return follow-up. You hopefully already
know from your own logs that they've tried to contact you for some
reason. You're also not necessarily calling the guy who got the bounce
or whatever -- your calling the domain's technical contact.
Besides, what are you going to do the first time you spot some mail
being rejected? Are you going to hack something and then just hope they
try to send it again?
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
