🚀 go-pugleaf

I wrote the following in answer to a question from that fella at
U of Toronto whose first name is Rayan (last name Zachary maybe?).

It was written with a mail-system expert in mind so I've done
very little explaining of terms.

> Btw, I'm writing a mailer capable of replacing sendmail/mmdf/etc. (supposedly
> for GNU, we'll see), and remember you as an MMDF fan. Why? What do you need
> (or want) to see in a mailer? Would you be willing to comment on documentation
> or code?

Mainly I like MMDF because I was able to come up with a configuration for
it and wasn't able to come up with one for SendMail.  That says *something*
about MMDF ....

Fortunately it turns out to be much nicer also.

um, gnu ... ok, you're going to be logged in all the time running gnu
so that your smtp server will be running all the time?  or do you
mean using gnu as your user agent?  and something else as the smtp
server?

[He sent back a response saying something about me being silly and
 that he meant GNU the OS, not GNU the overbloated text editor ... ]

anyway ...

The things which turned out to be really nice about MMDF ..

1. It does fairly nice rewriting of headers.  Domain table entries
   go something like

	dom.ain:dom.ain
or	dom:dom.ain		(if the table is attached to domain "ain")

   The right-hand-side (RHS) of the table entries is taken to be
   the Official Name for the machine.  If you have a header saying
   a host-name which EXACTLY matches a LHS then the host-name
   is re-written to match the value in the RHS.

   This trick is what lets our mail look like it came from "ms.uky.edu"
   even though there isn't a machine anywhere named "ms.uky.edu".

2. It's pure RFC-822 internally.  You don't have this silliness with
   a "From " line, for instance...  It also makes some warnings when
   it see's things that are questionable.  That kinda prods people
   to fix things when they see it.

3. The way that domain tables are, you can have people give short-hand
   in the domain-part of their addresses.  Like here I can say "engr"
   and it will come out as "engr.uky.edu" which is a group of machines
   across campus from us.  This is real handy.  The way this works
   is that I have a table attached to the domain "uky.edu".  In that
   table is an entry saying "engr" which gives a route over to their
   gateway machine.

4. If you have a domain entry which doesn't fully match the domain-part
   you're trying to find information for, i.e. you're trying to find
   information for "m.ecc.engr.uky.edu" and can only find "engr.uky.edu".
   A route is automatically routed through "engr.uky.edu" as with:

	@engr.uky.edu:user@m.ecc.engr.uky.edu

   I use this for a number of things, for instance I have stuff in my
   tables to route all berkeley.edu traffic through ucbvax.berkeley.edu.
   This is with a top-level domain table entry like:

	berkeley.edu: ucbvax.berkeley.edu

5. It's real real easy to know that certain domains are to be routed
   through a certain place.  For instance, that berkeley.edu line above
   really reads:

	berkeley.edu: ucbvax.berkeley.edu, g.ms.uky.edu

   because g.ms.uky.edu has a table made from HOSTS.TXT.  Another case
   is the uucp domain.  I have the uucp domain table on 3 of our
   machines, but only one of them is attached to uucp.  The other
   two have their entries as "host:host.uucp,g.ms.uky.edu".

6. The model is very nice.  Mail comes in and out of MMDF through
   particular channels.  Attached to a channel are hosts which you
   can reach through that channel.  A host can appear in more than
   one channel, and the one that will be used is the first one it
   finds.  It can use second (and following) ones in certain cases
   but I won't talk about that right now.

7. There are (at least) two special channels.  One is the badhosts
   and badusers channel.  If you have a piece of mail going to a user
   or host that isn't known, the mail will be forwarded to a host
   which is known to the channel.  This allows me to have tiny tiny
   configurations on most of our machines and they forward mail on
   to the main machines.  Very simply too.

   The other nice channel is meant for mailing lists.  You set up
   a pseudo-host ("list-processor" is suggested) which listed only
   in the table entry for the list channel.  Then for the mailing
   list you set up aliases like:

	list: list-outbound@list-processor
	list-outbound: :include:file
	list-request: someone
	list-owner: someone

   Sending mail to the list will cause it to be sent to host 
   "list-processor", which is really on the local machine.  But 
   because of this linkage, the list expansion is done in the 
   background and the user is able returned almost immediately.

   ALSO ALSO ALSO ... the MAIL FROM:<> stuff in the smtp conversations
   (and the "From " line in uucp based mail) is set to list-request
   which ensures that error messages go back to the maintainer
   of the list rather than the list itself.  This is very very very
   nice... (except to those maintaining the list, but that's another 
   point entirely :-)).

8. Authorization.  I don't really understand this feature, but if
   you enable it, it looks like you can control fairly explicitly
   who can and cannot send mail through certain channels.  Or many
   other combinations of sending/receiving mail.  But I haven't
   managed to figure this out, and it isn't very necessary at
   the moment that we use this.

   This is what I meant earlier by saying that mail could go through
   secondary channels sometimes.  If authorization fails on a 
   channel, and the host is mentioned in another channel, then the
   mail can go through that channel ... assuming that authorization
   works for the second channel too.  You can also be nicer than
   just disallowing access, you can instead send a warning message
   and allow the mail through.  This allows you to phase in
   changes (a la, the change of sending mail to ac.uk where they've
   had it configured to send warnings and will eventually cause it
   to bounce messages).

9. Mail delivery is very flexible.  You can specify a while bunch of
   options to occur whenever a mail message is delivered.  It can
   match against the values of certain headers, and a few other
   things.  It can pipe the message into certain programs, cause
   it to be discarded (i.e. bozo filter), and any number of things.
   There's a facility which allows you to send/receive files from
   yourself via mail, which I haven't looked at the manual pages
   for and even though that sounds fairly dangerous it probably
   is actually safe :-).

   example ... my .maildelivery:

	default	-	pipe	R	/usr/mmdf/rcvmail/rcvalert $(size)

   The mh system has a similar gadget ...

I can't think of anything more right now...  hope this helps
-- 
<---- David Herron -- The E-Mail guy            <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- Winter health warning:  Remember, don't eat the yellow snow!