reid@Glacier.ARPA (Brian Reid) (07/27/85)
I've always admired Peter Honeyman and his friends for being so successful at using intellectual terrorist tactics to squelch most criticism of their ideas. Usually when groups resort to this kind of ad hominem argot, the world stops paying any attention to them. But in addition to being terrorists, the Honeyman gang often know what they are talking about. It's therefore always dangerous to disagree with Peter in public, because your mailbox will fill up with letterbombs (though the letterbombs always have malformed headers and a smart mail-reading program can just ignore them......) Anyhow, I'd like to take the dangerous step of disagreeing with Peter that automatic rewriting of addresses is a good idea. My network home is at the confluence of several networks (arpa, uucp, PUP ethernet) and 1 hop away from several more (bitnet, DEC Enet, Xerox clearinghouse, etc.) I send, receive, and provide postmaster services for an awesome amount of mail that crosses "domain" (pardon the expression) boundaries. Automatic address rewriting in the current mail world has the problem that it doesn't know what addresses to rewrite, and cannot. Furthermore, it makes it impossible for a person to know his own address. If I send you a message to honey%down@princeton, somebody's mailer can rewrite it so you see a message sent to princeton!down!honey. But what if the message has a CC field? Do you rewrite that? You will quickly answer "yes", of course, because you do. Though some probably don't believe in the existence of CC fields--smacks too much of the dreaded arpanet. If you have a religious belief that messages should not have certain header fields (or should not have headers), then how do you handle translation to and from these headers. But that is the easy part. The hard part is addresses passed as data, or written down on pieces of paper. If I get a message from DSITES%null.DEC@Decwrl.ARPA, and I forward the message to you, the message that I am forwarding will not be subjected to any kind of address translation, because it is just text, and not message headers. If you are a smart guy like Peter Honeyman, you will know how to translate manually the address that you see in the message. But let's suppose that you are a typical sort of AT&T employee who isn't even capable of learning not to post "house for sale in NJ" ads on net.general. What are you going to do with that address? Probably just send to it, trusting that some smart gateway will get it right. What if you are at a conference and somebody asks you for your mail address. What do you tell him? Well, you ask him for his mail address, and then based on what he tells you, you mentally translate your address into the vernacular of his network, so that he can mail to it. But what if he is playing the same trick that you are, waiting to know your address before he can tell you his. Automatic address translation creates context-sensitive addresses. Context-sensitive addresses are bad. It behooves addresses to be universal. Current mail technology makes universal addresses impossible. I claim that any technological solution (such as automatic rewriting gateways) that serves to prolong the existing situation (total chaos) is bad. Can you imagine how awful things would be if the telephone system used the same kind of addressing scheme that the techno-zealots at the phone company are trying to foist on the computer mail world? And you thought MCI with access codes was bad.... -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.ARPA
honey@down.FUN (Peter Honeyman) (07/30/85)
robert and brian (and a cast of dozens? ten? just robert and brian?
brian?) cry out for universal addresses. but at what price? do i
really need or want an international namespace commission? can i
afford it? i doubt it -- the last time i checked, entry into the arpa
world cost $50,000 down and $50,000 a year, and that's if they'll have
you! (have you designing killer cyborgs in space, that is.)
they go on to say that any system that contends with today's godawful
mess is impractical, dangerous, and generally a bad idea. rather, they
propose, we should adopt a single set of rules, and anoint overpaid
bureaucrats to assure compliance. (incidentally, this is also mandated
by rfc819. maybe it's not incidental.) fine, to whom to i write out
the check? what's the delivery schedule? and what do i do while i
await this holy grail?
mind you, i'm not arguing for or against domains (or any other
abstraction -- at least not in this paragraph). i wish i had known
that my goals were impossible, impractical, dangerous, impotent,
flaccid, emasculated, menopausal, and generally bad before i built the
fun domain mailer.
picky stuff for robert:
yes, the fun mailer can be sabotaged by rogues giving me bad data.
name a piece of software that doesn't have this problem. (consider,
e.g., ken thompson's famous trojan horse.) nonetheless, wouldn't you
agree that mutual cooperation has worked pretty well so far? and you
can't beat the price.
also, if you really believe that mark@cbosgd.att.uucp is the same as
uucp!att!cbosgd!mark, then we're in the same camp, aren't we? i have
insisted all along that a "domain" is a pseudonym for a host that can
gateway to a specific set of hosts. so let's call a spade a "spade"
and write attunix!cbosgd!mark (with the possible addition of a uucp
gateway).
vortex!registry claims to be a uucp naming authority; maybe someday
this will help me build better mailers.
picky stuff for brian:
i don't translate addresses manually, you luddite, that's what
computers were invented for.
who are these "techno-zealots" at the phone company? (electronic
addresses please.)
finally, please stop confusing me with bimmler.
picky stuff for everyone:
a cogent point made (in passing) by pike and weinberger at the last
usenix ("the hideous name") is that what uucp routes are more than
routes, they're addresses. i take that view and run with it: given
the proper data, a uucp route maps into a graph traversal, specifying a
given host at least as precisely as any domainist's incantation. (and
software that does just that is more than just a gleam in an
rfc-writer's eye.) my major departure from rfc819 is the extension of
their graph model (undirected trees) to arbitrary directed graphs.
obviously any connected undirected graph can be viewed as a tree, but
the world is neither connected or undirected. this fact can not be
wished away.
as for universal addresses, i give mine relative to glacier. doesn't everyone?
peterhokey@plus5.UUCP (Hokey) (07/30/85)
UUCP mail routes can be viewed as addresses. If so, they are addresses with (at least) implicit routes. The problem is that one cannot tell with syntactic analysis if a given bang path is explicitly or implicitly routed. I know that Peter does a really splendid job of determining this stuff with the aid of a really neat database to semantically disambiguate routing. The point I am not making in the debate between ! and . is that bang paths are *implicitly rooted*, while a fully qualified domain name is *explicitly rooted*. This is the crux of the issue! -- Hokey ..ihnp4!plus5!hokey 314-725-9492
hokey@plus5.UUCP (Hokey) (07/30/85)
One problem with classic RFC822 header lines in the UUCP environment is that
while there is no parsing ambiguity in an RFC822 header, there is still a
problem with user interfaces. If I have simple sender and recipient fields
in the header and the mail between the sender and a recipient requires non-
local routing, what does one do about a reply? The routing information is
not there.
By the same token, it is not really correct to keep the routing information
floating around, as the path will grow and grow with each reply.
Additionally, I think that it it is a good idea to put (at least) the
recipient fields of the 822 header into bang format in UUCP land, as
non-822 mailers still recognize the To: line, and they will produce replies
with hybrid paths.
There is also the issue of >From crushing. I *like* knowing when a mail
message was sent to me. We need to either fix sendmail to recognize multiple
>From lines as legal headers, or come up with a way to determine if a site
listed in the >From line has also put a corresponding Received: line in the
header. It would be *swell* if we could come up with a mechanism to tell
other mailers how smart our mailer is, so that routes between smart mailers
could be optimized. For example, we talk dorectly to seismo and ihnp4, but
we have mail for us sent through those sites go through another site on its
way to us.
--
Hokey ..ihnp4!plus5!hokey
314-725-9492jordan@ucbvax.ARPA (Jordan Hayes) (08/01/85)
In article <545@down.FUN> honey@down.FUN (Peter Honeyman) writes: >also, if you really believe that mark@cbosgd.att.uucp is the same as >uucp!att!cbosgd!mark, then we're in the same camp, aren't we? i have >insisted all along that a "domain" is a pseudonym for a host that can >gateway to a specific set of hosts. so let's call a spade a "spade" >and write attunix!cbosgd!mark (with the possible addition of a uucp >gateway). You just don't get it, do you Peter? A domain is NOT A PSEUDONYM FOR A HOST THAT CAN GATEWAY TO A SPECIFIC SET OF HOSTS. I am not a member of .att.uucp (or, if you like, WOULD NOT BE...), but my machine does have a connection to cbosgd.att.uucp (or whatever Mark is calling it these days...), and so I can use that address. Hmmm... come to think of it, if we didn't get called by cbosgd, I would still have a way to resolve that address to ihnp4 (my other entry point to .att.uucp), but the address stays the same. Not true if I send to attunix!cbosgd!mark, and I have no connection to attunix, nor would pathalias tell me how to get there reasonably from one of my other addresses, oh, say, jordan@klaatu.wny.atl.uucp, since this machine is not on the map (and yet I have been able to get mail to it for almost a year now...), not to mention jordan@orion.ames.nasa.gov but I could use the above address for Mark from any of those accounts... Open your mouth and make way for the size 12 Nike Basketball sneeker... >a cogent point made (in passing) by pike and weinberger at the last >usenix ("the hideous name") is that what uucp routes are more than >routes, they're addresses. Right. This is bad, unreliable, and subjective. >i take that view and run with it: Good thing to do with something braindamaged. >given the proper data, Where? When was the last time we saw a "correct" map? >a uucp route maps into a graph traversal, specifying a >given host at least as precisely as any domainist's incantation. Wrong. Decisions in routing can be made down the line that are much smarter than your bloody map... >my major departure from rfc819 is the extension of >their graph model (undirected trees) to arbitrary directed graphs. >obviously any connected undirected graph can be viewed as a tree, but >the world is neither connected or undirected. this fact can not be >wished away. Yes, but you can work within it, being a little flexible for the sake of simplicity and elegance. Sure, I can throw a 900K map, a 300K resultant database and lots of flashy software at the problem and get the right answer *most* of the time, but there *IS* a better way... ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
peter@graffiti.UUCP (Peter da Silva) (09/03/85)
> Wrong. Decisions in routing can be made down the line that are much smarter > than your bloody map... OK. You want to replace his bloody map with your bloody map. Where did all this blood come from?