🚀 go-pugleaf

In article <14227@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>
>I hate smail.

Well, I've been using smail for two months now and I think it works
very well.  Perhaps there really are problems with it, but you sure
can't tell from Phil's flame.  Phil, it would help everyone if you could
be more specific about the problems you've encountered.  A flame may
make you feel better, but does no one else any good at all.
-- 
Larry Campbell                                The Boston Software Works, Inc.
Internet: campbell@maynard.uucp             120 Fulton Street, Boston MA 02109
uucp: {alliant,wjh12}!maynard!campbell              +1 617 367 6846
ARPA: campbell%maynard.uucp@harvisr.harvard.edu      MCI: LCAMPBELL

Well, I too am beginning to dislike smail ... but not becuase my mail get
bounced around ... but because (because, because, of the wonderful things...)
it doesn't even come near considering geographic area ... Eg: location!!
This, ofcourse, could be mostly the fault of pathaliases ... but I won't
point any fingers (                            ^^    )

Quite often I have large pieces of mail shipped all over the country.
From Boston to Miami to Denver to Canada [back] to Miami then to San Jose.
Even though I specify a direct path (quick and fast), all it takes is
one smail site to reroute the message BACK across the country ... and two
weeks later my 99K mail gets to me.

Oh well. Smail is atleast great for domains ... but geographical domains
would also be nice (providing geographical domains are used to reach
the target geographical domain ... eg: mail to joe.ca from site.maine doesn't
need to be routed to site.europe ... you get the idea )

But I'm crazy anyways...
-- 
"No matter      Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA.
where you go,   ARPA: aussjo!joe@lll-tis-b.arpa       PHONE: [408] 279-5533
there you       UUCP: {sdencore,necntc,cbosgd,amdahl,ptsfa,dana}!aussjo!joe
are ..."        UUCP: {styx,ucbvax!imagen,dlb,gould}!auspyr!joe

In article <799@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes:
>In article <14227@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>>
>>I hate smail.
>
>Well, I've been using smail for two months now and I think it works
>very well.

The problems with smail are caused to the people who DON'T use smail.  I'm
sure smail works just wonderfully on all the sites where it has been
installed and is maintained, but I see a LOT of return addresses that simply
don't work anymore.  There has always been a problem with bogus return
addresses, but the incidence is way up in the last few months, primarily
because smail sites love to send out return addresses like
"mark@cbosgd.att.com" -- which is great if you have smail around to figure
out where that is, but not so great if you don't -- and your sendmail system
sends the message off to ARPAland looking for the machine.

Which, I guess, brings forward the biggest hassle with domaining -- it
assumes that everyone is doing domains, which isn't true, and likely will
never be true.

[Don't take this as a anti-domain argument.  I could yell just as much about
	direct routing, and one of these days I might.  The reality is there
	just isn't a good, compatible, reasonable mailing system, so I'm
	not taking sides -- both reality and domains have advantages and
	disadvantages.  Take your choice]

chuq
Chuq Von Rospach	chuq@sun.COM

It's only a model...

In article <799@maynard.BSW.COM>, campbell@maynard.BSW.COM (Larry Campbell) writes:
> 
> Well, I've been using smail for two months now and I think it works
> very well.

What is smail, and what are its advantages?  Sorry, but I joined
this discussion late.

-- 
-Dennis Bednar
{decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis	UUCP

In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes:
>it doesn't even come near considering geographic area ... Eg: location!!
>This, ofcourse, could be mostly the fault of pathaliases ... but I won't
>point any fingers (                            ^^    )
>...
>Even though I specify a direct path (quick and fast), all it takes is
>one smail site to reroute the message BACK across the country ... and two
>weeks later my 99K mail gets to me.

The greatest problem here is not that pathalias doesn't take into
account geographic areas, or that geographic domains do not exist.  The
problem is a lack of standardization on what costs should be used for
map entries, and is also a function of the number of system
administrators who just put DEMAND and DIRECT costs on lines that
probably shouldn't be used for high amounts of traffic.

I believe that a somewhat standard system of cost figuring that took
into account poll rate, line cost, line capacity, system reliability
and size, and (possibly) distance, would, if adopted by enough system
administrators, yield a much more reliable path database.

For example, a small widget box in the midwest which happens to poll on
demand to a system on the west coast and a system on the east coast
should take into account that it doesn't have leased lines or the
necessary system size and performance to handle all traffic between
coasts and state costs other than DEMAND, and probably much higher.

Another parallel possibility here is to give a cost to a host that
indicates a _through_ cost, which would raise the cost for routing
_through_ a site as opposed to routing _to_ a site.  Pathalias would need
to be modified for this to work, but perhaps the best way to reach this
midwestern machine from either cost is through those demand lines, while
sites wouldn't generally want to route through this site.  In this
case, a low cost could be given for the lines, while a high cost is
given for routing through the site.
-- 
   tron  |-<=>-|    ARPAnet: nsc!tron@sun.COM
  tron@sc.nsc.com   UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron

In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes:
>
>Well, I too am beginning to dislike smail ... but not becuase my mail get
>bounced around ... but because (because, because, of the wonderful things...)
>it doesn't even come near considering geographic area ... Eg: location!!
>This, ofcourse, could be mostly the fault of pathaliases ... but I won't
>point any fingers (                            ^^    )

What makes you think that geographic distance has much to do with
time or cost?  It costs me less to call my parents in Washington, DC
than my friends in LA (from San Jose).  There are relatively few good
north-south UUCP connections in California; there are many more
east-west connections.  Internet connections are just about
instantaneous, and many companies have leased lines.  There's no
reason to consider geography if the pathalias data reflects true
costs (unfortunately, it doesn't).

I am bothered by mailers that rewrite bang-form paths.  It makes it
impossible to avoid ihnp4, for example.  But no one should be
surprised when pathalias generates 6000-mile paths in the US; that's
exactly what it should do.
-- 
- Joe Buck 	{hplabs,ihnp4,sun}!oliveb!epimass!jbuck		HASA (A,S)
  Entropic Processing, Inc., Cupertino, California

In article <14227@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
> I hate smail. I don't think too highly of the people that unleashed it
> on us either. This system works worse than PC-DOS. I hate it.  Maybe
> the authors are trying to teach me I get what I pay for. Unreliable
> software.

Hmm.  That seems quite odd.  We've been using smail here, and I've
been more than happy with it.  About the only real problem there
might be with it isn't really a problem with smail, and that is that
smail interprets From: addresses properly, whilst many sites do the
improper thing by prepending their hostname onto the From: address,
the result being an improper address.  This makes replies a somewhat
iffy proposition, though that was true before smail came along.

I believe that the UUCP-Project is still working on improving smail,
so if you have some specific suggestions, why don't you spell them out?

-- 
Greg Paris ....................... gmp@rayssd.RAY.COM
{cbosgd,gatech,ihnp4,linus,mirror,uiucdcs}!rayssd!gmp
... Everything seems to be up in the air at this time
................ I need something to change your mind

People keep asking me "what do you not like about smail?" I already
said what I don't like: my mail bounces all the time now that we
run smail. Before we ran smail, my mail went through with maybe
5% as many problems.

Then people start asking me what particularly is going wrong. I don't
know and I don't want to know. Why should I have to know all this
stuff? My mail used to work great, and I didn't have to know anything
then.

It seems that the problems are all of different natures anyway. The
one that I do sort of understand has to do with getting mail from
ARPAnet sites. I thought this domain stuff worked. Not until after it
is installed that I find out amdcad.amd.com makes sites like lll-crg
puke. Not until after we invest a lot of time in this do we find out
that the use of domains by uucp sites appears to be a disputed issue
in the ARPA world. Well, eventually sun agreed to perform some vital
service the nature of which I don't quite understand which allows me
to receive mail from ARPA sites again. But I feel quite deceived that
smail appeared to be passed off as something easy to use when
important nodes such as decwrl and lll-crg don't even want to talk to
amdcad.amd.com. I get the sense that smail was released to get
innocent sites like mine to run it and put pressure on the sites which
don't hold the same philosophy as the smail project to accept their
notion of the world.

I don't appreciate being used that way. But most of all I don't like
my mail bouncing all over the place.

Anyway, even sun apparently can only handle a limited number of sites.
We were lucky enough to be accepted. What about the sites after us?
ARPA mail used to work just fine. Now we have a system where only the
lucky few with connections at Internet sites can get mail. Some people
are going to be unhappy about this.

In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes:
>
>Well, I too am beginning to dislike smail ... but not becuase my mail get
>bounced around ... but because (because, because, of the wonderful things...)
>it doesn't even come near considering geographic area ... Eg: location!!
>This, ofcourse, could be mostly the fault of pathaliases ... but I won't
>point any fingers (                            ^^    )

In this situation I don't quite blame smail. It looks like the map
data is causing the problems. But there are two points here. One is
that the map data is unreliable. As long as we rely on system admins
who are usually saddled with more work than they can really handle to
provide the map data, there will be bad or out of date paths. If
something like Erik Fair's uucp logfile analyzer were coupled with
software which automatically sent updates to the map data repository,
then there would be some hope.

The problem with mail crossing the country to get next door is of
course due to the map data. It is not even necessarily incorrect.  It
could be faster to cross the country and delay is what pathaliases
optimizes for. If it isn't faster, then the map data is wrong.

The other problem is when rerouting is forced on users. Then bad data
in the map knocks you out. Back when I was routing manually with the
aid of uupath, I could do things like say "ah, it wants to go through
ihnp4 but we know better" and avoid bad sites. Now it does whatever it
pleases.

What I liked to do a lot of was to take an address like
fred@site.dec.com and ship it off to decwrl to handle with
decwrl!fred@site.dec.com.  Now smail says "ah, @ takes precendence".
How am I supposed to dump addresses on a smarter site like decwrl now?

No doubt this article reveals a profound ignorance on the operation of
smail. I don't want to learn it. I didn't have to learn all this stuff
before and my mail worked. I am not especially lazy or unknowledgable
about computers and this is how I feel about smail. How do you suppose
all the other users feel about this mail situation?

-- 
 Butter and salt can make almost anything taste good.

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

In article <14237@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>What I liked to do a lot of was to take an address like
>fred@site.dec.com and ship it off to decwrl to handle with
>decwrl!fred@site.dec.com.  Now smail says "ah, @ takes precendence".
>How am I supposed to dump addresses on a smarter site like decwrl now?

Decwrl seems to do this just fine if you use an address like:

	decwrl!site.dec.com!fred

So you know.
-- 
   tron  |-<=>-|    ARPAnet: nsc!tron@sun.COM
  tron@sc.nsc.com   UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron

In article <14237@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>The other problem is when rerouting is forced on users. Then bad data
>in the map knocks you out. Back when I was routing manually with the
>aid of uupath, I could do things like say "ah, it wants to go through
>ihnp4 but we know better" and avoid bad sites. Now it does whatever it
>pleases.

I think a mailer should be able to find sites using whatever information
it has but more importantly it should be able to let me do it manually.
All this domainizing is great but if I want to send it my own way I should
be able to bypass the internal routing tables. Intermediate machines
in the path should look at the mail and say "Hmm.. he routed this himself
I better leave it alone." If I route it incorrectly, instead if rerouting it
when it comes to a dead end, it should bounce so that I know that the path
I chose was bad and I can find a new one.

>What I liked to do a lot of was to take an address like
>fred@site.dec.com and ship it off to decwrl to handle with
>decwrl!fred@site.dec.com.  Now smail says "ah, @ takes precendence".
>How am I supposed to dump addresses on a smarter site like decwrl now?

Try  fred%site.dec.com@decwrl

>No doubt this article reveals a profound ignorance on the operation of
>smail. I don't want to learn it. I didn't have to learn all this stuff
>before and my mail worked. I am not especially lazy or unknowledgable
>about computers and this is how I feel about smail. How do you suppose
>all the other users feel about this mail situation?

The front end mail system should make routing completely invisible to those
who want it that way so they can say fred@site.dec.com and assume it will
get there (within the limits of your site knowing where site x is) but if
joe smart-user wants to be able to explicitly do his routing that should be
possible to (but not nessessary).

Personally, I still like to route my mail myself because it seems that even
short routes are changing daily.

Well, it looks like my soap box has a crack in it so I'll step down now :-)
		    scott

-- 
				"I feel fine..."

...{utzoo, decvax, ihnp4, cbosgd, utcsri, mnetor}!utcs!scott
scott%utcs.toronto.edu@csnet-relay.arpa
scott@utoronto.bitnet
scott@utcs.utoronto.bitnet

Disclaimer: The above is not actually the opinion of anyone at all but
	especially not the administration or staff of this institution.

Well, I'm sorry that Phil is having problems with smail.  It's also
unfortunate that, rather than to ask us for help in fixing whatever
problems he's run into (or better yet, asking his SA, who understands
smail) he's chosen to go public.  I don't stay caught up on netnews
these days, and it's hard to help out members if we are unaware of
the problem.  We are contacting AMD to see if we can work out the problems.

Smail does not normally reroute mail.  It is possible to configure
it to do that, but in general we don't recommend that, because it
gets in the way of smart users who want to force a particular path.
(Rerouting was put there for hosts like ihnp4 that get lots of
netnews-path replies sent through them - it saves them considerable
money.  Gary Murakami is an expert and fully understands the tradeoffs
of doing rerouting.  We don't recommend that people set REROUTE unless
they really know what they are doing, and even then I discourage it.)
If people are finding their mail rerouted, then either people are
disregarding the warnings, or else there is a bug somewhere we'd like
to track down and fix.

Telephone calls tend to be about the same cost, no matter how far they
go, as long as they stay within the 48 states.  Intrastate calls are
often more expensive, due to less restrictive local regulation.  The
hop that goes across the country may seem inefficient, but if pathalias
chose it, it's usually pretty reasonable.  Of course, direct links
should be used, if they are reliable and exist, unless there is good
reason not to.

Mail is sometimes bounced, due to systems that violate the standards.
Since UUCP is a free community with lots of R&D on it, there are always
people breaking their mailers.  When politely told of the problem, most
SA's are very happy to fix it.  But it's a fact of life, whether one
runs smail or not - mail will be bouned.  Within the domain world, I
have found mail to be pretty solid, certainly the weakest part is the
underlying UUCP connection.  Before smail, I had to keep a map of the
net in my head, and a lot of my mail bounced.  With smail, the system
keeps a map for me, and less of my mail bounces.

decwrl is primarily on DEC's ENET, and secondarily on the ARPANET.
They consider themselves to be only tertiarily on UUCP.  Given the
complexity of an ENET-ARPANET gateway, I understand their decision.
As a result, anything they get for a domain they don't recognize
gets sent via the ARPANET, since they have chosen not to be a
forwarder between ARPA or ENET and UUCP.  Brian Reid and I spent
some time a while back tracking down problems with their MX handling
(most of which turned out not to be decwrl's fault, but problems
elsewhere on the ARPANET) and now mail from DEC to a UUCP domain
is forwarded properly, as Phil points out - in his case via Sun.
The extra hop should be transparent and quite fast, since it goes
over the ARPANET from decwrl to sun.  It would be nice if decwrl's
software would deliver it directly, but that would be hard to do,
and the benefit would be awfully small, so I certainly understand
why they aren't devoting the effort to do so.

	Mark Horton

> 
> I believe that the UUCP-Project is still working on improving smail,
> so if you have some specific suggestions, why don't you spell them out?
> 
> -- 
> Greg Paris ....................... gmp@rayssd.RAY.COM
> {cbosgd,gatech,ihnp4,linus,mirror,uiucdcs}!rayssd!gmp

OK - here's one:

	It would be nice if smail could handle aliases. 

I find smail to be a very nice package - it gives us no trouble
at all. I did try running uumail for a while, specifically to
get the aliasing feature, but quickly switched back to smail
(we had a number of problems that I won't go in to. Most were
configuration problems that will vanish when I can spend some
time with the software).

There has been a problem with sites completely rewriting the bang
path. Our philosophy is to route anything that shows up on ncc in
the form "domain!user", "uucp_host!user", or "user@domain". This
allows us to control access to directly connected sites if there are
problems (well, sometimes :-), and allows us to route for downstream
sites. It *also* allows a downstream user to pick an explicit path
to a site if s/he so chooses.

Recently we added another rule to the above: If a piece of
mail arrives destined for "b!c!d" where "b" is not a machine we
know about, smail attempts to prepend the necessary path to "b".
This seems to help quite a bit when a downstream site tries to
reply to a message with a munged up bang path in the From: line.
-- 
Lyndon Nerenberg - Nexus Computing Corp. - lyndon@ncc.UUCP
UUCP: {ihnp4,ubc-vision,vax135,watmath}!alberta!ncc!lyndon

>In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes:
>>Even though I specify a direct path (quick and fast), all it takes is
>>one smail site to reroute the message BACK across the country ... and two
>>weeks later my 99K mail gets to me.

In article <4070@nsc.NSC.COM> tron@nsc.NSC.COM (Ronald S. Karr) writes:
>The greatest problem here is ... a lack of standardization on what
>costs should be used for map entries....

This is indeed probably the greatest problem.  One thing that I
have not seen mentioned, though, is that in some cases bouncing
across the country several times may in fact be the fastest and
cheapest route.  Some companies have dedicated, high-speed links
between (say) California and New York offices.  Going from Palo
Alto to Rochester to NYC to L.A. may be faster and less expensive
than going from Palo Alto directly to L.A.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

>  > > I hate smail.
>  > I've been using smail for two months now and I think it works very well.
>  The problems with smail are caused to the people who DON'T use smail.  

All true, and all somewhat missing the point.  If there were just one
mailer in the universe, and we were all forced to use it, we'd likely 
be better off (unless it came from IBM, in which case only giants could
affort to use it :-).  The problems don't arise from any one mailer
being bad, but rather from a multitude of incompatible mailers.  

What we need is not Yet Another Funny Mailer.  Regardless of how
marvelous one is, it just adds to the confusion.  There's no way
at present to impose a single standard mailer on the world, and
even if there were, it is probably too early; if someone decreed
that we must adopt the new foomail system, we'd be stuck forever 
with the moral equivalent of Fortran.

What is needed is more the sort of thing that sendmail attempted to
do:  find a way to interface to all the existing mailers, in such a 
way that it is (1) reasonably easy to install (not true of sendmail);
(2) reasonably easy to augment with an assortment of user interfaces;
and (3) reasonably easy to invert mail paths automatically.

Whether such is even possible, I don't know (though I'd like to
find a way to work on it).  

>  [Don't take this as a anti-domain argument.  I could yell just as 
> much about direct routing, and one of these days I might.  

It seems to me that both are inherently desirable.  General-purpose
mail messaging can benifit greatly from a domain-based approach.  On
the other hand, if I need to get a megabyte of code from here to our
site in Phoenix, and we have a direct link, I sure don't want some
mailer to decide that, since the modem is busy at the moment, it will
"help" me by mailing it indirectly via moskvax (which, unbeknownst
to me, has email links to both of the sites).  I mean, some of that
code is company confidential, f'Gawd's sake.  The mailer had damn
well better send it along the path I specified.  If it doesn't, I'm
gonna go and shoot it down.

One of the nice things about the good ol' uucp mailer is that I can
give it a totally dumb mail path, and it will do it exactly what I
tell it to do, without trying to outsmart me.  I've grown to really
appreciate that, after having got mail bounced back by "smart" mailers
that find a "better" path that happens not to work for some reason.

Sigh.

-- 
	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.

> > What I liked to do a lot of was to take an address like
> > fred@site.dec.com and ship it off to decwrl to handle with
> > decwrl!fred@site.dec.com. Now smail says "ah, @ takes precendence".
> > How am I supposed to dump addresses on a smarter site like decwrl now?
> 
> Try fred%site.dec.com@decwrl
> 
Which brings up an opportunity to remake an old observation:  Many
of the problems with email paths are due to the existence of a lot
of "operators" like '!', '@', '%', '.', and so on, without agreement
among the mailers about their precedence.  Imagine the fun if the
people who write compilers each had their own ideas about the "right"
operator precedence.  

No, you don't have to imagine it; just use some complicated expressions 
in C that involve the non-traditional operators (i.e., anything other 
than "+-*/").   Experienced C programmers often throw up their hands
at the task of memorizing the precedence table, and just use lots and
lots of "unnecessary" parentheses.

It has been centuries since mathematicians worked figured out that
parentheses are valuable; they even conventionally use several types
of "brackets" for readability: (a*[b/sqrt(c)-{x/y}]*17).  

Scanning for parens is easy to code.  Occasionally I've seen the hint
that mailers should do this, and (if you have the source code), it could
be profitably added to all existing mailers.  Instead of using paths
like those above, we should start putting pressure on anyone responsible
(i.e., anyone with source code :-) to add code that in effect says "This
mailer only understands the parts of a mail path that is outside all
bracketing characters, after first stripping off all outside brackets,
of course".  Anything within barckets would be passed to the next mailer
for it to ponder.  

If we could pressure the folks with source to all the mailers, we could
then use paths like:
	decwrl!(fred@site.dec.com)
	{decwrl!fred@}site.dec.com
	[fred%site.dec.com]@decwrl
	fred%(site.dec.com@decwrl)
and the results would be unambiguous.  This would allow us to force mail
through a known working path, even when the "intelligent" mailers were
(typically through no fault of their own; the map data isn't good) not
able to do it correctly.

Hey, you guys with the source code, what do you think of this?  It's
worked for mathematicians for ages; it can work for us, too.  How fast
can you add it to your mailer?

-- 
	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 <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes:
>
>Well, I too am beginning to dislike smail ... but not becuase my mail get

>Even though I specify a direct path (quick and fast), all it takes is
>one smail site to reroute the message BACK across the country ... and two
>weeks later my 99K mail gets to me.

Note that this is an installation option.  I use smail, and my site is set
up to use the path you hand it.  I use pathalias to find the path to ONLY
the next site in the path.  If the incomming path tells me to send it to a
machine I am connected to, I will.  If it says to send it elsewhere, I use
pathalias to determine how.  If I can't figure it out, I send it to a
backbone site, in hopes they have better maps (thanks to the
forwarding-relay patch that was posted to the net).  (My software can't
return it, so this actually gives the sender a better chance of getting it
back if it is completely bogus.)  smail offers the ability to configure it
so that it ignores the supplied path and routes to the destination.  I find
this to be extremely anti-social, and I wish that that capability had not
been provided, as it causes exactly the kind of behavior you describe.

By the way, one advantage of always using pathalias to route to the next
hop is that I can keep paths working if a neighbor renames his site, or if
I drop a link.  Pathalias handles these for me.  If I didn't use it, it
would drop the floor.

Now, what I hate is all the sites running sendmail that louse up the From:
line, and the way that mailx louses up my outgoing domain format addresses!

-- 
Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741
8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA
UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp
ARPA: ndmce!tp@seismo.css.gov   CSNET: ndmce!tp@smu

In article <3232@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes:
>[much removed] and now mail from DEC to a UUCP domain
>is forwarded properly, as Phil points out - in his case via Sun.

Ah, but it doesn't recognize that there already is a direct connection
between decwrl and amdcad that works quite well, thank you..  Why make
an extra hop?  Wasteful!

>The extra hop should be transparent and quite fast, since it goes
>over the ARPANET from decwrl to sun. 

Sorry, but that isn't always the case.  Decwrl, while on the Internet,
isn't on the Arpanet, it's on the Milnet.  Sun hangs off of one of SRI's
internal networks and those networks get routed through the Arpanet, which
means you have to go through one of the damnable Arpanet/Milnet gateways.

In the best of all possible worlds, the packets would go through a very
nearby gateway (um, SRI may have an arpa/mil gw but I don't think so) such
as LBL (Lawrence Laboratory, Berkeley) but the EGP data that has been flying
around these days might force their packets to go through (ugh) bbn-milnet-gw
which is way the hell out on the east coast (you have to get your money 
changed when you go out there an everything!).
-- 
Why have keyboards gotten so horrible in recent years?  The \i\b\m-\p\c
has become an \'\industry \standard\' and the vt200 is an <i<s<o standard.
Ick.  Give me back my vt52 keyboard!

Andrew Scott Beals, {lll-crg,decwrl}!amdcad!bandy

In article <4071@nsc.NSC.COM> tron@nsc.UUCP (Ronald S. Karr) writes:
>In article <14237@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes:
>>What I liked to do a lot of was to take an address like
>>fred@site.dec.com and ship it off to decwrl to handle with
>>decwrl!fred@site.dec.com.  Now smail says "ah, @ takes precendence".
>>How am I supposed to dump addresses on a smarter site like decwrl now?
>
>Decwrl seems to do this just fine if you use an address like:
>
>	decwrl!site.dec.com!fred

	fred@site.dec.com@decwrl

Will also work nicely.  Anytime you need to sneak syntax by smail
that would normally be altered, use the above example.

--Bill

In article <4070@nsc.NSC.COM> tron@nsc.UUCP (Ronald S. Karr) writes:
>
>I believe that a somewhat standard system of cost figuring that took
>into account poll rate, line cost, line capacity, system reliability
>and size, and (possibly) distance, would, if adopted by enough system
>administrators, yield a much more reliable path database.
>
>Another parallel possibility here is to give a cost to a host that
>indicates a _through_ cost, which would raise the cost for routing
>_through_ a site as opposed to routing _to_ a site. 

I too believe that with the growth of the net a more effective cost scheme
should probably be considered. The current system is so arbitrary that mail
often jumps all over the place using "cheap" routes, which results in certain
hub system (i.e. ihnp4) to be overloaded. The end result is cheap, but slow
mail and a lot of frustration for all. 

By the way (minor flame here), how come everybody and their dog claims to
have a DEMAND or DIRECT connection to ihnp4? Is it any wonder poor ihnp4
is totaly buried in mail?

Perhaps some sort of binary ored cost mechanism would be a more effiecent
system. This has the advantage that few changes would need to be made
to pathalias to invoke it. Something like the following could be considered:

	  1	Dedicated Line
	  2	Direct (Demand) Connect
	  4	Polled System
	 10	LAN
	 20	High Speed (>9600 baud)
	 40	Low Speed  (<9600 baud)
	100	Local System (<100 miles)
	200	Short [sic] Haul (<1000 miles)
	400	Long Haul (>1000 miles)

One advantage to a system like this is that it can take geographical proximity
into account. It could also be much less arbitrary as far as the cost value
associated with a particular link. Of course the system administrators would
have to stay honest for this to work.

Obviously this is only an idea to kick around. Please, no nasty abuse about me
posting a half baked idea... I'm making this up as I go along. It's only meant
to be food for thought. 

I'd like to hear your thoughts on the subject. Don't mail them to me though,
post them so we can get some global feedback. Besides, I am NOT volunteering
to rewrite pathalias or anything. There are lots of people out there who are
much better qualified than I to take on an evdevor such as this.

Cheers-


-- 
Eric D. Christensen		      UUCP:   ihnp4!sun!altos86!altnet!edc
                                      AT&T:   (408) 433-3614	
Altos Computer Systems  	Snail Mail:   399 West Trimble Road
Customer Support Division                     San Jose, Calif. 95131 USA

In article <1286@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes:
>OK - here's one:
>
>	It would be nice if smail could handle aliases. 
>

Here is a quick fix, if you can configure it for your system. I set my mailers
up to call the following shell script rather than smail. It does aliasing and
then passes the new address list to smail. It doesn't nest aliases, and it
treats them as case insensitive. The alias file is named /usr/lib/uucp/Aliases
and has the following format:

alias:<TAB>address

Where of course <TAB> is a real tab. An alias is a list of one or more
addresses, where an address is either something you can pass to smail, or
a '|' followed by a program invocation. In the latter case, there is one
caveat, no spaces are allowed. However any '#' characters will be translated
to spaces before the command is executed. Program invocations and mail 
addresses can be mixed.

I set mailx to use this directly, and set the binmail program that comes with
smail to call it rather than smail. I also am lucky enough to be able to
change the PATH that uuxqt uses, so I but this in my local bin directory
and call it rmail, and I get alias handling on incoming mail as well. It has
been working here for a month or so at least.

This is just a quick hack, and if anyone makes any improvements, please
send them back to me.

---------------- cut here, and watch the .signature ---------------
: Mail aliasing script. Please send any comments or improvements to:
: Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741
: 8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA
: UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp
: ARPA: ndmce!tp@seismo.css.gov   CSNET: ndmce!tp@smu
: UUCP Domain based: tp@ndmce.com
dest=""
list=""
plist=""
STDIN=""
Aliases=/usr/lib/uucp/Aliases
for name in $*
do
   if grep -i \^${name}: $Aliases >/dev/null
   then
      dest="`grep -i \^${name}: $Aliases|cut -f2-` $dest"
   else
      dest="$name $dest"
   fi
done
for name in $dest
do
   case $name in
   \|*) :
      plist="$name $plist"
      ;;
   *) :
      list="$name $list"
      ;;
   esac
done
if [ "$plist" ]
then
   STDIN="< /tmp/rmail$$"
   cat >/tmp/rmail$$
   for name in $plist
   do
      cmd=`echo $name|cut -c2-|tr '#' ' '`
      eval $cmd $STDIN
   done
fi
if [ "$list" ]
then
   exec /l/bin/smail $list $STDIN
fi
if [ "$STDIN" ]
then
   rm -f /tmp/rmail$$
fi
---------------- cut here ---------------------

Here are a few pieces from my alias file, by way of example.
The TP alias allows me to get mail to tp, TP, Tp, or tP, as this is
case insensitive. As there is no nesting, this doesn't cause a loop.
As you see EVERYTHING coming in gets aliased, so this script has been used
a lot, and is stable. I've tested the program forwarding, though I don't have
any real examples. The one below is concocted for illustrative purposes.

---------------- cut here ---------------------
Poot:	tp
postmaster:	tp
root:	tp
Terry.F.Poot:	tp
Terry.Poot:	tp
Terry:	tp
TP:	tp
TP14:	tp
usenet:	tp
uuadm:	tp
uucp:	tp
prog:	|/l/bin/prog#arg1#arg2#arg3
-------------  cut here -------------------
-- 
Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741
8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA
UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp
ARPA: ndmce!tp@seismo.css.gov   CSNET: ndmce!tp@smu

In article <32@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes:
>Quite often I have large pieces of mail shipped all over the country.
>From Boston to Miami to Denver to Canada [back] to Miami then to San Jose.
>Even though I specify a direct path (quick and fast), all it takes is
>one smail site to reroute the message BACK across the country ... and two
>weeks later my 99K mail gets to me.

No, the problem is not with smail.  The problem is with the data which
is being given to pathalias.

The map is a description of a directed graph with weights on each edge.
All pathalias does is compute a least-cost-spanning-tree of the graph.
Since everybody which generates map data has different methodologies for
assigning the weights then it's no wonder that paths can be screwy...

Another point to consider is that in some cases it is CHEAPER to make
the cross country transfer ... communications technology has made
geographic considerations less and less and less important.  A company
(AT&T for instance) may advertise it's internal network in the map
allowing everybody else on the net to use them.  Then because of the
weights assigned to that internal link (DIRECT or HOURLY both seem
to be reasonable weights) pathalias will very likely decide to
route a buncha stuff over that link....

-- 
David Herron,  cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet
(I'm also "postmaster", "news", "netnews", "uucp", "mmdf", and ...)

"Don't put your money in South Africa -- Give it to me!" -- Cerebus

In article <649@crash.UUCP> bblue@crash.UUCP (Bill Blue) writes:
>
>	fred@site.dec.com@decwrl
>
>Will also work nicely.  Anytime you need to sneak syntax by smail
>that would normally be altered, use the above example.
>
>--Bill


Remember, though, if you're trying to get mail out over the Internet, the
above address is illegal according to RFC822, which explicitly specifies
that only ONE '@' sign be present in the address.

--Pat.

I think smail is great, we have had great success with it.  Of course,
I did spend two days studying the docs before installing it with
trepidation, and for those who just want to type 'make' and be done
with it I have no sympathy- the docs are great and with a little common
sense and some local configuration editing it might improve your mailer
situation instead of causing problems.

The questions of domains and paths is really something outside of smail,
if the maps are out of date, that's their problem, not a problem with
smail.  And explicitly specified ! paths go through unmodified in case
you don't trust the maps.  We are still sticking with .UUCP as domain for
outgoing mail for now, because I know that .Villanova.EDU as a return
path would be equivalent to /dev/null, but we can accept incoming mail
of that format.


...Rick			..{cbmvax,pyrnj,bpa}!vu-vlsi!perry
			perry@vuvaxcom.bitnet

Summary:

Expires:

Sender:

Followup-To:

Distribution:

Keywords:



Hey, I don't understand the problem.  I use smail, and really like it.
Mail sent to foo@bar gets 'routed' there.  mail sent to 'a!b!c!d' gets
pushed on the uucp mailer.	If, perchance, we don't talk to 'a' then
smail tries to build a route to 'a', if that fails, smail tries to build
a path to 'c', then 'b'.  If some other site sends mail through 'otto' then
and it is a valid path, nothing gets touched.  (i.e. we talk to the
machine 'a' in the above example), if not, then the rest of the rules
are followed.  If smail can't find your silly machine, or any other
in the path, THEN the mail bounces..

-- 

                                                    --Jim
____________________________________________________________________________
| try: {akgua,ihnp4,mirror,sdcrdcf}!otto!jim       Jim Thompson            |
| for "smart" mailers -- jim@otto.UUCP             Las Vegas Sun           |
|                                                  2551 Green Valley Pkwy  |
| <My company doesn't care what I think..>         Henderson, Nv.   89015  |
| "All of life is a blur of Republicans and meat"  (702) 454-4636          |
----------------------------------------------------------------------------

In article <1286@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes:
>	It would be nice if smail could handle aliases. 

pathalias does, so why have smail do it too?

..Bob
-- 
Bob Page,  U of Lowell CS Dept.      ulowell!page,  page@ulowell.CSNET

In article <3232@cbosgd.ATT.COM>, mark@cbosgd.ATT.COM (Mark Horton) writes:
> decwrl is primarily on DEC's ENET, and secondarily on the ARPANET.
> They consider themselves to be only tertiarily on UUCP...

This is interesting since my 1-December-1986 Usenet backbone map (published
in news.misc, last updated by spaf@gatech.edu) shows decwrl connecting
ucbvax, hplabs and decvax.

I am a Usenet/UUCP novice user (I've been following this discussion because
I'm facinated by this free exchange of information across the world enabled
by Usenet and UUCP). Now I understood that to send mail to another UUCP site,
I needed to generate a path from my site to a backbone site, then through
the backbone to a path given by the recipient. For example, if someone
says that their address is "...mcnc!xxx!yyy", I will use the following address:

	mtxinu!ucbvax!decwrl!decvax!mcnc!xxx!yyy
	|to-backbone-|-across-backbone--|to-recip

Gee, what do you know, I just used decwrl as a UUCP forwarder. This says one
of three things to me: (1) that's not how you are supposed to do intra-UUCP
mail (in which case, please tell me the correct way) or (2) decwrl shouldn't
be listed as on the backbone or (3) decwrl is a little closer to UUCP than
Mark indicated.

Please do not get me wrong. This is not a flame. My major flame is that
despite the mod.newuser postings and available documentation (that I've found),
conventions on UUCP are still very hard for a novice to learn. (I guess that
shows everyone's UNIX background (1/2 :->)).

===============================================================================
            Ted Marshall
            Britton Lee, Inc.
p-mail:     14600 Winchester Blvd, Los Gatos, Ca 95030
voice:      (408)378-7000
uucp:       ...!ucbvax!mtxinu!blia!ted
ARPA:       mtxinu!blia!ted@Berkeley.EDU
disclaimer: These opinions are my own and may not reflect those of my employer;
            I leave them alone and they leave me alone.
fortune for today:
Justice is incidental to law and order.
		-- J. Edgar Hoover

In article <1442@blia.BLI.COM>, ted@blia.BLI.COM (Ted Marshall) writes:
> In article <3232@cbosgd.ATT.COM>, mark@cbosgd.ATT.COM (Mark Horton) writes:
> > decwrl is primarily on DEC's ENET, and secondarily on the ARPANET.
> > They consider themselves to be only tertiarily on UUCP...
> 
> This is interesting since my 1-December-1986 Usenet backbone map (published
> in news.misc, last updated by spaf@gatech.edu) shows decwrl connecting
> ucbvax, hplabs and decvax.

You mistake Usenet with UUCP mail, which is what is being discussed.
Usenet connectivity does not necessarily mean UUCP connectivity.  As
the posting you refer to says:

     A Usenet "backbone" site is one which exchanges every (non-local) news
     article it receives with at least two other backbone sites; or which is
     the main newsfeed for a particular area (e.g., Australia) and exchanges
     news with at least one other backbone site.  ...

As I stated in another posting, a site has to make some decisions
about "preferred" protocols and go with it.  It is easier for a site
on the Internet to take any domain for which it itself is not an
authority and pass it off to the Internet handler for that domain.

Fred

decwrl is a USENET backbone site. USENET does not necessarily have anything
at all to do with uucp. We also happen to be a major uucp hub in Silicon
Valley, and we have several people who put a lot of work into making sure
that decwrl works smoothly for uucp.

I suspect that the reason Mark thinks that we think we are not a serious uucp
site is that we choose not to perform automatic routing.   We refuse to
process addresses of the form foo@baz.UUCP. This is a conscious decision on
our part, based on our observations that the automatic routing database has a
lot of garbage in it, and that it will frequently route messages into
hyperspace.

The quality of the database is improving, and we are considering making the
change to our software to turn on automatic routing.

Brian Reid
DEC Western Research
uucp, DEC E-NET, ARPAnet, CSnet

In article <7534@decwrl.DEC.COM> reid@decwrl.UUCP (Brian Reid) writes:
>
>decwrl is a USENET backbone site. USENET does not necessarily have anything
>at all to do with uucp. We also happen to be a major uucp hub in Silicon
>Valley, and we have several people who put a lot of work into making sure
>that decwrl works smoothly for uucp.
{Yes, decwrl is a major uucp hub and things in general work very
smoothly.  I am grateful for the services that decwrl provides.

>I suspect that the reason Mark thinks that we think we are not a serious uucp
>site is that we choose not to perform automatic routing.   We refuse to
>process addresses of the form foo@baz.UUCP. This is a conscious decision on
>our part, based on our observations that the automatic routing database has a
>lot of garbage in it, and that it will frequently route messages into
>hyperspace.

I would like to make a plea here. I hope I'm not carrying coal to
Newcastle; decwrl is very well run and you probably know these things
already.  But there are people who don't and I think it's an important topic.

Please, don't ever reroute uucp routed addresses of the form a!b!c.
Please don't even shorten things like a!b!c to b!c where b is a site
you know you connect to directly.  This takes away the ability to test
uucp links. And in my experience, the testability of a network is
essential to keeping it running. It also takes away the ability to
explicitly route around something known to have problems.

It is appropriate to route domain addresses such as
phil@neptune.amd.com.  In the first place, you have to. In the second
place, such addresses are fair game.

Let's try to maintain two classes of addresses, ones which are
eligible for routing and ones which should be handled strictly as
specified by the sender.

By the way, Brian, if you don't route foo@baz.UUCP, what do you do
with it? Drop it, bounce it, or something else?
-- 
 My left foot is digital, my right foot is analog. 

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

In article <929@ulowell.UUCP>, page@ulowell.UUCP (Bob Page) writes:
> In article <1286@ncc.UUCP> lyndon@ncc.UUCP (Lyndon Nerenberg) writes:
> >	It would be nice if smail could handle aliases. 
> 
> pathalias does, so why have smail do it too?

What I was referring to was aliases ala sendmail and the /usr/lib/aliases
file. I guess this has been added to smail 2.0.

WRT the request for smail 2.0 source I made, I have five people who
sent mail requesting I forward it if I get it, but nobody seems to
have it :-) Help somebody please!
-- 
Lyndon Nerenberg - Nexus Computing Corp. - lyndon@ncc.UUCP
UUCP: {ihnp4,ubc-vision,vax135,watmath}!alberta!ncc!lyndon

In article <4982@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <4070@nsc.NSC.COM> tron@nsc.NSC.COM (Ronald S. Karr) writes:
>>The greatest problem here is ... a lack of standardization on what
>>costs should be used for map entries....

>           ...  Some companies have dedicated, high-speed links
>between (say) California and New York offices.  Going from Palo
>Alto to Rochester to NYC to L.A. may be faster and less expensive
>than going from Palo Alto directly to L.A.

Thus, a well thought-out standard for computing costs should give very
low costs to direct high-capacity links, though it may be preferable to
use two short-distance direct links to get to a site rather than using
two long-distance direct links.  This last point is certainly open to
debate.
-- 
   tron  |-<=>-|    ARPAnet: nsc!tron@sun.COM
  tron@sc.nsc.com   UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron

In article <272@.altnet.UUCP> edc@altnet.UUCP (Eric D. Christensen) writes:
 >Perhaps some sort of binary ored cost mechanism would be a more effiecent
 >system. This has the advantage that few changes would need to be made
 >to pathalias to invoke it. Something like the following could be considered:
 >
 >	  1	Dedicated Line
 >	  2	Direct (Demand) Connect
 >	  4	Polled System
 >	 10	LAN
 >	 20	High Speed (>9600 baud)
 >	 40	Low Speed  (<9600 baud)
 >	100	Local System (<100 miles)
 >	200	Short [sic] Haul (<1000 miles)
 >	400	Long Haul (>1000 miles)

A useful starting point, though I would suggest adding a digit to each of these
to allow a +/-HIGH and +/- LOW on the values.  However, experimentation with
pathalias must be done to ensure that this does the correct thing.  Note that
this means that it is better to go through 350 dedicated lines than to use
one long haul line, though this may be a technicality.
-- 
   tron  |-<=>-|    ARPAnet: nsc!tron@sun.COM
  tron@sc.nsc.com   UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron

Mark Horton posted a useful message on why autorouting should be
disabled with smail.  If you are doing autorouting and you don't fully
understand the dynamics of it, you should reread his message, then go
read the code that implements rerouting under smail.

I haven't looked at smail but I imagine the algorithms used for smail
rerouting are pathalias table driven.  A proper network routing
algorithm requires near real-time connectivity information so that costs
can be computed, links declared up/down, etc. with little interference
to any given message.  Pathalias table data could be months out of date,
not to mention just plain incorrect.  The uucp network is far too
autonomous for autorouting to be done, period.

Whether it is ok to optimize (cutting out intermediaries in the
uucp-path) is debatable.  I am inclined to say it is, because a site may
have specific reasons for using a shorter path (it may be cheaper in $$
to connect to a host further down the path).  I am opposed to mailers
that rewrite the path entirely.

Unfortunately I don't have the time or energy to write a mail router,
much as I'd like to.  I have a strong interest in communications routers
(I've worked with some on the Internet) and would like to approach the
problem in our heterogeneous environment.

--gregbo

In article <4076@nsc.nsc.com> tron@nsc.UUCP (Ronald S. Karr) writes:
>In article <272@.altnet.UUCP> edc@altnet.UUCP (Eric D. Christensen) writes:
> >
> > [...edited...suggestion of binary or'ed cost system, nicely done! ]
> >
>
>A useful starting point, though I would suggest adding a digit to each of these
>to allow a +/-HIGH and +/- LOW on the values.  However, experimentation with
>pathalias must be done to ensure that this does the correct thing.  Note that
>this means that it is better to go through 350 dedicated lines than to use
>one long haul line, though this may be a technicality.

Then I would suggest that you add something like a 'max-hops' value that would
limit this kind of insanity.  You'd have to be carefull though, you don't want
to keep people from mailing to some site that only has one path to it that
happens to be one hop longer than your limit!

-- 

					Edwin Wiles
	seismo!sundc!netxcom!ewiles	Net Express, Inc.
					1953 Gallows Rd. Suite 300
					Vienna, VA 22180