Re: transports directory

[Tom Samplonius <tom@uniserve.com>]

On Thu, 6 Jul 1995 Nicholas_Briggs.PARC@xerox.com wrote:

> I haven't had any router crashes since I added code to detect loops in DNS
> CNAME entries and MX entries.
> 
> I think that ZMailer's advantage over Sendmail is that its configuration
> language (zmsh) is easier to read and write than Sendmail's -- and Sendmail's

  I have no love for Bourne style shells.

  Now I know this might provoke quite a response (quite likely negative 
:) ):  I propose to replace the zmsh stuff with either tcl or perl.  
Both are easily embedded, are well maintained (tcl probably more so), 
have structures well suited to mail processing (perl probably more so), and 
there is lots of documentation available.  This would remove the entire 
burden of maintenance/testing of the interpreter, just link router.o with 
the most recent stable version of libtcl.a/libperl.a  

> wasn't particularly well documented (and you couldn't necessarily easily get
> the source for the version of Sendmail you were running).   Now people are
> publishing real books on Sendmail.  If there were accurate documentation on
> some stable version of ZMailer i'd be very happy.
> 
> I can't, in all conscience, tell some sysadmin who has never configured a
> mailer before "here's ZMailer; go figure what local changes you need, oh, and
> by the way, there's no accurate documentation -- just read the source".   I CAN
> tell them, "go buy the Sendmail book by XXX, and don't you dare send me any
> mail with hostnames visible or non-FQDNs"

  I'd have to agree.  I do the same thing.  I know the admin of a large 
mail system (freefall.cdrom.com, 100,000 per day) running various 
mailing lists, and I was very hestitant to suggest Zmailer.  
Eventually, he went to using Sendmail+bulkmailer (which IMO, is rather a 
kludge, and still doesn't deal with queue management), in order to deal 
with the load.  With a system this big running Sendmail, manual 
intervention is way of life for a administrater.

> I think the design of the scheduler is actually fairly simple.  There are some
> complicated data-structures (which are not well documented in the code), but
> overall the design has some elegance.   Again, documentation would be the most
> useful.
> 
> If I had the time to do a rewrite (I don't!) i'd start with a specification of
> what it was supposed to do, then how it was supposed to do it (maintainers
> documentation), then the reference manuals, then the code, and then update the
> manuals to be accurate.

  That is covered is CS 101! :) 

> Re: "I think that this was covered in CS 201!  :)  I think I can manage..."
> 
> I didn't mean to offend -- there are a lot of people who have never taken CS201
> :-(.  [Which is why Sun is starting to teach courses on "how to write
> multithreaded applications".]

  It is Hot Java hype.  Everyone seems to be having trouble porting that 
sucker.  These days, people won't accept new software technology unless its 
embedded in a web browser.

Tom