🚀 go-pugleaf

In article <14396@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>Third, and most facist, is to start bouncing ! routed addresses.  To
>avoid breaking the network maintenance features I am arguing so
>strongly for, the sites which bounce ! routed addresses would check
>for a header line of the form "Netman: loopback check" or "Netman:
>routing around dead site", etc. Just check for the equivalent of the
>moderated newsgroups Approved header line and if present, let it
>through. If it is missing, send it back with a msg advising the sender
>to use domain addresses.
>
>Comments? 

Does this mean that my pathalias (which I've never gotten to work properly)
has to be operational?
-- 
+----------------------------------------------------------------------------+
|     Mark Steven Jeghers         ECHOMPGULP - process has eaten it          |
| cryptography, terrorist, DES, drugs, cipher, secret, decode, NSA, CIA, NRO |
|                                                                            |
|     {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark                |
|                                                                            |
| Cogent Software Solutions can not be held responsible for anything said    |
| by the above person since they have no control over him in the first place |
+----------------------------------------------------------------------------+

In article <14396@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>[...].  To
>avoid breaking the network maintenance features I am arguing so
>strongly for, the sites which bounce ! routed addresses would check
>for a header line of the form "Netman: loopback check" or "Netman:
>routing around dead site", etc. Just check for the equivalent of the
>moderated newsgroups Approved header line and if present, let it
>through. If it is missing, send it back with a msg advising the sender
>to use domain addresses.

This seems unnecsary to me, since RFC822 compliant address can still
specify routing.  The syntax for this is @host1:@host2:user@host3.
I've been told that the ":"'s should be ","'s except for the
right-most one (as the Berkeley sendmail configuration does), but I've
been unable to find this stated in RFC822 (could someone send me a
reference, if the ","'s are actually correct).

Jeff

In article <4611@mit-eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal writes:

> ...  The syntax for this is @host1:@host2:user@host3.      [sic -zben]   
> I've been told that the ":"'s should be ","'s except for the
> right-most one (as the Berkeley sendmail configuration does), but I've
> been unable to find this stated in RFC822 (could someone send me a
> reference, if the ","'s are actually correct).

See extended BNF on page 27 (section 6.1).

   route = 1#("@" domain) ":"

The parentheses are groupers, the 1# syntax is a comma-separated list of
from 1 to (arbitrary) members.  Thus this rule matches things like:

   @domain:
   @domain,@domain:
   @domain,@domain,@domain:

   addr-spec = local-part "@" domain
   mailbox = addr-spec / phrase route-addr
   route-addr = "<" [route] addr-spec ">"

Thus a "mailbox" can be something of the form:

   phrase <@domain,@domain,@domain:local@domain>

like:

   Ben Cranston <@wiscvm.wisc.edu,@umd2.bitnet:zben@umd5.umd.edu>

("Oh no, we've created a Finster!")
("You mean monster, don't you?")
("No, his name is Finster!")
-- 
                    umd5.UUCP    <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU    Kingdom of Merryland UniSys 1100/92
                    umd2.BITNET     "via HASP with RSCS"

> 
> For those who just dropped in, my claim (or plea) was:
> 
> 1) don't reroute a!b!c!joe
> 	a) even if you think d!c!joe is better
> 		o your map data could be out of date
> 		o site d's map data could be wrong about its costs
> 		o sender may know site d is down
> 	b) even if you directly connect to site b
> 		o sender may be trying to test site a's connectivity
	c) even if d!c!joe really is faster and/or cheaper
		o the mail may be private or proprietary
		o sender may have security-related reasons to avoid d

I've run into several cases where a!b!c!joe is all within a single
company, but d!c!joe goes through an 'outside' site.  Many companies
are concerned that mail of a proprietary nature be restricted to the
company's own machines.  In such cases, autorouting would generally
be undesirable, unless I have a way of suppressing it for a specific
piece of mail.  The easiest way to do this is probably something like
Phil's suggestion:

> 2) do route joe@c.domain
> 	you have to route this anyway.

The 'security' issue is a somewhat stronger one.  I suspect that those
among us with strong interests in having a secure system are not now
installing mailers that do autorouting.  There is just too much danger
that a message to headquarters will be routed through berkeley or
moskvax.  [It's hard to say which would be considered the biggest
security risk! :-]

After all, if you're passing around insider trading info, do you want
everyone at any random network site to have a chance to scan it?

A related topic that I haven't heard discussed:  We have some uucp
links that are internal to the company, and are rather expensive 
long-distance calls.  For company business, it is often a good 
idea to encourage their use.  It's easier to uucp a big chunk of
source code across a phone line than it is to mess with tapes or
floppies, and it gets the job done much faster.  But management
has some reasonable concerns that the outside world start using
these links for mail.  

The question is what sort of cost we attribute to such links.  For
internal mail, we'd like to make them look cheap, so that company
communication be fast.  To outsiders, we'd like to make them look
expensive.  

So far, the approach has been to tell the outside world that they
either don't exist or are very expensive.  Internally, we aren't
using a routing mailer, so it's no problem yet.  With the existing
routers, it looks like we'd have to have two sets of records (just
like the accounting department :-), an internal set that makes the
links cheap and an external set that makes them expensive.  This
seems undesirable; one of them has to be incorrect, and it'd be 
hard to prevent them from being accidentally 'corrected' to agree 
with each other.

Any good ideas?  Any ideas at all?  Has this already been hashed 
out?  If so, can someone email me the general solution?

-- 
	John M Chambers			Phone: 617/364-2000x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193
Clever-Saying: If we can't fix it, it ain't broke.

In article <14396@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
> Social security is welfare for the elderly.

Thats total fucking god damn bullshit!!!!  Welfare people put nothing
in and get something out.  The elderly have been force to put money
into the pot but are very likely not to get a thing out.
-- 
Perry Smith
{convex!ctvax,{ti-csl,infotel}!pollux}!bobkat!pedz

>This seems unnecsary to me, since RFC822 compliant address can still
>specify routing.  The syntax for this is @host1:@host2:user@host3.
>I've been told that the ":"'s should be ","'s except for the
>right-most one (as the Berkeley sendmail configuration does), but I've
>been unable to find this stated in RFC822 (could someone send me a
>reference, if the ","'s are actually correct).

I have had severe problems writing a sendmail.cf that would properly handle
addresses of that form:

@host1,@host2,@host3:user@host4

The basic problem is that the sendmail parser wants to take the above address
and break it apart at the commas.  This effect can be turned off if the address
is enclosed in angle brackets.  However 1) what if the user forgets to use
angle brackets? and 2) what if your mailer receives from another site an
address of that form that is not enclosed in angle brackets?

Here is one place I ran up against a wall when I did my recent complete rewrite
of our sendmail.cf script.  When gatewaying from uucp to sites reachable by
SMTP I want to avoid creating From: and envelope From addresses that mix !'s
and @'s (I treat "From:" and "envelope From" together here because, as
previously discussed, an unhacked sendmail does not provide the ability to
treat them differently).  I handled !'s in addresses by dividing the SMTP
reachable world into two classes.  Those sites that understand !'s in an
address are sent the address untouched.  For the strict RFC822 sites, those
that don't understand !'s in an address, the string of ! connected sitenames is
turned into an RFC822 route. This is in the theory that when the reply to that
message reaches here that my site can turn it back it to a ! format route and
that, as is likely to be true, the site sending the reply does not otherwise
know how to get mail back to the original sender of the note.  When a ! route
is turned into RFC822 route it needs to be surrounded by angle brackets to
protect it from sendmail's parsing.  However,  the ruleset trying to do this
has no idea whether the original address was surrounded by angle brackets
(sendmail passes what is inside them to the ruleset and the replaces what was
inside with the output of the ruleset). The safest thing to do seemed to be to
have the ruleset put a set of angle brackets around it. But then, if they were
already there, then two sets of angle brackets would be around the address.  I
am not sure if <<address>> is legal RFC822.  I do know that some sites reject
it.

I don't know why the framers of RFC822 chose that form of syntax.  The form
@host1:@host2:@host3:user@host4 would really have been much easier to parse.
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,topaz}!astrovax!wls
one of these days:	wls@astrovax.princeton.edu

> Thus a "mailbox" can be something of the form:
> 
>    phrase <@domain,@domain,@domain:local@domain>
> 
> like:
> 
>    Ben Cranston <@wiscvm.wisc.edu,@umd2.bitnet:zben@umd5.umd.edu>

Your technical description is completely correct, but I just want to point
out that your example above does not conform to RFC822 because umd2.bitnet
is not a registered domain.  All the domains must be fully registered to
conform to RFC822.

John Diamant
Systems Software Operation	UUCP:  {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co.		ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO

In article <837@astrovax.UUCP>, wls@astrovax.UUCP (William L. Sebok) writes:
> I have had severe problems writing a sendmail.cf that would properly handle
> addresses of that form:

> @host1,@host2,@host3:user@host4

> The basic problem is that the sendmail parser wants to take the above address
> and break it apart at the commas.

Sendmail only "breaks apart" addresses in the headers, and in the
headers this form of address is illegal if not surrounded by
angle brackets.  If the user forgets to add them, the user has
used an illegal address, and bouncing the mail is the right
thing to do (it should bounce, as @host1 has no "local part",
and so is illegal too).

Mail received from other sites is either received via smtp, which
has a single address in the Rcpt cmd (and its enclosed in < > anyway),
or its handed to sendmail as a command line arg, in which case sendmail
does not "break it apart".

> For the strict RFC822 sites, those that don't understand !'s in an address,
> the string of ! connected sitenames is turned into an RFC822 route.

I have considered doing this at times, but I have been unable to convince
myself that it is truly an invertible conversion.  In particular, when
the rfc822 only site send you back an address in route-addr form, and
its addressed to a uucp (!) site, can you really assume that you can
unravel the route-addr into a ! path, and be certain of not unraveling
too far?  I couldn't work out any safe way to guarantee this.  If I can't
guarantee to invert a transformation, I'm not about to make it.

> When a ! route
> is turned into RFC822 route it needs to be surrounded by angle brackets to
> protect it from sendmail's parsing.  However,  the ruleset trying to do this
> has no idea whether the original address was surrounded by angle brackets

This is indeed a problem, and one that should be fixed.

> The safest thing to do seemed to be to
> have the ruleset put a set of angle brackets around it.

Unfortunately, even if you could avoid the double << >> problem
(which sendmail could easily arrange to do), this still doesn't
necessarily generate a legal address.  Anywhere a route-addr is
used, there must also be a "phrase" in the address as well.
Sendmail would need to invent this phrase in some cases, and
inventing something rational isn't necessarily easy.

> I don't know why the framers of RFC822 chose that form of syntax.

Everything I have ever been able to ascertain suggests that the
thought of having user level source routing was so repugnant to
some of the rfc822 creators, that they deliberately made the syntax
as foul as they could get away with, given that others were
adamant that the facility had to be provided.

Robert Elz		seismo!munnari!kre	kre%munnari.oz@seismo.css.gov
			<@seismo.css.gov:kre@munnari.oz.au>

In article <1402@munnari.oz> kre@munnari.oz (Robert Elz) writes:

> In article <837@astrovax.UUCP>, wls@astrovax.UUCP (William L. Sebok) writes:

>> When a ! route is turned into RFC822 route ...
>> The safest thing to do seemed to be to
>> have the ruleset put a set of angle brackets around it.

> Unfortunately, even if you could avoid the double << >> problem
> (which sendmail could easily arrange to do), this still doesn't
> necessarily generate a legal address.  Anywhere a route-addr is
> used, there must also be a "phrase" in the address as well.
> Sendmail would need to invent this phrase in some cases, and
> inventing something rational isn't necessarily easy.

If there were any one particular wart in 822 that it would be reasonable 
to "by gentleman's agreement" ignore, it would be this requirement for a
non-null phrase.  Nevertheless, I think what we are talking about doing
(translating an address from one domain to another) falls into the category
of "munging".  The existing RFC standard for header munging suggests the
unmunged address be included as a pseudo-comment in the munged address.
This can simultaniously satisfy the syntactic requirement for "phrase".

So one might want to translate the address:

fee!fie!foe!fum!jack

into:

"fee!fie!foe!fum!jack" <@fee,@fie,@foe:jack@fum>

Seems as reasonable a default as any... My Internet to BitNet relay 
implementation does just this.
-- 
                    umd5.UUCP    <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU    Kingdom of Merryland UniSys 1100/92
                    umd2.BITNET     "via HASP with RSCS"

In article <613@cdx39.UUCP> jc@cdx39.UUCP (John Chambers) writes:
> There is just too much danger that a message to headquarters will be
> routed through berkeley or moskvax.
> [...]
> We have some uucp links that are internal to the company, and are rather
> expensive long-distance calls.  For company business, it is often a good 
> idea to encourage their use. [...]  But management has some reasonable
> concerns that the outside world start using these links for mail.  

	There was a talk at the Atlanta Usenix (don't remember who, sorry)
about domains and routing mail between the Arpa Internet, UUCP, BITNET,
CSNET, etc.  One of the basic ideas to to put a high price on crossing
domain boundaries.  If you have your company totaly contained within a
domain, both of the problems described above go away.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

"you can't spell deoxyribonucleic without unix!"

I forgot one more reason autorouting uucp ! format paths is bad:

Such addresses are path relative. That is, decwrl!amdcad!neptune is
different from ihnp4!neptune. ATT has a machine named neptune, AMD has
a (different) machine named neptune, not advertised to the world. If
some "smart" machine decided to do us a "favor" and change
decwrl!amdcad!neptune to ihnp4!neptune, the mail would end up going to
the wrong place.

I realize having non-unique uucp node names is a problem and
everything should be domainized but there ARE duplicates and
autorouting uucp ! format addresses is a good way to mess things up,
with little benefit.

-- 
 Social security is welfare for the elderly.

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

In article <14481@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>
>I forgot one more reason autorouting uucp ! format paths is bad:
>
>Such addresses are path relative. That is, decwrl!amdcad!neptune is
>different from ihnp4!neptune. ATT has a machine named neptune, AMD has
>a (different) machine named neptune, not advertised to the world. If
>some "smart" machine decided to do us a "favor" and change
>decwrl!amdcad!neptune to ihnp4!neptune, the mail would end up going to
>the wrong place.
>
>I realize having non-unique uucp node names is a problem and
>everything should be domainized but there ARE duplicates and
>autorouting uucp ! format addresses is a good way to mess things up,
>with little benefit.

True, but this already a fatal problem in the real world.  There are
unmarked anti-social routers out there that are diverting any external
mail to your neptune to the other...

These people think that they are doing you/themselves a favor...
-- 
George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

In article <1300@cbmvax.cbmvax.cbm.UUCP> (George Robbins) writes:
>In article <14481@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>>
>>I realize having non-unique uucp node names is a problem and
>>everything should be domainized but there ARE duplicates and
>>autorouting uucp ! format addresses is a good way to mess things up,
>>with little benefit.
>
>True, but this already a fatal problem in the real world.  There are
>unmarked anti-social routers out there that are diverting any external
>mail to your neptune to the other...

You make it sound as though "well, people are doing this (wrong) thing
already, so what are you complaining about?"

I'm sure that isn't what you meant.

-- 
 Paul Slansky: Those who believe that President Reagan had to have known about 
 secret fund diversions to the Contras are overlooking Reagan's hard-won
 reputation for knowing practically nothing.

 Phil Ngai +1 408 982 7840
 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

I think I must throw in my 2 Pfennig's worth...
we decided to do uucp autorouting a long time ago, when most unknowledgeable
mail users thought that ...!unido!mcvax!decvax!... was the only way across
the pond.  mcvax!decvax has been an awfully slow, awfully unreliable and
awfully expensive 300bd telephone link, and we have a fast, reliable and cheap
x.25 link to seismo...  Not doing autorouting would have meant mail delivery
times in the order of several days AND high comm. cost, while with seismo
we have delivery within a few hours.  Compared to the real benefits that
autorouting has, the disadvantages are nearly nil.  Who wants to talk to a
uucp site which can't choose a unique name, anyway :-) ?

	Hans-Martin Mosner
	(one of) postmaster@unido.uucp

> I forgot one more reason autorouting uucp ! format paths is bad:
> Such addresses are path relative. That is, decwrl!amdcad!neptune is
> different from ihnp4!neptune. 
> ... 
> I realize having non-unique uucp node names is a problem and
> everything should be domainized ...

Actually, while this is a problem for the global email system, it
is (from a user's viewpoint) one of the great advantages of uucp
mail.  

Why?  Well, because we don't need any kind of central Authority
to organize a little uucp exchange.  If our company has a cluster 
of Unix boxes, we can connect them together with null-modem links,
give each one a nodename unique within the cluster, and copy files
to our hearts' content.  This takes maybe 10 minutes to an hour.
We don't first have to spend weeks or months getting names and/or 
network addresses from some distant authority (which all too often 
means convincing the authority that we need to do what we're doing).

Granted, as soon as we make a uucp link out to the external world, 
and send email across it, there is a problem.  But at least we can 
put off burning that bridge until we come to it.  If all we need 
is a temporary link to copy a few megabytes of files, we can do it 
and get on with the job without a lot of bureaucratic hassles.

Uucp is, after all, used for a lot more than email.  Even with
intelligent mail routers installed everywhere (which is still
not too close to realization), people would still be making
little, temporary links and running uucp across it for purposes
like downloading binaries and uuxing them.  Requiring that users
first spend several orders of magnitude more time consulting a
name authority is not realistic.

-- 
	John M Chambers			Phone: 617/364-2000x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193
Clever-Saying: If we can't fix it, it ain't broke.

In article <14511@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>>
>>True, but this already a fatal problem in the real world.  There are
>>unmarked anti-social routers out there that are diverting any external
>>mail to your neptune to the other...
>
>You make it sound as though "well, people are doing this (wrong) thing
>already, so what are you complaining about?"
>
>I'm sure that isn't what you meant.
>
> Phil Ngai +1 408 982 7840

Silly me - I was just trying to say that there is nothing theoretical
or future tense about the duplicate name / auto re-routing problem.

One can either start a campaign to make these rerouters correct the
errors of their ways, or one can correct the duplicate name situation.

Which solution do you have more control over?

-- 
George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

In article <14481@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>>>I realize having non-unique uucp node names is a problem and
>>>everything should be domainized but there ARE duplicates and
>>>autorouting uucp ! format addresses is a good way to mess things up,
>>>with little benefit.

In article <1300@cbmvax.cbmvax.cbm.UUCP> (George Robbins) writes:
>>True, but this already a fatal problem in the real world.  There are
>>unmarked anti-social routers out there that are diverting any external
>>mail to your neptune to the other...

In article <14511@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>You make it sound as though "well, people are doing this (wrong) thing
>already, so what are you complaining about?"

This started when Phil mentioned that both AMD and AT&T have a
machine named neptune.  Actually, there's only a name conflict if you
call both machines neptune.  AMD's machine is neptune.AMD.COM (now
that Phil has installed smail), and AT&T's machine is
neptune.foo.bar.bletch.ATT.COM.  People with vanilla mailers can
mail to neptune.AMD.COM by just mailing to ...!amdcad!neptune.AMD.COM!user.
Voila, the unique UUCP name problem is gone, because of the magic of smail.  

On the other hand, people whose mailers reroute my mail through ihnp4 when
I've specified a perfectly valid path that avoids it should be shot.
Unlike Phil, though, I'm perfectly happy if a router converts an
invalid path into a valid one and makes my mail reach its
destination.

-- 
- Joe Buck 	{hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck	HASA (A,S)
  Entropic Processing, Inc., Cupertino, California

Anyone who wants to improve mail forwarding between the UUCP and RFC822 worlds
should start by reading the RFC822 spec.  Among other things, it becomes
obvious why <>'s are necessary in route-addrs, the reason for using commas
instead of colons to separate hosts in a route, etc.  Too many people are
trying to get the "look and feel" of RFC822 without paying attention to the
details, and if you don't follow the spec, you may do more harm than good.

I strongly discourage people from using uucp paths to construct RFC822
route-addrs, particularly because the uucp path components are generally not
going to be "registered", and if they're not, you just can't build a legal
route-addr.  Also, if you use a stock sendmail, you can't just turn a uucp path
into a route-addr since to be legal, route-addrs must be preceded by a
"phrase".  Furthermore, a proper RFC822 user agent will ignore any explicit
route in the From: header and just use the addr-spec component (the portion
following the ":") when generating replies.

One alternative to trying to build route-addrs out of uucp paths is to rewrite
the paths by appending your RFC822 domain name *and* prepending your uucp
sitename, so host!user becomes princeton!host!user@princeton.edu.  This is
perfectly valid RFC822, and unless someone is misusing smail, replies should
come back to you one way or another, at which point you just have to make sure
you strip your name off at both ends.
							Chris

In article <849@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes:
>This started when Phil mentioned that both AMD and AT&T have a
>machine named neptune.  Actually, there's only a name conflict if you
>call both machines neptune.  AMD's machine is neptune.AMD.COM (now
>that Phil has installed smail), and AT&T's machine is
>neptune.foo.bar.bletch.ATT.COM.

  The "magic of smail" also creates some other problems. For example, I just
found out the hard way that there are two machines named "solar" (I gather
from some comments in some map entries that this has been known for some
time, but I just found out today and it bit me BADLY). One is at Stanford,
and we have a direct uucp connection to them. Unbeknownst to me, there is
also a "solar" at AT&T that has a direct connection to cbosgd, the gateway
into some of those foo.bar.bletch.ATT.COM domains you mention. So, when
I changed our L.sys file to increase the frequency of our connection to
"solar" (due to user demand here), and changed my local map entry accordingly,
and regenerated my pathalias output/smail input database, I thought it worked,
because people who mailed from here to user@solar.uucp got their message
sent over the direct link as desired, as opposed to previously when it went
over some convoluted path through seismo (which, it now occurs to me, may
very well have ended at the wrong "solar" anyway). Unfortunately, my messages
to mark@cbpavo.MIS.OH.ATT.COM got routed to Stanford by smail, and bounced 
back. In order to fix the problem, I have to edit BY HAND the map files and
excise references to the AT&T "solar". Yes, I can still mail to the AT&T one
if I send to solar.ATT.COM, so you are right that smail removes ambiguity in
DESTINATION host names. However, ambiguous INTERMEDIATE host names becomes a 
serious problem, because a user can send the mail via the wrong intermediate 
host and lose the message, despite the fact that a "path" to the destination
supposedly exists! And this happens even when the destination host is 
specified with a domain address!
  Therefore, I think it is more important than ever to eliminate ALL duplicate
host names from uucp, or at least from the map postings, or we're going to see
lots of incorrectly routed mail as smail and other domain routers like it
become more and more common. As for me, I have no choice but to manually
edit the map postings every month, or do something else equally kludgy like
running pathalias with the cbosgd!solar link declared DEAD (and then there's
no guarantee that mail to other places within AT&T might not get routed to
Stanford anyway because of OTHER links that AT&T's solar might have). This
is a headache for me, but nearly as serious as the problem that occurs when
such duplicate names exist but are not KNOWN about.

--Greg
-- 
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet  ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edu

If you ask me, there are going to be more duplicate uucp names in the
future, not less. I'll leave it to the reader to guess why.

Peter Honeyman was right.
-- 
 Paul Slansky: Those who believe that President Reagan had to have known about 
 secret fund diversions to the Contras are overlooking Reagan's hard-won
 reputation for knowing practically nothing.

 Phil Ngai +1 408 982 7840
 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

> Granted, as soon as we make a uucp link out to the external world, 
> and send email across it, there is a problem.  But at least we can 
> put off burning that bridge until we come to it...

Actually, the right approach to that one is to do a bit of work on things
like mailers so that your internal cluster looks like one machine to the
outside world.  It is a crying shame that more sites don't do this.
-- 
Legalize			Henry Spencer @ U of Toronto Zoology
freedom!			{allegra,ihnp4,decvax,pyramid}!utzoo!henry

jc@cdx39.UUCP (John Chambers) says:
>> ... 
>> I realize having non-unique uucp node names is a problem and
>> everything should be domainized ...
> ...
> ...
>Uucp is, after all, used for a lot more than email.  Even with
>intelligent mail routers installed everywhere (which is still
>not too close to realization), people would still be making
>little, temporary links and running uucp across it for purposes
>like downloading binaries and uuxing them.  Requiring that users
>first spend several orders of magnitude more time consulting a
>name authority is not realistic.
>

Of course it is used for more than email.  You are making a useless point
since the issue of the actual workings of UUCP is not germane to this dis-
cussion.  UUCP knows nothing about domains and addresses and probably never
will.  All it knows about is paths.  As far as mail is concerned, UUCP is just
a transport protocol, ignorant of the application layer's needs and intentions.
Mail is the entity that needs to know about domains and addresses (if you are
a domainist and if you aren't then this entire discussion is of no interest).

-- 
	Chris Grevstad
	{sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!chris
	ihnp4!nrcvax!chris

Don't let the sunshine spoil your rain,
Just stand up and complain.

> >Uucp is, after all, used for a lot more than email.  Even with
> >intelligent mail routers installed everywhere (which is still
> >not too close to realization), people would still be making
> >little, temporary links and running uucp across it for purposes
> >like downloading binaries and uuxing them.  Requiring that users
> >first spend several orders of magnitude more time consulting a
> >name authority is not realistic.
> 
> Of course it is used for more than email.  You are making a useless point
> since the issue of the actual workings of UUCP is not germane to this dis-
> cussion.  UUCP knows nothing about domains and addresses and probably never
> will.  All it knows about is paths.  As far as mail is concerned, UUCP is just
> a transport protocol, ignorant of the application layer's needs and intentions.
>
Well, yes and no.  Note, first, that I didn't say anything about
the actual workings of UUCP.  I was talking about people using
it to do a job.  And when they set up little local uucp clusters,
they very often run mail across it.  Why?  Well, mail is often
more convenient than running uucp directly.  Many users know how
to use mail better than uucp, and they use what they know.  This
may not be the "best" from a guru's point of view, but they're not
gurus.  And as long as they're only passing source files across
the links, mail works just fine.  Granted, uuto would be better,
but people tend to use the tools they know.

Every Unix system I've ever seen has a library program called 
'mail', and they all work the same.  It's a nice little program, 
for what little it does.  I can teach a novice user all about
it in 5 minutes, and they can use it without surprises on a local
uucp cluster (which regrettably requires a guru to hook up). 
It's still going to be a while before domainized mailers are
so easy for a non-guru to use.

The point I've been trying to make is that there are many good
uses for temporary clusters of machines.  Those who are developing 
new mailers can rail all they want against such uses of machines,
but users aren't likely to listen.  Currently, hooking up a cluster 
via uucp can be done in time measured in fractions of an hour per
node.  Consulting a name authority is several orders of magnitude
slower, and in many cases would take longer than the lifetime of
the cluster.  This is quite prohibitive.

> Mail is the entity that needs to know about domains and addresses (if you are
> a domainist and if you aren't then this entire discussion is of no interest).

Actually, even if I weren't, I'd still find it interesting.  But
I can assure you that most of the other users around here find it
supremely boring; they leave newsgroups like comp.mail.headers to
weirdos like me. 

-- 
	John M Chambers			Phone: 617/364-2000x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193
Clever-Saying: Uucp me out of here, Scotty; there's no AI on this node!

Forgive me if I am not using the proper newsgroup.  If you can
re-direct me to an other it would be appreciated.

Does anyone know the mail address to 
		Abbot Labs., Int'l Co.
		1015 Distributors Row
		Harahan, LA 70123

I'm afraid everyone I have spoken to there are not very
computer literate and/or not helpful.

Any thoughts/suggestions would be most appreciated!

	celeste