chuqui@nsc.UUCP (Chuq Von Rospach) (07/23/85)
I'm starting to see problems that look like smart mailers messing up
addresses. I **think** it may have something to do with some of the
assumptions in the gatech sendmail configuration files -- I'm hacking on
them now and some things don't look quite right.
All of the problems seem to be involving munging around with gateway cross
overs -- I'm seeing them specifically involving seismo and decwrl, the two
ARPA gateways I talk to. Scenario;
someone mails to 'nsc!chuqui@decwrl'. A smart mailer says: "Aha! I know
where that goes -- it goes to 'ihnp4!nsc!chuqui@decwrl' (since it looks
for an optimal route to nsc, because the .ARPA is left off of decwrl).
When the mail gets to me, it is sent to 'chuqui@decwrl' and the thing
aborts.
There is an assumption in the gatech sendmail stuff that the top level
domain is .CSNET. This has interesting ramifications in both the .cf file
and in the uumail program they use for uucp mail optimization. uumail, for
instance, doesn't seem to like anything that isn't sent out as .UUCP (so
an address like 'decwrl!foo@bar.ARPA'). The configuration stuff doesn't
like .UUCP top level domains and gateway crossing -- if I sent the .cf
an address such as 'seismo!a@b.ARPA' it gets sent to uumail as
'decwrl!seismo!a@b.arpa' which uumail will then truncate back to the
original address -- not what is wanted at all. If you take uumail out of
the loop, you end up mailing to 'seismo!a', which is much different
than 'a@b.arpa', the final address in the original site.
There seems to be a growing problem with this. I'm looking at a couple of
things that might help:
o uumail will be taught the .ARPA domain, and will strip any leading
bang addresses from it and then mail it to the ARPA gateway (in my case
decwrl). This means that something sent to nsc as 'seismo!a@b.ARPA'
will really be sent to 'decwrl!a@b.ARPA'. Potentially, this can muck
out a header incorrectly, but since uucp -> ARPA -> uucp gateways are
frowned upon (and nigh impossible, I've tried it many a time) in
reality I don't think it is a problem. Is it?
o I'm trying to clean up the assumptions in the sendmail .cf that
the top level domain is well-connected rather than the uucp style
semi-directed store and forward.
Any suggestions or help would be happily accepted. I think I know what I'm
doing, but that doesn't always turn out to be a safe assumption...
chuq
--
:From the carousel of the autumn carnival: Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA
Your fifteen minutes are up. Please step aside!hedrick@topaz.ARPA (Chuck Hedrick) (07/23/85)
I'm not convinced that looking for the Arpa domain is going to solve your problem. There is the small problem that .ARPA is being phased out, to be replaced by .EDU, .COM, etc. But more generally, I am not convinced that it is right to have artificially-intelligent parsers that decide what foo!bar@baz means based on the semantics of the addresses. Can't we just agree on some other character that has the same meaning as @ (i.e. internet host), but with the same order as !. Suppose we choose $. Then foo!bar@baz would become baz$foo!bar or foo!baz$bar, depending upon what was meant. All of the UUCP/Internet gateways should be running software powerful enough to convert between this format to an RFC 821 format. I'd much rather have an unambiguous syntax to fix this thing once and for all, rather than get hairier and hairier special case handling. Indeed our gateway software is prepared to accept ! format when referring to Internet hosts. So mail can be addressed topaz!blue!user rather than topaz!user@blue. How common is this? If it is common enough, then we can just tell people not to use @ in UUCP addresses, and forget this whole problem.
honey@down.FUN (Peter Honeyman) (07/25/85)
i am delighted to hear a traditional arpanaut (hedrick@rutgers) espousing the wonders of source routing in general and uucp syntax in particular. welcome to the club. let me join in hedrick's request that gateways between dissimilar networks do the dirty work of translating between addressing styles. then i'll send him mail at topaz!rutgers!hedrick, and he'll send me mail at honey%princeton@topaz; naturally, the gateway at topaz will translate the addresses as they pass through. i must disagree with his suggestion that we tie transport to syntax: graph traversals are everything. give me a sequence of hosts, in any damn syntax you please, and i'll betcha i can get the mail through. but on the whole, hedrick is right on the mark. peter ps: please please please keep those nasty cbogsd!cbosgd.att.uucp's from my door.
adams@plx.UUCP (Robert Adams) (07/26/85)
> I'm not convinced that looking for the Arpa domain is going to solve > your problem. There is the small problem that .ARPA is being phased > out, to be replaced by .EDU, .COM, etc. But more generally, I am not > convinced that it is right to have artificially-intelligent parsers > that decide what foo!bar@baz means based on the semantics of the > addresses. It seems impossible to create an addressing format that would include be compatable on all of the interconnected nets and would be parsable. Rob Pike, in a USENIX presentation, brought up the point about why would we want to have a single addressing format. Why not have a naming scheme for an individual net and "smart" gateways that perform the mapping between the nets. The different nets are radically different -- some centralized, some chaotic, some ... -- so expecting domaining (which is probably a good solution for ARPA net) to work on Usenet (which couldn't keep routing tables in >1000 sites together) is crazy. Besides, I don't think there exists a parser that could handle all the @'s, !'s, %'s, ^'s, and everything else that would work all the time. I think work should be done on creating gateways that can do the mapping between Usenet address and other net addresses rather than getting the whole of Usenet to convert or use strange and interesting address parsers and mappers. ..!{decvax,ucbvax}!sun!plx!adams -- Robert Adams
jordan@ucbvax.ARPA (Jordan Hayes) (07/26/85)
In article <3018@nsc.UUCP> chuqui@nsc.UUCP (Chuq Von Rospach) writes: <...about a lot of problems with combinations of syntaxes...> > o uumail will be taught the .ARPA domain, and will strip any leading > bang addresses from it and then mail it to the ARPA gateway (in my case > decwrl). Well, that's a lose, because ".ARPA" will go away soon. And for good reason. Time has come for UUCP to either jump on the bandwagon or get lost in the dust. Domaining UUCP is a MUST, rather than a hope. > ...but since uucp -> ARPA -> uucp gateways are > frowned upon (and nigh impossible, I've tried it many a time) in > reality I don't think it is a problem. Is it? Ah, but it happens all the time. I don't think DARPA would like to hear it, but it indeed does. The problem is that if you can get mail to an ARPA host, most of the mailers out there make no distinction between locally generated mail and that which is gatewayed in from somewhere else, so it looks like you are sending from the arpa host, thus you can send to anywhere. I know of no filtering of stuff done this way. Alas, you have to be careful of the syntax you use to avoid the problems Chuq mentions (wrong assumptions, etc...)... I have some ideas of an easy way to domain-out UUCP, but it's gonna take about a dozen major UUCP sites (strategically placed...) to cooperate (namely the authoratative machine for each of a bunch of second level domains to be defined -- see Mark Horton's documents on "UUCP Subdomain Requirements" and "What is a domain" for details)... There seems to be no way to have 1 top-level machine, but if a bunch of machines cooperated in such a manner as to break the net up into smaller, more manageable pieces, things could run smoothly and life would be good. THINK NAMESERVER. THINK DOMAIN. If you don't understand these terms, drop me a note and I'll send you the documents to read. DO YOUR HOMEWORK... SAVE UUCP FROM ALMOST CERTAIN DEATH... Chuq -- you seem generally interested in the future of this net. Me too. Let's get something rolling. Anybody else? ------------ Jordan Hayes jordan@ucb-vax.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
gds@mit-eddie.UUCP (Greg Skinner) (07/27/85)
> From: chuqui@nsc.UUCP (Chuq Von Rospach) > I'm starting to see problems that look like smart mailers messing up > addresses. I have always had a problem with sendmail/pathalias optimizing a path I didn't want optimized. Sometimes, I want to see the message go through the entire path of machines, and other times I happen to know a few things about the route to the destination machine that pathalias doesn't know about (like hosts not necessarily in the pathalias tables). What I'd like to see is some flag which you could pass to sendmail, activated by some field in your mail message, something like: Optimize: n where n=0 for no optimization, n=1 for optimization. finer grades may also be included, if multiple levels of optimization are possible. -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. Greg Skinner (gregbo) {decvax!genrad, allegra, ihnp4}!mit-eddie!gds gds@mit-eddie.mit.edu
gds@mit-eddie.UUCP (Greg Skinner) (07/27/85)
I have always held that there should be precedence-specifying characters
(i know parens are already in use, but we could use another character
like {, or even change rfc822, for the purposes of cross-net mailing
where domains are not yet in effect). It's not that hard to do, and it
makes sense (like in a compiler).
I should never be restricted to expressions like
2 * 3 + 4
in my programming language if I have a need to multiply the quantity 3 +
4 by 2, I should be (and am able) to do this by saying
2 * (3 + 4)
I shouldn't have to worry about my context (am I in a *-over-+
environment, or not?). Similarly, if I'm on a machine that has
!-over-@, I should be able to get my UUCP mail through another ARPA
machine if I need to, e.g.
{allegra!friend}@harvard.arpa
By introducing {}'s and maintaining the same philosophy that whatever
lies on the local part of the ! or @ should be handled by the local
machine, it will be easier to cross multiple network boundaries without
having to use %, or sendmail trickery, or hardwired paths, etc.
As an example, chuqui's uucp->arpa->uucp problem is handled easily --
all he needs to do is send to
decwrl!{{allegra!friend}@harvard.arpa}
--
Do not meddle in the affairs of wizards,
for they are subtle and quick to anger.
Greg Skinner (gregbo)
{decvax!genrad, allegra, ihnp4}!mit-eddie!gds
gds@mit-eddie.mit.edudfk@unido.UUCP (07/27/85)
> /***** unido:net.mail / topaz!hedrick / 2:12 am Jul 24, 1985*/ > But more generally, I am not convinced that it is right to have > artificially-intelligent parsers that decide what foo!bar@baz means > based on the semantics of the addresses. I don't either. If we need these it means that the users who are supposed to understand the addresses couldn't cope either. It's sometimes difficult for myself although I am the local "postmaster". > Can't we just agree on some other character that has the > same meaning as @ (i.e. internet host), but with the same order as !. > Suppose we choose $. Then foo!bar@baz would become baz$foo!bar or > foo!baz$bar, depending upon what was meant. All of the UUCP/Internet > gateways should be running software powerful enough to convert between > this format to an RFC 821 format. I don't like that either. Why introduce a new symbol? I think you can solve that simply by knowing via wich net the mail did COME TO YOU. I use the general Rule: RFC822 (@/% precedence over !) if it is originated locally or comes via a network other than uucp. UUCP (! precedence over @/%) if it comes in via UUCP I have just made a new sendmail.cf including support programs for unido.uucp alias ddoinf6.bitnet. This is based on the work of Jim Crammond <jim@hwcs.uucp>. It parses addresses according to RFC822 giving @ and % precedence over !. I find this works well and I tell my users to avaid !s. We have a rerouter so most addresses don't use an explicit path. I tell users to avoid mixing @/% with !s if they HAVE to specify a route. They can use foo%bar.arpa%seismo@mcvax or even (for persistent bangists) mcvax!seismo!bar.arpa!foo wich is understood by seismo. As Hedrick suggested: > So mail can be addressed topaz!blue!user rather than topaz!user@blue. How > common is this? If it is common enough, then we can just tell people > not to use @ in UUCP addresses, and forget this whole problem. That's what I do. Sticking to these rules makes sendmail.cf easier to do and to understand. BTW: Jim's stuff is generated from a set of files so you don't have to write a single rewriting rule! The one tricky problem is when you interface to uucp! Normal uucp mailers give ! precedence over @ wich is perfectly OK from their point of viewing addresses. General rule for uucp-mailers: Is there a bang in it? If yes, strip foo! and send to foo. If not, deliver locally (whatever that may mean). I have rewritten /bin/rmail to cope with this before sendmail even sees the address. It simply converts any mixed mode addresses to a single mode (in my case bangish) giving bangs precedence. So if I get mcvax!seismo!foo@bar.arpa it will turn it into mcvax!seismo!bar.arpa!foo and give it to sendmail. I think this is the only valid interpretation if something comes in via UUCP! It goes without saying that I convert all addresses to !-format deleting .uucp domains when I SEND something via uucp. Users at hosts "behind" unido know that they can simply say unido!foo@bar.arpa. If they insist on routing stuff the "don't mix modes" rule aplies. unido!mcvax!seismo!bar.arpa!foo. If they would want to do forbidden things they could do: unido!mcvax!seismo!bar.arpa!uucp1!uucp2!user I am not sure seismo will interpret that correctly but I strongly suspect it. I admit this was rather lengthy, so let me repeat the morale: 1) don't mix ! and @ 2) If you get a mixed address decide about precedence based on the network by which the message ARRIVES Comments welcome. -Daniel Karrenberg <postmaster@unido.uucp>
kimcm@diku.UUCP (Kim Christian Madsen) (07/27/85)
In article <11500001@unido.UUCP> dfk@unido.UUCP (Daniel Karrenberg) writes: >I admit this was rather lengthy, so let me repeat the morale: > > 1) don't mix ! and @ > 2) If you get a mixed address decide about precedence > based on the network by which the message ARRIVES > >Comments welcome. One of the pleasant news I've got earlier this year was that many, backbone sites are doing a rerouting of the paths to a given site. This means that I don't have to write mcvax!seismo!decvax!ihnp4...etc...!site!user Now I can relax and say mcvax!user@site.domain which saves me a lot of typing and reduces the chance of typos. I agree that the syntax of adresses can be horrible. But to give absolute paths would be ridiculous -- Let the routing databases with their optimized paths give the absolute path. You don't tell the postman which way he shall walk to deliver your ordinary mail, as long as it is delivered - do you ? (-; Maybe what we need is an net-addressing like: [<backbone-site>] <user> at <machinename> nettype <network> example: mcvax joe at foo nettype bar Which should be obvious for anyone to understand, and it's more like the address you write on an envelope... -- Kim Chr. Madsen Datalogisk Institut (Institute of CS) University of Copenhagen {decvax,philabs,seismo}!mcvax!kimcm@diku.UUCP
jordan@ucbvax.ARPA (Jordan Hayes) (07/29/85)
[ burp! ] In article <536@down.FUN> honey@down.FUN (Peter Honeyman) writes: >let me join in hedrick's request that gateways between dissimilar >networks do the dirty work of translating between addressing styles. >then i'll send him mail at topaz!rutgers!hedrick, and he'll send me >mail at honey%princeton@topaz; naturally, the gateway at topaz will >translate the addresses as they pass through. Ho hum. Why do the networks have to be dissimilar? I submit that whomever you are and wherever you are (even princeton), you should send me mail at "jordan@ucb-vax.berkeley.edu". end of discussion. What is all this ! % etc, crap? It's a kludge, it's messy (Peter -- didn't you complain that the cbosgd stuff was messy?) and it's a lose. ------------ Jordan Hayes jordan@ucb-vax.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
jordan@ucbvax.ARPA (Jordan Hayes) (07/29/85)
In article <4787@mit-eddie.UUCP> gds@mit-eddie.UUCP (Greg Skinner) writes: >I should never be restricted to expressions like > >2 * 3 + 4 > >in my programming language if I have a need to multiply the quantity 3 + >4 by 2, I should be (and am able) to do this by saying > >2 * (3 + 4) > There are ways of getting around this. Make your notation unambigous. Ever hear of RPN? You can say the same thing (most times with fewer notainons) like this: 4 3 + 2 * Can you say "anology: domains <--> RPN" ?? ------------ Jordan Hayes jordan@ucb-vax.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
david@ukma.UUCP (David Herron, NPR Lover) (07/29/85)
In article <166@plx.UUCP> adams@plx.UUCP (Robert Adams) writes: >The different nets are radically different -- some centralized, >some chaotic, some ... -- so expecting domaining (which is probably >a good solution for ARPA net) to work on Usenet (which couldn't >keep routing tables in >1000 sites together) is crazy. Besides, >I don't think there exists a parser that could handle all the >@'s, !'s, %'s, ^'s, and everything else that would work all >the time. But ... but ... it doesn't have to keep routing tables for > 1000 sites (If everybody's domained properly). The point of domaining is knowing that you have an address druxa.ATT.UUCP. You don't know that druxa is in Denver, but you know that this guy in columbus knows how to get mail to all the ATT sites. So you send it to him. Simple. eerrr.... I don't know where you got ^ as a network character. -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david
david@ukma.UUCP (David Herron, NPR Lover) (07/29/85)
In article <4787@mit-eddie.UUCP> gds@mit-eddie.UUCP (Greg Skinner) writes: >I have always held that there should be precedence-specifying characters >(i know parens are already in use, but we could use another character >like {, or even change rfc822, for the purposes of cross-net mailing >where domains are not yet in effect). It's not that hard to do, and it >makes sense (like in a compiler). > >I should never be restricted to expressions like > >2 * 3 + 4 > >in my programming language if I have a need to multiply the quantity 3 + >4 by 2, I should be (and am able) to do this by saying > >2 * (3 + 4) > >I shouldn't have to worry about my context (am I in a *-over-+ >environment, or not?). Similarly, if I'm on a machine that has >!-over-@, I should be able to get my UUCP mail through another ARPA >machine if I need to, e.g. > >{allegra!friend}@harvard.arpa I agree ... However, the way I read rfc822, the <> characters do what you want. Your example becomes <allegra!friend>@harvard.arpa And there's other ways using rfc822 to specify routing. Like, @harvard.arpa,friend@allegra.uucp will work. (I may not have that EXACTLY correct... the , may be a : f'rinstance). The real problem is that not everybody will convert to rfc822 mailers. -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david
jer@peora.UUCP (J. Eric Roskos) (07/29/85)
> THINK NAMESERVER. > THINK DOMAIN. Think of the following letter, one day in your mail... Dear Mail Administrator, Due to escalating costs, our site is no longer able to continue its policy of serving as a no-charge nameserver. Our management has decreed that we must begin operating in a self-supporting mode within 6 months. Therefore, although you have been routing all your mail through us for the past year, we must discontinue providing this service to you on a no-charge basis. However, in cooperation with the 5 other sites serving as nameservers in the US, [we have formed a new, non-profit organization / who, fortunately, are all owned by Acme Communications, Inc], we have arranged to continue to provide this invaluable service for the low cost of only $x.xx/minute connect time. We know you will find this low-cost, convenient service of great benefit in keeping your organization's communication in step with our fast-paced world. You may also want to speak to our salesman, Joe Smith, about our new line of computers, terminals, and communication devices, especially optimized to UUCP communications; or our PC software, which simplifies communication with our powerful new mailer, HooplaDooBee, available for the low licensing fee of only $xx,xxx.xx. Now, this may in fact become necessary. It may be inevitable. But it's an eventuality you have to bear in mind, when you start to move more and more towards centralized mail delivery sites. It's how CSnet works now. ------------- Disclaimer: the above is all science fiction, and it should not be believed for a moment. It certainly probably has nothing to do with my company's opinion. -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Vg vf Pvonpuebzr'f fcrpvsvp, haybiryl dhnyvgl gung znxrf vg nofbyhgr- yl evtug gb gubfr sbe jubz neg arrq abg cyrnfr gur rlr, be va nal bgure jnl frqhpr gur frafrf..." -- B. Rqjneqf, Nz. Cubg. 15(1) 7/85
honey@down.FUN (Peter Honeyman) (07/29/85)
jordan, networks don't have to be dissimilar. they simply are dissimilar. peter
honey@down.FUN (Peter Honeyman) (07/29/85)
jordan, first you suggest "jordan@ucb-vax.BERKELEY.EDU -- end of discussion" then you propose RPN as a panacea. so did you mean jordanucb-vaxBERKELEYEDU@..? peter
sob@neuro1.UUCP (Stan Barber) (07/29/85)
In article <4786@mit-eddie.UUCP> gds@mit-eddie.UUCP (Greg Skinner) writes: >I have always had a problem with sendmail/pathalias optimizing a path I >didn't want optimized. Sometimes, I want to see the message go through >the entire path of machines, and other times I happen to know a few >things about the route to the destination machine that pathalias doesn't >know about (like hosts not necessarily in the pathalias tables). I do it by configuring sendmail to pass the address through as is if the first host is a neighboring uucp site. It will only route via a pathalias generated path if the first host in the path is not a neighbor (i.e. not in L.sys) OR if the address is of the form user@host.UUCP If you like, I will send a copy of the configuration file to you. -- Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed Olan ARPA:sob@rice.arpa here are ONLY mine & Barber CIS:71565,623 BBS:(713)660-9262 noone else's.
zben@umd5.UUCP (07/30/85)
In article <536@down.FUN> honey@down.FUN (Peter Honeyman) writes: >let me join in hedrick's request that gateways between dissimilar >networks do the dirty work of translating between addressing styles. >then i'll send him mail at topaz!rutgers!hedrick, and he'll send me >mail at honey%princeton@topaz; naturally, the gateway at topaz will >translate the addresses as they pass through. > >i must disagree with his suggestion that we tie transport to syntax: >graph traversals are everything. give me a sequence of hosts, in any >damn syntax you please, and i'll betcha i can get the mail through. >but on the whole, hedrick is right on the mark. > Agree. A least-common denominator between most (all?) networks is an ordered list of site names (followed by a user name, to be sure). The exact syntax is irrelevant: @umd2,@maryland:user@eneevax user%eneevax%maryland@umd2 umd2!maryland!eneevax!user Specify exactly the same information: the message is to go to machine umd2, then to maryland, then to eneevax, then to the specified user. Unfortunately, when rooted at say UMDA (IBM 4341) this path involves bitnet from umda to umd2, arpa from umd2 to maryland, and uucp from maryland to eneevax. This is not a misuse of the arpanet, as the link from umd2 to maryland is entirely our local etherstuff, and never passes through an arpa tip or imp or whatever. I tell the people on umda to send mail to: maryland!eneevax!user@umd2 BitNet gets it to umd2, where my software lives. I fudge translate the "maryland!eneevax!user" string to "eneevax!user@maryland" in the arpanet send program itself, just to get it up there. If the mailer at umda were just a LITTLE bit smarter I could have them code it as: umd2!maryland!eneevax!user and be done with it. This scheme is based on a subroutine to extract the "next" site name from an address, and to return the "rest" of the address (remaining site names, or just user name). The only arbitraryness is in which order it looks for each syntax - I do @ first, then %, then !, then RFC733 (user AT site) ugh but advisories from the IBM machines come back in that syntax so I gotta do it. Conclusion/summary: visualizing mail addresses as an ordered list of sites, followed by a user name, is a useful abstraction, and can be used to some effectiveness when multi-net addresses must be processed. -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA
avolio@decuac.UUCP (Frederick M. Avolio) (07/30/85)
In article <11500001@unido.UUCP> dfk@unido.UUCP (Daniel Karrenberg) writes: >I admit this was rather lengthy, so let me repeat the morale: > 1) don't mix ! and @ In article <1084@diku.UUCP>, kimcm@diku.UUCP (Kim Christian Madsen) writes: > One of the pleasant news I've got earlier this year was that many, > backbone sites are doing a rerouting of the paths to a given site. > ... > Now I can relax and say > mcvax!user@site.domain First, I agree... do not mix ! and @ because it is ambiguous -- you can never be certain how someone down the line will interpret it. For my money, I'd go with (h!j!k!...z)@n.d since RFC-something-or-other makes a case for it (I think). Consequently, Daniel, you cannot say mcvax!user@site.domain and be sure of how it'll come out, but sites should strive to handle an address such as mcvax!site.domain!user. Furthermore, many "backbone" sites are *not* doing rerouting. There should be a set of well-advertised sites which do and will (it is pretty cheap to do). I hope this is a by-product of some of the work The UUCP Project is doing. Anyway, some folks would think me radical. I mean I think it is *never* proper (well almost never) to change anything in the header of a mail message passing through -- only the "envelope" should be touched. The only exception is a gateway site cleaning up addresses (such as we do -- we change any node::user to user@node.DEC for mail coming from DEC's Enet). Fred.
honey@down.FUN (Peter Honeyman) (07/30/85)
robert adams reminds us that "Rob Pike, in a USENIX presentation, brought up the point about why would we want to have a single addressing format." in that talk (and in their paper) pike and weinberger deplore rfc819 syntax. bangist (or uucp) notation appears to be the only one in widespread use that is simple and uniform. peter
honey@down.FUN (Peter Honeyman) (07/30/85)
greg skinner proposes an "Optimize: n" header, presumably for sendmail. what is this disease? are we talking about the same thing here? explicit routing? as in uucp source routing? if so, please explain why you expect, or even desire, some faraway mailer to reroute your messages. if not, please tell me what optimization means for implicit routes. peter
jsq@im4u.UUCP (07/30/85)
UUCP requires the user to supply source routing. Practically no other
widely-spread network does. Not the ARPA Internet, not BITNET, not the
XEROX Internet, not PUP nets, not the Australian ACSNET, etc. You can
*do* source routing in the ARPA Internet, but hardly anybody ever
does: not because the syntax to do it is arcane (which it is), but
because there's no need.
In the current state of the world, you need source routing to get
*between* networks, e.g., user%host.CSNET@csnet-relay.ARPA. Given
domains and domain name service, which are gradually actually coming
into use, the source routing (and the %) disappears, and there is only
user@host.SUBDOMAIN.DOMAIN, e.g., jsq@sally.UTEXAS.EDU. A person
can then have one network address in domain style instead of two
or three in various different syntaxes. An absolute address which
does not vary depending on what host or network it is being used from.
Restrained flame:
Except possibly for UUCP, where some people are for some reason
enamored of personally controlling the paths their mail takes (system
administrators have to control what goes in and out of their machines,
to some extent, to control their phone bills, but why should ordinary
users care, and why should it be done at the application level?). And
where people complain bitterly that domains are being forced down their
throats. Well, that's not what it looks like to me. It looks to me
like some UUCP advocates are trying to force explicit source routing on
networks which don't need it. Why is this? Practically every other
network has gotten along without users having to do explicit source
routing for many years.
Peter Honeyman brags that he has written the best version of UUCP and
the best UUCP path finder. Well, that's admirable. But even the best
version of UUCP is still a kludge, because it does not support implicit
routing, and even the best version of pathalias is still a patch to fix
the problem of UUCP not having implicit routing. ACSNET has shown that
implicit routing is possible in a network supported by the same sorts
of underlying network connections as UUCP (maybe it won't scale up, but
then, maybe it will, too: maybe we should try it and see). Even given
UUCP as is, pathalias used to provide routing underneath a domain
naming scheme can make UUCP fit in with the rest of the world, where
UUCP and pathalias used to try to make the rest of the world look like
UUCP cannot. I agreed with the idea of smart gateways translating
syntaxes between networks, for a while, but there are just too many
problems with that idea (basically, no absolute naming, and differing
host name syntaxes), which have recently been described by others in
this newsgroup.
Rob Pike complained (at the Portland USENIX) that domain naming uses
too many special syntactic characters and is thus ugly, and furthermore
that it doesn't allow relative addresses. Well, this is ugly:
user%host.DOMAIN@host.DOMAIN, and even uglier if you mix in some !s.
But the % is a temporary kludge, one hopes, and the !s could go away,
leaving user@DOM1.DOM2.DOM. That still includes two separators, it's
true, and user.DOM1.DOM2.DOM might have been better. However,
it supplies absolute addressing, which UUCP syntax cannot.
Why should the defects of UUCP be foisted on the rest of the world,
which has gotten along quite well without them for many years?
--
John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET: jsq@ut-sally.ARPA, soon to be jsq@sally.UTEXAS.EDUjer@peora.UUCP (J. Eric Roskos) (07/30/85)
Recently, the argument over how to specify addresses has begun to flare up
in this usually peaceful newsgroup again.
Now, this is a necessary thing -- it is getting harder and harder to route
mail, making it necessary to declare more and more "smart mailer" sites
dead in our local UUCP map in order to get the mail through (since very
few of these sites handle the new "All-!" syntax correctly yet).
The problem is, whenever this issue comes up, everyone starts making arguments
that make no sense. One person starts repeating "domain, domain" endlessly;
another shouts "addresses are not routes" (substituting other synonyms
whenever anybody catches on) to anyone who posts a message; and even those
who appear to know what is going on begin bickering endlessly.
It seems to me the following are at issue here. I've written the issues
first, then gone back and written in my OPINION in brackets so you can
delete it (humph, he's just a lowly uucp site way out there on the periphery,
what does he know about the true enlightenment possible with Sendmail!) and
just have a plain list of issues.
1) The ancient issue of the "ambiguity" between "!" and "@". Because some
people run all their routing information through one parser, they can't
handle the fact that during transmission via UUCP, the routing syntax is
<nextsite>!<interpret-later>, whereas during transmission via other means,
it is often <interpret-later>@<nextsite>.
[But the real problem is just that we are dealing with different networks
here, which until they were gatewayed together had no problems. Furthermore,
except for unusual routing cases, once they were gatewayed, it was still
possible very effectively to send mail following simple syntax rules,
until people started using "intelligent" mailers that made these syntax
rules many times more complex.]
2) Some people throw away any routing information they get, and go for the
message header. This is a problem given the fact that one is allowed to
default the domain, since they have to then know the domain of the originating
site to interpret the address correctly.
[My opinion is that you should never look at the message header until all
other avenues fail. In the UUCP network, you are always given some routing
information in the uux command line. Unless this is unusable, there is no
reason to look at the message header at all.]
3) Some people edit the headers, when they are not the originating site.
They then complain because proposals others are making don't fit well with
this idea.
[This is a major, serious error, and is why I have special code in our mailer
to avoid seismo wherever possible, for example. You should never edit the
header on messages. It makes it impossible to see who the message was
sent to originally. (You can tell how to get it BACK via the "Return-Path",
which you have if you aren't using a mailer that throws away all that
information.)]
4) Some people feel that "esu!cs!joe" is a route, whereas "joe@CS.ESU.UUCP"
is a "domain", and that the latter does not specify any routing information.
They feel domains simplify how much information you have to keep at your
site. When pressed to explain how this works, they say, "Simple! You just
send to your local UUCP name server, who then sends to the ESU name server,
who then sends it to system CS, who sends it to joe."
[Of course, domains are routes; the only difference is that part of the
route is ambiguous: one of several name servers at a particular level may
exist. Domains are only theoretically "just addresses" because they do not
HAVE to be interpreted as routes; but Peter Honeyman has pointed out that
neither do uucp addresses. You can THINK of domains as simply addresses;
that is one model of them. But at the implementation level, you have to
interpret them as routes unless you have the entire map of all sites local
to you so you can generate the entire route yourself. If you have to get
someone else to do it, implicitly the domain information becomes routing
information.]
5) Some people are confused about whether or not they should "optimize"
routing. This means that they are confused as to whether, given a route by
which some previous system has said to send the mail, they should decide on
their own to send it instead by some other way: either by deciding to route
it on another net instead, or by deleting some of the sites in the UUCP
path. Some complain that some sites optimize; some complain that all sites
don't, or that they can't find the ones that do.
[My feeling is that you should never optimize routing. If a route is given
that is unoptimized, either (a) the sender has problems (see 6), (b) the
sender has some political reason for the routing (e.g., maybe some site has
complained "do not send your mail greater than 16K through our site!"), (c)
the sender knows something you don't. Our mailer here currently never
optimizes a route unless the sender delivers it to our site with only an
RFC822 address remaining in the routing information, or unless the next
site on the route is not adjacent. I don't think you should be giving
unsolicited "help" to other sites in their mail routing.]
6) Some people use USENET software which tries to send a mail message back
on the path by which it came, which can be highly suboptimal.
[If you have RFC822 addressing in your mailer, this problem disappears. Our
mailer here, for example, has the INTERNET option turned on in the Usenet
software because we generate routing information from the RFC822 address.
In any case, this is a bad problem with the Usenet software, and should be
solved there.]
7) Some people feel that UUCP should be just like the "real" networks in
terms of naming and routing.
[UUCP is a cooperative, distributed network. Having "real" addressing
requires centralized mail delivery sites. When you centralize in that way,
you lose one of the key qualities of UUCP. I suspect that as the user load
increases, UUCP will indeed change. But that is a whole different issue,
for a different line of discussion.]
8) Some people feel all gateways should rewrite addresses for the network
they are gatewaying onto.
[This doesn't currently work, and I believe from experience it will never
work. Some gateway sites either "don't care" about UUCP, or are barely
hanging on already due to staff shortages. The Mailnet gateway is an
example. Furthermore, it is unreasonable to expect all gateways to
understand everything there is to know about all other gateways. If you
specify addresses via a <locally-interpreted><later-interpreted> or <later-
interpreted><locally-interpreted> syntax, each site has to interpret only
one part of the address. Otherwise, it has to interpret all parts. It is
unreasonable to expect it to interpret all parts, especially when it is so
easy, by simply deciding on a few simple LR or RL rules, not to do that.
People are already complaining "What is this "%" syntax? What is this
"^"?" That is exactly symptomatic of the problem. The <later-interpreted>
part of the route should be just a string to the mailer interpreting the
<locally-interpreted> part. There is no reason nor justification for
requiring otherwise; it makes the mailers unduly complicated, since they
must always know about all other networks in the world that they are
connected to. I can tell you firsthand they don't, and never will.]
9) Non-unique site names exist.
[This is a definite problem. Both proposed approaches solve it, since
we've just shown that the two approaches are theoretically equivalent,
differing only in their CURRENT implementations: interpreting a!b!c as an
address, and c@b.a as an address, you arrive at an unambiguous site name.
The current argument seems based on the fact that people claim these two
equivalent address syntaxes are not equivalent, and then try to argue from
that. But they are equivalent. Both are both routes and addresses.]
[Most of the problems would go away if people would just think about them
in a coherent manner, adhering to one chosen viewpoint instead of constantly
changing their stance. This is why these arguments proliferate for so long.
People won't stick to what they believe. You can't make a reasonable argument
from contradictory premises; yet this happens very regularly.]
--
Shyy-Anzr: J. Eric Roskos
UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail: MS 795; Perkin-Elmer SDC;
2486 Sand Lake Road, Orlando, FL 32809-7642
"Fvzcyvsl, fvzcyvsl." -- UQGchuqui@nsc.UUCP (Chuq Von Rospach) (07/31/85)
Well, I was hoping to get some advice or answers on the routing problem. It
looks like all I've done is start another in an endless series of Usenet
arguments. Please consider my previous question unasked -- if you all wish
to continue arguing (how can I stop you?) then feel free, but I was hoping
for something other than a religious discussion. Hmm... I remember a time
when you could get reasonable information from the network...
depresssed,
chuq
--
:From the carousel of the autumn carnival: Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA
Your fifteen minutes are up. Please step aside!jordan@ucbvax.ARPA (Jordan Hayes) (08/01/85)
In article <543@down.FUN> honey@down.FUN (Peter Honeyman) writes:
jordan, first you suggest "jordan@ucb-vax.BERKELEY.EDU -- end of
discussion" then you propose RPN as a panacea. so did you mean
jordanucb-vaxBERKELEYEDU@..?
Peter... too cute for words... unfortunately, while you were studying
directed graph theory, you neglected number systems. Too bad that
in RPN there are separators (spaces) so that
4 3 2 + *
is unambiguous (i.e., isn't really "43 2 + *" or similar...). Thus
in the example above, "@" and "." are separators (to carry the analogy
further than need be taken...)... In the BNF spec (rfc819, in case
you aren't familiar with the literature), a mailbox is defined as
<mailbox> ::= <local-part> "@" <domain>
so that the "@" is a meta-character that separates the local part
from the domain, for the purpose of using the domain part in other
applications... "@" and "." are not, as you have suggested,
OPERATORS.
I am not saying that Polish Postfix has anything to do with domaining,
but merely pointing out that there are sometimes better ways of
breaking up an ambiguity than by specifying precidence with
parenthesis (or {} for that matter, as csh treats them special,
as it does with !...).
Sorry to all you who KNEW this already, but I thought I'd better
make sure Peter isn't at a disadvantage in this discussion.
re: dissimilar networks... Well, just because they are doesn't mean
they have to stay that way. You still have not presented a valid
reason why UUCP cannot (and/or shouldn't) be domained.
------------
Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU
UC Berkeley ucbvax!jordan
+1 (415) 835-8767 37' 52.29" N 122' 15.41" Wrs@mirror.UUCP (08/01/85)
>Why should the defects of UUCP be foisted on the rest of the world, >which has gotten along quite well without them for many years? >-- >John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq Maybe becuase we're bigger and older? :-) -- Rich $alz {mit-eddie, ihnp4!inmet, wjh12, cca, datacube} !mirror!rs Mirror Systems 2067 Massachusetts Ave. 617-661-0777 Cambridge, MA, 02140
jordan@ucbvax.ARPA (Jordan Hayes) (08/01/85)
John -- wonderfully put, but there's more to be said... >In the current state of the world, you need source routing to get >*between* networks, e.g., user%host.CSNET@csnet-relay.ARPA. Well, not really. Here I can do user@host.CSNET and our sendmail takes care of where to resolve it to (namely the csnet-relay, but it could be anywhere -- how many times have you seen people put the WRONG relay in their return address... I've seen many who say user%host.csnet@rand-relay or user%host.bitnet@BERKELEY...). These are decisions that are best made by administrators, not users. >But the % is a temporary kludge, one hopes, and the !s could go away, >leaving user@DOM1.DOM2.DOM. That still includes two separators, it's >true, and user.DOM1.DOM2.DOM might have been better. However, >it supplies absolute addressing, which UUCP syntax cannot. Well, the local part is separate from the domain part for a good reason, namely, other applications... >Why should the defects of UUCP be foisted on the rest of the world, >which has gotten along quite well without them for many years? GOOD QUESTION. There has not been one good reason given. ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
jordan@ucbvax.ARPA (Jordan Hayes) (08/01/85)
In article <1383@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >> THINK DOMAIN. > >Think of the following letter, one day in your mail... > > Dear Mail Administrator, > <I'm sure you all read the letter...>? Hmmm. Well, any site can do this now. If they did, I would take my mail elsewhere. The fundamental principles that guide UUCP can guide us into the 21st century if we care to see it happen. Where do you get the idea that I am proposing anything remotely resembling CSNET? CSNET is not domained, nor was there any discussion of a central mail machine. No new sites need connect. No one need bother dis-connecting. Things go on like normal, only the namespace has been changed to reflect a distributed view of the world. ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
jordan@ucbvax.ARPA (Jordan Hayes) (08/02/85)
In article <1386@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >4) Some people feel that "esu!cs!joe" is a route, whereas "joe@CS.ESU.UUCP" >is a "domain", and that the latter does not specify any routing information. >They feel domains simplify how much information you have to keep at your >site. When pressed to explain how this works, they say, "Simple! You just >send to your local UUCP name server, who then sends to the ESU name server, >who then sends it to system CS, who sends it to joe." That is not the correct answer. However, the answer is, of course, both simple and elegant. It goes like this: check your table to see if you have a gateway for CS.ESU.UUCP (which would only be true if you had a local connection to it...). If so, resolve there. If not, check to see if you have a gateway for .ESU.UUCP, which you'd have to have, even if you were a simpleton site that had only one connection to bounce to, since .ESU is the "top-level" for UUCP, an artificial domain set up for our purposes (shhh... don't tell anyone...;-) There's no reason to send everything you have to a UUCP central server. ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
jww@sdcsvax.UUCP (Joel West) (08/02/85)
> I have always held that there should be precedence-specifying characters > (i know parens are already in use, but we could use another character > like {, or even change rfc822, for the purposes of cross-net mailing > where domains are not yet in effect). It's not that hard to do, and it > makes sense (like in a compiler). > I shouldn't have to worry about my context (am I in a *-over-+ > environment, or not?). Similarly, if I'm on a machine that has > !-over-@, I should be able to get my UUCP mail through another ARPA > machine if I need to, e.g. > > Greg Skinner (gregbo) > {decvax!genrad, allegra, ihnp4}!mit-eddie!gds > gds@mit-eddie.mit.edu Some people would like to make this needlessly complicated. If one really wishes to support the full range of addresses out there, it's already a mess. We have sendmail out there. It can be modified to handle most of the existing schemes without adding a full syntax scanner for an expression evalutor. We have enough V7, Xenix, System III and System V sites out there to support that adding something (braces) that will break the smartest (BSD, sendmail) mailers yet in existence would assure that nothing would work for years. Tell me, what are the odds that someone along the way won't understand "{"? If one were to adopt unambiguous left-to-right AND right-to-left parsing rules, there's no reason that anyone should ever need parenthesis. For example, suppose I'm a non-UUCP arpa site that wants to send to ihnp4!cbosgd!mark. I could write this as ihnp4!cbosgd!mark@BERKELEY Of course, mark might have to reply ihnp4!ucbvax!myname@mysite.ARPA (excuse me, the name is changed) So far, no good--the "@" has top precedence in the 1st example, lowest in the 2nd. However, why couldn't these two be: berkeley!ihnp4!cbosgd!mark ihnp4!berkeley!mysite!myname or, if you like 822, the perfectly valid mark%cbosgd%ihnp4@berkeley.ARPA myname%mysite%berkeley@ihnp4.UUCP The first is completely compatible with every UUCP site in the world. The second is compatible with nearly all Internet Sites, any sendmail site, and the dictates of NIC and RFC 822. Why should it matter whether the connection between two sites is the ARPAnet, a 10 MB/sec ethernet, a 20-foot RS-232 cable, a time-restricted 1200 baud auto-dial modem, or a wombat carrying punched cards? Given all the transport mechanisms that are and will be used, I think the "!" vs. "@" distinction is becoming obsolete. Either solution could be adopted without any more software changes (come 'on, folks, the existing system doesn't work as it is--don't break it further). The only requirement is that each site know who it can talk directly to and how it should do so--a not unreasonable requirement for anyone who calls himself a system administrator. ----- Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA PS: I have a personal bias towards pathless geographic subdomains but it appears domains and UUCP, like oil and water, don't mix.
jordan@ucbvax.ARPA (Jordan Hayes) (08/03/85)
One of the problems with specififing ihnp4!cbosgd!mark@berkeley is that cbosgd could have an unknown connection to ucbvax through which the admins at ucbvax/cbosgd would like things to go, rather than taking the extra hop (and time and money...) through ihnp4. Now, all you people out there who mail things to Mark could say, "Hmmm... guess I'll read the map entry for ucbvax before I mail...", but more likely, just send it off to that other address, whereas, if you send to mark@cbosgd.ATT.UUCP and it winds up on ucbvax, the decision to route to that domain has been made locally, and will do the right thing. Pathalias does in fact clear up many problems like this, granted, but only if everyone has the current map. There are a lot of lazy system admins out there who will change their L.sys (because mail won't work without it) and NOT update their map entry (if they have one). If the table for mail resolution is built into the systems (as the info in L.sys is), there is no choice but to keep your site current, and everyone can assume that if it will go through at all, you will do it. As opposed to pathalias, which will give a path only if the map is current, but other ways of getting to a site possibly work (undocumented). ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
mvs@alice.UUCP (Mark V. Shaney) (08/04/85)
One of the pleasant news I've got earlier this year was that many,
backbone sites are not doing rerouting. It behooves addresses to
rewrite, and cannot. Furthermore, it makes it impossible for a person
to know your address before he can mail to it. Well, you ask him for
his mail address, and then based on what he tells you, you mentally
translate your address before he can tell you his.
The point I am not making in the header of a mail message was sent to
me. Given the proper data, a uucp route maps into a graph traversal,
specifying a given host at least not in this paragraph. Obviously any
connected undirected graph can be degrees of "smartness." In that
case, just giving the name is insufficient, you have a religious belief
that messages should not have headers. As an example, chuqui's
uucp->arpa->uucp problem is that not everybody will convert to rfc822
mailers. The only exception is a by-product of some of the dreaded
arpanet. By introducing {}'s and maintaining the same trick 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.
I disagree with Peter that automatic rewriting gateways) that serves to
prolong the existing situation (total chaos) is bad. Peter's solution
to that is more than routes, they're addresses.
Robert Adams reminds us that "Rob Pike, in a compiler". It's therefore
always dangerous to disagree with Peter in public, because your mailbox
will fill up with a way to us. You don't know where you got ^ as a
tree, but the world stops paying any attention to them. If you are
(even princeton), you should send me mail at topaz!rutgers!hedrick, and
he'll send me mail at "jordan@ucb-vax.berkeley.edu". end of
discussion.jer@peora.UUCP (J. Eric Roskos) (08/04/85)
> If not, check to see if you have a gateway for .ESU.UUCP, which you'd have > to have, even if you were a simpleton site that had only one connection to > bounce to, since .ESU is the "top-level" for UUCP, an artificial domain set > up for our purposes (shhh... don't tell anyone...;-) > > There's no reason to send everything you have to a UUCP central server. I think if you do this, you have some real problems. If you have only one connection, your routing is trivial, so that is not a good example. If you have two or more connections, either you have to know the path to ESU (even if that path is just the name of the next site down the line, which I think it can be shown requires that you need to know the entire path, even if it's not kept in your database), or you have to guess. If you guess, you could guess wrong quite easily. It is easy to demonstrate this. Consider an imaginary UUCP network in which the graph is partitioned into two disjoint subgraphs except at your site, which connects the two. Well, you have to choose one of the two connections you have, and if there are an equal number of sites in each of the subgraphs, half the time you will guess wrong. If you do better than that, either you have to have: (a) a map of the whole name space, in some form, or (b) a smaller map of some central nameservers (or an arbitrarily chosen nameserver for each subdomain, in my "distributed" example from my previous posting). (a) is what you are arguing against all a long, and (b) is what you just claimed you don't need. Thus the only alternative is that you must guess, and some proportion of the time, you will guess wrong, which is what I set out to show. In the real world, of course, the graph is not partitioned so neatly; this reduces the probability that you will guess wrong, but does not by any means reduce it to zero (or even close to zero, I don't think). -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Vg frrzf yvxr hc gb zr."
honey@down.FUN (Peter Honeyman) (08/05/85)
john asks "why should the defects of UUCP be foisted on the rest of the world", to which jordan voices approval. i don't recall any suggestion that the internet abandon their scheme. i have no experience with the arpanet (i must be the only person in the world), but from here it seems to work just fine (except every few years they say "ok everybody, CHANGE PROTOCOLS!" or "ok everybody, CHANGE HOSTNAMES!" but i'm sure there is good reason for this strange practice). i have, on the other hand, heard many suggestions that the uucp world adopt the internet style, in host names, in administrative practice, and in addressing. keep in mind that the "... defects ... foisted ..." argument is a blade that cuts both ways. peter
jer@peora.UUCP (J. Eric Roskos) (08/05/85)
> For example, suppose I'm a non-UUCP arpa site that wants to send to > ihnp4!cbosgd!mark. I could write this as > ihnp4!cbosgd!mark@BERKELEY > Of course, mark might have to reply > ihnp4!ucbvax!myname@mysite.ARPA (excuse me, the name is changed) > So far, no good--the "@" has top precedence in the 1st example, > lowest in the 2nd. Why? Who says that Mark has to write paths with the same syntax you do? [We're assuming that for some reason Mark actually wants to write the path, instead of an address -- which may well be a valid assumption sometimes.] Without getting into endless repetition, it is perfectly reasonable that on your "non-uucp" network, "@" might have precedence over "!". It is also perfectly reasonable that "!" might have precedence over "@" on Mark's. It is only unreasonable when, for some reason, you require a uniform path language for both networks. > However, why couldn't these two be: > berkeley!ihnp4!cbosgd!mark > ihnp4!berkeley!mysite!myname > > The first is completely compatible with every UUCP site in the world. Because the latter example requires that "berkeley" know how to translate "mysite!myname" into a routing or addressing format that is correct for your network. This is especially hard when the destination site is not on the network the UUCP gateway connects to -- i.e., when an intermediate network has to be used to get to the final destination network. By way of example, consider the following. Suppose I am on UUCP. There is another network -- and let's say it's some sort of secret network you at the UUCP gateway can't get the specifications for -- that is gatewayed to the ARPAnet. Now, how would Berkeley know that ihnp4!berkeley!nudet.ABC!gmas was to be translated to seclia##tnwmon#nudet#gmas@ABC-GW.MIL Furthermore, suppose ABC-GW.ARPA doesn't really care about UUCP at all. So you can't send them nudet.ABC!gmas@ABC-GW.ARPA and expect them to convert the UUCP address for you. (I.e., ihnp4!berkeley!abc-gw.MIL!nudet.ABC!gmas would not work for this reason.) Having them do this would require that they acknowledge sufficient importance of the UUCP network (or of the sender) to invest the effort to make ABC-GW recognize nudet.ABC!gmas and translate it appropriately -- something they may well not be willing to do. The point is, the amount of knowledge required by UUCP gateways is substantially increased if you require gateways to translate pure-UUCP paths into acceptable paths (or just addresses) for arbitrary other- gateways, especially if the destination address is not on a network directly accessible to UUCP. Alternately, it requires that non-UUCP gateways into other networks have knowledge of the UUCP addressing syntax. (The difference being that in the first case, your UUCP gateway generates the complete address as it would appear on the network you are gatewaying onto; in the latter case, you just put the leftover part of your UUCP path into the local-part of the address for the next gateway down the line and require it to make the translation.) -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Frr ubj Tbq jvgu uvf yvtugavat nyjnlf fzvgrf gur ovttre navznyf, naq jvyy abg fhssre gurz gb jnk vafbyrag; juvyr gurfr bs n yrffre ohyx punsr uvz abg." -- Negnonavf
jsq@im4u.UUCP (08/05/85)
In article <6900002@mirror.UUCP> rs@mirror.UUCP writes: >>Why should the defects of UUCP be foisted on the rest of the world, >>which has gotten along quite well without them for many years? >>-- >>John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq > >Maybe becuase we're bigger and older? :-) Ah, I see. The UUCP net has been around since 1969 (the beginning date of the ARPANET) or earlier. And all this time I thought Version 1 UNIX was written in 1969 and UUCP in about 1978. As for bigger, no doubt I counted wrong the last time I looked and saw that the ARPA Internet, the XEROX Internet, DEC's net, and IBM's VNET are each about the same size as the UUCP net. I'd guess by your smiley face that you were kidding, but there seem to be people who believe all that. PS: Some people have interpreted my original posting, especially the part quoted at the beginning of this article, to mean that I think that some people are trying to make, for instance, the ARPA Internet use UUCP routing syntax internally. I don't believe that. I do believe that the refusal of some people to accept anything better than old-style UUCP bangist source routing for internal UUCP network use puts an unnecessary burden on all gateways between UUCP and more rational networks, not to mention an unnecessary burden on anybody who has to send mail inside the UUCP network. Domains are not a horrible nasty military plot which outsiders are trying to impose on UUCP. They are a possible solution to many of the problems of UUCP which some insiders are trying to incorporate. They don't limit the flexibility of the network, either: they increase it, since connections inside a subdomain can change without the outside world having to know, much less wait a month for a global map to be updated. Trivia item: the majority of the registered hosts in the ARPA Internet run UNIX. -- John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq ARPA Internet and CSNET: jsq@ut-sally.ARPA, soon to be jsq@sally.UTEXAS.EDU
david@ukma.UUCP (David Herron, NPR Lover) (08/06/85)
In article <1422@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >UCBVAX.BERKELEY.EDU and UCBVAX.CSNET, for example. They are addresses for >separate networks; but at the user interface, they come together, and you >have this problem. No. You make a common mistake here. It's a mistake of visualization. One that I don't have clearly in my mind either. The problem is that the first implementation of domaining had the domains be equivalent to networks. But you can't do this because (as you said) machines exist on more than one network. (We're already on two, uucp and bitnet, hopefully soon we'll be on csnet, fr'instance.) The current implementation of domains (UCBVAX.BERKELEY.EDU) has them completely seperate from the underlying networks. The host tables have entries explaining which network to use to get to site X. And so forth. So, there is ONLY ucbvax.berkeley.edu. ucbvax.arpa and ucbvax.bitnet and ucbvax.everything.else no longer exist (except as names kept around till people fix things up to look right). As for the rest of your points. I see what you're saying. It does look like somebody could gain control of the net and charge fees. In one sense, maybe that would be the best way to handle the explosion of users. (Our budget could certainly use some capital infusion). But, take a look at the map files sometime. Sure AT&T has half the map. (You *were* implying that AT&T might want to grab the net weren't you? Don't they have it already?) But notice that a LOT of traffic is handled by non AT&T sites. gatech, ucb, sdcsvax, etc. There's enough handled by extraneous people that any one party would have a hard time gaining this control you warn against. I'd like to hear more though. -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david
chris@columbia.UUCP (Chris Maio) (08/07/85)
In article <1423@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: > : > b) NEVER edit existing lines in the message header. This doesn't mean you > can't add lines (e.g., "Received:" lines, etc.), but you should not > make transformations in the syntax of the addresses in the header, etc. > [I have seen dozens of these transformations made in mail that gets > returned to me for one reason or another; they are almost invariably WRONG.] > The originating mailer should provide a unique and unambiguous return > address (not path) telling who the message is from; if it doesn't, it is > the originating mailer's problem, not yours. > : Header rewriting is done precisely because "originating mailers" don't provide universally acceptable addresses. If you don't like the way header rewriting is done, just send mail to the postmaster at the offending site. Would you prefer to have the site return your messages to you with the comment "I refuse to forward your mail because your headers are unacceptable in the destination domain"? It would be far more constructive to suggest a standard, reasonable set of rewriting rules and try to get everybody to follow them than to take the easy way out and declare that header rewriting is wrong. - chris
sob@neuro1.UUCP (Stan Barber) (08/07/85)
Hmmm. This sounds so familiar. I could have written it myself. I wish
I had. This (to the letter) is exactly what I have happening on
neuro1. I try to maintain a UUCP database for uucp routing. neuro1 can
effectively forward mail to ARPANET (although it cannot cope with
.EDU, .COM, etc. yet), to MAILNET, to CSNET and to BITNET.
Thanks for writing this. If someone wants help in actually doing it,
drop me a line.
[ I am not looking for pats-on-the-back or flames, just noting that
it CAN be done...]
--
Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed
Olan ARPA:sob@rice.arpa here are ONLY mine &
Barber CIS:71565,623 BBS:(713)660-9262 noone else's.atbowler@watmath.UUCP (Alan T. Bowler [SDG]) (08/08/85)
All this discussion about domain addressing over source routing,
and "I want to explcitly route my messages with '!'",
is ignoring the fact that RFC822 does actually does have an explicit
routing syntax.
The syntax is
<@site1,@site2,@site3 : user@site>
The standard is unclear about wheither the routing list is interpreted
left to right, or right to left, but I presume you send to "site1" first.
Parsing precedence can also be specified by use of the quoting
mechanism. e.g.
"uucpsite!user"@gatesite.network
(the message is routed automagically to "gatesite" which then
attempts to parse "uucpsite!user" relative to its own rules.)
These potential capabilities seem to be ignored in all the discussion.
Is this because:
1) I am interpreting RFC822 incorrectly, and the capabilities are not there?
2) SENDMAIL can't do either of these things, or no one has yet figured
out how to make it do this?
3) No one has ever written a full parser for RFC822 type addresses? zben@umd5.UUCP (08/08/85)
In article <1431@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >In article ? somebody writes: >> However, why couldn't these two be: >> berkeley!ihnp4!cbosgd!mark >> ihnp4!berkeley!mysite!myname >> >> The first is completely compatible with every UUCP site in the world. > >Because the latter example requires that "berkeley" know how to translate >"mysite!myname" into a routing or addressing format that is correct for >your network. This is especially hard when the destination site is not >on the network the UUCP gateway connects to -- i.e., when an intermediate >network has to be used to get to the final destination network. Maybe I'm missing something here, but it seems that in the case that an intermediate network is used for routing, the first gateway would translate the entire path into the syntax used for the INTERMEDIATE net, and the second gateway would translate FURTHER to get the format required by the third (final) network. As an example: Message starts out sent to: seismo!rlgvax!umcp-cs!umd5!umd2!umuc!luser Message transfered via UUCP until it gets to site umd5, where the remaining address string is: umd2!umuc!luser Umd5 realizes that its link to umd2 is ARPA Internet, and it rewrites the address to be: @umd2:luser@umuc When umd2 gets the message, it realizes that its link to umuc is BitNet, so address is rewritten as: luser@umuc Actually, that's not a good example. How about a UUCP-ARPA-UUCP one: Message starts out sent to: left1!left2!gatea!arp1!gateb!rite1!rite2!luser Message transfered via UUCP until it gets to site gatea, at which point the remaining address string is: arp1!gateb!rite1!rite2!luser gatea realizes that its link to arp1 is ARPA Internet, and so gatea rewrites to ARPA form: @arp1,@gateb,@rite1:luser@rite2 By the time gateb gets it, the address string has been reduced to the much simpler string: @rite1:luser@rite2 Realizing that its link to rite1 is UUCP, the gate back translates the remaining string to UUCP: rite1!rite2!luser And the rest is just UUCP again. Other than what kind of back-path this would generate, it looks like it would work... What am I missing here? -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA
jer@peora.UUCP (J. Eric Roskos) (08/10/85)
[The referenced article questions my suggestion that the current trend
in domain routing would make the UUCP network vulnerable to a commercialized
takeover. It concludes by asking where I got the idea that he wanted
UUCP to be like CSnet.]
The major distinction between CSnet and the "other networks that don't
require source routing" which another poster mentioned involves the topology
of the UUCP network.
UUCP is inherently decentralized. There are no centralized machines
responsible for carrying out message delivery; in comparison to my example
of CSnet's phonenet, which does have 2 or so machines which poll the other
machines in the phonenet to pick up and deliver mail.
Now, the proposed nameserver strategy requires such centralized machines.
People have proposed designating name-administering authorities. Besides
the overhead of paying people to run those authorities, in order to make
nameserver queries you either have to send a message out to the nameserver
and get a route back (which you then use to mail the message), or mail the
message to the nameserver, who sends it on to the next nameserver. I suspect
the latter would be the actual implementation, due to efficiency
and coordination considerations.
Now, the problems with the currently proposed domaining schemes for UUCP are
twofold. First, the currently proposed scheme is geographic. This requires
one of two things: either each machine in a given geographic subdomain has
a database of all other machines and paths to them in that same subdomain,
plus paths to some selected set of machines in other subdomains that serve
as nameservers for them (this would be a distributed implementation); or
there has to be one or two (or so) machines in each geographic subdomain
that are the nameservers (the centralized implementation). But the
centralized approach thereby makes these nameserver machines be the principal
delivery machines for the network, exactly like CSnet. Furthermore,
it provides considerable leverage for gaining control of the network as a
whole, by acquiring (or initially providing) the geographic nameserver
machines.
The second problem with the proposed scheme is that it says that if a
geographic subdomaining is not provided, then there is still a minimum
number of machines allowed to comprise a subdomain. This tends to force
a large set of independent machines to consolidate to make their own
subdomains; I suspect this would tend to occur geographically anyway, but
in any case it leaves all the independent machines in a fairly awkward
situation, since they have to "sign up" with somebody.
Now, I agree with Peter Honeyman's discussion thus far. I think a great
deal of the discussion in here is essentially moot, centered around
inexact definitions of the proposed approaches to UUCP naming and routing.
On the other hand, I can see that it is advantageous to provide something
analogous to nameservers for sites which don't have adequate disk space
to contain a complete map. I can further see that it would be advantageous
for some companies that are sufficiently large to provide their own name-
servers. (In fact, I already have this implemented in our mailer for the
ATT.UUCP domain, since AT&T is doing funny things with its forwarding of
mail lately, I guess to discourage people from routing through them for
mail not destined for an AT&T site: I send anything with the domain
ATT.UUCP to a "smart mailer" at AT&T, without generating any further
routing.)
However, I don't think this requires anything radical. In fact, if one
were to undo a lot of the mess people have made already and start over with
things the way they were before sendmail and smart mailers, I think we would
end up with a better network.
As I've observed the ongoing arguments here, I have realized one major
thing. A lot of the current problems have to do with the fact that
people's user interfaces to the mailers serve as a sort of "gateway", even
if the mailer itself is not a gateway (or "bridge," in Mark Horton's
terminology.) The problem is that a lot of the current mailers will let you
send mail via UUCP, or the ARPAnet, or some other network, all from the
same user interface, and it's kind of a problem to figure out how to do it.
I think approaching this problem first would help things out a lot. One of
my basic beliefs regarding the implementation of a successful UUCP mail
network is that networks in general should be kept separate except at well
defined gateways, and the user interfaces are NOT well-defined gateways.
That is why you have problems with a site being named both
UCBVAX.BERKELEY.EDU and UCBVAX.CSNET, for example. They are addresses for
separate networks; but at the user interface, they come together, and you
have this problem.
Discussing this problem, and how to solve it, would take another long
message, and this one is already approaching the proposed limit of 100
lines; so in a separate message, I will post some comments on solving
problems other than the user interface ones, and leave the user interface
for some other time.
--
Shyy-Anzr: J. Eric Roskos
UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail: MS 795; Perkin-Elmer SDC;
2486 Sand Lake Road, Orlando, FL 32809-7642
"Vg frrzf yvxr hc gb zr."jer@peora.UUCP (J. Eric Roskos) (08/10/85)
In my previous posting, I promised to suggest an approach to simplifying
the UUCP routing problem. Here it is. The following are a set of basic
principles I think would help make the UUCP network work better. I hope
you can comment constructively on them, rather than just arguing some more.
The following discussion assumes that you have received a piece of mail
via UUCP.
1) Do not modify any routing information you have already been given. I.e.,
if in your uux'ed command you received from the previous site, there is
some a!b!c... path, do not try to "optimize" it. Assume that, for whatever
reason, the information you have been given is correct. If it's not, it
is a problem of the site that generated the routing. Giving unsolicited
help only complicates the problem.
2) In the routing information you have been given, if the next site on the
path is adjacent to you, deliver the message via UUCP to that site.
(Remember, this assumes it came via UUCP. If it came by another transport
mechanism, you should use that transport mechanism's delivery rules.)
3) If the next site on the path is NOT adjacent to you, this is a
nameserver request. This is the alternate case to #1 above; i.e., this
constitutes a REQUEST for help, which you can give if you are able. If the
named next site does not contain a ".", generate a path to the site and
prepend it to the path you've been given, if you can. If you can't, return
the mail as undeliverable. If it contains a ".", or is an RFC-style
address with no remaining "!", forward it to the site that is the
nameserver for the designated domain, unless you can generate the path
yourself (in which case you ARE a nameserver for the designated domain).
Some corollary rules:
a) Don't read the message header (the To:, etc) unless there is no other
choice. Use the routing information you were given by the remote command
invocation.
b) NEVER edit existing lines in the message header. This doesn't mean you
can't add lines (e.g., "Received:" lines, etc.), but you should not
make transformations in the syntax of the addresses in the header, etc.
[I have seen dozens of these transformations made in mail that gets
returned to me for one reason or another; they are almost invariably WRONG.]
The originating mailer should provide a unique and unambiguous return
address (not path) telling who the message is from; if it doesn't, it is
the originating mailer's problem, not yours. (Note that I guess this
means that I differ somewhat from Peter Honeyman's proposal in that regard,
in that I think this return address should be an RFC-style address, i.e.,
that all networks should try to adhere to a uniform address syntax. Again,
note that this has nothing to do with routing -- it's just the syntax of
what's in the From: line on the message.)
c) Treat all routing information provided via the UUCP network as having
the syntax <nextsite>!<uninterpreted-string>. This solves your ambiguity
problems, and eliminates the need for complicated syntax transformations
at gateways. (Unless, of course, you have a path that cannot be expressed
in the current routing language; I think this is a shortcoming of the
languages, though, and is the strong point of the proposed all-! language,
eventhough I tend to doubt that language is practical for other reasons
related to the need to know all other route-specifying languages at the
gateways, which is an unreasonable requirement in the real world.)
--
Shyy-Anzr: J. Eric Roskos
UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail: MS 795; Perkin-Elmer SDC;
2486 Sand Lake Road, Orlando, FL 32809-7642
"Vg frrzf yvxr hc gb zr."sob@neuro1.UUCP (Stan Barber) (08/12/85)
In article <16110@watmath.UUCP> atbowler@watmath.UUCP (Alan T. Bowler [SDG]) writes: >These potential capabilities seem to be ignored in all the discussion. >Is this because: > 1) I am interpreting RFC822 incorrectly, and the capabilities are not there? I think you are reading it correctly, but some people who read this list are not familiar with it. > 2) SENDMAIL can't do either of these things, or no one has yet figured > out how to make it do this? My sendmail configuration parses both just fine. The problem is that not everyones does and no one is quite sure how much "rewriting" should be done. In your first case, [<@site1,@site2,@site3:user@site4>] I would want the mailer to rewrite to <@site2,@site3:user@site4> and send it to the mailer that would send it to site1 hopeing that site1 could also cope with thi syntax. Other might want it rewritten to user%site4%site3%site2@site1. Still others might want site1!site2!site3!site4!user. The latter can be parsed by all uucp sites, neither of the others can be guarenteed to be useable. A uniform syntax would make this a lot easier, but no one can agree what that syntax is beyond the original bang notation. The second one ["user!site"@gatesite.domain] assumes that gatesite can correctly parse user!site.... this allows the addressor to use whatever knowledge s/he has about the gatesite or perhaps the network it is the gateway for. Sendmail cannot interfere with this and therefore should (and does in in the configuration I have) not alter what is in the quotes EVEN IF IT IS WRONG, and just route to the gatesite. > 3) No one has ever written a full parser for RFC822 type addresses? I think there are more than one. I think part of the problem is the few gray areas in RFC822. -- Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed Olan ARPA:sob@rice.arpa here are ONLY mine & Barber CIS:71565,623 BBS:(713)660-9262 noone else's.
gds@mit-eddie.UUCP (Greg Skinner) (08/13/85)
First off, let me make myself clear.
What I want to be able to do is source-route over different networks.
That is to say, I want to be able to specify, via whatever means
possible, the route my message takes over whatever networks I see fit to
route it through. Excepting in the case where it is illegal to use
intermediate networks to transport my messages, I would like to set the
precedence of certain network operators (more on this later) so that my
messages take the specified routes.
Now, about rfc822, source routing, etc.
Within a context which understands rfc822, the type of source routing
which you give example of <@site1,@site2:user@site3> works. However,
over multiple contexts rfc822 source routing does not work, because the
non-rfc822 environments most likely will not be able to put the commands
together to deliver the mail given the source route. As an example, if
I specify my route to be:
<@seismo,@ihnp4:gregbo@houxm>
what guarantees do I have that seismo knows how to put together the uux
command to deliver the mail to ihnp4? Maybe it does, maybe it doesn't.
It's possible that seismo will return to mail to me with a
ihnp4: Host unknown
since ihnp4 is not on the ARPAnet. However, let's assume that seismo is
running sendmail and does know that ihnp4 should be looked up in its
uuname tables. But then, how do I know that ihnp4 is running sendmail,
and can convert gregbo@houxm to what an address looks like in ihnp4's
context? (Note: this is just an illustration, and should not be
confused with any actual hosts or machines.)
Also, it was my impression that quoted strings were not broken up into
source routes in SMTP, so that if a user sends mail to
"ihnp4!houxm!gregbo"@seismo, the command that is created is
<@seismo:ihnp4!houxm!gregbo>
and seismo is left to cope with the entire formerly-quoted-string for
it's own interpretation, rather than have it pre-interpreted by the
ARPAnet. So, I don't believe it is SMTP's job to create end-to-end
source routes for mail messages.
On the subject of quotes -- quotes were never intended as delimiters for
source routes. In rfc822, quotes are used to make tokens out of phrases
like "John Smith" or "I. Furious User". The spec mentions nothing about
the use of "'s to explicitly specify routes, just as the spec mentions
nothing about % as an internetworking character. By using "'s in
addresses, one can specify an address such as "John Smith"@somehost,
assuming that somehost is capable of mapping "John Smith" to a mailbox
or process. Some mailers took the liberty of allowing users to quote a
part of an address on the lhs of the @, because the lhs may have had a
character in it which had a special interpretation on the host (for
example, on tops20 a ! is a comment character). Everything to the left
of the @ is left intact for interpretation by the rhs of the @.
In conclusion, there is no provision for source routing outside of an
rfc822 context specified by rfc822. Whether or not source routing
should be allowed outside of the originating context is a subject for
much debate, but I hold that it is feasible, especially when sending
messages over multiple networks (when it is legal to do so). Domains
provide one way of doing this, peter's pathalias scheme seems not to
have much knowledge of such things. My proposal, to treat network
characters as operators, with grouping of expressions to specify
precedence for how addresses are interpreted, is also a subject for much
debate, as it has not been proven that such interpretation of addresses
is necessary. However, I intend to give it some more thought, and will
probably post the same article maybe a year from now if domains or
pathalias don't provide neat solutions for the internetworking of mail
messages.
--
Do not meddle in the affairs of wizards,
for they are subtle and quick to anger.
Greg Skinner (gregbo)
{decvax!genrad, allegra, ihnp4}!mit-eddie!gds
gds@mit-eddie.mit.edujer@peora.UUCP (J. Eric Roskos) (08/15/85)
> The current implementation of domains (UCBVAX.BERKELEY.EDU) has them > completely seperate from the underlying networks. The host tables > have entries explaining which network to use to get to site X. No, really that wasn't exactly what I meant. I understand the benefits of having a single name for a single machine (or, more accurately, a single set of mailboxes), and also recognize that addresses that imply different networks do not represent this best-of-all-possible-worlds approach. Actually what motivates me to suggest the merits of networks implicit in addresses (and that is not even a point I STRONGLY advocate) is the economic and political considerations: for example, officially I should not send to my colleagues on UCIVAX via the ARPAnet, since they are both on ARPA and UUCP, since my communications have nothing to do with ARPA-sponsored research; yet someone else might well want to use the ARPAnet instead. What's really needed, from the USER standpoint, might be a network-specifier; but that's not currently in the addressing scheme, I don't think (though I remember someone from Europe recently suggested that in here; seemed like a good idea to me). My actual point was that I think the ROUTING strings should not be constrained by network-independent address formats; but that at present, the services provided by the user interfaces tend to tie closely together with the services provided by the transport mechanisms (apparently because both go through sendmail, or use the same set of sendmail configuration specifications, or something along those lines), so that a lot of confusion occurs over the semantics of the address and routing strings. I at present still contend that the UUCP transport mechanism's mail handling can and probably should be done by a relatively small rmail program, independent of sendmail, and that mail should be passed off to sendmail only when, for one reason or another, the UUCP routing information for a particular message has been exhausted (and then only if a real need exists). Only a few lines of code (maybe 75 or so) are actually required to implement domaining, based on my experiments, with direct passing of in-transit UUCP messages to uux. This assumes you follow the rules I explained earlier, though. > (You *were* implying that AT&T might want to grab the net weren't you? > Don't they have it already?) No. Actually my personal OPINION is that AT&T's present direction is to (a) implement domaining within the company (something I think they have already gotten most of the way to implementing already), and (b) discontinue serving as a free mail-forwarder for people outside, via the domaining approach. And I have no criticism of that at all; they are certainly entitled to do that. Actually, I was thinking of a rather unpleasant argument that occurred in here awhile back regarding another form of the UUCP network, though that only made me aware of the possibility -- i.e., I don't mean to imply that that incident actually was an attempt of that sort. If you think about it, AT&T already earns a very good income from UUCP, due to all the phone charges; the best they could do is probably to reduce their costs in various ways. Note that all the comments I have made on AT&T are mere speculation on my part, from looking at the maps that come out each month; I don't know anything about them, really, and have no opinion about their business matters. I'm sorry if my comment was misinterpreted that way; I was thinking more of something like a start-up company. -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
lawrence@encore.UUCP (Scott Lawrence) (08/20/85)
It seems to me that while geography makes a poor basis on which to base routing decisions, we have a better one. Most of the net is made up of organizations which have one or more systems, and more and more of those systems are installing internal networks which are far better than uucp. If we were to simply ask that each organization which does this establish just one machine as the gateway, and that gateway be configured to hide the very existance of the other machines on its own net, we would reduce the number of "global" machine names to a far more managable number than we have now. The net currently exists because various organizations are willing to foot the bill for phone calls - all this really does is formalize the situation which already exists to some degree or other.
linde@houligan.UUCP (dlinde) (08/22/85)
I took the time after reading all the RFC that I could find and looking at a few different configuration file (both original release version -- which are easy to spot and locally modified.) to see what the concensus was as to address parsing. I then basically rewrote a large portion of the configuration file so that most of the RFC822 is accepted including what is called the explicit "route address" of the form <@a, @b:user@c>. Incidently, I believe that you are correct in that it may be translated a!b!c!user . Quite a few sites use an address a!b!c!user as a domain address by pattern matching for the sites a, b, c and then rerouting. I did not include this type of parsing. I would like to see a standard set for addresses of the form a!b!user%site2@site1.ARPA that % binds more closely than @ which binds more closely than ! and that if neither % or @ appear all other separator have equal precedence. I feel that this seems to be the majority opinion by what the address parser I have looked at behave. Incidently, how about at the next USENIX conference we all get together and constructively hash out some standards in a commitee concerning this. From the discussion over the past few weeks it seems that there is disagreement and at least an informative class on this topic would be of interest to the community at USENIX if a commitee is not necessary.
jww@sdcsvax.UUCP (Joel West) (08/22/85)
> It seems to me that while geography makes a poor basis on which to base > routing decisions, we have a better one. Most of the net is made up of > organizations which have one or more systems If "most of the net" means AT&T, this might be true. Otherwise, I am inclined to disagree. Even if it is true, I think it will change with the name space explosion of PC's on the network. And even if it doesn't change, those of us with single systems are real people, too. Besides, only a few organizations (AT&T and DEC come to mind) will have their own national transport mechanism to use instead of the UUCP dial-up network. The rest of us -- no matter how many systems we might have in 2 or 3 cities -- will still have to rely on our brethren to assure connectivity in the 48 contiguous states. (USA.AK was empty last time I checked, and I can't afford a call to Hawaii). So again, connectivity will depend on geography. I would note, however, that the only form of geography that's important is to deliver the message to the right metropolitan area. A bias towards state (except for Rhode Island :-) ) or regional delivery doesn't help, because a call to San Francisco is about the same as a call to New York, more or less. Certainly San Diego-LA-San Jose-Berkeley is more expensive than San Diego-Columbus-Berkeley, for example, and less reliable to boot. The existing system of national hubs works well, if you can get to one. The only reason I'm hung up on geography and promoting the use of metropolitan hubs is that I fear having the phone costs from a network explosion kill the network. And THEN I'd have to use MCI Mail, god forbid. :-) Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA
bob@islenet.UUCP (Bob Cunningham) (09/02/85)
> Besides, only a few organizations (AT&T and DEC come to mind) will have > their own national transport mechanism to use instead of the UUCP dial-up > network. The rest of us -- no matter how many systems we might have > in 2 or 3 cities -- will still have to rely on our brethren to > assure connectivity in the 48 contiguous states. (USA.AK was empty last > time I checked, and I can't afford a call to Hawaii). Polling doesn't have to be both ways in order to have a link. While most mainland systems may not be able to afford calling us here in Hawaii, we can't afford not to be connected with the other 48 states, and will probably continue to poll a variety of different mainland systems from our end. Thus, you can also depend upon your brethern to assure connectivity to the 50th state. While I cannot speak for any potential sites in Alaska, I'll venture to say that they'll find themselves in a similar situation when they come up. On the other hand, they may be able to obtain some relatively inexpensive connections with sites in western Canada which we can't. -- Bob Cunningham {dual|vortex|ihnp4}!islenet!bob Hawaii Institute of Geophysics
peter@graffiti.UUCP (Peter da Silva) (09/03/85)
> UUCP requires the user to supply source routing. Practically no other > widely-spread network does. Not the ARPA Internet, not BITNET, not the > XEROX Internet, not PUP nets, not the Australian ACSNET, etc. You can > *do* source routing in the ARPA Internet, but hardly anybody ever > does: not because the syntax to do it is arcane (which it is), but > because there's no need. > > Why should the defects of UUCP be foisted on the rest of the world, > which has gotten along quite well without them for many years? > -- > John Quarterman Because (1) UUCP is changing too fast to keep a map intact: the only way to reliably generate a path to a given site is to use the return path, and even then you have to hope that a few cute mailers aren't there to "help" you on your way. (2) UUCP uses a wide variety of software and hardware configurations with no central government. Because of the ! syntax it needs no central government. Because of the wide variety of configurations there is really no way to ensure that everyone has software that can deal with domains without some kind soul writing a public domain mailer that is portable to machines as small as an LSI-11. Netnews won't even compile on an LSI-11. Pathalias won't run. (3) We're not trying to force anything down anyone's throats. We don't require that ARPA and BITNET and their friends stick with any old-fashioned arrangement. They all have some sort of government to take care of it. We don't. Just make .UUCP a domain and you don't have to change a line of code. (4) Why should the centralised organisation of ARPA be foisted on UUCP, which has gotten along without it for many years. I agree with down!honey. There is no way that you're going to get this mob of individualists to agree on anything coercively. Sorry about the Libertarian rhetoric but I've just been reading L. Neil Smith's latest and my text gener- ator is still configured for it.
peter@graffiti.UUCP (Peter da Silva) (09/03/85)
> Sorry to all you who KNEW this already, but I thought I'd better > make sure Peter isn't at a disadvantage in this discussion. While we're talking about the people who *know* things already, did you ever consider that pure-uucp paths are *also* RPN, with just one seperator. In fact unless you can freely intermix '.' and '@', you can't really claim that they are seperators and not operators.
peter@graffiti.UUCP (Peter da Silva) (09/03/85)
> languages, though, and is the strong point of the proposed all-! language, > eventhough I tend to doubt that language is practical for other reasons > related to the need to know all other route-specifying languages at the > gateways, which is an unreasonable requirement in the real world.) Why do you have to know this? Just convert it into *your* routing language & pass it on until it hits the next gateway.
jsq@im4u.UUCP (John Quarterman) (09/08/85)
It's just been my inestimable pleasure to join the ranks of the many people
on USENET who have been told what they meant to say by Peter da Silva.
Doubtless his version is more correct than what I actually did write:
it is certainly different.
Because pathalias does not run on small PDP-11s does not mean a) that
it could not be made to (compress does, and I'm sure Dr. honeyman is at
least as capable as the authors of that program) or b) that domain
routers could not (especially considering they wouldn't have to be
nearly as complex).
I wonder how it is that the huge UUCP map that current UUCP source routing
requires is not centralized but domains would have to be centralized....
--
John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET: jsq@sally.UTEXAS.EDU, formerly jsq@ut-sally.ARPAjer@peora.UUCP (J. Eric Roskos) (09/11/85)
[The article the following posting-excerpt comments on was my article saying that I felt that the all-! routing scheme wasn't viable in the real world, because you had to know all other route-specifying languages.] > Why do you have to know this? Just convert it into *your* routing language & > pass it on until it hits the next gateway. Remember I said "in the real world". Theoretically you don't, of course. However, as I pointed out, there presently EXIST gateways that don't really care atall about UUCP (I will risk giving an example, and say the Mailnet gateway, eventhough my last concrete example turned out to have been fixed by the time I gave it; since I've been unable to get UUCP mail through the Mailnet gateway successfully (outgoing) for over a year). The basic principle here is that the more often you rewrite the routing or address information, the more probability of error exists. Thus it is beneficial to have a route-specifying syntax which minimizes rewriting. A strictly left-right syntax within the UUCP transport mechanism provides this. A strictly right-left syntax within RFC822-supporting mailers also provides this. More exactly, within UUCP, the <nextsite>!<uninterpreted> syntax provides this; with the RFC method, <uninterpreted>@<site> provides this. The only place this is a problem is when these collide: for example, if I on my IBM PC want to send (using the @-precedence syntax) to samsmach!sam@samsneigh.UUCP. Because my PC will currently translate this, in the process of sending it to our nameserver, to peora!samsmach!sam@samsneigh.UUCP, which is wrong. Now, the real reason here that this is a problem is not the syntax per se, although a stronger syntax (and note that the RFC's method, with its simple quote, isn't strong enough to support this either) would allow you to write something like peora!(samsmach!sam@samsneigh.UUCP). The real problem is that samsmach is unmapped. But the above problem aside (the above problem would be resolvable by a simple "break" character in the UUCP path, I think, though I haven't tested that yet in our experimental nameserver), the only problem that's been brought up so far was the "ambiguity" between ! and @. And, as I've said, that's just because people insist on routing everything through Sendmail, which indeed appears incapable of handling this at present. If you use Sendmail only for inter-network routing, and for resolution of addresses into routes, then things work fine. These opinions of mine are not idle speculation; we do have a working name- server here, which as far as I am concerned can be public-domain, but which is changing too fast right now, and contains some hardcoded strings besides, to dump it out onto net.sources; and getting adjacent sites to test it is like pulling hen's teeth. But I do feel this method works. -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Nalgvzr gbzbeebj, gur cubar'yy evat, naq lbh'yy or ba lbhe jnl. Onpx ubzr va Buvb, gurl jba'g oryvrir lbh..."
honey@down.FUN (Peter Honeyman) (09/13/85)
john wonders ... how it is that the huge UUCP map that current UUCP source routing requires is not centralized but domains would have to be centralized.... it's simple. domains impose an authority structure on a network of computers, while uucp routers make no such requirement. peter
hokey@plus5.UUCP (Hokey) (09/13/85)
JER, Your ideas work well until mail hits a gateway. And the gateway need not be to a different network, either. A set of at least 2 sendmail sites will do it. I do not mean to sound like a flamer, but postulating how much better things would be given a nicer world is at best an academic exercise. It is a shame the Mailnet Gateway of which you speak is unable or unwilling to be a "proper" gateway. However, it is very difficult to teach all the folks in UUCP how to use the syntax needed by a gateway. Besides, it is less work for everybody if the gateway simply gets its act together. If the gateway is unable, then the job could be done by one of the gateway's neighbors. To substantiate some of this, the idea behind <nextsite>!<leave me alone> only works until just before the first (non-uucp) gateway. At that point, the gateway *must* figure out where to send the mail. It is *much* easier to require that gateways do the job of translating address/route specifications between transport domains. This means, for example, that *all* mail at the UUCP transport level should be in ! format. Send your Mailnet stuff to ..!mailnetgateway!site.mailnet!user and let the gateway do its job. Even if the mail is destined to a network which is unknown to Everybody in uucp-land, there must still be a gateway through which the mail must pass. Let it figure out how to get the mail farther along. Indeed, that gateway probably sent the mail to you in the first place... -- Hokey ..ihnp4!plus5!hokey 314-725-9492
jer@peora.UUCP (J. Eric Roskos) (09/13/85)
> I do not mean to sound like a flamer, but postulating how much better things > would be given a nicer world is at best an academic exercise. But what I've postulated works. Right now. I can send to every mail network I know of (well, except PE's, because they don't have a gateway :-) ). I have software right here that does it. To do it, all I have to do is specify the RFC822-form address handled by their mailer. In fact, yesterday I eliminated the last hardcoded string (other than filenames) from the router, so I guess I can post it (but not the mailer, yet, and anyway, Mark Horton is coming out with smail soon, which will be better I guess) to net.sources, no? The only place I have a problem is when I go through certain sendmail sites. Apparently even that works, since Seismo seems to have it working. Sendmail sites that see a route like: ...!ucbvax!john_doe%abc.CSNET@csnet-relay.ARPA and decide that since it has the string .ARPA on the end, it should send it to the CSnet relay immediately (since that's how you get to the ARPAnet from a CSnet site). Which they wouldn't do if they knew it came in via UUCP and thus should be treated with !-precedence. > It is a shame the Mailnet Gateway of which you speak is unable or unwilling > to be a "proper" gateway. However, it is very difficult to teach all the > folks in UUCP how to use the syntax needed by a gateway. Besides, it is > less work for everybody if the gateway simply gets its act together. If > the gateway is unable, then the job could be done by one of the gateway's > neighbors. You don't have to, though. Here if I want to write to a mailnet site, I write To: sam_smith@tops10site.mailnet The router looks in its domain table, where it sees .MAILNET,>ucbvax,,%P!%U%%%D@MIT-MULTICS.ARPA It translates the %P to the path to ucbvax (which is what >ucbvax stands for); it inserts sam_smith where the %U is, it generates a % where %% is (I guess I should have used a $), it puts tops10site.mailnet where the %D is, and that gives pesnta!hplabs!ucbvax!sam_smith%tops10site.mailnet@MIT-MULTICS.ARPA And that gets the message there right now, using plain old UUCP mailers. How? Well, each plain UUCP mailer takes off one sitename before the "!" and ships the rest of the routing string to that named site. When it gets to hplabs, hplabs takes off ucbvax!sam... and gives sam_smith%tops10site.mailnet@MIT-MULTICS.ARPA to UCBVAX's mailer. UCBVAX finds no "!", so it treats it as an RFC822 address, and connects up to MIT-MULTICS.ARPA (directly, since this is the ARPAnet) and delivers the message. The message arrives at MIT-MULTICS.ARPA with only sam_smith%tops10site.mailnet left in the address, which is a fine mailnet address, so it delivers it to tops10site.mailnet. Tops10site.mailnet see sam_smith, and that is a local user, so it delivers it to him. Now why is that so hard? All that it requires is that you DON'T give mail to sendmail if you don't have to. That is what my rmail does. If mail comes in via rmail, it knows it came in from UUCP, because uuxqt invokes rmail as its particular way of getting mail delivered. So, if it finds a "!" left on the address, it assumes that is a !-precedence address, and invokes UUX, the way the ancient "mail" did, back when rmail==mail. However, if it finds no "!", it invokes another program instead. This program ("deliver," due to certain inertial problems here) treats "@" as having precedence -- in fact, it is the program the user interface uses to initiate delivery, so users get to have "@" precedence also. It looks at the "@" address and decides what to do from there. [Actually the above was a simplification. The domain router in my rmail is capable of rewriting addresses with only an "@" into UUCP paths. It tries to do this first. If there is no matching domain, the address remains untransformed, and rmail goes on and passes it to deliver. This allows people at PCs to write sam@samsvax.UUCP, and have the PC simply prepend peora! to that string and route it here.] > Your ideas work well until mail hits a gateway. And the gateway need not be > to a different network, either. A set of at least 2 sendmail sites will do > it. I just described what happens in that case. I will agree that there exist certain gateways that require special processing -- though it's hard for me at the moment to think of any in reality other than gateways that alternate left and right precedence -- but I think *THOSE* gateways should handle the problem. It's like that military saying, "if device is not nonfunctional, do not attempt to effect maintenance procedures". Well, actually something is broken right now -- it's because sendmail just got stuck in everywhere in a fairly ad hoc fashion, rather than an orderly one. However, I think that is fixable, much more easily than by revising the routing language to require complete rewriting. -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
mark@cbosgd.UUCP (Mark Horton) (09/14/85)
In article <1632@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >You don't have to, though. Here if I want to write to a mailnet site, I >write > To: sam_smith@tops10site.mailnet > >The router looks in its domain table, where it sees > > .MAILNET,>ucbvax,,%P!%U%%%D@MIT-MULTICS.ARPA > >It translates the %P to the path to ucbvax (which is what >ucbvax stands >for); it inserts sam_smith where the %U is, it generates a % where %% >is (I guess I should have used a $), it puts tops10site.mailnet where >the %D is, and that gives > > pesnta!hplabs!ucbvax!sam_smith%tops10site.mailnet@MIT-MULTICS.ARPA > >And that gets the message there right now, using plain old UUCP mailers. This method may happen to work today, with the particular path you mention, but it's extremely dangerous, because you're generating an address has a ! to the left of an @. Let's suppose that next month hplabs installs smail or any other piece of software that conforms to RFC822, that is, gives @ priority over !. Now your mail will appear on hplabs addressed to ucbvax!sam_smith%tops10site.mailnet@MIT-MULTICS.ARPA and hplabs will in turn send it off to MIT-MULTICS.ARPA for ucbvax!sam_smith@tops10site.mailnet which sends it to tops10site.mailnet for ucbvax!sam_smith which fails. So you say "why don't we just require hplabs to hack their mailer so that mail coming in from uucp will give ! priority?" There are four problems with this: (1) This is anarchistic UUCP - you can't require hplabs to do anything. Any assumptions you make that every other host on the net will do "x" are bound to be false of some significant percentage of the net, unless "x" is something everyone has always done and always will. (2) RFC822 is a documented standard and ! routing is not. The chances are excellent that AT&T will soon endorse @ having priority over !. (3) What happens if you want to send mail to a remote UUCP host? That is, let's suppose that tops10site really runs UNIX (so let's call them unixsite) and has a UUCP link to foovax. You want to send to foovax!user@unixsite.mailnet which has you generating the path pesnta!hplabs!ucbvax!foovax!sam_smith%unixsite.mailnet@MIT-MULTICS.ARPA What would you have ucbvax do with this string? Especially if it happens to have a connection to foovax? (4) What is hplabs supposed to do with the following address typed by a user on hplabs? ucbvax!fred@F.ISI.ARPA It didn't come in via rmail, so you can't assume bang priority. It didn't come in via SMTP, so you can't assume @ priority. Is fred on ISI or ucbvax? In general, you can do the same thing with standard conforming syntax such as pesnta!hplabs!ucbvax!MIT-MULTICS.ARPA!foovax!sam_smith%unixsite.mailnet or better yet pesnta!hplabs!ucbvax!unixsite.mailnet!foovax!sam_smith (These examples assume that ucbvax is properly configured as a gateway, which I'm not sure is true right now. They would work using seismo as the gateway.) While smail is nearly ready (we're hoping for an October posting), I'd be interested to hear more about your nameserver. What we have is not a nameserver - it's a table driven routing program that uses pathalias and sendmail. A true nameserver might be a useful thing to have. Mark
jer@peora.UUCP (J. Eric Roskos) (09/16/85)
Oh, no... "the truth will out," as they say... > Let's suppose that next month hplabs installs smail or any other > piece of software that conforms to RFC822, that is, gives @ priority > over !. RFC822 does not specify how routing is to be done. RFC822 specifies the format the mail message itself will take. The transport mechanism used to deliver the message should form an "envelope" around this message, such that the routing information is outside the RFC822-conforming message: to preserve a reasonable hierarchical model for the mail system, each level should not be tampering with things on a lower level. What I have been proposing all along here (and what I am about to give up on, and go back to doing work they pay me for) is that you should preserve a proper, hierarchical model of mail delivery. There should be a transport mechanism that effects routing in a reasonable manner, and a lower (or higher depending on how you look at it) level piece of software that handles the user interface, and the inter-network "gatewaying." Most of the problems that exist today exist because people take their transport-level traffic and dump it into the same piece of software (sendmail) that is handling their gatewaying and user-level address parsing. This is ridiculous. It's poor structuring of the mail architecture. The mail architecture should not be this muddy. There should be a transport agent out on the periphery, which is sending mail by the sites along the route without tampering with them, which is in effect just a wire or conduit passing the messages along; and when a message is supposed to be gatewayed, it comes off the conduit and into your sendmail or whatever, and if it is supposed to be for a local user, it comes off the conduit and goes into the local mailbox, but mail that doesn't have anything to do with your site, that just happens to be passing through on the way to some other place, shouldn't be going off into your sendmail and getting its headers, which are not a part of the transport mechanism, macerated into unintelligibility; nor should the transport mechanism be trying to interpret the routing language in some way that paradoxically invokes the RFC822 language. > This method may happen to work today, with the particular path you > mention, but it's extremely dangerous, because you're generating an > address has a ! to the left of an @. I.e., it works now, but it won't work soon, because although it works fine now, soon it will be fixed so it is all better... the transport mechanism conforms to the standard of RFC822, a standard for the format of message text, and this is a tremendous improvement! (I'm starting to sound like RPF.) > Let's suppose that next month hplabs installs smail or any other > piece of software that conforms to RFC822, that is, gives @ priority > over !. ... > So you say "why don't we just require hplabs to hack their mailer > so that mail coming in from uucp will give ! priority?" There are > four problems with this: > > (1) This is anarchistic UUCP - you can't require hplabs to do anything. But you are requiring everyone to omit "@" from their routing language: > (2) RFC822 is a documented standard and ! routing is not. The chances are > excellent that AT&T will soon endorse @ having priority over !. even though AT&T first provided the '!'-precedence routing language, which had thereby become a standard for the UUCP mail. > (3) What happens if you want to send mail to a remote UUCP host? That is... As I said, this is the big problem. I don't deny that the all-! syntax has a definite advantage here; I even said so in the posting you're commenting on. In fact, until I tried the all-! syntax awhile and found so few places supported it, I even thought it was a good idea (aside from my doubts about excessive rewriting). The all-! makes a good deal of sense theoretically. I'm just looking at it from the viewpoint of someone who needs to get mail places with reasonable reliability, without sudden interruptions as people switch to other syntaxes. It's sort of like why all your telephone switching systems have to be able to withstand 130 volt signals... whatever happened to that proposal for electronic bells that was so popular awhile back? > (4) What is hplabs supposed to do with the following address typed by a > user on hplabs? > ucbvax!fred@F.ISI.ARPA > It didn't come in via rmail, so you can't assume bang priority. It didn't > come in via SMTP, so you can't assume @ priority. Is fred on ISI or ucbvax? Fred is on ucbvax. You send this message to F.ISI.ARPA, who sends it to ucbvax, who sends it to fred. This is because the address was TYPED by the user, i.e., into the message header, meaning it is interpreted by the user interface, which is RFC-conforming. Here again you've chosen the degenerate case, though, since there's no way to route it without getting into an "is this better than all-!" argument. > In general, you can do the same thing with standard conforming syntax > such as > pesnta!hplabs!ucbvax!MIT-MULTICS.ARPA!foovax!sam_smith%unixsite.mailnet > or better yet > pesnta!hplabs!ucbvax!unixsite.mailnet!foovax!sam_smith > (These examples assume that ucbvax is properly configured as a gateway, > which I'm not sure is true right now. They would work using seismo as > the gateway.) "Standard-conforming"? What's this? You mean, UUCP is really an AT&T network? It won't work, which is why I decided I didn't like the all-! syntax. I tried mailing through it, and a week later everyone's mail started getting returned. This suggested a lot of changes had to be made, which is where my opinion comes from. > While smail is nearly ready (we're hoping for an October posting), I'd > be interested to hear more about your nameserver. What we have is not > a nameserver - it's a table driven routing program that uses pathalias > and sendmail. A true nameserver might be a useful thing to have. I have posted the basic nameservice routines to net.sources. These use the pathalias database to resolve site names into paths there. This sounds a lot like what you have. It is not an RFC-style nameserver (which gives name resolutions for arbitrary object names; note that the RFC on domains (I forget its number) covers a lot more than names for mail sites) since I can't figure out what that would be good for. It simply yields routes given names. Since the pathalias database is automatically updated (when you send out new maps, or when we update our domain maps), it does provide an automated updating facility. All the above has been independent work. Unfortunately, typing this very message is eating into time someone else is paying for (by a few minutes), and this has to stop. You can't whomp the competition while you are arguing with one of them over how to route mail! I don't get paid to do any of this, and often wonder why I got involved in discussing it at all, since the path taken by the UUCP mail in the long run appears resolved and predetermined... I guess by the people who are paying someone to do it! It only makes sense, though... So in a few days, if I can get the time (I brought some sandwiches for lunch so I would have some time) I will fix up the rmail to run "mail", which is a fairly safe way of doing things, and put it in net.sources, where other people can do whatever they want with it, and I will get back to doing what I am supposed to, which is not mail. I am not going to write any more in here, though. I don't see much point in it: when you convert to the all-! syntax, all I have to do is change the translation file, and it will generate the !'s... so there is little point in arguing further (for me), since PE isn't in the mail business ... Reminds me of Chuqui's lament... -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
jsq@im4u.UUCP (John Quarterman) (09/18/85)
In article <582@down.FUN> honey@down.FUN (Peter Honeyman) writes: >john wonders > > ... how it is that the huge UUCP map that current UUCP source > routing requires is not centralized but domains would have to > be centralized.... > >it's simple. domains impose an authority structure on a network of >computers, while uucp routers make no such requirement. > > peter Forgotten the three bilbos problem already, peter? -- John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq ARPA Internet and CSNET: jsq@sally.UTEXAS.EDU, formerly jsq@ut-sally.ARPA
honey@down.FUN (Peter Honeyman) (09/23/85)
no, john, i haven't. what's your point? peter
sewilco@mecc.UUCP (Scot E. Wilcoxon) (09/23/85)
In article <582@down.FUN> honey@down.FUN (Peter Honeyman) writes: >john wonders > ... how it is that the huge UUCP map that current UUCP source > routing requires is not centralized but domains would have to > be centralized.... >it's simple. domains impose an authority structure on a network of >computers, while uucp routers make no such requirement. As with everything on UUCP, RFC822 UUCP centralization is only by influential sites agreeing on standards. The great advantages of RFC822 are globality of addresses and that only the sites sharing the same level of domain/subdomain routing need to agree on standard names. Even without a name registry, merely limiting the definition from the present global names will greatly reduce chance of name conflicts. The sites which pass messages between domains will have to agree on domain names. Penalty for not doing so is loss of mail. The sites which pass messages between subdomains will have to agree on subdomains. Penalty for not doing so is loss of mail. The sites which pass messages between sites will have to agree on names of those sites. Penalty for not doing so is loss of mail. RFC822 duplicate site names are impossible on ARPAnet due to the central registry. On UUCP (the .UUMAIL domain?) duplicate names are possible, but need site and subdomain addresses to match in order to be duplicates. UUCP domain-oriented mailers should obey the domain and subdomain information first when passing mail in the direction of a site without a direct link. With the current UUCP routing, a duplicate site name ON THE MAP: Pathalias might be confused and pick route to wrong one. IN THE NET: A site which rewrites paths may pick route to wrong one. While with RFC822 addresses, a duplicate site or domain name ON THE MAP: Less likely due to reduced conflicts in subdomains, but still possible. Same problems as current Pathalias, though new route-finding program should only find paths to subdomains. IN THE NET: The wrong site could only be chosen if the duplicate sites are within the same subdomain. -- Scot E. Wilcoxon Minn. Ed. Comp. Corp. circadia!mecc!sewilco 45 03 N / 93 15 W (612)481-3507 {ihnp4,uwvax}!dicomed!mecc!sewilco
jsq@im4u.UUCP (John Quarterman) (09/26/85)
To avoid the three bilbos problem on UUCP, you must have a master
registry of all UUCP host names. This must be quite large, and will
always be out of date and ignored by some, as witness that there
actually are three bilbos on UUCP.
With domains, the bilbos would presumably be named bilbo.WHEREVER.UUCP,
bilbo.FUN.BEACH, bilbo.A.B.C, etc. Whoever names each bilbo need only
know that its name is unique within the immediately local domain.
So, with domains you only need, in each domain, a registry for hosts
in that domain, and a registry of domains (which appears to be starting
to exist in mod.map).
--
John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET: jsq@sally.UTEXAS.EDU, formerly jsq@ut-sally.ARPA