🚀 go-pugleaf

Hi, folks...

I'm one of the people involved with the /usr/group/chicago CLOUT project; more
specificially, I own/operate one of the two CLOUT nodes (homebru/clout), and
have been involved in the project since its inception.  In the course of
things, I occasionally catch some of the questions/complaints, and am at the
bottom of some of the events--good *and* bad--that affect delivery, as well as
participating in the organization meetings.  As I come up with items that are
of general interest, I'd like to "share them" with you  (Note new corporate
buzz word.)  Please note that there is an official organ of /usr/group/chicago
which issued similar updates and information here; I'm the unofficial one.
Any time there is a difference of opinion expressed between my postings and
those of /usr/group, please accept theirs as gospel (and expect there'll be a
fine donnybrook at the next meeting...)

1) NEW HOMEBRU/CLOUT
====================
This is the top item that drove this posting.  I just (in the last few
weeks) fully rebuilt homebru/clout from a 3b1 running its own Unix 3.51m on
a 140Mb MFM drive, to a 386DX/33 with a 340Mb SCSI running Dell SVR4.  This
has not, unfortunately, been without some outages and mailer problems; for
this, I apologize.  The most recent gotcha occurred yesterday and part of
today.  (NOTE:  For anyone installing smail 3.1 under Dell Unix in particular,
and HDB UUCP in general--don't forget to make sure that the Grades file has
an entry for the default grade issued by smail.  It doesn't default to a low
grade or anything so nice; it rejects the job.)

At this point, I believe the system is stable; please give it two or three
days for any problem messages to clear, then please let me know if you
experience any problems that seem to originate on homebru/clout.  As usual, 
postmaster@clout.chi.il.us is the first-line for reporting problems, so simply
CC to me as ignatz@homebru.chi.il.us if you feel it's in my baliwick.

2) NET MAPS
===========
Recently, the administrator of a well-connected and heavily used CLOUT client
received a complaint from one of the other CLOUT clients, to the effect that
they figured that his system was redirecting mail to their site.  Why?  Their
mail was being routed to a site in *California*!

Examination of the problem proved this wasn't the issue.  Rather, there's a bit
of confusion out there concerning what should or should not be submitted to the
UUCP Mapping Project for CLOUT clients.  The rules are actually fairly simple:

1) Normal CLOUT clients do NOT submit a map entry.  They are described in the
   CLOUT map, and only there.  Subsequently, all mail directed to any
   machine in the chi.il.us domain will end up at CLOUT, which knows
   how to forward to that machine.

2) IF you need to submit a map--for instance, you have connections
   other than just your link to CLOUT, and you wish to advertise them
   to the world--you should only list a fully qualified domain name on
   the line where you declare your connections, i.e.:

   (a)
   homebru.chi.il.us	vfrot(DAILY), chinet(DEMAND), etc.

3) DO NOT EQUATE YOUR MACHINE NAME WITH THE FULLY QUALIFIED NAME
   UNLESS YOU'VE RECEIVED ASSURANCE FROM THE MAPPING PROJECT THAT YOUR
   NAME IS UNIQUE!  In fact, don't even trust this--scan the entire
   map database to make sure the name you've chosen isn't declared
   by some other site!!

   An example of this follows (the machine name has been changed to
   protect me from being yelled at by the real machine owner):

   (b)
   foobar = foobar.chi.il.us
   foobar	homebru(HOURLY), etc.

In the problem case mentioned above, it turned out that some site
in California advertised a link to a machine named 'foobar', that
had no map entry of its own.  Since 'foobar' was equated to
'foobar.chi.il.us', as in example (b), despite the fact they had a
unique address in the message header, they suddenly were equated with
the machine half a continent away.  This wouldn't have happened if
they gave the fully qualified name as in example (a).

The CLOUT Administration Group will, in the future, perform
periodic audits of their clients, at least, to catch problems like
this; but this advice applies to ANYONE who submits a map.

3) NETWORK ROUTING
==================
In another case, the administrator of a CLOUT client machine
complained somewhat bemusedly that despite the fact that he *knew*
that the CLOUT node to which he was attached, at the University of
Chicago, was directly on the Internet and could drop mail right at the
(virtual) door of 'uunet', any mail originating on his system for
uunet took a circuitous route through 'mcdchg' and about 4 other
machines.  Why?

The problem in this case was the fact that he was running a full map
database on his machine.  The CLOUT machine at the University of
Chicago runs smail 3.1, and 'knows' that it has several means of
delivery, including SMTP over the Internet.  His machine knows nothing
that isn't in the UUCP maps, and the costs associated with those maps
don't reflect direct Internet links.  The solution in his case--and in
the case of any CLOUT client in a similar situation--is to replace the
full paths database with a truncated database reflecting his first-hop
UUCP neighbors, and to declare their CLOUT machine to be a 'smart
host'.  This is supported in smail 2.5, smail 3.1, ELM, and various
other MTA/MUA combinations.  Thus, any address to which your machine 
has no direct link will be passed to the CLOUT node, which will
attempt to deliver first over the Internet, then as indicated by its
copy of the PATHS database.

This has two advantages for the CLOUT client.  First, large chunks of
convoluted address paths can be eliminated, as all machines on the
Internet are effectively one hop away from each other.  Secondly, the
not-inconsiderable overhead--in both disk space, CPU cycles, and
administrator time--of maintaining a private copy of the paths
database is handed off to the CLOUT project.

An alternative scheme, should you need to use a local copy of the full
database, is to use smail 3.1 and create a second UUCP entry in your
routers file.  Preceed the general UUCP paths file with a custom local
copy that advertises known Internet hosts as **very** cheaply
connected, and you link to the CLOUT host as even cheaper.  In this
manner you can force direction through the Internet.


Hope this has been a useful bit of information...if I hear that nobody
liked it, I'll stop wasting your time.  Otherwise, I'll do it again as
I come up with interesting happenings.

		Dave Ihnat
		ignatz@homebru.chi.il.us (preferred return address)
		ignatz@chinet.chi.il.us