Path: utzoo!attcan!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!gli.com!noloc
From: noloc@gli.com (Gil Colon)
Newsgroups: comp.mail.uucp
Subject: Mail routing
Message-ID: <1990Aug8.131135.24811@gli.com>
Date: 8 Aug 90 13:11:35 GMT
Reply-To: noloc@gli.com ()
Organization: General Logistics International, Inc.
Lines: 44

I have been hearing all the arguments for better
administration of sendmail.cf; barring end
nodes (who have improper sendmail.cf's 
information) from routing mail through my -- 
"Correctly (I think)" -- configured UUCP/Mailhost;
implementing the standards that are set forth in
RFC's from 822-11XX; actually understand all this
stuff......  :-)

I make a conscious effort to try and
assure proper mail routing to and from my machine.  I
try not to tinker to much with mail headers.  Afterall,
does not my UNIX box come with the sendmail.cf file
properly configured?

AAAARRRRRRGGGGG!  Wrong answer, but thank you for
playing..... :-)

I for one do not use pathaliasing.  I have neither
the resources and/or the time, to administer/implement this.
However I do rely on a site that does pathaliasing, and based
on who I want to talk with, determines whether or not I route
through them (so much for pathaliasing).  Simple HUH?  Well,
in actuality yes.  But, would I like to have the 200+ users I
support to have to know all the in's and out's? No.

But what I have found, is that not all sites have the latest
and/or the greatest uucpmaps.  Thereby, making "pathaliasing"
a tricky business (or so it seems to me).  Or, maybe I just
don't understand what can be benefited by making all these
front ends to mail?  It seems to me that were making a big
job out of something that appears to work well without all
the Bells and Whistles...

I guess what I am saying is, I need to fully know what I am to
gain from all this: pathaliasing, uucpmaps, smail stuff.


Gilbert Colon			UUCP: ..!rutgers!glinj!noloc
(201) 352-1500 x4302		INTERNET: noloc@gli.com

		"Where there's a will ----
       		       there is a relative...."
           		-- Treblig Noloc --