page@swan.ulowell.edu (Bob Page) (08/05/88)
vixie@palo-alto.DEC.COM (Paul Vixie) wrote: >Sun thinks it owns the world. > From: vixie!paul@Sun.COM Many Internet mailers do this when going from bangland to the Internet. ULowell does it, and I know Harvard and MIT do it too. Rude is a relative term. You say munging From: lines is rude. I say sending Internet sites From: lines like vixie!paul is rude. The problem is that when people use a machine as a gateway to get from UUCP-land to the Internet, Internet-only hosts don't know (or care) what From: vixie!paul means, since they don't have anyone named vixie!paul on their local machine. Rewriting it to From: vixie!paul@swan.ulowell.edu will allow Internet systems to reply, as long as my mailer can handle the address. It should, since I'm the one constructing it. If Sun doesn't correctly deal with the From: lines it generates, Sun is being rude to UUCP land. If they pass along bangland addresses to the Internet, they're propagating your rudeness to the Internet. If UUCP hosts would generate non-bang From: lines, or Internet hosts understood bang paths, this would not be necessary. Having said that, rewriting from uucp-to-uucp is rude, and it's difficult to say if rewriting user@host.uucp from uucp to the internet is rude or not. They are not easy choices. One can run by strict rules, or bend the rules so more things work. But I agree that rerouting, under any circumstances, is rude. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "What a wonder is USENET; such wholesale production of conjecture from such a trifling investment in fact." -- Carl S. Gutekunst
vixie@palo-alto.DEC.COM (Paul Vixie) (08/09/88)
In article <8446@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes:
# Rude is a relative term. You say munging From: lines is rude. I say
# sending Internet sites From: lines like vixie!paul is rude.
I almost agree -- except that when you take in something via UUCP, you've
got to expect it to be in the natural format for UUCP. So if Sun is trying
to be polite by adding @Sun.COM for their internet neighbors, I can support
the practice.
Rewriting <paul@vixie.uu.net> into <sun!vixie.uu.net!paul> is different, tho.
This was one of my tests, intended to find out just what Sun was really
trying to do. It appears that anything coming in over UUCP is fair game.
# Rewriting it to
# From: vixie!paul@swan.ulowell.edu
# will allow Internet systems to reply, as long as my mailer can handle
# the address. It should, since I'm the one constructing it.
Looks like you run (at least) a passive router. Sun doesn't. So
From: vixie!paul@Sun.COM
isn't replyable. In such an instance,
From: vixie!paul
or From: paul@vixie.uucp
are about equal to
From: vixie!paul@Sun.COM
any probably superior, since the message won't have to go to Sun to be
rejected. In fact, without the @Sun.COM there, it's something that might
trigger somebody ELSE's passive router. With the @Sun.COM there, it's
something only a rerouting mailer would be able to "fix". Pfaa.
# If Sun doesn't correctly deal with the From: lines it generates, Sun
# is being rude to UUCP land. If they pass along bangland addresses to
# the Internet, they're propagating your rudeness to the Internet.
As I said, if the mail comes into Sun over UUCP, Sun had better be able to
deal gracefully with the natural UUCP format of From: lines. So while Sun
would be generating Internet rudeness (maybe) by sending a "vixie!paul"
address to an internet neighbor, there's no original rudeness to "propagate".
# If UUCP hosts would generate non-bang From: lines, or Internet hosts
# understood bang paths, this would not be necessary.
But it didn't help when I did just that. <paul@vixie.uu.net> is a perfectly
legal, completely valid, reachable, normal, okay-by-everybody Internet
address. If you have an MX mailer and you try to send to that address, it
will reach me. If you run a pathalias-based UUCP-only mailer, it will still
reach me.
# But I agree that rerouting, under any circumstances, is rude.
Yeah. :-).
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013page@swan.ulowell.edu (Bob Page) (12/07/88)
brian@ucsd.edu (Brian Kantor) wrote: >'pacbell' doesn't add its sitename to the "From:" line in mail, but does >add it to the "From " line. The system administrator at host 'pacbell' >claims he's doing the right thing. I think he's wrong. There it stands. You should never edit a From: line. Never. Most sendmail sites add their hostname to the front of the From: line, which is wrong for two reasons: - address info is *not* routing info. - not everybody does it! That means you get lines like: From host5!host4!host3!host2!host1!host!user From: host4!host1!host!user >There is no quick fix. You have been warned. The 'smail' package fixes this errant sendmail behavior. However it requires that mail admins believe From: munging is a bad thing, which is damn near impossible. Also, the latest available version of smail has enough problems for sites with complex configurations. Maybe smail 3.0 fixes everything but I haven't seen it yet, and I don't know about the IDA sendmail patches. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.
david@pacbell.PacBell.COM (David St.Pierre) (12/07/88)
brian@ucsd.edu (Brian Kantor) wrote: >'pacbell' doesn't add its sitename to the "From:" line in mail, but does >add it to the "From " line. The system administrator at host 'pacbell' >claims he's doing the right thing. I think he's wrong. There it stands. Um Brian, you're taking liberty with what I said. I didn't say I was doing the right thing - I did say that traditional System V mailers didn't attempt to support RFC822 and didn't really support "headers". System V behavior is to prepend a From_ to each message. That's it. That's what I do here. I understand that most sendmails rewrite the From: line - I don't really agree with that. I'd rather have a destination address and use pathalias. But that's a different discussion. When you get all those sendmails out there to support MX records (we're an MX record and a lot of mailers can't reach us), then I'll start getting concerned. But neither sendmail nor smail 3.x are my idea of a lot of fun. I use pathalias heavily and will re-route the next hop if I don't talk to them directly. Maybe an interim solution would be for ames to send all their uucp bounces to a site which uses pathalias and actively reroutes. Or hack another flag into sendmail (:-) to continually consolidate From_ lines. -- David St. Pierre 415/823-6800 {att,bellcore,sun,ames,pyramid}!pacbell!david
arnold@vdelta.volt.com (Dave Arnold) (12/08/88)
In article <10510@swan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes: > brian@ucsd.edu (Brian Kantor) wrote: >>'pacbell' doesn't add its sitename to the "From:" line in mail, but does >>add it to the "From " line. The system administrator at host 'pacbell' >>claims he's doing the right thing. I think he's wrong. There it stands. > > You should never edit a From: line. Never. Most sendmail sites > add their hostname to the front of the From: line, which is wrong for It seems to mean we are getting From: lines and From_ lines confused. RFC976 says that you *SHOULD* add your 'site' to the beginning of the From_ line. The From_ line is used for routing. It's part of the UUCP transport envelope.
henry@utzoo.uucp (Henry Spencer) (12/09/88)
In article <504@pacbell.PacBell.COM> david@pacbell.PacBell.COM (David St.Pierre) writes: >System V behavior is to prepend a From_ to each message. That's it. In fact, this considerably pre-dates System V, and RFC822 (although not its predecessors) as well. This is the *standard* mailer behavior for uucp mail, dating back to V7. Any mailer that can't cope with other mailers doing it has broken backward compatibility, a very stupid thing to do in this network. >... Or hack another flag into sendmail (:-) to >continually consolidate From_ lines. Actually, the only program that should ever consolidate From_ lines is the user agent at the receiver. Consolidation removes information, and should not be done gratuitously by relay sites. (We won't even mention that 4.1 and, I think, all its successors, have bugs in the consolidation code...) Alas, there are a lot of misguided mailers that do consolidation at the drop of a hat... -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
brian@ucsd.EDU (Brian Kantor) (12/10/88)
In article <504@pacbell.PacBell.COM> david@pacbell.PacBell.COM (David St.Pierre) writes: >Um Brian, you're taking liberty with what I said. I didn't say I was >doing the right thing - I did say that traditional System V mailers >didn't attempt to support RFC822 and didn't really support "headers". You're right, David, and I apologize for misquoting you - I must have some missing bits in the wetware. But as we discussed over a beer two days ago, the difficulties of combining two networks with essentially different addressing semantics make any definitive answer difficult to achieve. I hope your suggestion to ames helps this situation. (BTW, wasn't it nice of Sun and AT&T to pay for the drinks and munchies while we discussed this in person?) The key here is that the From: line in a uucp world is a strange beastie: it has no meaning to sites which run pure uucp mail. Yet this mail network is no longer pure uucp; even if it only used uucp as a transport mechanism, the thousands of sites using sendmail (even those not connected to the internet) are using internet semantics and we must, as a practical matter, cope with that. In the pure uucp world, there are no addresses, there are only paths. In the internet world, there are normally no paths, just addresses. When you mix these worlds together, you get problems, and to solve the problem you have to process the address according to the semantics which apply. Luckily, it is often possible to decide which is the correct set of rules, because the addresses/paths contain clues which most of the time will allow you to guess correctly whether what you are looking at is an address or a path. And that's what we do with From: lines, and that's what I advocate others to do with From: lines. Those who say that one should never touch the contents of a From: line would seem to be those who believe that the From: line always contains an address. Regrettably, that is not always true, and sometimes the From: line contains a path, which must, by definition, be updated. Brian Kantor UCSD Postmaster UCSD Office of Academic Computing UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu BRIAN@UCSD ucsd!brian
vixie@decwrl.dec.com (Paul A Vixie) (12/10/88)
[Kantor]
# Those who say that one should never touch the contents of a From: line
# would seem to be those who believe that the From: line always contains
# an address. Regrettably, that is not always true, and sometimes
# the From: line contains a path, which must, by definition, be updated.
I am one who has advocated leaving From: lines alone wherever possible, and
I find that I agree with this exception. The sendmail.cf running at UB.COM
and FAI.COM will assume that a From: line with only one "host/domain" in it
is an address and should be left alone, whereas something with more than one
"host/domain" is probably not an address, and is probably either hopelessly
screwed up because not everybody has updated it (in which case updating it
won't make it worse) or it has been correctly updated so far (in which case
updating it will still not make it worse). There are other details involved,
but that's the general approach. I havn't heard any complaints so far...
The trick is to leave them alone if they don't appear to have been dinked
with already. If everybody did that, they would never get dinked with at
all.
Except when passing through a network gateway, which breaks this whole
scheme into a million shards. Hopefully a fully domainized internet will
make most of the things we think of as "gateways" disappear either by
hiding the whole "other network" in a domain tree ("sxn@ingersoll.sun.com"
is on "another network" but I don't have to treat it that way), or by
hiding all recipients on the "other network" behind a generic domain name
(I'm not really "vixie@decwrl.dec.com" but you don't have to know that).
--
Paul Vixie
Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600
Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013page@swan.ulowell.edu (Bob Page) (12/13/88)
brian@ucsd.edu (Brian Kantor) wrote: >Those who say that one should never touch the contents of a From: line >would seem to be those who believe that the From: line always contains >an address. I agree. The assumption is everything, right? :-) >Regrettably, that is not always true, and sometimes the From: line >contains a path, which must, by definition, be updated. When it leaves a site with a From: line of user, or host!user, are either of those an address or a path? I say an address. So host1 gets it and makes it host1!host!user. Is that an address or a path? I say it's a path. I also say it was wrong for host1 to assume it was a path when it got it. I still say leave it alone under all circumstances. There's no reason you should propagate someone else's error. Keep the path info in From_. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.
henry@utzoo.uucp (Henry Spencer) (12/15/88)
In article <10670@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >>Regrettably, that is not always true, and sometimes the From: line >>contains a path, which must, by definition, be updated. > >When it leaves a site with a From: line of user, or host!user, are >either of those an address or a path? ... >I still say leave it alone under all circumstances. There's no reason >you should propagate someone else's error. Keep the path info in From_. I have to agree with this. The first and foremost principle of mail relaying is (should be!) what it says in the Hippocratic Oath: "First, Do No Harm". Corollary: it is much more important that mail relaying be predictable than that it be smart. The receiving and transmitting ends can always add smartness, but they can't restore lost predictability. Trying to guess whether a From: line is an address or a path violates both of these rules. It introduces unpredictable behavior, since by definition it's guesswork. And it has the potential to do major harm, because an address which is misinterpreted as a path will probably cause later sites to guess "path" too, resulting in an indecipherable mess in the situation (our current one) where some sites munge paths and some don't. The most predictable, and least harmful, approach is to prepend a new From_ line and leave From: alone. (Trying to stuff your site name into an existing From_ line rather than just prepending a new one is not as safe, but it's better than a lot of the alternatives.) -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
rja@edison.GE.COM (rja) (05/03/89)
Lately I find that sites out in UUCP-only land are doing rude things by way of rewriting my FROM: lines in bizarre ways. When the leave here, the are in the form From: rja <rja@edison.cho.ge.com> When they arrive at the destination they are a mangled mess inside the < > that no site could parse correctly. If the From: line contains a clean RFC 822 domain-name address, PLEASE don't rewrite it. The chances of mail bounce when it isn't touched are small, the chances of mail bounce upon reply when a site tries to stuff a UUCP bang path in there are great. I just wish we could eliminate the entire host1!host2!user@relayhost.domain syntax and the user%relay@host.domain syntax since they seem to be widely implented incorrectly (if one believes that there is a clear "correct" way). If folks would keep some semblance of maps or a smart-host, then a simple user@domain syntax could be used without all this rewriting.... And we thank you for your support... ______________________________________________________________________________ Internet (vastly preferable) : rja@edison.CHO.GE.COM UUCP (if you've got no choice): ...uunet!virginia!edison!rja ______________________________________________________________________________ Bang paths : just say NO !
chip@ateng.ateng.com (Chip Salzenberg) (05/18/89)
According to rja@edison.GE.COM (rja): >Lately I find that sites out in UUCP-only land are doing >rude things by way of rewriting my FROM: lines in bizarre >ways. If only the UUCP sites were the only ones at fault! My most recent problems have been with cs.utexas.edu and Sun.COM, not exactly UUCP backwaters. Let's all chant the Mail Header Mantra: >If the From: line contains a clean RFC 822 domain-name address, >PLEASE don't rewrite it. I couldn't agree more. In fact, I personally would extend this courtesy to "user@host.UUCP"; but I suppose I'm just a reactionary. :-) -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas IR) (05/18/89)
In article <1989May17.194701.16816@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >According to rja@edison.GE.COM (rja): >>Lately I find that sites out in UUCP-only land are doing >>rude things by way of rewriting my FROM: lines in bizarre >>ways. >If only the UUCP sites were the only ones at fault! My most recent problems >have been with cs.utexas.edu and Sun.COM, not exactly UUCP backwaters. Interesting, can your provide examples? Perhaps I can help clean our end up, *IF* we have a problem. Its probably bad form to say this here, and I'll probably end up with more hate mail than I ever need, but I'm going to state this anyway. UUCP (and 'bang addressing') are a really stupid way of doing things. Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me which 'bar' you mean, and I have some hope of delivering it. But then, you were complaining about domain addresses to begin with. Nothing I've said has anything to do with where I work. Jim Jim Thompson - Network Engineering - Sun Microsystems - jthomp@central.sun.com Member of the Fatalistic International Society for Hedonistic Youth (FISHY) "I woudn't recommend sex, drugs, or unix for everyone, but they work for me." - Me (paraphrasing Hunter S. Thompson)
rsalz@bbn.com (Rich Salz) (05/18/89)
In <528@texsun.Central.Sun.COM> my good buddy Jim Thompson <jthomp@hemaneh.UUCP>
somewhat foolishly steps forward and offers:
>Perhaps I can help clean our end up, *IF* we have a problem.
Hey Jim, I've had a problem with Sun's non-domain routes for a long time...
island!argv@sun.com
argv%island@sun.com
elef%smarmy@sun.com
Now, the first is OK: <island!argv> is a local-part to sun.com, and you
should just hand it off to your UUCP neighbor "island." Which you do.
The second and third ones I have trouble with. In the past, the second
line has worked as the first one did, lately it works as the third line
does: "smarmy" is a local site within Sun.
Any chance of getting your outbound mail gateways to rewrite everything
so we see addresses like
elef@smarmy.sun.com
and putting out an MX wildcard record for *.sun.com?
Thanks. Sorry you asked?
/r$
--
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/19/89)
In article <528@texsun.Central.Sun.COM> jthomp@hemaneh.UUCP (Jim Thompson Sun Dallas IR) writes: >UUCP (and 'bang addressing') are a really stupid way of doing things. >Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea >which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me >which 'bar' you mean, and I have some hope of delivering it. No site is obliged to recognize bar!foo unless it has a direct link with bar. A site that wants to forward mail intelligently can maintain a UUCP map database and look for bar in it, and route the message accordingly. There is no need to consider bar!foo stupid. Bounce it or route it. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
chip@ateng.ateng.com (Chip Salzenberg) (05/20/89)
According to jthomp@hemaneh.Central.Sun.COM (Jim Thompson): >Interesting, can you provide examples [of UUCP problems at Sun]? Well, I'd say the general policy of "no UUCP routing ever" is part of the problem. The rest of the problem is the policy of rewriting headers as they pass through the site, even if they are not destined for the Internet. >UUCP (and 'bang addressing') are a really stupid way of doing things. >Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea >which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me >which 'bar' you mean, and I have some hope of delivering it. I mean "the bar in the UUCP maps". Although such a meaning is not specified in any RFC, it's nonetheless accurate. IMHO, if you advertise UUCP links in the UUCP maps, you should be willing to provide UUCP-like behavior. A rabid header rewriter is not typical UUCP behavior. It is, in fact, evil and rude. I avoid rabid rewriters and rabid rerouters with (almost) equal fervor. (Incidentally, your rn is generating "Reply-To: jthomp@hemaneh.UUCP".) -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
wisner@mica.Berkeley.EDU (Bill Wisner) (05/20/89)
(Jim Thompson) >UUCP (and 'bang addressing') are a really stupid way of doing things. >Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea >which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me >which 'bar' you mean, and I have some hope of delivering it. Pshaw. foo@bar.UUCP is a stupid revolting hack, I'll give you that. But bar!foo is just fine. It's a UUCP address. It's unmistakably a UUCP address. When you see bar!foo the first thing you should think is "that's a UUCP address". And when your mailer sees bar!foo it should think "this is a UUCP address" and act accordingly. So what's wrong with bar!foo?
vern@zebra.UUCP (Vernon C. Hoxie) (05/21/89)
In article <31051@sri-unix.SRI.COM>, jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas IR) writes: > > UUCP (and 'bang addressing') are a really stupid way of doing things. > Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea > which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me > which 'bar' you mean, and I have some hope of delivering it. > Jim: I have been confused for a long time about how to interpret domain names. "Bang" pathes seem quite logical in that they describe the step by step path from one user to another. In fact, bang pathes are used in domain addressing until we get to that weird stuff at the end. Suddenly the logical sequence of names is inverted so that the users name precedes the machine or whatever is inferred. That flip in logic is what makes me think of domain addressing as "stupid". Perhaps you can enlighten some of us who are not exactly in a "domain" as to the virtues of this style addressing. First, my dictionary has one definition of "domain" as "a sphere of influence". I can't see how the .COM on your address has any relevance to the delivery of a message when there are so many .COM's scattered all over the country. In your address, "jthomp@hemaneh.Central.Sun.COM", what are the meanings of the encryptions following the "@" sign? ..and of what concern are they to me so far from your organization. If we are not large corporations or universities, but individuals not affiliated with any defined domain, what addressing should be used? -- Vernon C. Hoxie {ncar,nbires,boulder,isis}!scicom!zebra!vern 3975 W. 29th Ave. voice: 303-477-1780 Denver, Colo., 80212 uucp: 303-455-2670
clutx.clarkson.edu (Drew Derbyshire,,,9143397425) (05/21/89)
From article <1936@edison.GE.COM>, by rja@edison.GE.COM (rja): > I just wish we could eliminate the entire > > host1!host2!user@relayhost.domain > > syntax and the > > user%relay@host.domain But you can't do it by fiat... even IBM can't kill off procotols it hates, and it has (compared to UNIX vendors) a vise-grip on its users. I just rewrote my copy of UUPC to handle the pathing you mentioned above (how? real simple, I guessed!), and you are correct, it is vague. But do you want every PC on the net to register as a proper domain? This could get REAL hairy REAL fast. QUESTION: What is the proper procedure to to register as a UUCP host.domain? A friend said drop mail to sri-nic, but they are internet, not UUCP (or do they do windows too?) Drew Derbyshire Internet: ahd@clutx.clarkson.edu U.S. Mail: 578 Broadway, Apt 6 Voice: 914-339-7425 Kingston, NY 12401
simpson@poseidon.uucp (Scott Simpson) (05/21/89)
It is kind of a sad statement on Sun's part when I have to add a -d option to pathalias to delete Sun as a node when their motto is "The Network is the Computer." Scott Simpson TRW Space and Defense Sector oberon!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (05/22/89)
ahd@sun.soe!clutx.clarkson.edu writes:
But do you want every PC on the net to register as a proper domain?
If such PC's are expected to receive either mail or news, yes.
This could get REAL hairy REAL fast.
Not really; nameservers are a concept which scales quite well.
QUESTION: What is the proper procedure to to register as a UUCP
host.domain? A friend said drop mail to sri-nic, but
they are internet, not UUCP (or do they do windows too?)
Ann Westine <westine@venera.isi.edu> is the domain contact for the .us
top-level domain, which is where random, organizationally-disconnected
machines can become registered. The .us domain is subdivided into
state and city subdomains, and machines are thereby registered
geographically. E.g., there is a machine here for which my machines
perform MX service called sydney.columbus.oh.us.
--Karlwisner@mica.Berkeley.EDU (Bill Wisner) (05/24/89)
I'm sure I'll get some help here (you there, Karl?) but here goes: (Vernon C. Hoxie) > I have been confused for a long time about how to interpret >domain names. "Bang" pathes seem quite logical in that they describe the >step by step path from one user to another. In fact, bang pathes are used >in domain addressing until we get to that weird stuff at the end. Suddenly >the logical sequence of names is inverted so that the users name precedes >the machine or whatever is inferred. That flip in logic is what makes me >think of domain addressing as "stupid". The addressing style makes perfect sense. I'm wisner@mica.berkeley.edu, which can be literally taken as "wisner at (the machine) mica.berkeley.edu". That can be further broken down as a machine named mica, which is at Berkeley, which is an EDUcational institution. Bang paths are *not* used in proper domain addressing. UUCP machines will use them to fit the constraints of the transport, but the users at either end of the delivery (the sender and receiver) should never see them. Domain-style addressing is not stupid. It is (opinion follows), if anything, simpler and more "graceful," if you will, than a bang path. > Perhaps you can enlighten some of us who are not exactly in a >"domain" as to the virtues of this style addressing. First, my >dictionary has one definition of "domain" as "a sphere of influence". >I can't see how the .COM on your address has any relevance to the delivery >of a message when there are so many .COM's scattered all over the country. One advantage of domain-style addressing is that you need only address mail to user@host and it will get there. No mucking about with paths or routing or gateways. Another advantage is that domain-style machine names guarantee uniqueness. This is the only mica.berkeley.edu there is. Someone at, say, UCLA could also name his machine mica. He would then have himself a machine called mica.ucla.edu. There are no conflicts involved because both names are different. Having two UUCP hosts named mica, on the other hand, would cause some problems. > In your address, "jthomp@hemaneh.Central.Sun.COM", what are the >meanings of the encryptions following the "@" sign? ..and of what concern >are they to me so far from your organization. hemaneh.Central.Sun.COM is the full, official name of his machine. At a guess, I'd say that the machine is named hemaneh and it's in the Central division offices of Sun Microsystems, which is a COMpany. > If we are not large corporations or universities, but individuals >not affiliated with any defined domain, what addressing should be used? There's a US (United States) domain which works out well for such things. You could, perhaps, register as zebra.denver.co.us.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (05/24/89)
Warning: lengthy technobabble begins...
vern@zebra.UUCP (Vernon C. Hoxie) writes:
I have been confused for a long time about how to interpret
domain names. "Bang" pathes seem quite logical in that they describe the
step by step path from one user to another.
The problem is that !-paths expect the user to know the underlying
infrastructure of how machines move mail from one place to another,
which is a violation of the Principle of Least Astonishment.
("Waddayamean, *I* have to know which 6 systems through which mail
must pass to get to Joe WhatsHisName at ThatSystemOverThere?")
If you, in ?Denver? were to write physical snail mail to me, you
wouldn't address it by stipulating the various post offices through
which it would send, e.g., Denver, via airmail to Columbus, via truck
to OSU campus mail, via deliveryperson to this dept, via
secretary/mail-handler/whomever to my mailbox. You'd be insulted if
you were expected to know that much detail, or had to tell the US
Postal Service people such things. You address it geographically and
organizationally, and you just expect it to Get There.
In fact, bang pathes are used
in domain addressing until we get to that weird stuff at the end. Suddenly
the logical sequence of names is inverted so that the users name precedes
the machine or whatever is inferred. That flip in logic is what makes me
think of domain addressing as "stupid".
All you're looking at there is a difference in which direction to read
an address. !-paths are written left-to-right, whereas strict domain
addresses are written right-to-left.
In the case of a mixed-mode address (that is, containing both ! and
@), think of the network punctuation as operators in a mathematical
expression. By the standards under which Internet hosts work, @ is a
higher-precedence operator than !. So the address
host!user@some.where.edu
means
Tell some.where.edu to hand this to host!user.
In the strictest terms, you, as the writer of such mail, have no
knowledge of exactly what some.where.edu is going to do with it. You
think it's going to do UUCP things once it gets to some.where.edu, but
you might well be wrong - you're just guessing. Nothing left of @ in
a domain address is anybody's business to interpret, except for the
host some.where.edu itself.
Now, in practice, we all "know" that host!user on the end is a
UUCPism, and that some.where.edu will speak UUCP to "host" and expect
"host" to deliver to "user" when the mail gets there. But that's
interpreting a lot more than you're really expected to know.
In a "pure" case, that is, a domain address using @ with no ! or other
punctuation, the syntax
username@host.domain
means
Tell host.domain to give this mail to username.
Note that there is nothing in a domain address which stipulates how
delivery is accomplished. Domains are, at best, organizational or, at
worst, geographical (e.g., the country [".US"] domains). Nothing is
provided indicating how the machines speak to one another to get
there. This is a Good Thing, for exactly the same reasons that you
don't want to tell the Denver postmaster how to get mail to my office.
The problems in knowing the connectivity of 17K hosts in UUCPland are
what led to the creation of the UUCP Project, pathalias, and smail.
The map data published in comp.mail.maps is hacked on by pathalias
into a paths file which describes least-cost paths between Hither and
Yon, so the UUCP user can use "absolute" addresses just like Internet
sites, where connectivity for such things is a question far below the
writer of mail. The pathalias-generated database is used by a mailer
(notably, smail 2.x) which takes, e.g., "osu-cis!karl" and turns it
into a full-blown, complete, UUCP !-path route by which to get between
(in your case) the machine "zebra" and my machine "osu-cis." You
don't have to know the connectivity because the map data, pathalias,
and smail took care of those details for you. Smail also has the
intelligence to look at, e.g., "karl@cis.ohio-state.edu" and turn that
into a UUCP !-path to reach the same place. Again, you need know no
connectivity.
For hosts running IP on the real, physical Internet (as distinct from
the pseudo- and non-physical internet of hosts capable of using this
kind of addressing), questions of routing to reach a domain address
are done in what I'll euphemistically call "real time," by which I
mean that my mailer sees that I've written mail to
"user@some.where.edu" and so it queries a program running on my
systems called a nameserver. My nameserver goes asking the
authoritative "root servers" about where "some.where.edu" is, in terms
of absolute Internet addresses. The root servers return not with the
actual address, but pointers ("NS records," which are pointers to
hosts which perform lower-level nameservice) to the hosts which really
do know all the gut-level details of hosts inside the organizational
entity "where.edu." So my mailer again queries those hosts, again
asking for the absolute address of "some.where.edu," and (one
presumes) such an address is returned by these hosts. Then my mailer
knows where and how to deliver mail, so my mailer connects with the
remote mailer, and delivers the mail via a protocol called SMTP
(simple mail transport protocol).
In the case of a host not physically connected to the Internet (that
is, not reachable with an absolute Internet address), a mailer does
not get back addresses, but rather another type of pointer, called an
MX record. MX records indicate the hosts which have advertised a
willingness to be the Mail eXchanger for the indicated destination.
So if you were to register "zebra" as "zebra.denver.co.us," and I were
to write mail to you, the sequence of events would be approximately:
[a] my mailer accepts the mail from my user agent.
[b] my mailer asks the local nameserver, "How do I get mail
to zebra.denver.co.us?"
[c] the nameserver doesn't know, so it asks the root servers,
"Who's in charge of Colorado?"
[d] root servers return the information, "Venera.isi.edu is
the host in charge of Colorado," via NS records.
[e] my nameserver than asks Venera, "How do I push mail in
the direction of zebra.denver.co.us?"
[f] Venera responds, "Mail addressed to zebra.denver.co.us
should be handed to boulder.colorado.edu," via MX
records.
[g] my nameserver informs my mailer of this answer, and also
caches a copy of the answer in case it's asked again in
the near future.
[h] my mailer requests an SMTP connection with
boulder.colorado.edu, and sends the mail. It is assumed
that the receiving (MX) host knows how to detect the
hosts for which it serves as MX (usually syntactically),
and will then convert the mail to some other transport,
probably UUCP in your case.
[A point to stress: boulder.colorado.edu is not, by any information I
have, performing MX service for anything called zebra.denver.co.us.
I'm just building an example out of the air here.]
[Another point: I know I'm glossing over details. Again, this is an
example only - hold your flames until/unless I make a major gaffe.]
Perhaps you can enlighten some of us who are not exactly in a
"domain" as to the virtues of this style addressing. First, my
dictionary has one definition of "domain" as "a sphere of influence".
I can't see how the .COM on your address has any relevance to the delivery
of a message when there are so many .COM's scattered all over the country.
The top-level domains (gov, com, edu, org, net, mil) are mostly
convenient pigeonhole-able pseudo-entities wherein large numbers of
entities of that general "class" can be placed. Universities are
educational entities, so all universities end up being parked in the
.edu domain. Similarly, commercial entities land in .com, military
entities are known under .mil, and so forth.
Concrete example: I can be addressed as karl@tut.cis.ohio-state.edu.
That means that there is an educational entity known as Ohio State
University, inside of which there is a Computer & Information Science
department. That department owns a machine called Tut. The user
`karl' can be found on that system from time to time. :-)
In your address, "jthomp@hemaneh.Central.Sun.COM", what are the
meanings of the encryptions following the "@" sign? ..and of what concern
are they to me so far from your organization.
Again, reading right to left for increasingly precise definition:
com: This is a commercial entity
sun: The commercial entity is called "sun."
central: An internal designation, probably for the
central or home offices of the company.
hemaneh: The name of the machine at which jthomp
can be expected to be found.
Hostnames are *always* case-insensitive: Sun.COM == sun.com == sUn.CoM
== SUn.coM == ...
If we are not large corporations or universities, but individuals
not affiliated with any defined domain, what addressing should be used?
There are geographical top-level domains. In particular, there is a
.us domain, under which are state and city subdomains, wherein
organizationally-disconnected machines can become registered. You
will have to find a real Internet site (using IP and nameservers and
the whole schmeer) willing to be your domain forwarder, that is, to
provide MX service to you. Once you have secured such services from
one such entity, you can request registration. The person in charge
of the .us domain is Anne Westine <westine@venera.isi.edu>. There is
a form to be filled out (electronically will do just fine), and
shortly thereafter the Internet nameservers will be given the
knowledge of your system. At that point, you can advertise your
full-qualified domain name (FQDN) in mail and news From: lines, and
everyone should be able to reach you. You should, of course, also
email a new form to the UUCP project so that updated data showing your
domain name is known to all the UUCP universe's pathalias data.
[Corrections to any of the aforementioned "major gaffes" will surely
be forthcoming now...:-]
--Karldce@Solbourne.COM (David Elliott) (05/24/89)
In article <160@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes: > Perhaps you can enlighten some of us who are not exactly in a >"domain" as to the virtues of this style addressing. First, my ... > In your address, "jthomp@hemaneh.Central.Sun.COM", what are the >meanings of the encryptions following the "@" sign? ..and of what concern >are they to me so far from your organization. Think about it this way: When you send a physical (as in paper, envelope, and stamp) letter, you don't tell the post office how to deliver it. When I send a letter home, I don't write on it "Send to Denver, then to Atlanta, then to Raleigh, then to Chapel Hill, then to 125 Booth Rd", I just write down the final address, and the post office figures out how to get it there. Postal addresses are unique. The same goes for a phone conversation. I don't tell the phone company how to route the call, I just dial a phone number and the system automatically connects me. Phone numbers are unique. By using a domain address, you are effectively asking for the same type of service that the post office and telephone company (I did say "type", and not "level" ;-) provides. Domain addresses are unique. You don't really need to know what hemanth.Central.Sun.COM means any more than you need to know where 125 Booth Rd. in Chapel Hill, NC is. All you need to know is that on all of the network served by this type of addressing, jthomp@hemanth.Central.Sun.COM is a unique mail address, and that no correctly-working mail forwarder will confuse it with another jthomp on some other machine. The other advantage is that it hides changes from people who don't really care about the topology of the network. It means that I don't have to know that to get to one of my friends in CA, I have to say nbires!ncar!ames!mips!ultra!rmg, and can instead send directly to rmg@ultra.com. Either way it will get there now, but if one of these sites dies, or if a pair quits talking to each other, I don't have to worry. -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce
jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas IR) (05/24/89)
I was asked to answer this question, but Karl has done a far better job than I would have. (Thanks, Karl.) To clear one minor point, 'Central' actually means 'Central US'. There are also, 'East', 'West', ''Corp', 'Eng', 'UK', and so forth. Each is a 'sphere of influence', as it were. Yes, UUCP is here to stay. However, as other have pointed out, its very inelegant to address with. I'll not start the 'uucp as a transport protocol' fight. (Not Here! :-) Most people who have delt with 'domain-style' addressing prefer it, though. I too remember thinking 'what the Heck is this stuff?'. It helps to imagine reading the domain from the right. '(sun is part of com, central is part of sun.com, hemaneh is part of central.sun.com, jthomp is part of hemaneh.central.sun.com. As also stated before, you can have a machine 'named' hemaneh, and so can I (and so can thousands of others) under this scheme. I will admit that sun.com is doing an evil thing with its rewritting. I'll see what I can do, though it will take some time. There were basicly 'good' reasons for doing what has been wrought. Without going into details, the decision was (back when things were a lot more broken), that internal mail was the most important. Hence the cruft. Sorry. Jim Jim Thompson - Network Engineering - Sun Microsystems - jthomp@central.sun.com Member of the Fatalistic International Society for Hedonistic Youth (FISHY) "I woudn't recommend sex, drugs, or unix for everyone, but they work for me." - Me (paraphrasing Hunter S. Thompson)
bill@twwells.uucp (T. William Wells) (05/24/89)
In article <24763@agate.BERKELEY.EDU> wisner@mica.Berkeley.EDU (Bill Wisner) writes:
: > If we are not large corporations or universities, but individuals
: >not affiliated with any defined domain, what addressing should be used?
:
: There's a US (United States) domain which works out well for such things.
: You could, perhaps, register as zebra.denver.co.us.
I'm registered as twwells.com, even though there is no commercial
activity going on here. I chose that over twwells.ftl.fl.us because I
didn't want to have to change my site name were I to move. In any
case, it is very simple to get registered.
---
Bill { uunet | novavax } !twwells!billles@chinet.chi.il.us (Leslie Mikesell) (05/25/89)
In article <KARL.89May23174107@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >The problem is that !-paths expect the user to know the underlying >infrastructure of how machines move mail from one place to another, >which is a violation of the Principle of Least Astonishment. >("Waddayamean, *I* have to know which 6 systems through which mail >must pass to get to Joe WhatsHisName at ThatSystemOverThere?") Alternately, the problem is that every machine has to know how to find every other machine in the universe. ("Waddaymean, I have to store 6 megs of path information on my laptop and register it and stay at the same place forever in order to get send and receive mail..) The real problem is that there is no standard way to let another machine route and forward mail for you. There are ways to do this but they tend not to produce a replyable path back. If this could be done, all you would need is one stable machine to service any number of addressable but possibly transient other machines which would not have to be individually registered. Is there some way to make this work? Or, perhaps the solution is a dial-up nameserver that anyone could access (via a 900 number if no one wants to do it for free) with on-line interactive registration. >If you, in ?Denver? were to write physical snail mail to me, you >wouldn't address it by stipulating the various post offices through >which it would send, e.g., Denver, via airmail to Columbus, via truck >to OSU campus mail, via deliveryperson to this dept, via >secretary/mail-handler/whomever to my mailbox. You'd be insulted if >you were expected to know that much detail, or had to tell the US >Postal Service people such things. You address it geographically and >organizationally, and you just expect it to Get There. Don't forget that this works *only* by government mandate. Wherever you are, there has to be a post office willing to provide the service. The same is not true electronically (why not?). Les Mikesell
fr@icdi10.UUCP (Fred Rump from home) (05/25/89)
In article <160@zebra.UUCP> vern@zebra.UUCP (Vernon C. Hoxie) writes: >In article <31051@sri-unix.SRI.COM>, jthomp@hemaneh.Central.Sun.COM (Jim Thompson Sun Dallas IR) writes: ->> ->> UUCP (and 'bang addressing') are a really stupid way of doing things. ->> Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea ->> which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me ->> which 'bar' you mean, and I have some hope of delivering it. ->> > I have been confused for a long time about how to interpret >domain names. >I can't see how the .COM on your address has any relevance to the delivery >of a message when there are so many .COM's scattered all over the country. > In your address, "jthomp@hemaneh.Central.Sun.COM", what are the >meanings of the encryptions following the "@" sign? ..and of what concern >are they to me so far from your organization. Hear, hear - I'm sure there are many of us who would like a logical explanation for Vernon's questions. In my address from uunet (fred@cdin-1.uu.net) I wonder whether I'm in domain uu or net or what? And since we have a lot of customers out there, to whom we assigned site names but nothing, else should they be in our own little domain even so they are all separate entities? Fred Rump -- This is my house. My castle will get started right after I finish with news. 26 Warren St. ...{dsinc bpa uunet}!cdin-1!icdi10!fr Beverly, NJ 08010 or INTERNET: fred@cdin-1.uu.net or icdi10!fr@icdi10.uu.net 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
fr@icdi10.UUCP (Fred Rump from home) (05/25/89)
I only wanted to say "THANK YOU" for the patient and explicit information
given by several of you net-experts about the internet/domain questions asked
here.
It is nice to hear civil talk for once and not somebody jumping all over
somebody else because he didn't already know.
Makes paying these damn phone bills worth their while.
Fred
--
This is my house. My castle will get started right after I finish with news.
26 Warren St. ...{dsinc bpa uunet}!cdin-1!icdi10!fr
Beverly, NJ 08010 or INTERNET: fred@cdin-1.uu.net or icdi10!fr@icdi10.uu.net
609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schillerjohn@jetson.UPMA.MD.US (John Owens) (05/25/89)
In article <8535@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > Alternately, the problem is that every machine has to know how to > find every other machine in the universe. ("Waddaymean, I have to > store 6 megs of path information on my laptop and register it and > stay at the same place forever in order to get send and receive mail..) > The real problem is that there is no standard way to let another machine > route and forward mail for you. Sure there is. If you run smail and build a paths file by hand containing one or two paths and a "smart-host" line, it'll hand everything to the smart-host. If the smart-host runs smail with friendly (first-hop) rerouting, it'll get there as well as if you had the pathalias info yourself. > There are ways to do this but they > tend not to produce a replyable path back. Whether you have your own 1MB pathalias output file or use smart-host has nothing to do with what the return addresses look like. The most common thing that messes up the reply path is an intermediate site that runs sendmail and adds their uucp name to the From: line. > If this could be done, > all you would need is one stable machine to service any number of > addressable but possibly transient other machines which would not have > to be individually registered. Sounds like uunet to me, although they encourage all their customers to have their own map entries. -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
fr@icdi10.UUCP (Fred Rump from home) (05/26/89)
In article <996@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >In article <24763@agate.BERKELEY.EDU> wisner@mica.Berkeley.EDU (Bill Wisner) writes: > >I'm registered as twwells.com, even though there is no commercial >activity going on here. I chose that over twwells.ftl.fl.us because I >didn't want to have to change my site name were I to move. In any >Bill { uunet | novavax } !twwells!bill If you are registered under twwels.com, how come you use twwells.uucp? And on top of that a bang path in your signature? Really, I'm curious. Fred -- This is my house. My castle will get started right after I finish with news. 26 Warren St. ...{dsinc bpa uunet}!cdin-1!icdi10!fr Beverly, NJ 08010 or INTERNET: fred@cdin-1.uu.net or icdi10!fr@icdi10.uu.net 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
les@chinet.chi.il.us (Leslie Mikesell) (05/27/89)
In article <241@jetson.UPMA.MD.US> john@jetson.UPMA.MD.US (John Owens) writes: >> The real problem is that there is no standard way to let another machine >> route and forward mail for you. >Sure there is. No, I said *standard* way. There are ways that work at least for sending but you need to know something about the machines. Smail passing off to a smart host works fine for sending, but how does a recipient, perhaps on BITNET, get a response back to you if you aren't in the maps? What I'd like to see is an address that allows one or perhaps two hops on either end of a site with a domain listing. That is, an address like: a!x.y.z!b!you (replace ! with your favorite character) would mean for the local machine to send to machine a (which it must know about). Machine a forwards to x.y.z by its choice of methods. Machine x.y.z forwards to the machine b that it knows about, and machine b delivers to user you. This approach would avoid the necessity to track the transient connections of every PC running uupc in the world yet allow the stable machines to optimize routing to each other. A FROM: line line x.y.z!a!me could then be replied to from anywhere. I suspect that it is intentionally not done this way because the domain nameserver would automatically get stuck with providing name service and/or forwarding for anything that connects downstream without having the control process of putting the machine in the domain. Les Mikesell
mark@cbnews.ATT.COM (Mark Horton) (05/31/89)
In article <160@zebra.UUCP> Vernon C. Hoxie writes: >In article <31051@sri-unix.SRI.COM>, Jim Thompson writes: >> >> UUCP (and 'bang addressing') are a really stupid way of doing things. >> Hence, foo@bar.UUCP is (almost) as bad as bar!foo. I have no idea >> which 'bar' you mean. foo@bar.baz.{com,edu,org,net,...} Does tell me >> which 'bar' you mean, and I have some hope of delivering it. > > I have been confused for a long time about how to interpret >domain names. "Bang" pathes seem quite logical in that they describe the >step by step path from one user to another. In fact, bang pathes are used >in domain addressing until we get to that weird stuff at the end. Suddenly >the logical sequence of names is inverted so that the users name precedes >the machine or whatever is inferred. That flip in logic is what makes me >think of domain addressing as "stupid". Ah, a true religious debate. If we can refrain from damning the blasphemers for a few moments, and look at the technical issues, it will become clearer. Vernon points out the difference in left-to-right and right-to-left addressing styles. Bangs are left-to-right (first!next!..!last!user) and domains are right-to-left (user@local..org.country). There is well established precedent for both: telephone numbers are left-to-right, and postal addresses are right-to-left. Which is best? On pure technical grounds, it doesn't matter. However, when you get mixtures of the two, bad things happen. This is why standardization is crucial. Hybrid addresses like foo!bar@mumble.com can be (and are) interpreted both ways, often wrong. Life is further complicated by the UK, which has a sideways notation user@country.admd.org..local. In networking, there are three key concepts: names, addresses, and routes. A "name" is a high level, user guessable way to identify a person, machine, or other entity. For example, "Mark Horton". Names may be ambiguous, especially when abbreviated "M Horton". Names can be made unambiguous by adding more information. "Mark Randolph Horton who works for AT&T in Columbus Ohio and whose SSN is 1234567890" An "address" is a medium level, unambiguous way to identify *where something is*. For example, "Room 234, 1234 Main St, Columbus Ohio, USA". Addresses depend on the underlying technology, and one entity can have several addresses, e.g. postal, latitude/longitude. A "route" amounts to giving directions to get to an address. "Get on I-70 eastbound, drive to Columbus and take the 4th street offramp, turn north on 4th, turn east on Main, drive until you see a building with 1234 on it, park the car, go in the side door, up the stairs to the 2nd floor, down the B hallway to room 234." Routes tend to be different, depending on where the entity following the directions is starting from. Routes are usually tied to the underlying technology. Various computer entities that might have names, addresses, and/or routes include people, mailboxes, machines, modems, terminals, and so on. For email mailboxes, since mailboxes are often described by a person or login and a machine, there is sometimes a mixture of these three descriptions for both people and machines. Bang paths are routes for machines. If the last entity in the bang path is a login name, it becomes a route to get to a person's mailbox. Dotted IP addresses, like 192.11.2.1, are addresses for machines. Datakit dialstrings, such as oh/cbh/cblpf, are also addresses, although they are nicer because they use character strings instead of numbers. Domains, like cblpf.att.com, are names for machines. It is possible to map a machine name cblpf.att.com into a machine address, like 192.11.2.1 or oh/cbj/cblpf, and from there into a route like att!cblpf. cblpf is also a machine name, although it's likely to be ambiguous. Mailboxes may have an address (e.g. a login on a particular machine). Sometimes a name server can provide a mapping from names to addresses. The AT&T post database will map "mark.horton" into "cblpf!mark", for example. Thus, you can get various mixtures of descriptions in email targets: ucbvax!att!cblpf!mark route mark@cblpf.att.com address @ named machine, e.g. address mark.horton@att.com name on named domain, e.g. name All three of these forms will work, although the first one only works if you have a connection to ucbvax (or if your machine can fake it.) In general, users usually prefer names to addresses, and addresses to routes. routes are easier for computers to deal with than addresses (a mapping is required), and addresses are easier than names (two mappings may be needed.) There are other reasons to prefer names to addresses, and addresses to routes. Names tend to follow people around when they change addresses. (When I moved from cbosgd to cblpf, my name stayed the same.) Replies to names and addresses are easy: just leave the text alone. If you've seen some of the stuff mailx/Mail has to do to bang paths on carbon copies to get replies delivered, you'll appreciate the simplicity of names and addresses. The replying machine has to look at the header (possibly broken by intermediate machines) and guess what the path on a Cc: line meant to the sender. Names and addresses are sometimes longer than routes, just like full phone numbers are longer than extensions. Sometimes people prefer to type the route if they know it, and it's shorter. This is when it's a good idea to have an aliasing mechanism for even higher level names that are local to a user: $ cat .mailrc alias frank frank.n.stein@att.com $ mailx frank Names, addresses, and routes will always be around. Names need to be mapped into addresses, and addresses need to be mapped into routes, internally to the machine. But the world is steadily moving away from routes (which were implemented first) through addresses (which have been around for some time) to names (which are just now starting to get serious use) as the preferred means of sending email to people. There are, however, so many different standards and dialects, that there is much confusion in the meantime. Each standard and dialect has a large cult of faithful followers. Just like religions. Mark Horton (no, I don't use the Bourne-again shell)
taylor@cs.glasgow.ac.uk (Mr Jem Taylor) (06/01/89)
In article <24642@agate.BERKELEY.EDU> wisner@mica.Berkeley.EDU (Bill Wisner) writes: >Pshaw. foo@bar.UUCP is a stupid revolting hack, I'll give you that. But >bar!foo is just fine. It's a UUCP address. It's unmistakably a UUCP address. > I'm sorry, but I can't agree with any of this. "bar!foo" has the same semantic content as "foo@bar" ; I believe it to be both permissible and necessary to convert one to the other merely to move a message between two connected systems if the standard notation is one on the first and the other on the second. If you wish to be able to communicate with a system such as ours which uses domain names (not the domain name system RFC88n), then you must use a domain name such as "foo@bar.uucp", or, in your notation, "bar.uucp!foo" otherwise I cannot send back. The problem is that few niave (ie, single environment, including many Unix gurus) people seem to acknowledge the need for globally valid names to be stamped when a message moves between systems. You can have local names and local domain expansion if you want it; you cannot expect me to have knowledge of your local domain, whereas you can expect me to recognise the name of the domain which encompasses yours. >When you see bar!foo the first thing you should think is "that's a UUCP >address". And when your mailer sees bar!foo it should think "this is a >UUCP address" and act accordingly. I suggest that you should recognise the name "bar" and 'complete' it (in the terminology of the ARPAnet Domain Name System) by adding the name of its enclosing domain, regardless of the notation originally used. The uk-sendmail sendmail.cf writing package generates sendmail.cf files which do this, regardless of the format in which names are presented. Afterwards, it routes messages to the correct relay and converts all addresses to the notation that the relay understands. -Jem Taylor. -- Arpa:taylor@cs.glasgow.ac.uk \ J.A.Taylor, Computing Science, Janet: taylor@uk.ac.glasgow.cs \ University of Glasgow, Uucp: mcvax!cs.glasgow.ac.uk!taylor \ GB-GLASGOW G12 8QQ
bill@twwells.uucp (T. William Wells) (06/03/89)
In article <174@icdi10.UUCP> fr@icdi10.UUCP (Fred Rump from home) writes: : In article <996@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: : >In article <24763@agate.BERKELEY.EDU> wisner@mica.Berkeley.EDU (Bill Wisner) writes: : > : >I'm registered as twwells.com, even though there is no commercial : >activity going on here. I chose that over twwells.ftl.fl.us because I : >didn't want to have to change my site name were I to move. In any : >Bill { uunet | novavax } !twwells!bill : : If you are registered under twwels.com, how come you use twwells.uucp? : And on top of that a bang path in your signature? : Really, I'm curious. : Fred Because, while the Internet knows who twwells.com is, uucp sites do not yet. Once one has registered with the Internet, one should also get ones uucp map entry updated. I've sent in the request but the update hasn't made it here yet. Once it has, I will update the software so that I appear as twwells.com rather than twwells.uucp. And, of course, I'll update my signature as well. --- Bill { uunet | novavax } !twwells!bill
allbery@ncoast.ORG (Brandon S. Allbery) (06/08/89)
As quoted from <174@icdi10.UUCP> by fr@icdi10.UUCP (Fred Rump from home): +--------------- | In article <996@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: | >In article <24763@agate.BERKELEY.EDU> wisner@mica.Berkeley.EDU (Bill Wisner) writes: | >I'm registered as twwells.com, even though there is no commercial | | If you are registered under twwels.com, how come you use twwells.uucp? | And on top of that a bang path in your signature? +--------------- The bang path is because not everybody runs smail or sendmail/ida or uumail or etc., so not everybody can locate twwells.com. As far as twwells.uucp is concerned: if you'll check up above, I haven't yet figured out where rn is getting ay of Pnews that hasn't yet been taught that we are ncoast.org. News is a b*tch. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
lamy@ai.utoronto.ca (Jean-Francois Lamy) (06/08/89)
>As far as twwells.uucp is concerned: if you'll check up above, I haven't >yet figured out where rn is getting ay of Pnews that hasn't yet been taught >that we are ncoast.org. News is a b*tch. The problem is that news has only the crudest notion of what a return address ought to be. Fix your inews, and modify the rn templates so they don't include the sender information. At least then you know then where to fix things (namely inews). What I did here was to fix our mailer so "mail comp.mail.uucp" would work properly (usenet is now just another transport mechanism like smtp, uucp, x.400, bsmtp, with the weird feature that it broadcasts messages). That way, the mailer gets to sanitize the From: lines, does it in full knowledge of what the mail address ought to be, and gets it right. In fact, many mailers do some fancy footwork like generating John.Doe@site.do.main and you really don't want to have to put back those smarts in the article posting machinery. To put an end to mail return address concerns I put in a fake inews (used by Pnews) that takes the message and mails it to the appropriate newsgroups. That way the mailer deals with the mail-related part (generating the mail return address) and the news mechanism deals with propagating the crud. Since that fake inews is only used by individals the extra overhead of going through the mailer is negligible. I'm not going to mention that you need a proper mailer to get this to work, because the one we run is in alpha testing. The usenet transport agent is sendmail-compatible, but don't ask me about getting sendmail to understand comp.mail.uucp as an address that reuires routing to usenet, I'm not the one to know. I am going to mention that running C news makes this easier, since it's finally coming out for real... Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4