[net.mail] path aliasing for sendmail - done

tony@ecn-ee.UUCP (01/16/84)

#N:ecn-ee:16800001:000:2273
ecn-ee!tony    Jan 13 19:41:00 1984



After checking around, and finding that no one else had done it already,
I put uucp path aliasing in sendmail. I took what code I could from the
delivermail implementation. The pathalias file remains the same.

I don`t know how this relates to what the Hortons have in mind, but I
had to get something running, and I`ll be happy to install something
better when it comes along.

The first thing to be aware of is that this is UUCP path aliasing, and
not a general aliasing mechanism. This seems sufficient since UUCP is
the only domain that uses relative addressing.

It is implemented as a separate process from sendmail. The uucp mailer
description for sendmail is modified to call my program (senduucpmail)
instead of calling uux directly. The syntax is:

	senduucpmail -h host -u user

In the case I was most concerned with (locally generated mail), both
host and user will consist of a single atom. However, for mail being
forwarded elsewhere, the user part will consist of one or more host
names followed by a recipient.

Aliasing is done on the "host" part, which is replaced by the path
found in the database. For locally generated mail, this generates a
hopefully valid path to the destination machine. The net effect for
forwarded mail is that no aliasing is done unless the next machine
in the path is one that we don`t talk to directly. In that case, the
host name is replaced by a path to it. I don`t trust my database
enough to impose it on others, but if a message is doomed to failure
anyway, it seems reasonable to try to give it some help.

The letter is piped into uux and occurences of host!user in the headers
are replaced by the aliased path.

If, for some reason, a particular path MUST be used, the pseudo-host
"DIRECT" may be used to disable path aliasing. Mail to "DIRECT!path..."
is sent to "path" with no aliasing. Occurences of "DIRECT!" in the
headers are deleted.

I`ll mail source to anyone who wants it. If there is sufficient interest,
I`ll post it to net.sources. It`s only about 250 lines. Also, is anyone
out there maintaining a host database in the form required by the path
aliasing software? Ours has fallen far out of date and I`d like to get
it in shape again.

Tony Andrews
UUCP: {decvax | ucbvax} !pur-ee!tony
ARPA: ada@purdue

teus@haring.UUCP (02/03/84)

Of course it is great what you have done. I think all little things
will help in the time between good rerouting software and no routing
software at all.

A few remarks, which should not cause to much trouble in your software:
- Do not rerouting if the route sounds reasonable (that is the way mail
  is done now), i.e. recreate the rout if the connecting site is failing
  or if no rout is given (f.i. the case teus@mcvax.UUCP).
  Or when the path is too long (15 sites or something?).
- Do not give a full rout to sites who are doing the same thing.
  It saves speed, computing power, delays and is more reliable.
  So some sites should get a reliable mark or something.
I.e. only the difficult problems should be forwarded to your program,
so you donot need the DIRECT pseudo site at all.
-- 
	Teus Hagen	teus@mcvax.UUCP  (CWI, Amsterdam)