NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/mail/misc/3947

Internet Message Format | 1992-12-13 | 13.6 KB

Xref: sparky comp.mail.misc:3947 comp.mail.uucp:2300
Newsgroups: comp.mail.misc,comp.mail.uucp
Path: sparky!uunet!destroyer!gatech!news.byu.edu!eff!ckd
From: [e-mail] (Christopher Davis)
Subject: Re: Mixed format addresses
In-Reply-To: [e-mail]'s message of Sun, 13 Dec 92 01:22:52 EST
Message-ID: <[e-mail]>
Sender: [e-mail] (NNTP News Poster)
Nntp-Posting-Host: loiosh.eff.org
Organization: Electronic Frontier Foundation Tech Central
References: <6#81H#[e-mail]> <[e-mail]>
Date: Sun, 13 Dec 1992 21:22:57 GMT
Lines: 271

DB> == [e-mail] (David Barr) writes:
WD> == Willard Dawson <[e-mail]>

 WD> Before I start replying to the various points to which David Barr
 WD> takes issue, I'd like to point out (as I've apparently not it clear)
 WD> that I'm not interested in presenting pathalias as being better or
 WD> worse than DNS for email address resolution.  I'm of the opinion that
 WD> neither one, by itself, is sufficient to the task.

This is true, as long as there are sites in the UUCP maps, *somebody* will
have to run pathalias to route mail to them.  (As long as someone cares
enough to want to mail to those sites.)

 WD> One such argument is that pathalias is unwieldy to keep up to date,
 WD> specifically because it uses large amounts of RAM and disk space.  Are
 WD> those the only valuable system or network resources that ought to be
 WD> considered?  Hardly.

Which "valuable system or network resources" does the DNS consume *just* to
be kept up to date?  (Note that, as I said earlier, you pay the cost of
keeping *all* the maps up to date even if you use only a small fraction of
them--this is one of the biggest problems with the maps.)  Nota bene: It
takes about 2 MB on our primary server to maintain primary service for two
forward and three (Class C) reverse domains, as well as secondary for 18(!)
different domains of various sizes.  (And for the primary domains, at
least, we maintain HINFO and the like, as well as the traditional A/MX
info.)

 DB> I suggest you get some real-world experience with the internet mail
 DB> world before you make statements like this that have no factual basis
 DB> whatsoever.

 WD> [...]  I've only made a few comments about mail delivery.  I perceive
 WD> it to be OK, but not nearly as OK as it could be.  Why?  Well, I've
 WD> had PLENTY of experience with failed mail... including mail that has
 WD> bounced because of improper DNS and MX configuration.

And I've had mail to UUCP sites bounce many days later because somebody
forgot to change their map entry, or moved their site to another state and
didn't call their old feed site often enough...

Sure, people can screw up their mailers or their DNS entries.  People can
screw up their map entries, too...but it takes a heck of a lot longer to
fix (it's actually pretty much impossible, because in the DNS stale data
has an expiry time; in the UUCP maps, it doesn't).

 WD> I can envision scenarios, for example, given present growth on the
 WD> Internet, and AROUND it as well, where queries to DNS could exceed
 WD> present day software's capabilities, in much the same way as the
 WD> events that would occur if ~everyone~ tried to call you on the
 WD> telephone at once.  What would happen?  Have you given any thought
 WD> about what would happen to your DNS system if ALL of the Internet
 WD> attempted to query it, simultaneously?

Sure.  It would choke and gag, and queries would start falling over to the
secondary server at UUNET.  Then that would choke and gag, and people would
get the DNS equivalent of EAGAIN, their mailers would queue the mail to try
again later, and life would go on.

The DNS design allows for secondary servers.  The NIC requires at least two
servers, and strongly recommends they be geographically and topologically
separated.  (UUNET suffices for us; if neither us nor UUNET is reachable,
there are big enough problems that nobody will be able to get mail to us
right then *anyway*.)

And remember, the DNS is a caching distributed database; if everyone did a
lookup for eff.org's MXes 50 times a day, they'd only ask *our* nameserver
once per day each; the other 49 queries would go to their local nameserver,
probably on the same machine (or at least the same wire).  So only if
everyone *without entries in their caches* decided to do a lookup
*simultaneously* (or nearly so) would it be a problem.

And even then, things would fail relatively gracefully, at least.

 DB> Which one is easier to update?  (DNS)

 WD> Easier for whom to update?  You (who are on the Internet)?  Those
 WD> whose only connection is by UUCP?  Why can we not have a system that
 WD> is easy for both sets of sites to administer?  Or is it your
 WD> contention that only those with enough wherewithal to warrant a direct
 WD> connection to the Internet ought to have any say in these matters?

To update your DNS entry if you're a UUCP site:

% mail [e-mail]
Subject: please add another site for me

Bob, I added another site in my domain.  Can you please add 'foobar.my.dom'
as an MX pointing through you, and change your mailer entry if need be?
^D

That's assuming you didn't just go forward with a wildcard MX for *.my.dom,
which would mean you'd never have to update it.

How is this "worse" than updating a map entry?  And remember, as soon as
Bob reads his mail and does the fix, you're in the database all over the
world; no waiting for the map coordinators to send out a new map for your
state, and people to run pathalias...

 DB> Which one is more reliable?  (DNS)

 WD> Yet to be proven, IMO.  Perhaps you've got something in mind to offer
 WD> as evidence, rather than just shouting "You've got no Internet
 WD> experience."  Which, BTW, is not true.  I've seen a few examples of
 WD> failed mail, in both DNS and pathalias settings.

Seeing failed mail is not Internet experience.  I've seen lots of failed
mail on both sides of the line, because I run a large mailing list...

 WD> I'd not claim to know, just from seeing a few examples of failed mail,
 WD> that either is worse than the other.  But, maybe I'm missing vital
 WD> information...  someone, please, point me to the correct documents for
 WD> that info?

I can't point you to *documents*, necessarily, but I will point out that
reliability is rarely something read about, more often something experienced.

 WD> What tells me that DNS is not so reliable as at first it might appear
 WD> are the example of incorrect routing I've seen... bounced email with
 WD> "no such host" or "no such domain" when it was damn well true that the
 WD> domain or host did exist, as did nameservers for them.  Mostly, these
 WD> examples are drawn from attempts to reply to email.

But you're not routing with the DNS, are you?  You're routing over the
maps, no?  Yes, sendmail can be misconfigured.  It happens often enough
just from what the vendors ship, after all... but as I've said before, I'm
willing to help folks out.  (Free advice: get IDA sendmail.)

 DB> Which one is faster?  (DNS)

 WD> Faster?  In what context?  Point to point delivery time?  I could
 WD> point you to some very negative examples of DNS routing, that disprove
 WD> that one.

You mean like the folks who send me mail through the UUCP maps, routing it
from a site one hop off the Internet through four or five hosts to here?
The primary MX for a site should be the site "closest" to that site; if
that's not the case, then the person who chose the MXes should choose
again.  Perhaps you could expand on these "very negative examples"?

 WD> Faster to query?  Not.

Are you including the time needed to get the maps and run pathalias?  Or do
those just "happen"?

 WD> Faster for Internet hosts to update?  Yes.  Faster for UUCP connected
 WD> sites to get updated?  Maybe, depending on the sysadmin or map
 WD> moderator in question.

But likely, as your domain server is likely to be closer to you in some
sense (especially if you're a customer of a commercial UUCP provider, in
which case they have much more incentive to update your DNS entry than any
map coordinator ever will to update your map entry).

 DB> Which one is is fat and prone to neglect? (pathalias)

 WD> That is an administrative issue, and does not address the issues I'd
 WD> hoped to discuss.  It's like saying "Nero would make a bad president
 WD> because he's dead."

The very nature of a solution that requires everyone to keep duplicate
copies of information on-line and up to date results in a lack of
scalability and the potential for stale data.  Why do you think the
Internet no longer uses a host table (except in the MILNET backwater)?

 WD> It's true, but it doesn't really address the issue of whether the idea
 WD> of using a database that is accessible to more than just the
 WD> privileged few who happen to be ON the Internet is a good, or the
 WD> best, solution to the problem of routing email.  The METHOD of
 WD> updating the maps is proven unwieldy.  The state of the maps has
 WD> little to do with the effectiveness of pathaliased-routed email.

Sure it does if they're going to get out of date BY THEIR VERY NATURE.

 DB> Which one comes standard with most vendors' flavor of UNIX? (DNS)

 WD> That's not really pertinent to whether the mail delivery daemon on
 WD> most vendor's flavor of UNIX can do mail routing.

Well, for the maps to be kept up to date, you need to:

- get a USENET feed for at least comp.mail.maps
- get a map unpacker
- get pathalias
- buy a new drive to put all this stuff on (1/2 :-)

For your DNS to be up to date, you need to:

- create /etc/resolv.conf
- (optional, SunOS <5.x only) do something about the Yellow Plague

 WD> For example, if you are running the standard flavor of sendmail
 WD> delivered on SunOS, and you are running DNS, with an MX record
 WD> declaring your site as mail forwarder for goofus.atl.ga.us, can you
 WD> easily convince your sendmail to route mail to that site directly?

Since *YOU* are the mail forwarder, then of course *YOU* have to configure
your sendmail to send that to goofus over UUCP.  That can be done with one
line in sendmail.cf, or you can get IDA sendmail and do it with mailertable
(that's what we do here).

 WD> Or, does your sendmail route it back to the site you've declared as
 WD> your mail forwarder?

You're thinking UUCP again, Willard; Internet sites don't declare "mail
forwarders".  (This kind of comment is what David and I are talking about
when we say you lack Internet experience.)  In this case, your sendmail
will bounce it unless you set up your configuration properly.  That's life.

 WD> If you're running AT&T SysVR4, you get attmail... of which I know next
 WD> to nothing.  That's unfortunate, as it has fallen to me to attempt to
 WD> have just such a system forward mail via UUCP to a site with a FQDN.
 WD> OK, we've set up DNS.  We've set up the UUCP connection.  Gee, DNS
 WD> doesn't do it all, does it!?  You mean there's still configurable
 WD> files elsewhere on the SVR4 system that control routing, and that it's
 WD> different from sendmail, and from smail, etc. ?

IF YOU ARE THEIR FORWARDER.  Duh.  The forwarder is responsible for the
special routing, because the MX says "this site will know how to get mail
to foobar.dom.ain.us".  That means *I* have to make sure that my mailer
knows how to route mail to icecube.pinedale.wy.us, and all that you need to
know is "send it to eff.org and they will take care of it".

If you are a "run of the mill" Internet site (like, say, my workstation,
which is not the UUCP machine) you need *NO* special knowledge coded into
your mailer configuration to route mail to MXes.

 WD> The point of all that is that DNS is neat; pathalias is neat.  But
 WD> saying that one or the other is delivered as a standard piece of
 WD> software on one or another flavor of OS avoids the issue of whether
 WD> either alone is more effective than the other at sending email to
 WD> valid addresses.

No, but it does address the issue of "what is a better general solution for
mail routing".

 WD> Neither of those two examples addresses yet another question... how do
 WD> you know that mail sent to a valid address is going to get through to
 WD> that system?  You bloody well don't.  What stands in the way of
 WD> successful mail delivery?  Two sets of problems that I see: wrong or
 WD> missing pathalias entries (caused, no doubt, by obsolete UUCP maps),
 WD> and wrongly configured DNS databases.

Generally the DNS databases are correct, but the mailer configurations are
not.  That is an unfortunate drawback of the most common vendor-supplied
mailers.

 WD> Both of these sets of problems are compounded by the apparent lack of
 WD> support in standard (read, as delivered by system vendors) software
 WD> for fully handling both types of routing.

This is true.

 WD> OK.  I believe I see a problem.  You might not accept that there are
 WD> problems in DNS driven mail delivery, but I've seen enough examples
 WD> that have me convinced.  I'd like to work on potential solutions to
 WD> those problems.  You'd (possibly) like to declare they don't exist.  I
 WD> don't suppose we can work together on this, can we.

I'd like to see these "examples".  I will grant that there are problems.  I
deny that these problems are in "DNS driven mail delivery"; they're in the
mailer configurations most of the time.

I have worked on solving these problems--just ask, say, Larry Snyder.  I
strongly suggest that you get and read the new Nutshell handbook on DNS &
BIND if you want to learn more about the DNS.
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<[e-mail]>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
[phone]  [CKD1]   |   --Peter da Silva <[e-mail]>