essick@uiucdcsb.UUCP (11/19/84)
Here are the University of Illinois, we've avoided modifying sendmail to do UUCP routing. Instead we changed the sendmail definition of the UUCP mailer to point to a program which does path expansion. Our path expanding program gets a user list and a UUCP host, looks in our path tables (/usr/local/lib/usemap) and builds a proper uux invocation. Sendmail's configuration file can be frozen to improve performance and the path file can be updated without worrying about re-freezing the sendmail file. This scheme does cost us in some respects. If a letter is destined to a number of users and the first hop for all of them is the same, we send multiple copies over the wire. This is because sendmail sees that each letter is destined for a different site and makes separate calls to the uucp mailer for each letter. (Actually, we don't even combine UUCP letters when the desination site is the same. This is mostly because the path expander only expects a single desination user and I'm too lazy to rework it to accept more. Sufficient interest in this filter will result in its being posted to net.sources.... -- Ray Essick, University of Illinois
mark@cbosgd.UUCP (Mark Horton) (11/21/84)
One piece of software being developed by the UUCP project is similar to what Ray Essick describes - a routing back end for sendmail. (Our current program is called uudom because it has some understanding of domains.) Note that sendmail does have a flag to batch several recipients with one invocation of the back end, so you only have to copy the file once. This is hard to use when the decision about who the next hop is rests with the back end, but if the back end is capable of splitting recipients up, it can be used. Our program does this splitting. While not modifying sendmail is a goal of ours (mainly for those sites with binary licenses) we suspect a few mods will be necessary to keep the From: line straight. These mods will be static, as will the sendmail.cf file itself. Mark Horton
kre@mulga.OZ (Robert Elz) (11/27/84)
I also have such a program, its called uumail (for the obvious
reason), it also handles multiple destinations. It doesn't
handle domains, as at the minute I have no real idea what
the uucp domain system is finally going to be like.
Its not in use here yet, as I don't have accurate enough maps
to let it loose upon - some of the routes I've tried it out
on are absurdly long (mostly because of the missing AT&T section,
but that will come soon). It uses data generated by pathalias.
My aim is to allow people in Australia to forget routing completely
(we already do internally) and do all the work at mulga.
Robert Elz decvax!mulga!kre
ps: really, its easy to make sendmail.cf files give the backend
mail for lots of hosts, you just do something like ...
R$*@$-.uucp $#uucp$@fakehost$:$2!$1
in ruleset 0, then define the "uucp" mailer 'm' flag, and give
its args without $h anywhere (which would always be "fakehost"),
$u contains all the needed info. If the mailer returns an
error (unknown host, or route, or something) you get to
see "fakehost" in the sendmail transcript that's mailed
back, but a little imagination can easily produce a nicer
word to use there (that's its only use really). "destination"
is a possibility ("Connecting to destination.uucp ...")
"router" is another. Given that the mailer name is also
not seen externally in any other place, calling the host
"uucp" and the mailer "router" would produce
Connecting to uucp.router
which wouldn't be at all bad.kre@mulga.OZ (Robert Elz) (11/27/84)
I also have such a program, its called uumail (for the obvious
reason), it also handles multiple destinations. It doesn't
handle domains, as at the minute I have no real idea what
the uucp domain system is finally going to be like.
Its not in use here yet, as I don't have accurate enough maps
to let it loose upon - some of the routes I've tried it out
on are absurdly long (mostly because of the missing AT&T section,
but/that will come /oon). It uses /ata generated by pathalias.
My aim is to a/low people in A/stralia to /orget routing c/mpletely
(we alzeady do interna/ly) and do all the work at mulga.
Robert Elz decvax!mulga!kre
ps: really, its easy to make sendmail.cf files give the backend
mail for lots of hosts, you just do something like ...
R$*@$-.uucp $#uucp$@fakehost$:$2!$1
in ruleset 0, then define the "uucp" mailer 'm' flag, and give
its args without $h anywhere (which would always be "fakehost"),
$u contains all the needed info. If the mailer returns an
error /unknown host, or route, or something) you get to
see "fakehost" in the sendmail transcript that's mailed
back, but a little imagination can easily produce a nicer
word to use there (that's it/ only use really). "destination"
is a possibility ("Connecting to destination.uucp ...")
"router" is another. Given that the mailer name is also
not seen externally in any other place, calling /he host
"uucp" and the mailer "router" woul/ produce
Connecting to uucp.router
which wouldn't be at all bad.gnu@sun.uucp (John Gilmore) (11/28/84)
I have been wondering about a side of this question that nobody has answered yet. We all have little sendmail tricks for routing, but I haven't seen a method of RECEIVING the map data and generating the routing database that doesn't involve a lot of hand tweaking. Each posted map article seems to have yet a different format for the data, plus varying amounts of text on the front and end that confuse "shar", "par" and other such schemes. It looks like the articles mostly contain shell archives containing a Berkeley archive per state which then contains a file per site which you then have to unravel, unroll, and unpack before you can do anything with them anyway. If I was writing the routing database builder I'd want one large input file with all the sites in it, rather than having to read fourscore files with random names, unpacking archives as I went. On the other hand, for updating the routing data I'd want per-site access, without necessarily having to know the state/province the site was in. Something like a dbm database indexed by sitename would do both. Has someone built a shell script that I can have call from /usr/lib/news/sys with a line like "map:mod.map::shellscript" that will maintain some kind of sitename info database automatically? Such a database could be used for readnews and inews too, e.g. "Where *is* this site anyway?".
brad@bradley.UUCP (11/29/84)
For people interested, I took the uupath, and filter programs
from UofI (uiucdcs) and made them run on a 11/44 2.9BSD. The neat
thing about this is that you can generate your own maps without
having to have someone else make them for you. Note VAX versions
do everything in memory.
Bradley Smith UUCP: {cepu,ihnp4,noao,uiucdcs}!bradley!brad
Text Processing ARPA: cepu!bradley!brad@UCLA-LOCUS
Bradley University PH: (309) 676-7611 Ext. 446
Peoria, IL 61625piet@mcvax.UUCP (Piet Beertema) (11/30/84)
>I have been wondering about a side of this question that nobody has >answered yet. We all have little sendmail tricks for routing, but I >haven't seen a method of RECEIVING the map data and generating the >routing database that doesn't involve a lot of hand tweaking. What do you mean by "a lot"? If saying "s | mapfilt" on every map article received and saying "make map" after all maps have been received is in your opinion a "lot" of hand tweaking, I can't help you. If it's not, drop me a mail and I'll send you our routing package. -- Piet Beertema, CWI, Amsterdam ...{seismo,decvax,philabs}!mcvax!piet