I already sent you a mail off-list about this, but I'll answer this on
list because actually I think it's an important enough point to make.
I'm also scared that I'm agreeing with the most.weird one. :-)
On Sat, Feb 22, 2003 at 03:16:43PM -0500, Greg Louis wrote:
> On 20030222 (Sat) at 1301:32 -0500, Greg A. Woods wrote:
> > I'd like to do very nasty things to every idiot who has ever claimed
> > they could send and receive e-mail with every other domain but mine
> > when the problem is clearly their own!
> I'm not devoid of sympathy with that sentiment. But from their point
> of view, if it works with lots of other domains, why is it a problem?
Because it may not work in the future with those other domains? Because
what they're doing is undermining the reliability of the system. People
like the internet because in general, most things on it are actually
pretty reliable. The web does, in general, just work. Ditto with email.
The reason that this works is because the standards have been thought
out, reference implementations were designed (for better or for worse)
and the theory of the standard was shown to work, and where bugs in
the standard were found, they were corrected. These standards are
pretty resilient for the most part. Pre RFC1123, for example, it would
have been absolutely possible to do this magic with IP addresses on
the RHS of an MX, and do it absolutely reliably, because the format
of any DNS label was defined to start with an alphabetic character,
so if you saw something that started with a number, then it was going
to be a dotted-quad form IP address.
One big networking company changed all this, and suggested that their
domain name ought to be allowed to start with a number. The standard
was duly relaxed (after much discussion) in RFC1123 to allow them to
do this. This means that you can no longer reliably identify a dotted
quad IP address to be an IP address rather than an (albeit weird)
hostname. This very small change didn't matter, per se, and was a
very small code change for most of the libraries out there (the apps
didn't care, on the whole), but it made the task of detecting a dotted
quad harder and less reliable.
In this case, these people say "it works everywhere else", and they
are appealing to the fact that the internet tends to be reliable, but
this is a classic commons situation. It suits them to not conform,
but if everyone doesn't conform, then the overall situation is much
much worse. Each of those farmers who add one more sheep to the common
is having a subtle effect, even though his sheep gets the benefit, but
ultimately there's no grass left.
> That's the perception that makes it really hard to convince them.
People are always selfish. Why can't *I* do something (at the expense
of other people)? Most spammers can't see why, for example, they get
attacked when they send out spam, after all, people can just hit the
'D' key, can't they? Why is this erosion of my system, and the whole
rest of the internet's reliability ok, at the expense of making their
lives a bit easier, by having a bit less to learn? I'd like the internet
to stay reliable. These interactions and erosions have subtle problems
that will come back to haunt us.
What, for example should an MTA do if it finds, say:
some.domain. IN MX 0 1.2.3.4.some.domain.
?
(caused by someone doing:
@ IN MX 0 1.2.3.4
)
Should it send it to 1.2.3.4, on the basis that that is what the person
must have meant? What if it's
some.domain. IN MX 0 1.2.3.4.sub.some.domain.
or alternatively:
sub.some.domain. IN MX 0 1.2.3.4.some.domain.
At what point do you stop?
> What I would like is for my MTA to tolerate as much error as possible
> on the other end while behaving perfectly in every other respect.
But you're decreasing the reliability of your own software, by introducing
complexity in it that makes it harder to audit, harder to spot the subtle
interactions between all these human-error correcting bits of code. The
simpler the code that handles my email, the more likely it is that my
email gets from A to B and doesn't get lost somewhere in the middle. What
you're actually doing is increasing the ability of communication, while
potentially decreasing it for everyone else, and hoping that the changes
you're making won't fail catastrophically where your edge cases occur.
> (That's what I'd like to be like, myself, for that matter ;)
It's rather easier for a human than a computer. :-)
Personally, I'd rather that the default exim configuration shipped as
tightly as it does now, and that Dr. Hazel keeps up the good work in
trying to produce the tightly standards compliant software, and trying
to encourage others not to let the standards slip. If you want to let
the standards slip, as (the other) Greg says, be *fully* aware of what
you're doing. The subtleties of interactions are never obvious.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
