Mixed format addresses
daw...@willard.uucp
> In article <BwRgVB...@willard.UUCP> daw...@willard.UUCP writes:
> |They want to be part of the largest net in the world and not accept any
> |responsibility for running it?
>
> Sorry, "they" who? "They" J. Random Internet site? And which net are you
> talking about? The Internet? The unnamed mail network which is the
> combination of all of FidoNet, the Internet, the UUCP network, BITNET, etc...
I was referring to "The" Internet... the one that starts with I and which
attempts to tell everyone what is correct (via RFC documents), and which is
made up of many, many sites that fairly well ignore many of the suggestions
in the RFC's. In particular, I was referring to sites that want Internet
connectivity, and furthermore accept requests for UUCP connections from
those who cannot afford to be directly on the Internet, yet refuse to accept
that it is they (each and every sysadmin of each and every Internet site),
who should make email to and from their UUCP friends WORK.
> |"Have to get permission first?"
> |That's a good idea, I suppose, but I don't recall seeing such in any RFC...
>
> Well, the point is that if you don't ask someone if you can use someone else
> as a gateway, you shouldn't be surprised if they get mad at you when they fin
> out that you're the reason their phone bills just doubled.
So, they should ask THEIR mail feed systems to do filtered mail delivery.
> |People on the Internet can just pick an arbitrary place to send all their
> |UUCP mail... happens all the time...
>
> Can... but shouldn't. Let's say someone picks psuvax1.cs.psu.edu as their
> place to send all their UUCP mail. After all, it used to be a major
> UUCP<>BITNET gateway, and is still listed in the UUCP maps as a reasonably
> well connected site. Since there's no need to ask for permission, just go
> ahead and send your mail, right? Well, it'll most likely get bounced or
> bit-bucketed; psuvax1 stopped doing UUCP gatewaying for anyone outside of
> Penn State's college of science some time ago.
There ought to be a universally available (easily accessible to both UUCP
and Internet connected sites) means of determining which systems are willing
to provide gateway services between the Internet and the "UUCP-net".
> |For what it's
> |worth, I've had mail bounce from Internet->Internet on a "host not found in
> |domain x" error, when it did in fact exist... we're not just talking about
> |the forwarding of UUCP-addressed mail here.
>
> Yes, there are Internet sites which are configured improperly. It's sometime
> hard to get things working well when many vendors ship a 4-year old copy of
> sendmail. That doesn't have much of anything to do with the current discussi
It has everything to do with the discussion. Reasoning for MX over pathalias
includes "it works so much better." Does it really? I don't think so. Why?
Because so many are using old, out-of-date mail delivery software.
> |But, why not have a concept of a "smarthost" for Internet mailers?
>
> Because the whole concept of the DNS was that everyone would get registered,
> if only with an MX. Since registration in the .US domain is free and easy, a
> registering your own domain name is free and slightly more difficult, there's
> no excuse for any UUCP-only site not to have a domain name.
You'll NEVER have the case where EVERYONE is registered in MX. Even so, the
MX system could soon be overwhelmed by the load of systems joining one domain
or another. Perhaps I'll be proven wrong.. but I don't see how this system
of managing email routing is any better (by itself) than pathalias in its
management of system resources or in its ability to properly route email.
> You say that people who call themselves authoritative because they run
> pathalias and can look up MX records are doing a disservice. If they keep
> their UUCP maps up to date, then they are completely authoritative, and the
> concept of a "smart-host" to that system is essentially meaningless - there
> is nothing more authoritative than the UUCP maps for the UUCP pseudo-domain,
> or DNS MX or A records for DNS-registered systems.
>
> Bill
The maps and the MX records are truly authoritative. Convincing Internet
sites that routing to sites in the UUCP pseudo-domain is possible, despite
"no" response from DNS queries, should be an interesting trick. What's
required? IDA-Sendmail, smail, or some other software that does appropriate
mail routing. Are a substantial number of systems that are set up as
DNServers running mail delivery daemons that perform UUCP routing (a la
pathalias)? Is it only my own poor luck to come across several that are
apparently not?
Not. Hence my earlier comments on an apparent lack of responsibility.
Internet sysadmins have not yet been convinced that proper routing of
email is a matter of responsible networking, or they would surely take it
upon themselves to set up sites (which already do name service resolution)
to also perform pathalias routing. Software to do that is available, and
is relatively easy to configure... What's the big deal?
[ Note: The topic has little to do with Waffle, and perhaps would be of
interest to some outside our little circle, so I've added
comp.mail.misc to the newsgroup header, and directed follow-ups
to comp.mail.misc. It does transcend simple discussion of UUCP
mail, yes? ]
--
daw...@willard.UUCP (Willard Dawson)
gatech!vdbsan!willard!dawson
emory!uumind!willard!dawson
Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814
Christopher Davis
WD> == Willard Dawson <daw...@willard.UUCP>
BF> == fen...@postscript.cs.psu.edu (Bill Fenner)
WD> In particular, I was referring to sites that want Internet
WD> connectivity, and furthermore accept requests for UUCP connections
WD> from those who cannot afford to be directly on the Internet, yet
WD> refuse to accept that it is they (each and every sysadmin of each
WD> and every Internet site), who should make email to and from their
WD> UUCP friends WORK.
Every single UUCP neighbor of my site has a domain name. In fact, a
couple of them aren't registered in the UUCP maps; they're just MXed,
and we translate between their UUCP name and domain name before sending
the mail out into the "rest of the world", so nobody should ever *care*
what their UUCP name is.
We do make email to them WORK. I put a fair amount of time into getting
each one set up so that email to them WORKS. The UUCP maps are not the
only way to get email to "WORK".
I do not feel that it is the responsibility of the rest of the Internet
to make sure that the sites I gateway for are reachable. It's *my*
responsibility to see that they're properly registered as an MX record
in the DNS.
BF> Yes, there are Internet sites which are configured improperly.
BF> It's sometime hard to get things working well when many vendors
BF> ship a 4-year old copy of sendmail. That doesn't have much of
BF> anything to do with the current discussi
WD> It has everything to do with the discussion. Reasoning for MX over
WD> pathalias includes "it works so much better." Does it really? I
WD> don't think so. Why? Because so many are using old, out-of-date
WD> mail delivery software.
You know what? They either fix it or lose out. How many sites are
using old UUCP maps? At least with MXes, if you fix your software once,
you're automatically "up to date". People who have non-MX mailers can't
get mail to CompuServe, either (that one was a really useful way to get
some sites to upgrade their mailers). Or AppleLink.
Heck, even Sun ships an MX-capable mailer with 4.x, and this is the same
company that took until 5.0 to put in the all-1s broadcast address...
BF> Because the whole concept of the DNS was that everyone would get
BF> registered, if only with an MX. Since registration in the .US
BF> domain is free and easy, a registering your own domain name is free
BF> and slightly more difficult, there's no excuse for any UUCP-only
BF> site not to have a domain name.
WD> You'll NEVER have the case where EVERYONE is registered in MX.
True. But those who aren't are already becoming an increasingly
marginalized fringe. I have a .BITNET hack in my mailer configuration,
to punt to a local INTERBIT gateway. I have a .UUCP hack, which punts
to a nearby friendly site that takes the time to keep the maps handy.
But I treat that part of the mailer configuration as the hack it is, in
place for user convenience; it's not worth the effort to maintain local
maps just to send mail to sites not in the DNS.
WD> Even so, the MX system could soon be overwhelmed by the load of
WD> systems joining one domain or another. Perhaps I'll be proven
WD> wrong.. but I don't see how this system of managing email routing
WD> is any better (by itself) than pathalias in its management of
WD> system resources or in its ability to properly route email.
It scales. That's why it's better. Do you really care that someone
added a leaf node in East Podunk? Not unless you're sending them email.
So why do you have a map entry for them sent to you every month, stored
on your disk, run through pathalias, and ready for you to send email to
fredsvax, when you could just send mail to fr...@fredsvax.podunk.nd.us,
do an MX lookup, and hand the message off to bigsun.cs.podunk.edu? Is
it really worth the half-K of storage on your disk *just in case* you
want to mail Fred? Especially since you can mail him without it? What
if every adult in Podunk gets their own UUCP site? Will you have a huge
u.usa.nd.* map file around, or would you rather look up the wildcard MX
for *.podunk.nd.us and send it to bigsun, which knows the difference
between fredsvax and bobsmac?
Remember, the DNS is a *distributed* database. Only the domain servers
for a given domain have to have the data on hand; you only get what you
need, when you need it. The 50-odd hosts within the eff.org domain
don't matter to *you* unless you're trying to send mail to one of them,
or ftp there; why should you have to have any data about them at all on
*your* disk?
WD> Hence my earlier comments on an apparent lack of responsibility.
WD> Internet sysadmins have not yet been convinced that proper routing
WD> of email is a matter of responsible networking, or they would
WD> surely take it upon themselves to set up sites (which already do
WD> name service resolution) to also perform pathalias routing.
WD> Software to do that is available, and is relatively easy to
WD> configure... What's the big deal?
Pathalias requires one to get the maps, store the maps, and process the
maps. Care to send me an additional disk to put 'em on? And some spare
CPU to run pathalias with? Oh, and then tell me why I have to have the
main machine up to send you mail...because I'm not putting the UUCP maps
on my workstation.
I just got a full set of UUCP maps from ftp.uu.net as a discussion aid;
they total 7.5MB (as an uncompressed tar file, which at least limits the
losses due to disk block size wastage). That's not counting the
pathalias results file.
The full set of DNS data is impossible to measure; suffice it to say
that it's huge (on the order of 1 million A records for directly
connected hosts, and a number of MXes, CNAMEs, HINFOs, and the like).
And you're saying the *DNS* won't scale properly? The UUCP maps are
already showing signs of scalability problems (not least of which is the
namespace getting full; the extensible nature of the DNS tends to put
exhaustion a LONG way off).
Proper routing of email is a matter of responsible networking. That's
why I make sure I have a mailer that honors MX records. Routing to
non-DNS sites is a useful feature, so I implement it on the good graces
of some neighbor sites.
Getting in the DNS is available, free (for the .US domain), and only
requires an Internet-connected site willing to act as your forwarder.
Many sites currently in the UUCP Zone qualify.
--
Christopher K. Davis | ``Usenet seems to run much like the Kif (or,
<c...@eff.org> EFF #14 | for the TV generation, Klingon) high command.
System Administrator, EFF | Whoever takes action and can be heard wins.''
+1 617 864 0665 [CKD1] | --Peter da Silva <pe...@ferranti.com>
Bill Fenner
|In particular, I was referring to sites that want Internet
|connectivity, and furthermore accept requests for UUCP connections from
|those who cannot afford to be directly on the Internet, yet refuse to accept
|that it is they (each and every sysadmin of each and every Internet site),
|who should make email to and from their UUCP friends WORK.
Ok, wait, let me get this straight. You say that site foo.bar.edu accepts
a UUCP connection to your site, and therefore that makes me, at
cmf.nrl.navy.mil, responsible for being able to get mail to you? Uh-uh.
If you want to look like part of the Internet, then get a domain name. If
you don't want to play by the (easy and free) rules, then don't complain
that the game's no fun.
|> Well, the point is that if you don't ask someone if you can use someone else
|> as a gateway, you shouldn't be surprised if they get mad at you when they fin
|> out that you're the reason their phone bills just doubled.
|
|So, they should ask THEIR mail feed systems to do filtered mail delivery.
Huh? The Internet isn't store-and-forward like UUCP; for the most
part, anyway. If I want to send mail to foo.bar.edu, I'll open a
connection to foo.bar.edu (or mail.bar.edu, if they have an MX record)
and send it. Who's going to do the filtering?
|There ought to be a universally available (easily accessible to both UUCP
|and Internet connected sites) means of determining which systems are willing
|to provide gateway services between the Internet and the "UUCP-net".
I'm not arguing that there shouldn't be. I'm just saying that there
isn't now [that I know of]. It's not the data in the UUCP maps - 3 of
the 7 sites that I asked about their entries in d.Top responded. Two
said that the entry was deprecated cruft (one of them said he barely
had any UUCP connections at all any more), and one said they would
route mail if I was a customer.
(This, btw, is the biggest problem with the UUCP maps. Some of the
data is so ancient that there's no way it's current. Not usually a
problem with the DNS; since the DNS is a distributed database, you can
be easily in charge of your little section, as opposed to having to
mail your database updates to central site X.)
|It has everything to do with the discussion. Reasoning for MX over pathalias
|includes "it works so much better." Does it really? I don't think so. Why?
|Because so many are using old, out-of-date mail delivery software.
The same people who are using old, out-of-date mail delivery software
are the same ones who are likely to use old, out-of-date pathalias
data. At least, with the DNS, once you get it right, there's almost no
way to use out-of-date info. With the UUCP maps, it's easy for
automated unpacking systems to break, sysadmin doesn't notice, *poof*,
you're using old data.
|You'll NEVER have the case where EVERYONE is registered in MX.
You mean the DNS. Why not? That was the original design goal.
|Even so, the MX system could soon be overwhelmed by the load of systems
|joining one domain or another.
The DNS is a distributed, scalable database. The UUCP maps are significantly
more likely to get overwhelmed by numbers of systems than the DNS is.
|I don't see how this system
|of managing email routing is any better (by itself) than pathalias in its
|management of system resources or in its ability to properly route email.
Using the DNS, I have no need to store any information about anyone on
my computer; I can just look it up. Using the UUCP maps, I have to keep
6.7 megs of map files, and a 1.6 meg (33k line) paths file. Which seems
like the more desirable system?
|The maps and the MX records are truly authoritative. Convincing Internet
|sites that routing to sites in the UUCP pseudo-domain is possible, despite
|"no" response from DNS queries, should be an interesting trick.
Well, all you need is a site that is willing to be a gateway for you, which
is where we seem to have started this conversation.
|Hence my earlier comments on an apparent lack of responsibility.
|Internet sysadmins have not yet been convinced that proper routing of
|email is a matter of responsible networking, or they would surely take it
|upon themselves to set up sites (which already do name service resolution)
|to also perform pathalias routing.
It makes no sense for an Internet-only site to run pathalias; the maps are
of no use for them. Therefore, the site must find a way from the Internet
to UUCP. The easiest way for it to do that is an MX record.
Why not register in the .US domain? It's free, easy, and will let you get
E-Mail from the Internet with no trouble. The .UUCP pseudo-domain is an
old hack that should have disappeared years ago. That's the problem with
"transitionary" hacks, though - they never go away...
Bill
Zbigniew J. Tyrlik
And I will support Bill quite strongly.
+---------------
> In article <eBmLVB...@willard.UUCP> daw...@willard.UUCP writes:
> |In particular, I was referring to sites that want Internet
> |connectivity, and furthermore accept requests for UUCP connections from
> |those who cannot afford to be directly on the Internet, yet refuse to accept
> |that it is they (each and every sysadmin of each and every Internet site),
> |who should make email to and from their UUCP friends WORK.
What ? Are you saying that cuz I am on internet, I should bother
about bozoo 2 hops from me, who is using some weirdo setup with
old data ???
>
> Ok, wait, let me get this straight. You say that site foo.bar.edu accepts
> a UUCP connection to your site, and therefore that makes me, at
> cmf.nrl.navy.mil, responsible for being able to get mail to you? Uh-uh.
> If you want to look like part of the Internet, then get a domain name. If
> you don't want to play by the (easy and free) rules, then don't complain
> that the game's no fun.
>
Bill is right. I am on Internet; I do feed 30+ uucp only sites; I
do gateway mail for them. Each of the sites is encouraged to use
FQDN in my domain; I do keep MX record for them, and I do maintain
it.
> |There ought to be a universally available (easily accessible to both UUCP
> |and Internet connected sites) means of determining which systems are willing
> |to provide gateway services between the Internet and the "UUCP-net".
>
Guys in Ohio started it, using relay approach - each site which
gateways mail, is using as an alias OARnet-relay; thus, sites
running pathalias will find always nearest gateway.
> (This, btw, is the biggest problem with the UUCP maps. Some of the
> data is so ancient that there's no way it's current. Not usually a
> problem with the DNS; since the DNS is a distributed database, you can
> be easily in charge of your little section, as opposed to having to
> mail your database updates to central site X.)
Point well taken.
> |Even so, the MX system could soon be overwhelmed by the load of systems
> |joining one domain or another.
>
> The DNS is a distributed, scalable database. The UUCP maps are significantly
> more likely to get overwhelmed by numbers of systems than the DNS is.
>
Well, full run of pathalias and someadditional massaging I perform
on pathalias database to shorten routing over Internet, on 486/33
machine with 16MB takes... an hour. Pathalias grows up to 1MB
size in memory. It is a huge load. On the other side, I do run
primary namesrever for my domain; I do not feel the load of it.
> |Hence my earlier comments on an apparent lack of responsibility.
> |Internet sysadmins have not yet been convinced that proper routing of
> |email is a matter of responsible networking, or they would surely take it
> |upon themselves to set up sites (which already do name service resolution)
> |to also perform pathalias routing.
I belive you are reversing order; Internet sites are quite happy
with themselves; it is uucp-only sites who want to get quicker
mail delivery, and who should catch on.
>
> Why not register in the .US domain? It's free, easy, and will let you get
> E-Mail from the Internet with no trouble. The .UUCP pseudo-domain is an
> old hack that should have disappeared years ago. That's the problem with
> "transitionary" hacks, though - they never go away...
>
> Bill
Correct. Luckilly, there is more and more domain parks growing up,
with one site acting as gateway. At least that is what is
happening in Cleveland.
regards,
and for every UUCp-addicted site: make your own life easier;
get a friend and register !
_zjt
--
********************************************************************
Zbigniew J. Tyrlik DoD# 0759 VF700C '84 zb...@wariat.org
IBM PC SIG Sysop - Cleveland Free-Net aa...@cleveland.freenet.edu
APK Public Access UNI* Cleveland, (216)-481-9436
Feeds, shell, FTP & telnet access Uniboard distribution point
********************************************************************
Zbigniew J. Tyrlik
+---------------
> I can envision scenarios, for example, given present growth on the Internet,
> and AROUND it as well, where queries to DNS could exceed present day software's
> capabilities, in much the same way as the events that would occur if ~everyone~
> tried to call you on the telephone at once. What would happen? Have you given
> any thought about what would happen to your DNS system if ALL of the Internet
> attempted to query it, simultaneously?
>
You forgot about secondary nameservers, and the fact that usually
all editions of named do cache adresses... The only one case of it
will be if if all machines will come up at once, and all will want
to send you mail at once...
> > Which one is easier to update? (DNS)
>
> Easier for whom to update? You (who are on the Internet)? Those whose
> only connection is by UUCP? Why can we not have a system that is easy
Either you do not understand DNS, or are simply joking. For a site
which is uucp only connected, and has a FQDN, it is enough to set
it once forever... done. For a Internet based site, it is easier
for me to update my own edition of DNS, and from this monet every
quesry will get updated version. With pathalias - propagation time
of maps is quite long, and we have had multiple occurences of maps
going to /dev/null. Claiming that updating maps is easier is
funny.
>
> What tells me that DNS is not so reliable as at first it might appear are
> the example of incorrect routing I've seen... bounced email with "no such
> host" or "no such domain" when it was damn well true that the domain or
> host did exist, as did nameservers for them. Mostly, these examples are
> drawn from attempts to reply to email.
Usually it comes to the point that site unable to respond was
configured totally wrong... like only local nameservers...
> of whether the idea of using a database that is accessible to more than
> just the privileged few who happen to be ON the Internet is a good, or
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
you must be kidding, man ... priviledged few on Internet...
Are you aware that number of hosts on Internet is a magnitute
bigger that hosts with uucp only connections ???
> --
> daw...@willard.UUCP (Willard Dawson)
> gatech!vdbsan!willard!dawson
> emory!uumind!willard!dawson
> Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814
Sorry, Willard - your bias against Internet is quite
interesting...
Christopher Davis
WD> == Willard Dawson <daw...@willard.UUCP>
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 hostm...@my.dns.server.site
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.
jim_shirreffs
I didn't really didn't follow that discussion but it sounds like you are the right
people to tell me how to set my home Unix system mail routining (UUCP).
I'm running SVR4. Right now I just make and entry into my System file to get
mail access to that system. I know this is not the right way to do things.
What is?
Thanks in advance.
jim shirreffs (I wish I knew more)
John Stanley
>In article <eBmLVB...@willard.UUCP> daw...@willard.UUCP writes:
>If you want to look like part of the Internet, then get a domain name. If
>you don't want to play by the (easy and free) rules, then don't complain
>that the game's no fun.
What easy and free rule says that UUCP sites have to look like part of
the Internet?
>|There ought to be a universally available (easily accessible to both UUCP
>|and Internet connected sites) means of determining which systems are willing
>|to provide gateway services between the Internet and the "UUCP-net".
>
>I'm not arguing that there shouldn't be. I'm just saying that there
>isn't now [that I know of].
Sigh.
>It's not the data in the UUCP maps - 3 of
>the 7 sites that I asked about their entries in d.Top responded. Two
>said that the entry was deprecated cruft (one of them said he barely
>had any UUCP connections at all any more),
Guess whose responsibility it is for notifying the uucp mapping project
that a map file is wrong? No, it isn't the uucp mapping project's. It is
the site who believes his entry in the file is "deprecated cruft".
>and one said they would route mail if I was a customer.
The same one who will route mail even if you aren't a customer.
>Not usually a
>problem with the DNS; since the DNS is a distributed database, you can
>be easily in charge of your little section, as opposed to having to
>mail your database updates to central site X.)
I can be in charge of my "little section" of the DNS? Really? From a
UUCP site? Just what protocol do YOU know of that will allow a UUCP
site to change the DNS records for its MX site?
>With the UUCP maps, it's easy for
>automated unpacking systems to break, sysadmin doesn't notice, *poof*,
>you're using old data.
With the DNS, it is easy to poke incorrect data into the database and
*poof* EVERYONE is using bogus data.
>|You'll NEVER have the case where EVERYONE is registered in MX.
>
>You mean the DNS. Why not? That was the original design goal.
For someone who is adamant that nothing in the UUCP maps could possibly
apply to Internet sites, why this sudden compulsion that MX records
must apply to UUCP sites?
>Using the DNS, I have no need to store any information about anyone on
>my computer;
Really?
>I can just look it up.
And just, pray tell, if you keep no information about anyone in your
computer, who do you talk to to look it up?
>Using the UUCP maps, I have to keep
>6.7 megs of map files, and a 1.6 meg (33k line) paths file. Which seems
>like the more desirable system?
Or you keep a <30 character name of a site that will gateway traffic.
That sounds most desirable.
>It makes no sense for an Internet-only site to run pathalias; the maps are
>of no use for them. Therefore, the site must find a way from the Internet
>to UUCP. The easiest way for it to do that is an MX record.
To do that reliably requires one MX record for every UUCP site. Passing
mail to a gateway requires knowing one address. The latter sure seems to
be much simpler than trying to get every UUCP in the world to register
in a voluntary database. It is, however, less simple that expecting them
to.
Bill Fenner
|In article <Bz4xx...@cs.psu.edu> fen...@postscript.cs.psu.edu (Bill Fenner) writes:
|>If you want to look like part of the Internet, then get a domain name. If
|>you don't want to play by the (easy and free) rules, then don't complain
|>that the game's no fun.
|
|What easy and free rule says that UUCP sites have to look like part of
|the Internet?
If you want to send mail to and receive mail from the Internet, then you should
look like part of the Internet, or you should not be surprised when you can't
get mail back from the Internet. This seems to me to be common sense.
|>It's not the data in the UUCP maps - 3 of
|>the 7 sites that I asked about their entries in d.Top responded. Two
|>said that the entry was deprecated cruft (one of them said he barely
|>had any UUCP connections at all any more),
|
|Guess whose responsibility it is for notifying the uucp mapping project
|that a map file is wrong? No, it isn't the uucp mapping project's. It is
|the site who believes his entry in the file is "deprecated cruft".
I didn't suggest that it was the uucp mapping project's fault for not knowing
that the entries were wrong. I just said that the entries were wrong. Do
you really think it's a good idea to suggest using a source where nearly
half the data is verifiably wrong?
|>and one said they would route mail if I was a customer.
|
|The same one who will route mail even if you aren't a customer.
This is irrelevant. Just beacuse they have not installed filters yet doesn't
mean that they won't. Their policy is, apparently, that they won't route
mail for non-customers, so if you're depending on breaking that policy, don't
be surprised when your mail all disappears one day.
|I can be in charge of my "little section" of the DNS? Really? From a
|UUCP site? Just what protocol do YOU know of that will allow a UUCP
|site to change the DNS records for its MX site?
mail hostm...@otc2.psu.edu
Hey, Steve, would you please add an MX record for:
foo.redbeard.com. IN MX 20 cs.psu.edu.
Thanks,
Bill
^D
|With the DNS, it is easy to poke incorrect data into the database and
|*poof* EVERYONE is using bogus data.
For the part of the DNS that you are responsible for. Big deal. I can
put a connection to uunet, with 0 cost, in my map entry, and then rm
/usr/spool/uucp/uunet/* every night. Which would screw more people up?
For me to say "bogus.redbeard.com. IN MX 20 zing.zang.no.such.host." or
"hogbbs uunet(0)"?
|>You mean the DNS. Why not? That was the original design goal.
|
|For someone who is adamant that nothing in the UUCP maps could possibly
|apply to Internet sites, why this sudden compulsion that MX records
|must apply to UUCP sites?
I didn't say anything about MX records applying to UUCP sites. I said that
the original design goal of the DNS was that everyone would have a domain
name. I also don't see the leap you took between saying that the UUCP maps
have nothing to do with Internet mail routing and that sites that are
contactable via UUCP should register in the DNS. Those two statements are
orthogonal, I don't see why you think they're contradictory.
|>Using the DNS, I have no need to store any information about anyone on
|>my computer; I can just look it up.
|
|And just, pray tell, if you keep no information about anyone in your
|computer, who do you talk to to look it up?
Ever so sorry; I need to store one IP address of a name server.
|Or you keep a <30 character name of a site that will gateway traffic.
|That sounds most desirable.
Sure, except that there's no good way of finding such a site.
|Passing
|mail to a gateway requires knowing one address. The latter sure seems to
|be much simpler than trying to get every UUCP in the world to register
|in a voluntary database. It is, however, less simple that expecting them
|to.
But there's no good way to find such a gateway. The UUCP maps are no good;
even if that is the intention of the data in d.Top, the data is bogus.
Bill
Christopher Davis
JS> == John Stanley <sta...@skyking.OCE.ORST.EDU>
BF> If you want to look like part of the Internet, then get a domain name.
BF> If you don't want to play by the (easy and free) rules, then don't
BF> complain that the game's no fun.
JS> What easy and free rule says that UUCP sites have to look like part of
JS> the Internet?
None. But if they *do* want to look like part of the Internet, they should
do so, instead of whining about how Internet sites "must" support pathalias
and the .UUCP hack.
BF> Not usually a problem with the DNS; since the DNS is a distributed
BF> database, you can be easily in charge of your little section, as
BF> opposed to having to mail your database updates to central site X.)
JS> I can be in charge of my "little section" of the DNS? Really? From a
JS> UUCP site? Just what protocol do YOU know of that will allow a UUCP
JS> site to change the DNS records for its MX site?
Email, or telephone. Or even having an account on your DNS server's
machine so you can make the updates yourself. Who do you think will be
more responsive, your (single) DNS site, or the map coordinators *and*
everyone everywhere who uses the maps?
BF> With the UUCP maps, it's easy for automated unpacking systems to
BF> break, sysadmin doesn't notice, *poof*, you're using old data.
JS> With the DNS, it is easy to poke incorrect data into the database and
JS> *poof* EVERYONE is using bogus data.
And pretty soon you notice that EVERYONE is failing to get you mail, so
someone called your Zone Contact and told them to fix the zone. If only
30% of the UUCP map people can't get you mail, you may never notice.
BF> You mean the DNS. Why not? That was the original design goal.
JS> For someone who is adamant that nothing in the UUCP maps could possibly
JS> apply to Internet sites, why this sudden compulsion that MX records
JS> must apply to UUCP sites?
Who said MX records "must" apply to UUCP sites? They can sit out there in
the maps, and maybe I can get mail to them. They can get in the DNS and
improve their chances. It's up to them.
BF> Using the DNS, I have no need to store any information about anyone on
BF> my computer; I can just look it up.
JS> And just, pray tell, if you keep no information about anyone in your
JS> computer, who do you talk to to look it up?
The root name servers are not "about anyone".
BF> Using the UUCP maps, I have to keep 6.7 megs of map files, and a 1.6
BF> meg (33k line) paths file. Which seems like the more desirable
BF> system?
JS> Or you keep a <30 character name of a site that will gateway traffic.
JS> That sounds most desirable.
And *they* keep the maps and path files. At least until *they* get tired
of doing it, and find another "smarthost". Who gets sick of routing, and...
Every site that *does routing* with the UUCP maps has to keep them around.
With the DNS, sites can do routing without keeping the entire DNS on their
local disk (or even local net).
BF> It makes no sense for an Internet-only site to run pathalias; the maps
BF> are of no use for them. Therefore, the site must find a way from the
BF> Internet to UUCP. The easiest way for it to do that is an MX record.
JS> To do that reliably requires one MX record for every UUCP site.
It does? You've never heard of wildcard MX records, I see.
JS> Passing mail to a gateway requires knowing one address.
Until that gateway changes, goes away, gets out of sync with the maps...
JS> The latter sure seems to be much simpler than trying to get every UUCP
JS> in the world to register in a voluntary database.
The UUCP maps are not a "voluntary database"?
JS> It is, however, less simple that expecting them to.
I don't expect every UUCP site in the world to be in the DNS. I do expect
those that want to be more reachable from Internet sites to do so.
John Stanley
>BF> == fen...@postscript.cs.psu.edu (Bill Fenner) writes:
>JS> == John Stanley <sta...@skyking.OCE.ORST.EDU>
>But if they *do* want to look like part of the Internet, they should
>do so, instead of whining about how Internet sites "must" support pathalias
>and the .UUCP hack.
I have seen nobody "whining" about how Internet sites "must" do anything.
> BF> database, you can be easily in charge of your little section, as
>
> JS> I can be in charge of my "little section" of the DNS? Really? From a
> JS> UUCP site? Just what protocol do YOU know of that will allow a UUCP
> JS> site to change the DNS records for its MX site?
>
>Email, or telephone.
Neither of these puts me in charge of my little section of the DNS. They
put me in contact with someone else, who is in charge of my little
section. Not the same thing.
>Or even having an account on your DNS server's
>machine so you can make the updates yourself.
Oh boy, an account where I can access system files and make changes.
Internet admins who give priveleged accounts to their UUCP connections
are asking for trouble. And the first place they will see it is in their
DNS records when UUCP-user forgets to update the serial number or puts a
goofy date in the file. Or when two UUCP-users try to update the same
file at the same time.
> JS> With the DNS, it is easy to poke incorrect data into the database and
> JS> *poof* EVERYONE is using bogus data.
>
>And pretty soon you notice that EVERYONE is failing to get you mail,
Pretty soon? This implies that I know that someone else sent me mail,
and I am not quite sure how I am supposed to know that unless the mail
gets through to tell me that.
>someone called your Zone Contact and told them to fix the zone.
If you really think that Joe Internet User even knows there is a Zone
Contact, much less would call him when his mail doesn't get through, you
are wrong.
>If only
>30% of the UUCP map people can't get you mail, you may never notice.
And if 100% of the Internet can't get me mail, I may never notice.
Or it will take a while, perhaps.
> BF> Using the DNS, I have no need to store any information about anyone on
> BF> my computer; I can just look it up.
>
> JS> And just, pray tell, if you keep no information about anyone in your
> JS> computer, who do you talk to to look it up?
>
>The root name servers are not "about anyone".
Sigh. You must keep something that tells you who a root nameserver is.
That is, indeed, keeping some information about someone.
> BF> Using the UUCP maps, I have to keep 6.7 megs of map files, and a 1.6
> BF> meg (33k line) paths file. Which seems like the more desirable
> BF> system?
>
> JS> Or you keep a <30 character name of a site that will gateway traffic.
> JS> That sounds most desirable.
>
>And *they* keep the maps and path files.
Yes.
>At least until *they* get tired
>of doing it, and find another "smarthost". Who gets sick of routing, and...
I haven't seen the list of gateways change in a long time.
>Every site that *does routing* with the UUCP maps has to keep them around.
The complaint was that "I" have to keep them around. "YOU" don't.
>With the DNS, sites can do routing without keeping the entire DNS on their
>local disk (or even local net).
And sites can do routing without keeping the entire UUCP maps on their
local disk, or even local net.
> JS> To do that reliably requires one MX record for every UUCP site.
>
>It does? You've never heard of wildcard MX records, I see.
Yes, I have heard of wildcards. I have one. Change the "one" to "an",
if you wish. It is still not a reasonable expectation for every UUCP
site to have an MX record, whether it is its own or part of a
wildcard.
Leslie Mikesell
>>If you want to look like part of the Internet, then get a domain name. If
>>you don't want to play by the (easy and free) rules, then don't complain
>>that the game's no fun.
>What easy and free rule says that UUCP sites have to look like part of
>the Internet?
Rules don't have much to do with it, but if you would like most sites
to be able to reply to your mail you need a domain name. When mail
is gatewayed among differing systems (uucp, internet, bitnet, etc.)
the return path is often damaged such that a reply is not possible
using the reverse routing information. If you have a domain name,
the routing doesn't have to be maintained in the message.
>I can be in charge of my "little section" of the DNS? Really? From a
>UUCP site? Just what protocol do YOU know of that will allow a UUCP
>site to change the DNS records for its MX site?
Wild-card MX records allow this. All you have to do is maintain one
stable site to act as the gateway and have a forwarder deliver there.
For example, uunet handles MXing and forwarding for the domain *.fb.com,
delivering it to uucp site "afbf05". As it happens, my mailer uses
fb.com as the name for all our machines and does an alias lookup to
find the right machine for delivery to each user, but if I wanted I
could let addresses go out with subdomains of .fb.com as long as my gateway
machine knows where to send the reply.
>>|You'll NEVER have the case where EVERYONE is registered in MX.
>>You mean the DNS. Why not? That was the original design goal.
Personally, I think that unrealistic goals are a sign of a bad design
and more effort should have been put into encapsulating addresses from
incompatible systems so the imbedded routing information could be
used. But that's kind of irrelevant at this point...
>>It makes no sense for an Internet-only site to run pathalias; the maps are
>>of no use for them. Therefore, the site must find a way from the Internet
>>to UUCP. The easiest way for it to do that is an MX record.
>To do that reliably requires one MX record for every UUCP site. Passing
>mail to a gateway requires knowing one address. The latter sure seems to
>be much simpler than trying to get every UUCP in the world to register
>in a voluntary database. It is, however, less simple that expecting them
>to.
It could be really simple: each site that gateways onto the internet could
maintain a wild-card MX so sites using that gateway would automatically
have a return address under the DNS. A little IDA sendmail header rewriting
magic could even make it happen automatically. However, sites typically
don't want to lend their domain names to everyone who forwards mail through
them because there are usually other things associated with the name. And
it's extra work for someone to register another name and set up the MX
so it doesn't get done except within organizations where someone is paid
to do it or in domain parks where a group of users understand the problem
and make the effort to fix it.
Les Mikesell
l...@chinet.chi.il.us
Bill Fenner
|In article <CKD.92De...@loiosh.eff.org> c...@eff.org (Christopher Davis) writes:
|>Or even having an account on your DNS server's
|>machine so you can make the updates yourself.
|
|Oh boy, an account where I can access system files and make changes.
No, an account where the single file for your domain is owned by you.
There could even be a script to make sure that the serial number gets
updated properly. No problem.
|>At least until *they* get tired
|>of doing it, and find another "smarthost". Who gets sick of routing, and...
|
|I haven't seen the list of gateways change in a long time.
That seems to be because nobody cares about the list you're looking
at. As I've said, 2 of the 3 people who responded to my queries said
they didn't really belong on the list. The third said that they only
want to route for you if you're a customer, and the other 4 didn't care
enough about it to respond to my query.
Bill
John Stanley
>In article <1gg7ee...@gaia.ucs.orst.edu> sta...@skyking.OCE.ORST.EDU (John Stanley) writes:
>
>the original design goal of the DNS was that everyone would have a domain
>name.
Including UUCP sites. Register in the .us domain and get an MX record, I
believe, is your opinion of the entire problem of gatewaying to UUCP. If
not, it is a very close approximation.
>|>Using the DNS, I have no need to store any information about anyone on
>|>my computer; I can just look it up.
>|
>|And just, pray tell, if you keep no information about anyone in your
>|computer, who do you talk to to look it up?
>
>Ever so sorry; I need to store one IP address of a name server.
One IP address for a gateway.
John Stanley
>In article <1gg7ee...@gaia.ucs.orst.edu> sta...@skyking.OCE.ORST.EDU (John Stanley) writes:
>Yes.
>>Just what protocol do YOU know of that will allow a UUCP site to change the
>>DNS records for its MX site?
>mail hostm...@my.mx.dom.ain
And if hostmaster is on vacation? If he doesn't feel like doing it this
week?
Mail is hardly "being in charge" of anything.
>And guess what, if you were to update your UUCP map entry, you'd have to
>do something similar anyway.
So? I haven't claimed otherwise. All I am trying to do is counter the
silly claim that anyone can be in charge of their part of the DNS.
Christopher Davis
Y'know, it'd be nice if your news software maintained References:...
ckd> But if they *do* want to look like part of the Internet, they should
ckd> do so, instead of whining about how Internet sites "must" support
ckd> pathalias and the .UUCP hack.
JS> I have seen nobody "whining" about how Internet sites "must" do anything.
Willard, for one, appears to be insisting that Internet sites keep
up-to-date pathalias maps around so they can route to .UUCP sites. And his
posts have sounded a bit whiny to me.
JS> Neither of these puts me in charge of my little section of the DNS.
JS> They put me in contact with someone else, who is in charge of my
JS> little section. Not the same thing.
Then my boss isn't really in charge of the machines at my site, because he
has to go through one of the sysadmins to make a configuration change?
ckd> Or even having an account on your DNS server's machine so you can
ckd> make the updates yourself.
JS> Oh boy, an account where I can access system files and make changes.
Have you looked at the BIND configuration setup lately? Normally each zone
is stored in a separate file. It is trivial to set up the configuration so
that, say, the zone file for "johnstanley.com" is /home/stanley/js.com.zone.
JS> Internet admins who give priveleged accounts to their UUCP connections
JS> are asking for trouble.
See above. Having the ability to edit a specific file doth not a
privileged account make (unless the specific file really *is* a system
file, which BIND zone files most definitely are not).
Admittedly, this means that the change is less than instant, unless a
setuid program is provided to send a HUP signal to the named. (Obviously a
crontab entry to HUP the named nightly would be another solution.) Of
course, such programs are easily written, made group-executable, and
installed, in order to give the proper "feeling of control" to people like
you.
JS> And the first place they will see it is in their DNS records when
JS> UUCP-user forgets to update the serial number or puts a goofy date in
JS> the file.
For the UUCP user's zone. Either they control it (meaning they have the
power to screw it up), or they don't (where they can ask for changes, and
hope the other guy doesn't screw it up :).
Sure, if the Internet admin gave the UUCP-user access to all the zone
files, then he's either trusting or stupid (or both). But that's not
necessary, except perhaps in building strawman arguments.
JS> Or when two UUCP-users try to update the same file at the same time.
If they share a domain, they should figure out which one of them keeps the
file up to date. If they can't figure that out, they shouldn't share a
domain, then...
ckd> And pretty soon you notice that EVERYONE is failing to get you mail,
JS> Pretty soon? This implies that I know that someone else sent me mail,
JS> and I am not quite sure how I am supposed to know that unless the mail
JS> gets through to tell me that.
If no mail arrives at this site for an hour, something's wrong. Your site
may vary. If *nobody* sends you mail, don't you wonder why?
ckd> someone called your Zone Contact and told them to fix the zone.
JS> If you really think that Joe Internet User even knows there is a Zone
JS> Contact, much less would call him when his mail doesn't get through,
JS> you are wrong.
No, Joe Internet User (at least *my* users) will ask me "why did this
bounce?" I'll also see the headers of the bounce, so I can note that the
address looks right (wasn't "skyking.ece.orst.edy" or the like) and check
it out with nslookup or DiG. If necessary, *I* call the ZC.
JS> And if 100% of the Internet can't get me mail, I may never notice. Or
JS> it will take a while, perhaps.
I'm sorry that you get so little mail. I tend to believe that the
wider-ranging the outage, the more likely it is to be noticed.
JS> Sigh. You must keep something that tells you who a root nameserver is.
JS> That is, indeed, keeping some information about someone.
Yes. And how often do they change? Not very (and even when they do, most
of them stay the same; I'm sure many folks still have SRI-NIC.ARPA in their
root cache files, but terp is still there, for example...).
The best part, of course, is that you can query any of them for an
up-to-date list; I usually just type something on the order of
"dig . ns +aa @some.root.server > /var/domain/root.cache"
every few months or so (in case I miss the multiple postings that have
marked every recent change).
JS> And sites can do routing without keeping the entire UUCP maps on their
JS> local disk, or even local net.
That's not doing routing. That's doing punting.
JS> Yes, I have heard of wildcards. I have one. Change the "one" to "an",
JS> if you wish. It is still not a reasonable expectation for every UUCP
JS> site to have an MX record, whether it is its own or part of a
JS> wildcard.
However, it is a reasonable expectation for a site that wishes to be
reachable by Internet sites to use the Internet-standard method for
registering a mail gateway. The fact that many sites support the .BITNET
and .UUCP hacks is merely a courtesy to those sites that, for whatever
reason, are not in the DNS.
Marc Unangst
>put me in contact with someone else, who is in charge of my little
>section. Not the same thing.
And from what you're saying, you don't really want to be in charge of
your own little section of the DNS because it's too much trouble to do
correctly.
So, register in the .US domain, where there are nice people at ISI to
take care of the nitty-gritty details for you.
>> JS> With the DNS, it is easy to poke incorrect data into the database and
>> JS> *poof* EVERYONE is using bogus data.
With the UUCP maps, it's just as easy to poke the incorrect data into
the database, except once it's in there it becomes a lot more
difficult to remove. How many sites out there are still using
outdated versions of the maps?
The UUCP maps are a lot less deterministic when it comes to routing.
If I want to make sure that all mail for machine A gets sent through
machine B, where machine A talks to around 15 different sites, I have
to play games with the costs in machine B's map or in the maps of all
the other sites machine A talks to. And if one of them puts too low
of a cost for machine A in their map, the mail will get misrouted for
the next month.
>Sigh. You must keep something that tells you who a root nameserver is.
>That is, indeed, keeping some information about someone.
Okay, so the root nameservers is "someone". I still think it's a lot
more reliable and efficient to store 32 bits of information on each of
a dozen machines -- especially when that data changes very rarely --
than it is to store 500 bytes or so of data on each of thousands of
hosts.
>if you wish. It is still not a reasonable expectation for every UUCP
>site to have an MX record, whether it is its own or part of a
>wildcard.
I disagree. Registering in the .US domain is no more difficult than
registering in the UUCP maps, and you won't even have to find another
machine to connect to if you're already talking to an
Internet-connected machine who is willing to forward mail for you. If
you don't feel like doing that you can always pay UUNET or MSEN $35 to
register your domain for you.
--
Marc Unangst, N8VRH | "Of course, in order to understand this you
m...@mudos.ann-arbor.mi.us | have to remember that the nucleus of the atom
| is squishy."
| -W. Scheider, from a Physics lecture
daw...@willard.uucp
to tell you (that's the generic, plural you, BTW) that it doesn't have
some very nice properties. I am trying to tell you of some problems I've
had due to failed mail. Failure to find a route for delivery of mail,
when routes do indeed exist, point to limitations in the software.
I propose that a solution to routing mail could be arrived at that has
a higher degree of success than is currently the case with either DNS
or pathalias routing alone.
Blindly screaming "DNS has this, this, and that, so it must be better"
doesn't do much for me. Comparisons against alternative routing techniques
are helpful. It's a shame that the best we can seem to come up with for
such comparisons is pathalias.
zb...@wariat.org (Zbigniew J. Tyrlik) writes:
> > Easier for whom to update? You (who are on the Internet)? Those whose
> > only connection is by UUCP? Why can we not have a system that is easy
>
> Either you do not understand DNS, or are simply joking. For a site
> which is uucp only connected, and has a FQDN, it is enough to set
> it once forever... done.
Ok. How, then is this different than registration in the UUCP mapping
project? For each site for which you agree to forward mail, you must
re-edit your configuration file. That corresponds exactly to the update
process for the UUCP maps, meaning that for each new connection, a forward-
ing site should send in one update.
So, perhaps that "update it once and forget it" idea doesn't count as an
advantage of DNS over pathalias routing.
> For a Internet based site, it is easier for me to update my own edition
> of DNS, and from this monet every quesry will get updated version.
Yes, it is nice that DNS gets propagated so quickly. Did I ever say that
was bad?
> With pathalias - propagation time of maps is quite long, and we have had
> multiple occurences of maps > going to /dev/null. Claiming that updating
> maps is easier is funny.
I never claimed that updating the UUCP maps was easier, nor that it is
more effective, than updating name servers, for Internet connected sites.
My claim is that neither is as good as we could have.
> > What tells me that DNS is not so reliable as at first it might appear are
> > the example of incorrect routing I've seen... bounced email with "no such
> > host" or "no such domain" when it was damn well true that the domain or
> > host did exist, as did nameservers for them. Mostly, these examples are
> > drawn from attempts to reply to email.
>
> Usually it comes to the point that site unable to respond was
> configured totally wrong... like only local nameservers...
Yes, and it happens with an amazing regularity. That only said that you
still have to deal with operator error. No system will be immune to it,
but you can attempt to minimize the effects of it. Any smarts built into
either pathalias or MX forwarding, to aid admins in recovering from mis-
configured routes? Hardly. Of course, there are scripts to test the
validity of map files. Perhaps there are similar for
> you must be kidding, man ... priviledged few on Internet...
> Are you aware that number of hosts on Internet is a magnitute
> bigger that hosts with uucp only connections ???
Are YOU aware of how many sites connect via UUCP? Many more than actually
get registed in either mail forwarding system, I feel sure. The advent of
cheap, readily available software to do UUCP means that you'll see MANY
more such sites. Just because the Internet, with its much higher costs for
connections, is larger at this point in time, does not mean that it will
continue to be so indefinitely.
Of course, when ISDN gets tariffed for residential consumption, and all
the people with modems rush out and buy ISDN hardware, and after some
cheap TCP/IP over ISDN software gets out in the market, then you may see
people moving away from their cheap UUCP connections in wholesale numbers.
Yeah, right. Look, I'm holding my breath.
> Sorry, Willard - your bias against Internet is quite interesting...
What have I said to give you the impression I am biased against the Internet?
Bill Fenner
|I propose that a solution to routing mail could be arrived at that has
|a higher degree of success than is currently the case with either DNS
|or pathalias routing alone.
Please do. If you come up with any concrete ideas, please share them
with us. The current discussion seems to have degenerated into a
religious war, and, as such, I won't be participating any more. (Plus,
Chris Davis and David Barr always make my points anyway... =)
A solution like "Have a forwarder to send unknown addresses to" is
prone to serious configuration errors - what happens if two people
configure each other as their unknown-host forwarder? Don't just brush
this off as a configuration problem; your main complaints with the DNS
seem to be caused by configuration problems.
Bill
Christopher Davis
WD> Ok. How, then is this different than registration in the UUCP mapping
WD> project? For each site for which you agree to forward mail, you must
WD> re-edit your configuration file. That corresponds exactly to the
WD> update process for the UUCP maps, meaning that for each new
WD> connection, a forwarding site should send in one update.
Depends on the mailer software the gateway site is running. Let's say that
someone's acting as a domain park gateway, for "foobar.org". They have a
wildcard MX for *.foobar.org, and they run IDA sendmail.
They have an entry in their mailertable:
UUCP-A!%s .foobar.org
This will route mail to blurfl.foobar.org to UUCP neighbor "blurfl", mail
to willard.foobar.org to UUCP neighbor "willard", and so on. Add a new
neighbor? Just set it right on up, the mail will get gatewayed. Adding
automatic outbound rewriting (from blurfl!user to us...@blurfl.foobar.org)
is easy as well.
Sending in updates? To where? Again, the only changes are local, and if
you design for flexibility, you don't even need to make those.
WD> So, perhaps that "update it once and forget it" idea doesn't count as an
WD> advantage of DNS over pathalias routing.
Perhaps. Depends on your viewpoint.
WD> Are YOU aware of how many sites connect via UUCP? Many more than
WD> actually get registed in either mail forwarding system, I feel sure.
WD> The advent of cheap, readily available software to do UUCP means that
WD> you'll see MANY more such sites. Just because the Internet, with its
WD> much higher costs for connections, is larger at this point in time,
WD> does not mean that it will continue to be so indefinitely.
That doesn't mean those sites "connecting via UUCP" need to use the maps
for email, as we've said before; the sites I handle MXing for are *not* in
the maps, as UUCP is merely the best way to get their email back and forth
to us.
WD> Of course, when ISDN gets tariffed for residential consumption, and
WD> all the people with modems rush out and buy ISDN hardware, and after
WD> some cheap TCP/IP over ISDN software gets out in the market, then you
WD> may see people moving away from their cheap UUCP connections in
WD> wholesale numbers.
If they want to do ftp, telnet, gopher, WAIS, WWW, and the like, they will.
If all they want is email, they can just do UUCP. This has *nothing* to do
with DNS vs. pathalias.
daw...@willard.uucp
> Willard, for one, appears to be insisting that Internet sites keep
> up-to-date pathalias maps around so they can route to .UUCP sites. And his
> posts have sounded a bit whiny to me.
Oh, really. Please send me email, and elaborate. I'd just love to know
how I can redeem myself.
David Lesher
John Stanley said:
# Neither of these puts me in charge of my little section of the DNS. They
# put me in contact with someone else, who is in charge of my little
# section. Not the same thing.
>Or even having an account on your DNS server's
>machine so you can make the updates yourself.
# Oh boy, an account where I can access system files and make changes.
{}
# And the first place they will see it is in their
# DNS records when UUCP-user forgets to update the serial number or puts a
# goofy date in the file. Or when two UUCP-users try to update the same
# file at the same time.
Mr. Stanley appears to want the ability to make changes on his
own, without any responsibility for the problems he would cause
when he screws things up.
Mr. Stanley, sir. There is only ONE way to get a such a
powerful, unaccountable role in the United States.
Get off the net, and run for public office.
--
A host is a host from coast to coast..wb8foz@skybridge.scl.cwru.edu
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
John Stanley
> JS> They put me in contact with someone else, who is in charge of my
> JS> little section. Not the same thing.
>
>Then my boss isn't really in charge of the machines at my site, because he
>has to go through one of the sysadmins to make a configuration change?
There is a bit of a difference between your boss, who is in charge of
the system admins who make the changes, and me, who is in charge of
nobody at the site who maintains my DNS records. Unless you think that
having someone keep an MX record for you somehow makes you in charge of
the person doing it.
>course, such programs are easily written, made group-executable, and
>installed, in order to give the proper "feeling of control" to people like
>you.
Just what people are "people like" me? You seem to be missing the point
of what is being said here and wandering into insult. I am not
complaining about not being able to control "my section of the DNS",
only trying to correct an erronious statement that anyone can. I have
said that twice, now. Will it sink in this time?
>If no mail arrives at this site for an hour, something's wrong. Your site
>may vary. If *nobody* sends you mail, don't you wonder why?
Please explain how I am to tell the difference between nobody sending
me mail and my site not receiving any mail. It has been 30 minutes here
since I've gotten any mail. Is there a problem? (Could be, I've spent
most of today trying to work around a bogosity in sendmail.) My UUCP
site hasn't gotten any mail for the last two days. Is there a problem?
Until there is a known piece of mail missing, I have no idea whether
nothing has been sent or it was sent and bounced.
> JS> And sites can do routing without keeping the entire UUCP maps on their
> JS> local disk, or even local net.
>
>That's not doing routing. That's doing punting.
Routing, punting, same difference. The mail is being sent somewhere that
it can be taken care of. It might not be the most direct route, but it
is being forwarded on A route. Neither pathalias nor DNS guarantee the
most direct or lowest cost routes.
John Stanley
>And from what you're saying, you don't really want to be in charge of
>your own little section of the DNS because it's too much trouble to do
>correctly.
It would be nice, but I don't need to be in charge of it.
>So, register in the .US domain, where there are nice people at ISI to
>take care of the nitty-gritty details for you.
Why? Isn't my current MX record adequate? I seem to recall saying that
I was aware of wildcard MX's because I already had one.
>Okay, so the root nameservers is "someone". I still think it's a lot
>more reliable and efficient to store 32 bits of information on each of
>a dozen machines -- especially when that data changes very rarely --
>than it is to store 500 bytes or so of data on each of thousands of
>hosts.
So, don't store 500 bytes or so of data for thousands of hosts.
>Registering in the .US domain is no more difficult than
>registering in the UUCP maps, and you won't even have to find another
>machine to connect to if you're already talking to an
>Internet-connected machine who is willing to forward mail for you.
Uhh, let's see here. If I register in the UUCP maps, I don't need to
find any other machine to talk to, whether on the Internet or not. If I
register in the .US domain, I need to be talking to an Internet
connected machine who is willing to forward mail to me. If I am not,
then I need to find one. The latter seems to be more effort than the
former.
John Stanley
>Mr. Stanley appears to want the ability to make changes on his
>own, without any responsibility for the problems he would cause
>when he screws things up.
Would you care to show me where I have said I wanted such ability?
>Mr. Stanley, sir. There is only ONE way to get a such a
>powerful, unaccountable role in the United States.
>
>Get off the net, and run for public office.
Thank you so much for your constructive commentary. You won't mind
terribly if I ignore what you say, since you have obviously been
ignoring what I have been saying?
Christopher Davis
JS> Uhh, let's see here. If I register in the UUCP maps, I don't need to
JS> find any other machine to talk to, whether on the Internet or not.
Not that it wouldn't be tough to get you mail if you don't talk to anyone.
JS> If I register in the .US domain, I need to be talking to an Internet
JS> connected machine who is willing to forward mail to me. If I am not,
JS> then I need to find one. The latter seems to be more effort than the
JS> former.
Well, you need to find one that is willing to route (not punt; I make a
distinction between "hand all mail of a certain class to this site" and
"route all mail of a certain class according to this database", even if you
don't) mail to you. You can be ten hops off the Internet as long as some
Internet site is willing to convert mail for "us...@stanley.podunk.nd.us" to
"nearby!farther!wayout!boonies!stanley!user".
Karl_Kl...@cs.cmu.edu
>Then my boss isn't really in charge of the machines at my site, because he
>has to go through one of the sysadmins to make a configuration change?
There is a bit of a difference between your boss, who is in charge of
the system admins who make the changes, and me, who is in charge of
nobody at the site who maintains my DNS records. Unless you think that
having someone keep an MX record for you somehow makes you in charge of
the person doing it.
Your attitude is insulting to the many sysadmins out there who
voluntarily support domains requiring MX support. I used to have an
open offer to provide nameservice and MX connectivity to absolutely
any entity anywhere, when I was [ph]ostm...@cis.ohio-state.edu.
Anyone who ran such a domain and needed updates simply mailed me the
update, and I didn't do anything more than check it quickly for
outright errors so my nameservers wouldn't choke on it. Installation
of the updates was usually done within the day.
It is singularly inappropriate for you to be accusing others of taking
the low road of personal insult when you are quite possibly doing more
of the same, obtusely and without direct reference, than the rest of
the participants in this pointless argument combined.
Yes, when you are the domain contact of an MX-supported domain, you
_are_ in charge of the zone file for your domain, and the sysadmin who
actually manages the nameservers that support your domain has a quite
obvious and clear responsibility to be responsive to your needs for
updates. If they weren't prepared for that responsibility, they
wouldn't have offered to be provide nameservice.
If you're going to be insulting, you could at least have the common
decency to provide counterexamples, situations where nameserver admins
have deliberately, or even unknowingly, made life difficult for
MX-supported domains by _not_ being responsive to such needs.
--karl,
at one time, technical and zone
contact for some 40 domains, most
of which I registered myself
John Stanley
>sta...@skyking.oce.orst.edu writes:
> >Then my boss isn't really in charge of the machines at my site, because he
> >has to go through one of the sysadmins to make a configuration change?
No, I certainly did not write this.
>Your attitude is insulting to the many sysadmins out there who
>voluntarily support domains requiring MX support.
My "attitude" is that those people who voluntarily provide support by
providing MX records do not automatically come under my control just
because they are providing an MX record for me. Period.
Since they are not under my control, I am not "in charge" of them, in
the same sense that the "boss" referred to by the true author of the
above quote is. If they have two things to do late Friday afternoon,
and one of them isn't making a change in my DNS information, I am in no
position to demand that the one thing they have time to do will be
mine.
>Anyone who ran such a domain and needed updates simply mailed me the
>update, and I didn't do anything more than check it quickly for
>outright errors so my nameservers wouldn't choke on it. Installation
>of the updates was usually done within the day.
Did you consider yourself to be under the control of the sites who
connected to you? Were THEY in charge of your nameserver, or were you?
Consider what you did with changes that had errors -- did you make them
or did you refuse? And when you refused, were any of your sites able to
overturn your refusal? Then they weren't in charge, were they?
>It is singularly inappropriate for you to be accusing others of taking
>the low road of personal insult when you are quite possibly doing more
>of the same, obtusely and without direct reference, than the rest of
>the participants in this pointless argument combined.
I have accused no admin of any wrongdoing. Show me where I have. Don't
tell me about what you inferred or thought I said -- tell me where I
said it.
>Yes, when you are the domain contact of an MX-supported domain, you
>_are_ in charge of the zone file for your domain,
I am not the domain contact, thus not in charge. I doubt that I am the
only site like this. If I am unable to force a change to the zone file,
then I certainly am not in charge of that file.
>and the sysadmin who
>actually manages the nameservers that support your domain has a quite
>obvious and clear responsibility to be responsive to your needs for
>updates.
In my case, yes, because I pay for him to do it. In the case of
Random.uucp who gets a free connection from Arbitrary.edu, the "obvious
and clear responsibility" is not so obvious and clear. It becomes even
less so when the feed is arbitrary.com.
>If you're going to be insulting,
Conditional clause not fulfilled, remainder of paragraph deleted.
Leslie Mikesell
>voluntarily support domains requiring MX support.
You may indeed be a very nice person, but I don't see why that should
make everyone want to be forced to rely on the kindness of strangers.
>I used to have an
>open offer to provide nameservice and MX connectivity to absolutely
>any entity anywhere, when I was [ph]ostm...@cis.ohio-state.edu.
I trust some other kind stranger has taken over the task...
Les Mikesell
l...@chinet.chi.il.us
Steve Romig
>>I used to have an
>>open offer to provide nameservice and MX connectivity to absolutely
>>any entity anywhere, when I was [ph]ostm...@cis.ohio-state.edu.
>
>I trust some other kind stranger has taken over the task...
Some people think I'm kind. John Mudd took over name server
maintenance when Karl left here, and I took over when John left a
while back. The only thing that changed was the names behind the
[ph]ostmaster aliases, so to speak. We still freely provide
nameservice and MX stuff to anyone that asks.
--- Steve
Bruce Becker
|you want to continue using pathalias, fine, but don't cry when J.
|Random Site on the Internet can't send mail to you, since there's no
|offical system to provide Internet->UUCP gateways for all Internet members.
|Understand? The solution is to get yourself a registered DNS MX record,
|and a site to MX for you. Plain and simple.
It seems logical for sites which are Internet/UUCP
gateways to declare MX records for all the systems
that they publish in their pathalias map entries -
sitex.uucp. MX 10 mail.mysys.mydom.
sitey.uucp. MX 10 mail.mysys.mydom.
...
I know we don't do this at my workplace, but there
seems no obvious reason not to do so.
--
,u, Bruce Becker Toronto, Ontario
a /i/ Internet: b...@becker.gts.org Uucp: ...!web!becker!bdb
`\o\-e "...symbolising Excitement and Fun."
_< /_ -- Disneyland North investment brochure
Alan P Barrett
sta...@skyking.OCE.ORST.EDU (John Stanley) writes:
In article <BzBBMJ...@cs.cmu.edu> Karl_Kl...@cs.cmu.edu writes:
> My "attitude" is that those people who voluntarily provide support by
> providing MX records do not automatically come under my control just
> because they are providing an MX record for me. Period.
I missed the start of this discussion, so I hope that I am have not
completely misunderstood, but it looks as though two groups of people
are talking at cross purposes here, with both groups being right (or
nearly right).
It seems to me that you *can* be in charge of _the MX records_, even
if you are *not* in charge of _the people_ or _the equipment_ that does
some of the work that is needed to make the MX records useful.
For example, suppose that you have a site that is not IP reachable,
and that a volunteer (with the necessary equipment, connectivity, etc.)
is willing to provide nameserver service for you. If you register a zone
for your site and edit the master file for that zone, then I would say
that you are in charge of the zone, even though you would not be able
to install the updates yourself. On the other hand, it seems clear that
you would not be in charge of the volunteer person.
--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: bar...@ee.und.ac.za Bang: m2xenix!undeed!barrett
Willard Dawson
> In article <1992Dec19.1...@becker.GTS.ORG> uuc...@becker.gts.org wri
> > It seems logical for sites which are Internet/UUCP
> > gateways to declare MX records for all the systems
> > that they publish in their pathalias map entries -
> >
> >
> > sitex.uucp. MX 10 mail.mysys.mydom.
> > sitey.uucp. MX 10 mail.mysys.mydom.
> > ...
> >
> > I know we don't do this at my workplace, but there
> > seems no obvious reason not to do so.
>
> Most mailers are configured by default to not do DNS lookups on
> certain specified domains. (Most notably .UUCP, .BITNET, and the
> now-gone .CSNET) This is to save undue wear-and tear on the root
> nameservers.
Yes, but... I've come across more than a few mailers that (incorrectly)
attempt to do DNS lookup on .UUCP sites. I've had several direct exper-
iences with failed mail in exactly this scenario.
> Even if this were not so, with DNS there's no way for one site
> to just "declare MX records" for .UUCP and have them be seen by just
> anyone. _One_ site has to be declared as "authoratative" for entire
> .UUCP pseudo-domain in order for anything to work consistently. How is
> my mailer going to know what nameserver to look at to resolve the MX
> for "becker.UUCP"?
Hmmm... some site would need to advertise itself as a top-level server
for .UUCP? Not likely, not for free? Or is it really all that big a
deal? Has any site actually ~tried~ it, to show what the results would
be? Could the MX record on a given site still be made to point to the
true best path to the UUCP-connected site?
For example, suppose UUNET declared itself the top-level server (and,
thus, only server, as .UUCP is not sub-domain-ized <ick>) for .UUCP.
If the MX record for willard.UUCP were to indicate a path of
gatech.edu!vdbsan!willard!%s, or something similar, would that not still
route mail in the exact same way that UUNET would route mail otherwise?
Mail would not need to be sent to UUNET in order to see that the route
to willard.UUCP would best be through the indicated path. So, a tighter
link between MX/pathalias would not be necessarily a bad thing, unless
the resulting load on the system acting as the nameserver were such that
it would in fact be inpractical to implement.
What have I overlooked?
>
> --Dave
> --
> System Administrator, Population Research Institute ba...@pop.psu.edu
> What if there was no such thing as a hypothetical question?
Bill Fenner
|Could the MX record on a given site still be made to point to the
|true best path to the UUCP-connected site?
MX records point to hosts, not to paths.
|If the MX record for willard.UUCP were to indicate a path of
|gatech.edu!vdbsan!willard!%s, or something similar, would that not still
|route mail in the exact same way that UUNET would route mail otherwise?
The MX record would have to point to "gatech.edu". This is where the
biggest problem arises - how do you come up with the proper Internet
host at which to point the MX record? Note that, at least in psuvax1's
pathalias data, the route to willard is "gatech!vdbsan!willard!%s" --
no mention of any Internet sites in that path at all. So you need to
process the maps again, looking for sites that look like they may be
Internet hosts, and then make their MX'er the closest Internet host.
This means, at least, a new pathalias-like program.
Now, the next problem: you have to make sure that all of these machines
are actually on the Internet. How do you know that
gatech =gatech.edu is on the Internet, while
wcfpc =growler.redbeard.com is not? You can do a DNS lookup, but
there are a *lot* of records to look up... this will probably end up
putting a significant load on your system (significantly more than just
pathalias).
Ok, are we done yet? Nope -- how do we know that the Internet site we chose
is set up properly to accept mail to .UUCP? Just because a node is on the
Internet and is in the .UUCP pseudo-domain doesn't mean that it can route
between the two properly. You're likely to get horribly mangled From: and
To: addresses if you just decide to pick a random site as your gateway.
A new flag in the pathalias data, noting that one is:
a) connected to the Internet
b) willing to gateway to the .UUCP pseudo-domain (maybe a radius factor --
psuvax1 might be willing to gateway to hosts less than 2 hops away, or
something)
would solve the second and third problem. Then the only problem left
would be writing a graph-traversal program similar to pathalias but to
find the closest Internet site to each UUCP host. If you want to
select the closest Internet gateway to each site, this turns out to be
a problem N times as big as the pathalias problem, where N is the
number of Internet gateways registered. The pathalias data from any
particular site will not necessarily give the closest Internet
gateway. Let's say, for example, that willard connects to psuvax1.
UUNET's path would still be gatech!vdbsan!willard, but the closest
Internet gateway would actually be psuvax1.
And, of course, the new flag would be slow to propogate into the maps, and
would have the expected problems (not getting updated, etc.).
Bill
David Keegel
>In article <V1L9VB...@willard.UUCP> daw...@willard.UUCP (Willard Dawson) writes:
>>for .UUCP? Not likely, not for free?
Very unlikely. Unless you could get a number of sites to start
doing it at the same time (then it's just "quite unlikely").
>>If the MX record for willard.UUCP were to indicate a path of
>>gatech.edu!vdbsan!willard!%s, or something similar, would that not still
>>route mail in the exact same way that UUNET would route mail otherwise?
>You're thinking UUCP again, Willard.
Yes, bzzt. Unless someone wants to do some serious hacking on BIND (or
equivalent), the only way I can see to do this is either:
* all mailers that ask the DNS about .UUCP. MXes send the
mail on to a randomly selected Internet->UUCP gateway.
* Everyone in .UUCP. registers an MX with somebody.
The second option is pretty pointless. If you're going to register,
you may as well use a real domain (eg in .US.), modulo concerns about
the US domain currently being strictly geographical.
As far as I know, the random selection will give a different MX for
each message, for sendmail and RFC-compliant MTAs. Is this wrong?
There will be some sites which always pick the first MX which responds
before timeout (not very random), but are they more than say 10%?
>>What have I overlooked?
>The fact that you'd have to reconfigure the majority of mailers out there
>in order for it to work (Remove CPUUCP from the sendmail.cf)
Your milage may vary depending on vendor, etc. Not everyone uses "P".
It may not be necessary to do this though. If a mailer can handle the
.UUCP "domain" intelligently now, there's no reason to change it.
I thought the idea was just to provide a "safety net" for mailers
which don't know what to do with mail for .UUCP. Why flood the
(hypothetical) internet->uucp gateway(s)?
You've also overlooked the question of whether the Internet (with a
capital I) people would want to encourage anything which "legitimises"
the .UUCP (pseudo) domain. I suspect the answer (at least from Inter-
net-centric people) may be "if you want your mail to work reliably,
go get a real domain name; if not, stop complaining".
Perhaps now would be a good time for Willard to tell us his tale of woe
regarding being in ".US."
--
<David....@apana.org.au> <werple!tuple!boombox!djk> Tel: +61 3 593-1460
aka: d...@boombox.apana.org.au, d...@cs.mu.oz.au. Formerly: d...@bby.com.au.