david@ms.uky.edu (David Herron -- Resident E-mail Hack) (12/14/87)
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!