peter@ficc.ferranti.com (Peter da Silva) (06/28/90)
I have a question about paths. What's the official word on % versus !? I'm currently implementing things so that % has tighter binding than !, and @ has looser, so: foo!user%site ( after stripping off @*.ferranti.com ) means send to foo for forwarding to user@site, while: foo!user@site means send to site for forwarding to foo!user. Is this a reasonable interpretation? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
parmelee@wayback.cs.cornell.edu (Larry Parmelee) (06/28/90)
In article <HRA48BC@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > ... What's the official word on % versus !? See RFC 1123 "Requirements for Internet hosts - application and support", section 5.2.16, "RFC-822 Local-part: RFC-822 Section 6.2". Quoting from second from last paragraph in that section, ... This is commonly known as the "%-hack". It is suggested that "%" have lower precedence than any other routing operator (e.g., "!") hidden in the local-part; for example, "a!b%c" would be interpreted as "(a!b)%c". Using parens to indicate precidence in mail addresses may be misleading- it may be clearer to say that "a!b%c" should be parsed as "HOST ! MAILBOX", where "HOST" is "a" and "MAILBOX" is "b%c". The message should be sent to HOST, and then it's up to HOST to interpret the MAILBOX part. The above quote (and a little bit of surrounding context in the RFC) is the ONLY official definition of "the %-hack" that I'm aware of, and a weak definition it is, too, since they only said "suggested". In parsing a mail address, I ignore "%"s if there's any other routing characters available, and I avoid using "%"s in any addresses I generate. -Larry Parmelee parmelee@cs.cornell.edu
lear@turbo.bio.net (Eliot) (06/29/90)
One should avoid using the percent hack. That is why we chose the language we did. It truely has no official standing, even though we mentioned it in RFC 1123 in a discussion section. -- Eliot Lear [lear@turbo.bio.net]
peter@ficc.ferranti.com (Peter da Silva) (06/29/90)
In article <Jun.28.11.25.31.1990.12626@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: > One should avoid using the percent hack. That's good advice for users, but as the local mail scapegoat I have to be able to deal with it. It seems that the official word is divided, so I'll continue interpreting "a!b%c" as "route via a for delivery to b@c". Seriously, do people really think @foo,@bar:zap@baz is a better syntax? (this is a rhetorical question relating to aesthetics, not an attempt to derail RFC822) -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
karl_kleinpaste@cis.ohio-state.edu (06/29/90)
peter@ficc.ferranti.com writes:
Seriously, do people really think @foo,@bar:zap@baz is a better syntax?
(this is a rhetorical question relating to aesthetics, not an attempt to
derail RFC822)
Source routes (@foo,@bar:zap@oz) have been duly denigrated by RFC1123,
derailing RFC822 already. They're explicitly discouraged. p.51:
A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
explicit source route using the "@...:" address form. Thus,
the relay function defined in section 3.6 of RFC-821 should
not be used.
DISCUSSION:
The intent is to discourage all source routing and to
abolish explicit source routing for mail delivery within
the Internet environment. Source-routing is unnecessary;
the simple target address "user@domain" should always
suffice.
--karl
--
Depression \di-'presh-un\ n. A condition observed on return from
3 weeks' vacation to find ~2000 mail messages waiting for oneself.
(And people marvel that I employ GNUS as a mail-reading interface.)lear@turbo.bio.net (Eliot) (06/30/90)
Issue number one: % has no precedence at all. If you change that, I promise you that mail will be lost. The easiest and most correct way to deal with % is not to. If you just pass it along when you see it, the right thing will happen - ESPECIALLY if you are a UUCP site. If you insist on checking for it, let it be the lsat thing you check before final delivery (thus giving it lowest preference). There are enough routing characters in this world, thank you! End of tirade. Issue number two: Route addrs are obsolete. It is legitimate for an implementation to short circuit right to the address after the colon. Because the mail specification designed to be an end to end protocol, ``routing'' other than through the use of MX records is strongly discouraged. -- Eliot Lear [lear@turbo.bio.net]
fitz@wang.com (Tom Fitzgerald) (06/30/90)
peter@ficc.ferranti.com (Peter da Silva) writes: > I have a question about paths. What's the official word on % versus !? I'm > currently implementing things so that % has tighter binding than !, and @ > has looser > Is this a reasonable interpretation? It's reasonable in the sense that it will make things work right, but unfortunately it violates RFC1123 section 5.2.16, which says that ! should bind tighter than %. This is actually an unfortunate choice. As more and more sites become compliant with it, the use of %-addresses from UUCP sites becomes less and less reliable. I've started telling people here never to use addresses with %'s in them, because they rarely work. The problem is that, under smail 2.5 (and, I believe, uumail), addresses like a%b@c get rewritten to path!to!c!a%b and sent out onto the UUCP net. This works as long as 'path' and 'to' disobey RFC1123. If either of them follow it and interpret c!a%b as (c!a)%b, the message will get lost. Smail 3.1 avoids this problem by rewriting a%b as b!a in outgoing mail, but even the authors point out that it involves rewriting the local parts of nonlocal addresses, which isn't always such a great idea. In this case, however, it does make things work right. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
peter@ficc.ferranti.com (Peter da Silva) (07/02/90)
In article <Jun.29.11.42.03.1990.18231@turbo.bio.net>, lear@turbo.bio.net (Eliot) writes: > % has no precedence at all. If you insist on > checking for it, let it be the lsat thing you check before final > delivery (thus giving it lowest preference). That's what I said I was doing. > End of tirade. Here, have a cookie. > Because the mail > specification designed to be an end to end protocol, ``routing'' other > than through the use of MX records is strongly discouraged. Except that sometimes you need to use ! routing to get to a site that understands domains, but you're going through a site that understands @ for local mail only. What would you do? I'd do a!b!c!d!u@e, but then c will complain about not being able to get to e. a!b!c!d!u%e is, on occasion, the only game in town. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (07/02/90)
In article <ap10fp.1w6@wang.com> fitz@wang.com (Tom Fitzgerald) writes: > It's reasonable in the sense that it will make things work right, but > unfortunately it violates RFC1123 section 5.2.16, which says that ! should > bind tighter than %. OK. Sounds like RFC1123 is just plain wrong. Who wrote it, and why did they make this choice? > Smail 3.1 avoids this problem by rewriting a%b as b!a in outgoing mail, Which may bounce at sites that reroute @ or % but leave ! alone unless the first part is a domain (such as smail 2.5 in some configurations). -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
les@chinet.chi.il.us (Leslie Mikesell) (07/03/90)
In article <Jun.29.11.42.03.1990.18231@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: >% has no precedence at all. If you change that, I promise you that >mail will be lost. The easiest and most correct way to deal with % is >not to. If you just pass it along when you see it, the right thing >will happen - ESPECIALLY if you are a UUCP site. If you insist on >checking for it, let it be the lsat thing you check before final >delivery (thus giving it lowest preference). There are enough routing >characters in this world, thank you! End of tirade. It is guaranteed to fail if you hand an address with a % separator on the next hop to a standard (i.e. ATT) unix rmail. You can only ignore it if you know that the machine that will encounter it as the local part of the addres will understand it. Les Mikesell les@chinet.chi.il.us
oc@vmp.com (Orlan Cannon) (07/03/90)
In article <42765@cornell.UUCP>, parmelee@wayback.cs.cornell.edu (Larry Parmelee) writes: > > Using parens to indicate precidence in mail addresses may be misleading- > it may be clearer to say that "a!b%c" should be parsed as "HOST ! MAILBOX", > where "HOST" is "a" and "MAILBOX" is "b%c". The message should be sent to > HOST, and then it's up to HOST to interpret the MAILBOX part. > On the other hand, I always look at the "a!b%c" as being just another implemtation of " LOCALADDRESS @ HOST ". That is, after the original host is stripped away, the "%" has the same meaning as "@" and the "!" is merely another normal character to be dealt with by mailers that don't know any better. -- Orlan Cannon oc@vmp.com Video Marketing & Publications, Inc. (800) 627-4551 Oradell, NJ 07649
chip@tct.uucp (Chip Salzenberg) (07/03/90)
According to fitz@wang.com (Tom Fitzgerald): >Smail 3.1 avoids this problem by rewriting a%b as b!a in outgoing mail, >[...] Lest anyone get the wrong idea, Smail 3.1 doesn't modify the message header. It only modifies the envelope (i.e. rmail argument). While envelope munging is unfortunate, it isn't EVIL and RUDE like header munging. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
peter@ficc.ferranti.com (Peter da Silva) (07/04/90)
In article <1990Jul2.235334.5511@vmp.com> oc@vmp.com (Orlan Cannon) writes: > On the other hand, I always look at the "a!b%c" as being just another > implemtation of " LOCALADDRESS @ HOST ". That is, after the original > host is stripped away, the "%" has the same meaning as "@" and the "!" > is merely another normal character to be dealt with by mailers that > don't know any better. The problem with this is that this means there's no way to say "a!(b@c)". -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
Makey@Logicon.COM (Jeff Makey) (07/04/90)
In article <S0E44F7@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <ap10fp.1w6@wang.com> fitz@wang.com (Tom Fitzgerald) writes: >> It's reasonable in the sense that it will make things work right, but >> unfortunately it violates RFC1123 section 5.2.16, which says that ! should >> bind tighter than %. > >OK. Sounds like RFC1123 is just plain wrong. Who wrote it, and why did >they make this choice? There is nothing wrong with RFC 1123. The relevant section (5.2.16) says: It is suggested that "%" have lower precedence than any other routing operator (e.g., "!") hidden in the local-part; for example, "a!b%c" would be interpreted as "(a!b)%c". The use of parentheses in the example is a poor attempt at using algebraic notation to describe source routing, but the part about "lower precedence" indicates to me that "a!b%c" means "deliver to "a", who should interpret "b%c" as a local-part. This is the One True Order of Precedence. RFC 1123 also makes it quite clear that only host "a" has the option of rewriting "a!b%c" as "a!c!b". :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
lear@turbo.bio.net (Eliot) (07/04/90)
In article <WZE4AXD@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > The problem with this is that this means there's no way to say "a!(b@c)". Why not a!c!b? This is what RFC 976 talks about. -- Eliot Lear [lear@turbo.bio.net]
peter@ficc.ferranti.com (Peter da Silva) (07/04/90)
In article <Jul.3.16.35.40.1990.4175@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: > > The problem with this is that this means there's no way to say "a!(b@c)". > Why not a!c!b? This is what RFC 976 talks about. Then when "c" doesn't grok "!", what do you do? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/04/90)
In article <HRA48BC@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
I have a question about paths. What's the official word on % versus !? I'm
currently implementing things so that % has tighter binding than !, and @
has looser, so:
Ha. The essential point is that is part of the local address, and should
*only* ever be turned into an @ by the delivery software on the target
machine. No intermediate machine should ever touch it. The percent hack
is precisely there as a *delayed* routing technology.
Naturally there is the problem that UUCP and Internet have different
ideas as to which is the target, because they have different ideas on
the priorities of ! and @ (more exactly, each tries to ignore the
other's routing symbol).
If you have 'a!b!c%d@e.f', 'a!b!c%d' is the local part at the 'e.f'
gateway. The gateway tries to deliver it to 'a!b!c@d'; at this point, if
it is an UUCP machine, the mail will be routed to 'a' and 'b' then on
'b' it will be sent to 'c@d'. If the gateway is an Internet machine, it
will be sent to 'a!b!c', which may or may not be a local user with a
funny bangish name or user 'c' on 'a!b'.
Somebody says that percent should have the lowest priority, but this is
from an Internet viewpoint.
Oh my, why don't we just stop being silly with RFCs, and revert to using
only bang paths throughout and have gateways fake them (hahahaha) into
Internet format at destination only?
Note that I also prefer names as relative bang paths (a completely
separate issue from routing), but I am prepared to accept domainized
names just to be nice... :-).
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uktron@tolerant.com (Ron Karr) (07/05/90)
In article <2690C7F4.A40@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to fitz@wang.com (Tom Fitzgerald): >>Smail 3.1 avoids this problem by rewriting a%b as b!a in outgoing mail, >>[...] > >Lest anyone get the wrong idea, Smail 3.1 doesn't modify the message >header. It only modifies the envelope (i.e. rmail argument). While >envelope munging is unfortunate, it isn't EVIL and RUDE like header >munging. Actually, this behavior is controlled on a per transport basis. By default, if smail3.1 is given an address a!b%c where a is one hop, then it gives to a the address b%c. A flag can be used to change this behavior if you believe that your neighbors won't understand the b%c form. Also by default, if a is two hops, then it will give the address a!b%c to the neighboring host. With respect to operator precedence, Smail3.1 is correct in accordance with RFC822 and RFC976, with the % operator added as a more tightly binding operator than both @ and ! (and : and ::, for that matter). -- tron |-<=>-| ARPAnet: tolsoft!tron@apple.com tron@tolerant.com UUCPnet: {amdahl,apple,hoptoad}!tolsoft!tron
fitz@wang.com (Tom Fitzgerald) (07/06/90)
Makey@Logicon.COM (Jeff Makey) writes: > There is nothing wrong with RFC 1123. The relevant section (5.2.16) says: > It is suggested that "%" have lower precedence than any other > routing operator (e.g., "!") hidden in the local-part; for > example, "a!b%c" would be interpreted as "(a!b)%c". > The use of parentheses in the example is a poor attempt at using > algebraic notation to describe source routing, but the part about > "lower precedence" indicates to me that "a!b%c" means "deliver to "a", > who should interpret "b%c" as a local-part. This is the One True > Order of Precedence. That's exactly the opposite of how I read it. The words "higher precedence" and "lower precedence" apparently mean different things to different people, and I won't use them. The RFC seems to be saying that ! binds tighter than %, whence the interpretation of a!b%c as (a!b)%c. This implies immediate delivery to c, which is solely responsible for interpreting a!b however it wishes. I agree with you that interpreting a!b%c as a!(b%c) would be better. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
urlichs@smurf.sub.org (Matthias Urlichs) (07/07/90)
In comp.mail.uucp, article <apceni.fa2@wang.com>, fitz@wang.com (Tom Fitzgerald) writes: < Makey@Logicon.COM (Jeff Makey) writes: < > [ RFC1123 example ] < > The use of parentheses in the example is a poor attempt at using < > algebraic notation to describe source routing, but the part about < > "lower precedence" indicates to me that "a!b%c" means "deliver to "a", < > who should interpret "b%c" as a local-part. This is the One True < > Order of Precedence. < < That's exactly the opposite of how I read it. The words "higher precedence" < and "lower precedence" apparently mean different things to different people, < and I won't use them. The RFC seems to be saying that ! binds tighter < than %, whence the interpretation of a!b%c as (a!b)%c. This implies < immediate delivery to c, which is solely responsible for interpreting a!b < however it wishes. < Using parentheses, as well as talking about "binding tighter" or "precedence", is highly ambiguous in this context. Does a!(b%c) mean that b%c is to be evaluated first (as in mathematics), resulting in c!a!b, or that b%c is to be seen as one unit (as in a graph), making the message go a!c!b? < I agree with you that interpreting a!b%c as a!(b%c) would be better. < I assume you mean a!c!b here. ;-) Whatever RFC1123 says, and/or whatever we think it says, it seems that visualizing a!b%c as a!c!b (without actually rewriting it that way, and especially without rerouting it to what you think "c" is supposed to be) is the right way to do it, with "right" being defined as breaking less things than doing it the other way 'round. Unfortunately, many vendor-supplied sendmail.cf's do not share this opinion. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
les@chinet.chi.il.us (Leslie Mikesell) (07/08/90)
In article <K0E4G47@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Except that sometimes you need to use ! routing to get to a site that >understands domains, but you're going through a site that understands >@ for local mail only. What would you do? I'd do a!b!c!d!u@e, but then >c will complain about not being able to get to e. a!b!c!d!u%e is, on >occasion, the only game in town. This is what RFC 976 talks about and recommends pure ! syntax. Most sites that accept uucp traffic and understand domains will take domain!user as well as user@domain, so the non-ambiguous a!b!c!d!e!u is the safest bet since it doesn't depend on anyone else's interpretation. Les Mikesell les@chinet.chi.il.us
snoopy@sopwith (Snoopy) (07/08/90)
In article <696@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: | RFC 1123 also makes it quite clear that only host "a" has the option | of rewriting "a!b%c" as "a!c!b". If all this is so clear, why do we have all these studly mail wizards arguing about this stuff? Keep it simple, stupid. Use bang paths. [1] _That_Hideous_Name_, Rob Pike and P.J. Weinberger _____ /_____\ Snoopy "I read banned newsgroups." /_______\ cse.ogi.edu!sopwith!snoopy |___| sun!nosun!qiclab!sopwith!snoopy |___| uunet!tektronix!nosun!qiclab!sopwith!snoopy
ches@alice.UUCP (Bill Cheswick) (07/08/90)
>Keep it simple, stupid. Use bang paths. > >[1] _That_Hideous_Name_, Rob Pike and P.J. Weinberger We try to, but there are a couple complications: 1) Some of our users like to use the addresses they are given, often with the `@' sign. The upas mail canonicalizes this to the all bang format. We follow RFC 1123 in these cases. 2) When our Internet gateway moves this mail to the internet, we have to come up with some RFC 822-compliant address. Past translations have included RFC976 and `%' forms. Both were rejected by various (different) mailers reflecting the political philosophies of their keepers. For a while we defaulted to `%' form with a stop-list for those insisting on RFC976. We finally picked the source domain routing form, which turns out to be accepted generally, if grudgingly. The bottom line is that the mail gets through, which is our goal. BTW, it is wonderful to give the users the following forms: bitnet!machine!user inet!machine!user csnet!machine!user etc. Much easier to teach, and the lay user can avoid the @/% jungle entirely. Bill Cheswick postmaster@research.att.com
wisner@hayes.fai.alaska.edu (Bill Wisner) (07/09/90)
snoopy@sopwith: >>Keep it simple, stupid. Use bang paths. Keep it simpler, stupid. Use user@host. ches@alice: >Much easier to teach, and the lay user can avoid the @/% jungle entirely. user@host is simpler than bang paths. One username, one hostname. >postmaster@research.att.com See? Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775 "Of course, this isn't really the best way to do it. But seeing as you're not quite as clever as I am -- in fact, none of you are anywhere near as clever as I am -- we'll do it this way."
karl_kleinpaste@cis.ohio-state.edu (07/10/90)
ches@alice.uucp writes: [first quoting snoopy@sopwith:] > Keep it simple, stupid. Use bang paths. > [1] _That_Hideous_Name_, Rob Pike and P.J. Weinberger We try to, but there are a couple complications: Yes, there are. For example, _T_H_N_ is largely an excuse to complain without really addressing the _problem_, choosing instead to complain about particular bad implementations, at a time when bad implementations outnumbered good ones, at least at highly visible sites. (P&W spend quite some effort picking on CMU and Stanford.) This paper came up several times about a year ago, so I dug it out and posted a review of it then. Re-posting of that review follows. BTW, it is wonderful to give the users the following forms: bitnet!machine!user inet!machine!user csnet!machine!user etc. Much easier to teach, and the lay user can avoid the @/% jungle entirely. You have just returned to the land of transport-centric addressing. I'm really tired of having to know what network someone is using. With DNS, I don't have to. It's silly to have to tell your physical postmaster how to find your street -- s/he's just supposed to know that. Email should be treated similarly -- the user isn't supposed to have to know or care about how the bits get between here and there. You force them to know by encouraging network-specific address forms. Furthermore, if you actually tell people to use "csnet!..." then you're being redundant. Or so I understand, because it's supposedly the case that all CSNet members/customers have real DNS names now, which is to say that your use of "csnet!..." has been wholly subsumed into "inet!..." If/when BITNET sites ever accomplish full DNS registration, then "bitnet!..." will be similarly subsumed. The result will be a contentless "inet!" indication at the beginning of an address of the form "machine!user," and assuming that the machine name is an FQDN, it's of the form "f.q.d.n!user," which can be transformed to "user@f.q.d.n" with no loss of information; so the only remaining difference is in the choice of network punctuation and the ordering of the (host,user) pair. In other words, no semantic difference remains. I find it interesting to note that, in _T_H_N_, it is observed that !-paths "do not necessarily indicate transport," but your use of !-paths is _explicitly_ and _deliberately_ indicative of transport, via pseudomachine names instead of via choice of network punctuation schemes. You can indicate transport however you want, but it's clear that, as a practical matter if not a theoretical one, !-paths ultimately result in transport indications. Kinda silly. Last year's review posting follows. --karl ---------------- Path: triceratops.cis.ohio-state.edu!karl From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) Message-ID: <KARL.89May31103452@triceratops.cis.ohio-state.edu> Date: 31 May 89 10:34:52 Organization: OSU In-reply-to: honey@mailrus.cc.umich.edu's message of 31 May 89 01:25:16 GMT Newsgroups: comp.mail.uucp Subject: Re: Domain Registration References: <1105@mailrus.cc.umich.edu> Distribution: na honey@mailrus.cc.umich.edu (peter honeyman) writes: pike and weinberger give some insights of a different nature in "the hideous name" (summer usenix, 1985, portland). I've seen this paper referenced two other times in the recent past, so I dug around in my files, pulled it out, and re-read it. My memory of it wasn't as bad as I feared (but not as good as I hoped, either). I am alternately impressed and irritated by this paper. On the one hand, a lot of excellent guidelines are (re-)introduced for naming schemes. However, a lot of trees were killed for the space in which to do what seems to me to be gratuitous mudslinging. There's a lot of discussion on filename representation, the evilness of VMS' use of no less than 6 punctuation characters and the problems of late-evaluated dynamic macros, as well as the problems in interpretation of Berkeley (actually, IBIS and [later?] berknet) conventions to use host:filename. When it jumps into the area of mail addressing, I think the bulk of the gratuitous bashing begins. In particular, the example addresses (These are given on the cover page and on page 4, and are research!ucbvax!@cmu-cs-pt.arpa:@CMU-ITC-LINUS:dave%CMU-ITC-LINUS@CMU-CS-PT and IJQ3SRA%UCLAMVS.BITNET%SU-LINDY@SU-CSLI.ARPA and yes, the first does include !@ and :@) are nothing more than pathological cases of something that was clearly broken from the outset. Not that the standard in question was broken, but that the mailers which generated these addresses did not (then) implement that standard. The moaning about the use of % as a pseudorouting punctuation character is nothing but moaning; it is not and has never been a part of anyone's standard, and I don't know of anyone who advertises it as advisable - I tell my users about it from time to time to get around temporary, transient difficulties regarding, e.g., nameserver blackouts and dead links. The same cannot be said for UUCP !-paths which are absolute until and unless one implements aggressive rerouting. I think we all know how well that goes over with The General Populace. There is also the general complaint that naming requires registration with a central authority. I consider this complaint vacuous. You can register with hostmaster@sri-nic.arpa, or you can register with uunet!uucpmap, take your pick. If you don't register with *someone*, mail is not going to get back to you, even if you can get mail sent out properly. Not many people are willing to put up with the need for manual tracking of UUCP connectivity to any serious extent, especially if one is prone to receiving mail from a wide variety of sources through gateways which do not even necessarily use bidirectional links[*]. In general, the domain naming system gets around the problem by hiding the issue of transport from the mail-writing user entirely, so that he no longer needs to worry about it in the least. I have to write a heck of a lot of mail, and without domains, it would border on the impossible. I don't care how it gets there, just so long as it does. There is further complaint that, "the gateway service between BITNET and ARPANET was made explicit," in the second example. Give me a break - tell it to the BITNET, OK? If they'd ever get their collective butts into gear, they would settle down to the task of registering hosts in the domain system properly somewhere (whether they do it at UUNET or the NIC, I don't care). Then I would be able to take out the morbid special case in my mailer where I detect .BITNET addresses and foist such mail onto a gateway system of which I know little. With proper use of the domain system, I don't have to know what network Joe Random is using, and I'm tired of complaints that .BITNET is abusing the network naming schemes. *When the standard is properly implemented,* it works well. Those who don't implement it have no one but themselves to blame for their inability to get between Here and There. All things considered, the closing complaint, "despite the words in the standard about hierarchy, the domain space is completely flat," is just a lot of nonsense. Consider, for one thing, that this paper was written when the standard which it so heavily abuses was really rather new, and there wasn't a whole lot done in the way of implementation yet. Now, 4 years later, there is considerable support available, ready-made and off-the-shelf. Plug it in and it goes - and the result is that now it's not flat. AT&Ters, the paper in question can be requested from the library as 11271-850508-05TM. --Karl [*] I run the archive machine osu-cis, which provides UUCP-accessible source archives to anyone who cares to call it, using an anonymous account. Execution of rmail is permitted in this area. We have had incidents where sites Out There Somewhere (I know not where, physically) have used osu-cis as their mail gateway to the Known Universe, with ensuing complaints directed at me from the recipients of such mail, wondering why mail can't get *back* the way it came. The answer is obvious, since we don't know about (in a UUCP Systems file sense) 99+% of the systems which use osu-cis. ---------------- -- There is nothing sweeter than the sound of ``Misty'' played on a cheap sousaphone. --Tom Fine <fine@cis.ohio-state.edu>
peter@ficc.ferranti.com (Peter da Silva) (07/10/90)
In article <KARL.90Jul9143911@giza.cis.ohio-state.edu>
karl_kleinpaste@cis.ohio-state.edu reposts his original review of
That Hideous Name.
I think we're all agreed that the DNS is a good thing, and if you want to
get to a registered site it's the cat's meow, and finally that RSN all sites
will be registered.
But, still, DNS source-routing is incredibly ugly. Using both prefix and
postfix in the same expression has been proven a horrible idea twice now:
first with C declarations (wouldn't it have been wonderful if indirection
was a postscript operator, like subscripts and function calls), and second
with DNS source routing. Whatever its other faults, a pure bang path is
at least self consistent. Why not user@site@site@site?
(Forth and Lisp afficianados will recognise this argument)
(and then there's what the British did to the DNS...)
--
Peter da Silva. `-_-'
+1 713 274 5180.
<peter@ficc.ferranti.com>karl_kleinpaste@cis.ohio-state.edu (07/10/90)
peter@ficc.ferranti.com writes:
But, still, DNS source-routing is incredibly ugly.
Peter, quit putting up that straw man. It's getting irritating.
Source routes are part of RFC822. But _nobody_ likes them. They're
hated so badly and so universally that RFC1123 revises the situation
and actually tries to shut them down, giving the option that a site
can be fully compliant while flatly ignoring source routes. RFC1123,
section 5.2.6, page 52:
DISCUSSION:
The intent is to discourage all source routing and to
abolish explicit source routing for mail delivery within
the Internet environment. Source-routing is unnecessary;
the simple target address "user@domain" should always
suffice. This is the result of an explicit architectural
decision to use universal naming rather than source
routing for mail. Thus, SMTP provides end-to-end
connectivity, and the DNS provides globally-unique,
location-independent names. MX records handle the major
case where source routing might otherwise be needed.
Source routes suck. Everybody knows it. Stop arguing an empty point.
--karl
--
"Reading news with GNUS gives the phrase `garbage collecting'
a whole new meaning." --jgreely@cis.ohio-state.eduurlichs@smurf.sub.org (Matthias Urlichs) (07/10/90)
In comp.mail.uucp, article <++J4QGC@xds13.ferranti.com>,
peter@ficc.ferranti.com (Peter da Silva) writes:
< In article <KARL.90Jul9143911@giza.cis.ohio-state.edu>
< karl_kleinpaste@cis.ohio-state.edu reposts his original review of
< That Hideous Name.
<
I wonder what these people would say about the longish X.400 "tree names"
(yes, X.500 talks about a Global Naming Tree ;-) -- BTW, they're not domain
names because the appropriate documents use that word for something almost,
but not quite, different) which start appearing in people's signatures..?
< I think we're all agreed that the DNS is a good thing, and if you want to
< get to a registered site it's the cat's meow, and finally that RSN all sites
< will be registered.
<
That "RSN" might be a tad too optimistic. :-(
But gentle force may be useful when convincing people to register...
On the German hobbyist's UUCP-style network (more or less a superset of
.sub.org), for instance, either you get registered in our domain (or in any
other domain, for that matter) or you won't get any mail back to you except
when (a) the sender actively source routes and (b) you get lucky. (As of now,
political problems still prevent the reverse from being true also... Oh well.)
< [ Prefix vs. postfix considered harmful ] Why not user@site@site@site?
user%site%site@site gives you that one... more or less.
<
< (and then there's what the British did to the DNS...)
Well, if they _want_ the hassles they're presumably getting (I freely admit
almost-total ignorance here) with having to parse their domain names from both
directions, they're welcome to it. ;-)
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)peter@ficc.ferranti.com (Peter da Silva) (07/11/90)
In article <KARL.90Jul10093842@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: > peter@ficc.ferranti.com writes: > But, still, DNS source-routing is incredibly ugly. > Peter, quit putting up that straw man. It's getting irritating. OK, so how do we get a *path* through the internet? Even if everyone is domainised, somewhere someone out in UUCP land *has* to run pathalias to figure out how to get there. So we have to deal with mixed precedence addresses, or use source routing. People are going to source routing, because the address: a!b@c is interpreted differently by different mailers, as is the address: a!b%c It's not a straw man. It's bounced mail. It's getting less common as more and more sites support pure bang paths, but there are always folks who insist on mixed syntax. And it's as much a problem here as it is in C declarations. We need a cdecl for mailpaths. :-> -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
ches@alice.UUCP (Bill Cheswick) (07/11/90)
> I wonder what these people would say about the longish X.400 "tree names"
We simply won't use it, for the same reason we don't use sendmail - it
is much too big.les@chinet.chi.il.us (Leslie Mikesell) (07/11/90)
In article <KARL.90Jul9143911@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >You have just returned to the land of transport-centric addressing. >I'm really tired of having to know what network someone is using. >With DNS, I don't have to. It's silly to have to tell your physical >postmaster how to find your street -- s/he's just supposed to know >that. Email should be treated similarly -- the user isn't supposed to >have to know or care about how the bits get between here and there. >You force them to know by encouraging network-specific address forms. But the DNS really wants the sending postoffice to know that a building exists at a certain street address or rural route before sending a message instead of just passing along the necessary information to the receiving postoffice that may have its own way of doing things. At least the current methods make it extremely inconvienent to pass that information around bi-directionally. Sort of like not being able to put a street number and a zip code on the same letter. >[...] and assuming that the machine name >is an FQDN, it's of the form "f.q.d.n!user," which can be transformed >to "user@f.q.d.n" with no loss of information; so the only remaining >difference is in the choice of network punctuation and the ordering of >the (host,user) pair. In other words, no semantic difference remains. *If* the end point is an FQDN. F.q.d.n!site!user or site!user@f.q.d.n are subject to all sorts of abuse by the transports. >You can indicate transport however you want, but it's clear >that, as a practical matter if not a theoretical one, !-paths >ultimately result in transport indications. In dial-up uucp, obviously the transport follows the connectivity, and the theoretical (and reasonable) domain!user must be converted to a physical path to some other machine or its not going to go anywhere. In a uucp-connected subdomain, the tendency seems to be for a.b.c to actually become c!b!a in the transport but its not necessary. Neither is the reverse, given suitable software. >Kinda silly. Not as silly as machines that prevent you from using the routing information that you know will work, or reliably passing it to another site. Given an f.q.d.n as an anchor point, mail is not transport-centric leaving your site. After that, its not your problem, or it wouldn't be if there were a reliable way to specify routing so that mail wouldn't bounce all the time. Actually, it would be better not to think of it as routing, but an address in a different syntax (and it may well be). A reasonable naming scheme should let you encapsulate any other scheme within it. The DNS itself doesn't actually prevent this, but the current software certainly doesn't handle it well. To require an FQDN without enforcing some sort of organization among sites that have no particular reason to be organized is going to result in a nearly flat address space anyway, so why not just allow .uucp? Or, perhaps the internet <-> uucp forwarders could just offer a sub-subdomain name to their connections. Les Mikesell les@chinet.chi.il.us
I.G.Batten@fulcrum.bt.co.uk (Ian G Batten) (07/11/90)
peter@ficc.ferranti.com (Peter da Silva) writes: > (and then there's what the British did to the DNS...) But, with karmic correctness, the major headaches fall to us anyway. ian
amanda@mermaid.intercon.com (Amanda Walker) (07/12/90)
In article <3RK4TQE@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > OK, so how do we get a *path* through the internet? We don't. You send paths through UUCP. The fact that currently you can "tunnel" UUCP paths through the internet is a bug, not a feature. Once mail gets to the Internet, it should have an address, not a route. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
chip@tct.uucp (Chip Salzenberg) (07/12/90)
According to peter@ficc.ferranti.com (Peter da Silva):
>OK, so how do we get a *path* through the internet?
You don't.
The envelope (rmail parameter) will have a bang path that ends in
"...!gateway!inter.net.host!user". The address in the message header,
however, will be RFC822: "user@inter.net.host". That's all there is
to it.
--
Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>peter@ficc.ferranti.com (Peter da Silva) (07/12/90)
In article <269B6560.3F1E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > We don't. You send paths through UUCP. The fact that currently you can > "tunnel" UUCP paths through the internet is a bug, not a feature. Once > mail gets to the Internet, it should have an address, not a route. That's all very well, but in the real world you have little UUCP trees hanging off the internet, and pathalias gives you a nice little bang path all the way through to the end. Your idealism is commendable, but for the forseeable future it's going to be necessary to "tunnel" uucp paths through the internet. So how does one do it? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
amanda@mermaid.intercon.com (Amanda Walker) (07/13/90)
In article <S2M4Q11@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > That's all very well, but in the real world you have little UUCP trees > hanging off the internet, and pathalias gives you a nice little bang path > all the way through to the end. > > Your idealism is commendable, but for the forseeable future it's going to > be necessary to "tunnel" uucp paths through the internet. So how does one > do it? Use bang paths. ...!...!...!f.q.d.n!...!...!... is fine, because it is unambigous. ..!...!...%...@f.q.d.n is not, because it's not. -- Amanda Walker <amanda@intercon.com> Postmaster With An Attitude InterCon Systems Corporation
peter@ficc.ferranti.com (Peter da Silva) (07/13/90)
In article <269D048B.5A0C@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > Use bang paths. ...!...!...!f.q.d.n!...!...!... is fine, because it is > unambigous. Once it gets to f.q.d.n it doesn't matter whether it's !-pathed, @-ed, %-ed, if the name after ! is an internet address you're still tunneling uucp through the internet. I use smail and convert everything to bang paths anyway. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
urlichs@smurf.sub.org (Matthias Urlichs) (07/14/90)
In comp.mail.uucp, article <S2M4Q11@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: < In article <269B6560.3F1E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: < > We don't. You send paths through UUCP. The fact that currently you can < > "tunnel" UUCP paths through the internet is a bug, not a feature. Once < > mail gets to the Internet, it should have an address, not a route. < < That's all very well, but in the real world you have little UUCP trees < hanging off the internet, and pathalias gives you a nice little bang path < all the way through to the end. < Your idealism is commendable, but for the forseeable future it's going to < be necessary to "tunnel" uucp paths through the internet. So how does one < do it? I'm currently running my mailer (MMDF, with the UUCP stuff somewhat modified) based on the reasonable assumption that anyone hanging off me has either Pathalias, is on the Internet, or is a node with one single connection (to me). So I don't generate paths, I generate "uux - nexthop!rmail user@somewhere" (with 'somewhere' either a FQDN or a hostname.UUCP), or somewhere!user for the one site which can't understand the former yet. Mangling Pathalias output to do the same is real easy via a simple sed script, which transforms host: hop1!hop2!hop3!host!%s into host: hop1!host!%s and which is left as an exercise to the reader.) This is based on the simple assumption that the next site along the path really should know better how to get to the destination than I do, since it's assumed to be closer to it. Of course, that Internet site, probably not running Pathalias, might need another FQDN so that it will know where to send that mail. (Why is no one offering .UUCP MX service? Just distill the pointers from the maps, everyone should be happy -- right?) A Perl script which analyzes the raw maps will help determine the FQDN of the correct host; I'm currently testing it. The equivalent operation on the other side of the mailer, called "Rerouting", is kind of a religious issue by itself... Right now I'm chopping off incoming elements from the left until I either see the end (i.e. a user name) or an unknown host, and then back off one. It has yet to break anything at this site; in this is differs from the widely used method of examining the path from the right and stopping at the first _known_ host, which _does_ break things.) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
amanda@mermaid.intercon.com (Amanda Walker) (07/15/90)
In article <T:M4WO4@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > Once it gets to f.q.d.n it doesn't matter whether it's !-pathed, @-ed, %-ed, > if the name after ! is an internet address you're still tunneling uucp > through the internet. Mmmm, sort of. There are hosts (such as UUNET) which will "pretend" to have UUCP connectivity with hosts that they actually reach via SMTP over the Internet. Even so, it is still a route, and not an attempt to encapsulate a route in an address. Also, I don't want to give the impression that I think that it's gatewaying mail or even passing UUCP mail through the Internet that's a problem--on the contrary, I am all in favor of as universal connectivity as possible. What I object to is promulgating magic interpretations of the local part of an address, and even that I only object to because it breaks. Back in The Old Days, when the UUCP network map fit on a half-page of line printer paper, ARPANET used an essentially static host table, and Berkeley was the only point of contact between them, source routing worked pretty well (not perfectly, but pretty well). I know--I used it. However, at this point, the state of email connectivity is so complex that any magic that is introduced to make life easier in one place makes it harder somewhere else. Entropy is conserved :-). On the Internet, source routes have been deprecated in favor of domain addresses and mail exchangers. This isn't because of politics, it's because it works better this way. !-@ hybrids and %ification are just source routes in disguise, and they are just as prone to break mail. My domain bigotry is not based on idealism, it's based experience and on the fact that when I have to send mail to someone with something besides a straight UUCP path or a straight domain address, chances are it will bounce or disappear. I've given up on even *trying* addresses with a few certain sites in them, because I have never seen mail get through them, however permuted an address I use. Mail comes out of them, but it never gets back... DNS + MX handling: it's not the law, it's just a good idea. -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
peter@ficc.ferranti.com (Peter da Silva) (07/16/90)
In article <[$6je2.vl6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > I'm currently running my mailer (MMDF, with the UUCP stuff somewhat modified) > based on the reasonable assumption that anyone hanging off me has either > Pathalias, is on the Internet, or is a node with one single connection (to > me). In Germany that might be a reasonable assumption. I know that telecommunication costs are simply outrageous, and there's this all the weird EUNET rules on top of that. In the U.S., where people typically get Usenet access by finding someone and hooking up... without necessarily telling *any* sort of central authority... it's not. Now whether or not people should be forced to tell the NIC when they get onto Usenet is a political issue, and I shan't touch it. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (07/16/90)
In article <269FEC7D.40E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > I've given up on even *trying* addresses with a few certain sites in them, > because I have never seen mail get through them, however permuted an address > I use. Mail comes out of them, but it never gets back... I don't suppose it might be because someone between you and them decided to block source routing... as you originally implied you were doing? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
karl_kleinpaste@cis.ohio-state.edu (07/16/90)
amanda@mermaid.intercon.com writes: > I've given up on even *trying* addresses with a few certain sites in them, > because I have never seen mail get through them, however permuted > an address I use. Mail comes out of them, but it never gets back... peter@ficc.ferranti.com writes: I don't suppose it might be because someone between you and them decided to block source routing... as you originally implied you were doing? I've never seen that as a cause. Rather, it's with bogus domain registrations. No, I don't mean .uucp, I handle that, bogus though it is; I mean, just to pull an example out of the air (wouldn't want to step on anyone's toes or anything, purely hypothetical and all that, any relation between this example and the Real World(tm) is purely coincidental, fictional hosts, etc ad nauseum)... ...scallop.austin.ibm.com. [mumble,] --karl PS- One of my users gets mail from this garbage site. "You can't get there from here." | [69] [9:49am] giza:/n/giza/0/karl> host -a scallop.austin.ibm.com. | Host not found. | [70] [9:49am] giza:/n/giza/0/karl> host -a austin.ibm.com. | Host not found. | [71] [9:49am] giza:/n/giza/0/karl> host -a ibm.com. | The following answer is not authoritative: | ibm.com 170755 IN NS RELAY.CS.NET | ibm.com 170755 IN NS SH.CS.NET | ibm.com 53998 IN SOA sh.cs.net cic.sh.cs.net( | 29 ;serial (version) | 108000 ;refresh period | 300 ;retry refresh this often | 54000 ;expiration period | 54000 ;minimum TTL | ) | For authoritative answers, see: | IBM.com 170755 IN NS RELAY.CS.NET | IBM.com 170755 IN NS SH.CS.NET | Additional information: | RELAY.CS.NET 170817 IN A 192.31.103.4 | SH.CS.NET 170817 IN A 192.31.103.3 | SH.CS.NET 170817 IN A 128.89.0.92 | [72] [9:49am] giza:/n/giza/0/karl> host -a austin.ibm.com. sh.cs.net. | Using domain server: | Name: sh.cs.net | Address: 192.31.103.3 128.89.0.92 | Aliases: | | Host not found.
amanda@mermaid.intercon.com (Amanda Walker) (07/17/90)
In article <UBP4EI9@ggpc2.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > I don't suppose it might be because someone between you and them decided to > block source routing... as you originally implied you were doing? No, it's because the host in question (let's call it XXX.COM) **requires** source routing for mail going into the organization, and then, as far as I can tell, breaks any mail coming in from the outside world, however it's addressed. Occasionally, I will get a piece of mail that has managed to escape with a domain address, and I get hopeful, but evidently subdomains of XXX.COM are supposed to be secret, and XXX.COM itself will bounce my replies back. Argh. Sound familiar, anyone...? -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
peter@ficc.ferranti.com (Peter da Silva) (07/17/90)
In article <KARL.90Jul16095640@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: [ inaccessible sites ] > I've never seen that as a cause. Rather, it's with bogus domain > registrations. [ like IBM ] Oh, I assumed you meant something was screwed up. Institutionalised corporate paranoia doesn't count. That has nothing to do with paths or domains... Tried to get anything through AT&T lately? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
les@chinet.chi.il.us (Leslie Mikesell) (07/17/90)
In article <[$6je2.vl6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >Mangling Pathalias output to do the same is real easy via a simple sed script, >which transforms > host: hop1!hop2!hop3!host!%s >into > host: hop1!host!%s >and which is left as an exercise to the reader.) >This is based on the simple assumption that the next site along the path >really should know better how to get to the destination than I do, since it's >assumed to be closer to it. Hmmm, it should be fun when 2 sites doing this each decide that the other is the best next-hop toward the end point. Les Mikesell les@chinet.chi.il.us
urlichs@smurf.sub.org (Matthias Urlichs) (07/17/90)
In comp.mail.uucp, article <KBP4=A9@ggpc2.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: < In article <[$6je2.vl6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: <> I'm currently running my mailer (MMDF, with the UUCP stuff somewhat modified) <> based on the reasonable assumption that anyone hanging off me has either <> Pathalias, is on the Internet, or is a node with one single connection (to <> me). < <In Germany that might be a reasonable assumption. I know that telecommunication <costs are simply outrageous, and there's this all the weird EUNET rules on <top of that. In the U.S., where people typically get Usenet access by finding <someone and hooking up... without necessarily telling *any* sort of central <authority... it's not. < Right about the telecommunication costs, but wrong on EUNET rules. (We are doing what we're doing precisely because we want to avoid any and all of these rules, but I'd better not talk politics now. ;-) Maybe I phrased this wrong. I _know_ that the people hanging off me are such hosts. If any of them has just dumb UUCP-bang-without-even-smail software, doesn't understand what @s are for, and needs routes generated for them, that's their problem, and it's their job to generate the addresses appropriate for forwarding the mail. The only remaining problem with this strategy is, of course, whether a site XYZZY is _the_ site XYZZY, or some other XYZZY which doesn't appear in the maps but is connected to a site which either has a domain name or is in the maps. That's the only condition which a reasonably-smart rerouting algorithm can't cope with. But, to be honest, I don't think that this is my problem; it's the "other" XYZZY who is having a bad time. So mail to them may go to the wrong host. Tough. Sooner or later, people will realize what's going on, and XYZZY will either change its name or register in a "real" domain, and the problems will be over. If you want to eliminate all those problems with routing and mixed-mode addressing, and want to exclusively use real RFC822-addresses in the near/far/any future (user@host.UUCP is considered to be a real RFC address for the purposes of this discussion), you gotta start somewhere. I choose to start right here. After all, (a) it's my host, (b) it works. The only problem was writing a Perl script which distills domainized host names from the maps, and then aliases all UUCP names to domain names before trying to get any intelligent routing done. After all, if anyone wants to send his/her mail through a ten-hop path instead of directly beaming it across the Internet, then that's their decision, but definitely not mine. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
peter@ficc.ferranti.com (Peter da Silva) (07/17/90)
In article <z]fle2.ia2@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > Maybe I phrased this wrong. I _know_ that the people hanging off me are such > hosts. Like I said, maybe that's how things are in Germany, but here in the states Usenet is not a tree. Look at the postscript maps some time: you have this nice tree structure in Europe, and an incredible mesh of redundant links in the U.S.. Even clumps of sites hanging off the internet are going to look the same way, as individuals with PCs hook on and drop off. > The only problem was writing a Perl script which distills domainized host > names from the maps, and then aliases all UUCP names to domain names before > trying to get any intelligent routing done. After all, if anyone wants to send > his/her mail through a ten-hop path instead of directly beaming it across the > Internet, then that's their decision, but definitely not mine. Three points. What if that message contains material that violates the Internet's charter. Say, digitized playboy pics? Besides, I don't consider the growing dependence of Usenet on the Internet a healthy trend. If it wasn't for the independent nature of Usenet, your little subnet wouldn't have stood a chance. And there is still the problem of getting to sites that you know about but aren't in the maps? Not everyone publishes all their connections: look at the map entry for Intercon. And that's a site that fully supports domains! Finally, routing everything through the internet is expensive. That 10-hop path might be cheaper than sending the mail up the hierarchy and a few thousand miles to the friendly internet site you leach off, only to have it beamed back to a location 30 miles away. Better to send it through your buddy's system because a friend of his is a student at the local college. Hod do you find that out? The maps. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
karl_kleinpaste@cis.ohio-state.edu (07/17/90)
peter@ficc.ferranti.com writes:
Tried to get anything through AT&T lately?
_Through_ AT&T, no. I never try to get anything _through_ att.
They've been publicly declared "dead" as a pass-through site for a
couple of years now. You are keeping up on this sort of basic
configuration detail, yes?
I get mail _to_ AT&T routinely, on a daily basis. No sweat.
--karlkarl_kleinpaste@cis.ohio-state.edu (07/17/90)
urlichs@smurf.sub.org (Matthias Urlichs) writes: >This is based on the simple assumption that the next site along the path >really should know better how to get to the destination than I do, >since it's assumed to be closer to it. les@chinet.chi.il.us writes: Hmmm, it should be fun when 2 sites doing this each decide that the other is the best next-hop toward the end point. Yup, mail ping-pong, followed by bounce-o-gram due to hopcount overrun. Big deal. Consider it an inducement to fix the @#$% pathalias values and local routing tables. Periodically, someone (I forget who; if you're reading, please identify yourself and take a bow) posts to comp.protocols.tcp-ip a list of bogon domain pointers -- he walks the entire domain tree, finding NS records that aren't actually supported by the referenced hosts. I've been caught in that list twice. I considered it a favor and appreciated it fully, and fixed the problems immediately. Based on the !-path centric crowd seen around here, I expect to be told that doing the equivalent thing for pathalias routing would be considered abuse, rather than assistance. --karl
urlichs@smurf.sub.org (Matthias Urlichs) (07/18/90)
In comp.mail.uucp, article <1990Jul16.203728.501@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: < In article <[$6je2.vl6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: < < [ UUCP-Non-routing ] < >This is based on the simple assumption that the next site along the path < >really should know better how to get to the destination than I do, since it's < >assumed to be closer to it. < < Hmmm, it should be fun when 2 sites doing this each decide that the other < is the best next-hop toward the end point. < You're right; that's why mailers have a maximum hop limit... A better solution might be to remember the message-ID and to generate successively longer paths if the message shows up again (or to examine the Received:-headers, which aounts to the same thing). Unfortunately I haven't found a good way to integrate that into MMDF yet, and I am not going to search unless it becomes a problem, which it isn't now. Anyway, ping-pong routing like that will not happen unless a link gets downgraded or dead, and only if this downgrading isn't propagated in the maps. The latter can happen when I adjust link costs without making them public, or when some site doesn't use the latest maps. So, that situation can be avoided by publishing a new map entry with downgraded link cost, but using the old link cost for local routing until everyone else has the new map. Alternately, it can be avoided by never downgrading a link, which is what I am doing -- instead, links tend to get better as more and more people discover the joys of faster modems. ;-) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
david@twg.com (David S. Herron) (07/18/90)
In article <[$6je2.vl6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >< In article <269B6560.3F1E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >< > We don't. You send paths through UUCP. The fact that currently you can >< > "tunnel" UUCP paths through the internet is a bug, not a feature. Once >< > mail gets to the Internet, it should have an address, not a route. eh? the internet-gateway can fully handle the translation of a!b!c!d to <@a,@b:d@c> and back to b!c!d once it gets to a ... what's the problem?? Other than a little unavoidable header translation that is.. >I'm currently running my mailer (MMDF, with the UUCP stuff somewhat modified) >based on the reasonable assumption that anyone hanging off me has either >Pathalias, is on the Internet, or is a node with one single connection (to >me). Quickly stepping in to save MMDF's ass :-) >So I don't generate paths, I generate "uux - nexthop!rmail user@somewhere" >(with 'somewhere' either a FQDN or a hostname.UUCP), or somewhere!user for the >one site which can't understand the former yet. >Mangling Pathalias output to do the same is real easy via a simple sed script, >which transforms > host: hop1!hop2!hop3!host!%s >into > host: hop1!host!%s >and which is left as an exercise to the reader.) My general strategy, and that of MMDF's, is that anything beyond the first hop in the address is left as an excercise to the next hop, not this hop. The only modification of that strategy which I would allow is to look into the address for FQDN's and route directly to the last one. This might foil somebody who's trying to route around something but still putting FQDN's into their path. >This is based on the simple assumption that the next site along the path >really should know better how to get to the destination than I do, since it's >assumed to be closer to it. You can't control all the sites around you. Nor can you control what happens beyond your neighbors, but what happens out there will still go through your site occasionally. -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
amanda@mermaid.intercon.com (Amanda Walker) (07/18/90)
In article <L4Q4M=6@ggpc2.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > routing everything through the internet is expensive. That 10-hop > path might be cheaper than sending the mail up the hierarchy and a few > thousand miles to the friendly internet site you leach off, only to have > it beamed back to a location 30 miles away. Cost is relative, though. For example, I once sent a package less than 50 miles via Federal Express. It would have been cheaper by one metric (cash outlay) to just drive out and drop it off. On the other hand, the extra couple of bucks were well worth it terms of time and reliability. Sometimes it really does make more sense to bounce a message around the planet, for performance or administrative reasons. To take another example, my brother works at a NASA center just across the city from me. When he sends me mail, it goes from GSFC to Ames (other coast) to U.S. Sprint's X.400 gateway to the Internet to UUnet to me. It would be "cheaper" to have his machine call mine (it's just a local call, after all), but it would not be even close to cost effective to do so. Sending those bits across the country a couple of times has negligible marginal cost, either in terms of either money or administrative overhead. If we were shipping megabytes of data around every day, then it might be worth it. For a similar reason, most of my mail to OSU goes over the Internet, even though I have the ability to UUCP directly to osu-cis for picking up files (when, that is, I can get through to the lone Trailblazer+). -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
urlichs@smurf.sub.org (Matthias Urlichs) (07/18/90)
Warning: Some or all of the following may be bleedin' obvious to some people, blatantly wrong to others, and just disconnected ramblings to still others. You have been warned. In comp.mail.uucp, article <L4Q4M=6@ggpc2.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: < In article <z]fle2.ia2@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: < > Maybe I phrased this wrong. I _know_ that the people hanging off me are such < > hosts. < < Like I said, maybe that's how things are in Germany, but here in the states < Usenet is not a tree. Look at the postscript maps some time: you have this < nice tree structure in Europe, and an incredible mesh of redundant links in < the U.S.. Even clumps of sites hanging off the internet are going to look the < same way, as individuals with PCs hook on and drop off. < Umm, like I said before, the German UUCP network is divided into two parts: One consists of EuNET members and subscribes to that tree structure (more or less -- see below), the other part does as it damn well pleases, much like you do in the US. I am part of the latter. Anyway, none of my configuration depends on this. I am just using knowledge about my neighbors, based both on what they tell me about themselves and what they do about my fancy RFC822 addresses I send them when testing the link. What higher-level structure (if any) my neighbors and I are meshed into does not enter the picture. <>The only problem was writing a Perl script which distills domainized host <>names from the maps, and then aliases all UUCP names to domain names before <>trying to get any intelligent routing done. After all, if anyone wants to send <>his/her mail through a ten-hop path instead of directly beaming it across the <>Internet, then that's their decision, but definitely not mine. < < What if that message contains material that violates the Internet's charter. < Say, digitized playboy pics? Besides, I don't consider the growing dependence < of Usenet on the Internet a healthy trend. If it wasn't for the independent < nature of Usenet, your little subnet wouldn't have stood a chance. I'd like to see "The Internet's Charter", please. Sending the EMail equivalent of alt.sex.pictures across the Internet may violate some charter or other, but so does mailing said picture across multiple UUCP hops violate the purpose these links have been set up for. Besides, what do you want me to do? Make my mailer analyze your (and anyone else's) traffic, using some sort of AI, when deciding how to route it? I don't think I have to mention that this won't work. If two sites want to exchange traffic which violates anything, either in content or in volume, they'll have to set up a private link. No problem. Or to be more exact, their problem, not mine. Reserving some links for some special traffic is easy if you use MMDF. Don't say "your little subnet". There are 570 sites in our map, which isn't exactly little. ;-) < And there is still the problem of getting to sites that you know about but < aren't in the maps? Not everyone publishes all their connections: look at < the map entry for Intercon. And that's a site that fully supports domains! If I know (a path to) someone who isn't in the maps, I have to add a route to that site into my database. No problem; the algorithm only breaks down when I locally attribute a link with higher cost than with which it is published. Besides, if Intercon has a private link which isn't published, then either the linked-to site is in the maps or it isn't. If it is not, then I'll have to use source routing, and my MTA knows about that. If it is, then presumably Intercon doesn't want that link used for general traffic anyway and Pathalias will find a better route. < < Finally, routing everything through the internet is expensive. That 10-hop < path might be cheaper than sending the mail up the hierarchy and a few < thousand miles to the friendly internet site you leach off, only to have < it beamed back to a location 30 miles away. Better to send it through your < buddy's system because a friend of his is a student at the local college. < Hod do you find that out? The maps. I didn't say that I want to route everything through the Internet. There also isn't a hierarchy. The Usenet map (which is not relevant to this discussion since it's a News map, not a UUCP map) still looks like a tree over here, and so do the UUCP maps for that matter, but today the "backbone" links are Internet lines. Why generate a path along these links instead of sending the mail directly to the destination? I _am_ using pathalias to find out how the mail would be routed. Who said I don't? Assume the pathalias-generated path sitea!siteb!sitec!sited!user, which (according to the maps) is equivalent to sitea.dom.one!siteb!sitec.dom.x! !sited!user. These equates are in the maps, but so far no one seems to actively use them. Now I can do what everyone else seems to be doing which is to take the first bang path and dump it on sitea, which I'm trying to avoid. Alternately, if I know sitea to be intelligent enough, I say "user%sited@sitec.dom.x" (or whatever style of source routing both I and sitea like). Or, if sited is registered in a part of the map which both I and sitea know about, I can say user@sited. If siteb isn't intelligent enough to understand that sort of address, then sitea has to generate a path through it. I'll do the same with any of my neighbors who requires it (and if I publish links to those, they'll be marked DAILY*2 or higher in order to avoid them, if possible), but if siteb needs bang paths it's not my problem, and not my responsibility either, but sitea's. Or, I can take the short cut across the network, and say "user%sited@sitec.dom.x" (or "@sitec.dom.x:user@sited". Or you might use "sited!user@sitec.dom.x" if you want to. I'm not that optimistic) to sitec's SMTP ports. Or to the SMTP port sitec.dom.x is MXed to, which amounts to the same thing -- I'm willing to assume that links to MXes are reasonably fast. I'll admit that how to determine which of these options to use may not always be obvious, but they all should work. The reverse problem is far more common, i.e. when someone generates a ten-hop-path (hosta!....hostj!user), and no one realizes that hostb could send the stuff directly to hosti through the Internet instead of letting the addresses get mangled beyond recovery. I've seen lots of that happen with my bang paths. That's why I decided to cut through all this, and hand off the addresses to my neighbors according to their intelligence. See above. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
peter@ficc.ferranti.com (Peter da Silva) (07/18/90)
In article <KARL.90Jul17113119@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: > Based on the !-path centric crowd seen around here, I expect to be > told that doing the equivalent thing for pathalias routing would be > considered abuse, rather than assistance. Wrong again. There are people who check the maps, at least for local sites, and get people to fix them. I've been guilty, been reprimanded, and updated my entry. But I'm a computer nerd. You can't expect folks who aren't totally into this stuff to spend as much time on it. Just getting a chat script to work is tough enough. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
peter@ficc.ferranti.com (Peter da Silva) (07/18/90)
In article <26A3CFD1.67F@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > It would be "cheaper" to have his machine call mine (it's just a local call, > after all), but it would not be even close to cost effective to do so. Sounds like the UUCP connectivity in your neck of the woods sucks. Over here it's pretty complete, but Internet connectivity is strictly long distance. That's what the costs in the maps are for, to allow for this sort of regional variation. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
urlichs@smurf.sub.org (Matthias Urlichs) (07/19/90)
In comp.mail.uucp, article <7619@gollum.twg.com>, david@twg.com (David S. Herron) writes: < In article <[$6je2.vl6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: < < >I'm currently running my mailer (MMDF, with the UUCP stuff somewhat modified) < >based on the reasonable assumption that anyone hanging off me has either < >Pathalias, is on the Internet, or is a node with one single connection (to < >me). < Quickly stepping in to save MMDF's ass :-) < >Mangling Pathalias output to do the same is real easy via a simple sed script, < >which transforms < > host: hop1!hop2!hop3!host!%s < >into < > host: hop1!host!%s < >and which is left as an exercise to the reader.) < < My general strategy, and that of MMDF's, is that anything beyond < the first hop in the address is left as an excercise to the next < hop, not this hop. The only modification of that strategy which Caution: You are talking about addresses as they come in, probably via rmail. I was talking about generating a routing database for those addresses. < I would allow is to look into the address for FQDN's and route < directly to the last one. This might foil somebody who's trying to < route around something but still putting FQDN's into their path. < Unfortunately, that general strategy doesn't always work in an environment where about everyone else has their own ideas on what to do to mixed-mode addresses (defined as containing !s and either @s or %s). At least here, it has proven to be far less hassle to modify that strategy, but only for incoming UUCP stuff. Think of this as adjusting the incoming addresses to fit into MMDFs view of the world. ;-) Besides, "looking for FQDNs in a path" can also be defined as first converting all members of the bang path into FQDNs whenever possible (you do this by examining the maps' "system = alias1.dom.ain" lines), and _then_ looking for the last FQDN... < >This is based on the simple assumption that the next site along the path < >really should know better how to get to the destination than I do, since it's < >assumed to be closer to it. < < You can't control all the sites around you. Nor can you control what < happens beyond your neighbors, but what happens out there will still < go through your site occasionally. < Who said anything about controlling? I am using my knowledge about my neighbors (both what their mail admin tells me when we're setting up the link, and what I get back when sending weird addresses (which nevertheless point back at me) down the line) to decide which is the most intelligent address format each can handle, and sending out that. The other, more common way seems to be to use the lowest common base, bang paths, and sending these to everyone. I think the former way is better. You might also argue that sending each message separately via uux is stupid and should be replaced by something more intelligent, like BSMTP. We're doing that also (assuming that I get the BSMTP-sending interface to MMDF debugged someday :-( Receiving BSMTP already works, courtesy of a Perl script). NB: All of the above does carry a big "IMHO", which should be obvious anyway. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
tp@mccall.com (07/19/90)
In article <7619@gollum.twg.com>, david@twg.com (David S. Herron) writes: > ... The only modification of that strategy which > I would allow is to look into the address for FQDN's and route > directly to the last one. ... This isn't guaranteed to work. Once upon a time, my email address from the internet was tp%mccall.claremont.edu@cunyvm.cuny.edu. the mccall.claremont.edu domain (or the claremont.edu domain) was not registered with the NIC at that time. It only existed on Bitnet. (I don't know of bitnet domains are all registered now, but there's probably other networks that have this problem (milnet?).) The bang-path version of this is, of course: cunyvm.cuny.edu!mccall.claremont.edu!tp Your scheme would break this, because you wouldn't know how to route mccall.claremont.edu!tp, so you'd send it to one of the hosts that advertizes itself as a gateway for .edu, and they wouldn't know either. As I said, this might not be a problem on bitnet anymore, but it might be somewhere. (The question is whether or not you care, I guess.) BTW, just to point out that this is not a contrived example, I did not have a .bitnet address, because I was not on bitnet, I had a PMDF phonenet link (similar to a uucp link for those who don't know) to someone who was. The only way to reach me was to use domain based addressing on bitnet because only his machine knew about the mccall subdomain, and his domain wasn't registered on the internet. Thus you had to route to a bitnet host that understood domain based addressing, and thence to me. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
peter@ficc.ferranti.com (Peter da Silva) (07/20/90)
In article <b9mme2.=+6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > Besides, if Intercon has a private link which isn't published, then either the > linked-to site is in the maps or it isn't. If it is not, then I'll have to use > source routing, and my MTA knows about that. Well, well, well. We get to the point here. You need source routing. If you don't have a problem with that, why are we having this discussion? > Assume the pathalias-generated path sitea!siteb!sitec!sited!user, which > (according to the maps) is equivalent to sitea.dom.one!siteb!sitec.dom.x! > !sited!user. These equates are in the maps, but so far no one seems to > actively use them. > Now I can do what everyone else seems to be doing which is to take the first > bang path and dump it on sitea, which I'm trying to avoid. Why? Assuming the maps are correct, dumping it on sitea is the cheapest way to do things. If they're not, then get them corrected. Just because sitea.dom.one and sitec.dom.x have domains *doesn't* mean they're on the internet. If you want to take a short cut like that, and your maps are more up to date than the originators, you have to check each link to make sure that the sitec you're trying to get to is the sitec in the maps. To do that you have to verify each link in the maps in turn. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
amanda@mermaid.intercon.com (Amanda Walker) (07/20/90)
In article <U.R43PA@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > In article <b9mme2.=+6@smurf.sub.org> urlichs@smurf.sub.org (Matthias > Urlichs) writes: > > Besides, if Intercon has a private link which isn't published, then > > either the linked-to site is in the maps or it isn't. If it is not, > > then I'll have to use source routing, and my MTA knows about that. > > Well, well, well. We get to the point here. You need source routing. If > you don't have a problem with that, why are we having this discussion? I think you've jumped to the wrong conclusion. He doesn't need source routing. If one of my links is published, as is the one to uunet (last I looked at our map entry), then he doesn't need to source route. If he tries to source-route through one of my unpublished links, his mail will bounce. They are unpublished precisely *because* they are for InterCon's use only. If I have a downstream feed that is not in the maps (such as the Macintosh on my desk), then it will have a domain name and my host will route mail appropriately based on that domain name. If (for some reason I cannot think of at the moment) I end up with a downstream feed without a domain name, it will appear in the maps and bounced mail will be their problem. Still no need for source routing, even for a dwnstream site that deals only in UUCP paths. Routing policy for my host is set at my host, not at the site where the mail originated... -- Amanda Walker <amanda@intercon.com> InterCon Systems Corporation
pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/23/90)
In article <269FEC7D.40E@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: On the Internet, source routes have been deprecated in favor of domain addresses and mail exchangers. This isn't because of politics, it's because it works better this way. !-@ hybrids and %ification are just source routes in disguise, and they are just as prone to break mail. But that is the problem! Those are not source routes, they are an example of *foreign naming* which is a completely different thing. The so called percent-hack is a way to require the interpretation of a name to be done at a specific host. There is something of the source routine here, but the essential assumption is that only the indicated host knows about such names. For example: "mcsun!ukc!pcg@uk.ac.aberyswtyth.cs"@uunet.uu.net is a relative name, *not* a route, and cannot be faithfully rendered as pcg@cs.aber.ac.uk even if it mostlt works, because the naming conventions of Janet are different from those of the Internet. The above monstrosity is *really* saying that 'uunet.uu.net' should be used to to interpret a non Internet address in the form of a bang path (note that 'ukc' is identified as the one near 'mcsun', but uunet.uu.net may well connect directly to 'ukc', without routing thru 'mcsun', using the reference to the latter only to disambiguate possible confusion iof there is another host called 'ukc'), and 'ukc' should be used to interpret a Janet address, which superficially resembles an Internet address, but plays by totally different rules. My domain bigotry is not based on idealism, it's based experience and on the fact that when I have to send mail to someone with something besides a straight UUCP path or a straight domain address, chances are it will bounce or disappear. The problem here is that you can only avoid relative naming if every netowrk system shares its full directory with everybody else, e.g. if all Janet hosts get registered with the DNS, and viceversa. Unfortunately this is in general possible, and relative name interpretation is necessary. Summary: We have absolute names, e.g. internet ones, whcih are only tenable if there is centralized administrative authority, however lightweight, and a single directory system. We have relative names, e.g. UUCP ones, where a host is uniquely identified by a pattern of neighbours. This name *may* be used for routing, and usually is. We have foreign names, e.g. those that cross the boundary between two naming systems, whatever their flavour, which are kind of address *resolution* relative names/routes (but are not transport routes or relative names), where a succession of gateways is quoted, and it is assumed that only the gateway can sensibly interpret the rest of the address, because only the gateway is assumed knowledgeable of both different naming rules of the mail systems it bridges. It is, I believe, simply *impossible* to get rid of foreign names; IMNHO relative names are better than absolute names, at least if there is no authority with a mandate for naming and clear rules (e.g. ok for ARPA and X.400 and Janet, not ok for Internet and UUCP). -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk