[Comp.Sci.Dept, Utrecht] Note from archiver<at>cs.uu.nl: This page is part of a big collection of Usenet postings, archived here for your convenience. For matters concerning the content of this page, please contact its author(s); use the source, if all else fails. For matters concerning the archive as a whole, please refer to the archive description or contact the archiver.

Subject: The MMDF Frequently Asked Questions List (FAQ)

This article was archived around: 5 Nov 1998 07:30:07 GMT

All FAQs in Directory: mail/mmdf-faq
All FAQs posted in: comp.mail.misc, comp.unix.sco.misc
Source: Usenet Version


Archive-Name: mail/mmdf-faq/part1 Version: $Id: mmdf,v 1.11 1998/11/04 22:37:32 jsweet Rel $ Posting-Frequency: monthly X-Comment: There is only one part to the MMDF FAQ at this time.
============================================== The MMDF Frequently Asked Questions List (FAQ) ============================================== Overview -------- This is the Frequently Asked Questions document about MMDF, the Multi-channel Memo Distribution Facility, a popular mail transport agent (MTA). Table of Contents ----------------- 1) Introduction 1.1) Conventions 1.2) Where can I get the MMDF FAQ? 2) What is MMDF? 2.1) How MMDF is used 2.2) Where to get MMDF 2.3) A brief history of MMDF 2.4) Glossary 3) User-Level Questions 4) Administrator-Level Questions 5) Miscellaneous Questions and Gotchas 6) An MMDF Bibliography 7) Other Resources 7.1) Free Software 7.2) Commercial Software 8) Authorship 8.1) Acknowledgements 8.2) Permissions -- 1) Introduction --------------- 1.1) Conventions - Direct quotations begin with an attribution in a standard format, and are indented by four spaces. - Pointers to resources available via the Internet, such as references to FTPable goodies, appear in WWW URL format. URLs beginning with "ftp:" refer to FTP sites. For example: ftp://domain.name/path/to/package Those with FTP access, but without WWW access, may treat such references as follows: 1. Log into host domain.name using anonymous FTP 2. Look for /path/to/package An FTP reference usually lists only the distribution site; please try your nearest FTP archive first. Archie may be of some help here. Here is a brief summary of some common URL prefixes: http: refers to a WWW server gopher: refers to a gopher server ftp: refers to an anonymous FTP server mailto: refers to an Internet e-mail address news: refers to a USENET news group Internet browsing tools, such as Mosaic, know about URLs. - You'll occasionally see text in braces, like this. { Here is some example meta-text. } Sometimes, this indicates a place where information is missing, or where the information may be unreliable, or where major changes are planned in the near future. You can ignore these if you're just looking for information. But if you can help fill in the gaps, and you want to achieve fame, fortune, and your name at the bottom of this FAQ, please send e-mail to the maintainer. -- 1.2) Where can I get the MMDF FAQ? - The MMDF FAQ is posted monthly to the MMDF2 mailing list (mailto:mmdf2-request@a.cs.okstate.edu) and to these USENET newsgroups: comp.mail.misc, comp.unix.sco.misc, comp.answers, and news.answers. An archive source for old MMDF2 list messages is available at this URL: http://www.irvine.com/~mmdf - Many sites archive news.answers postings, including these: ftp://ftp.uu.net/usenet/news.answers/mail/mmdf-faq/ ftp://rtfm.mit.edu/pub/usenet-by-group/news.answers/mail/mmdf-faq/ If possible, please try to find a closer site; for example, by asking archie for "mmdf-faq". Alternatively, use WWW search engines to look for the MMDF FAQ. - HTML versions of the MMDF FAQ may be found at these URLs: http://www.cs.ruu.nl/wais/html/na-dir/mail/mmdf-faq/.html http://www.irvine.com/~mmdf/mmdf.html - If you are reading this FAQ via some fixed medium such as hardcopy or CD-ROM, please try to obtain the latest edition from the net instead. - There is also a Supplement to the MMDF Frequently Asked Questions List at this URL: http://www.irvine.com/~mmdf -- 2) What is MMDF? ---------------- MMDF is the Multi-channel Memo Distribution Facility, a popular mail transport agent (MTA) for UNIX. Strong points of MMDF include: - Native user-level mail delivery control (".maildelivery"). - Ability to turn up and down logging/debugging levels on the fly. - Authorization and permission checking. - Mail blocking based on from whom it came, how it got there, and to whom it is going. - Modularity: it's relatively easy to add new transport and translation channels for special e-mail gateways. - High capacity: it's designed to process very large message flows and can efficiently handle very large message queues. MMDF may have special appeal to persons in the UK, in that MMDF knows how to handle mail addresses in the UK-endian order, e.g. "edu.okstate.cs.a", as well as in the more widespread format, e.g. "a.cs.okstate.edu". MMDF is the standard mail system on at least one UNIX implementation, SCO UNIX. However, MMDF does not enjoy deployment as widespread as some other MTAs, such as sendmail. This is partly because, as Marshall Rose says in his book, _The Internet Message_, MMDF suffers from a tyranny of complexity: it requires configurations of many different files and daemons. In contrast, sendmail uses one daemon and one central configuration file. Sendmail, on the other hand, has its own set of disadvantages, and in many (if not most) implementations sendmail is not nearly as correct, secure, modular, or robust a message transfer agent as is MMDF. Sendmail was once compared by one old Internet hand to "those killer bees that escaped from the laboratory--and now they're everywhere and you can't get rid of 'em". Sendmail is still widely disparaged by experienced mail system administrators, although perhaps less deservedly so now than in the past. -- 2.1) How MMDF is used MMDF works on the principle of passing messages between incoming and outgoing communications channels. In MMDF, a channel is typically implemented as a program for accepting messages from a Mail User Agent, say, via SMTP, or for delivering messages to a local mailbox file or to another host. (In sendmail parlance, these are called "mailers".) MMDF is typically run by starting up a set of persistent daemons named "deliver", each daemon managing delivery to a different channel, or to a set of channels. Other daemons are also involved, such as "smtpd", which monitors the SMTP port, and arranges for submissions and deliveries via SMTP. Here is a UNIX "ps" snapshot of MMDF processes running at a relatively simply-configured Internet site, including SMTP, POP, "delay", "local", and "list" channels, as well as one local relay channel named "laurel": UID PID PPID C STIME TTY TIME COMMAND mmdf 8306 1 0 Jan 16 ? 0:07 lib/deliver -b -T120 -clocal mmdf 154 1 0 Dec 8 ? 0:11 lib/deliver -b -T120 -csmtp mmdf 155 1 0 Dec 8 ? 2:34 lib/deliver -b -T120 -cpop mmdf 156 1 0 Dec 8 ? 0:13 lib/deliver -b -T120 -clist mmdf 157 1 0 Dec 8 ? 0:10 lib/deliver -b -T120 -claurel mmdf 8338 1 0 Jan 16 ? 0:02 lib/deliver -b -T300 -cdelay root 152 1 0 Dec 8 ? 0:44 chans/smtpd -n 16 chans/smtpsrvr smtp,local Channels are managed by a set of configuration files, aka "tables", one or more per channel. Address rewriting is done according to a set of compiled-in rules, configured by each channel's table. The table formats themselves are relatively simple; understanding their effects may not be so simple. Because the stock version of MMDF's documentation was written when the Internet DNS was brand-new, it is somewhat vague or diffuse on the subject of specific configurations for typical modern Internet e-mail sites. The closest match to a typical Internet site's configuration in the MMDF 2.43 source release is in the samples/bbn directory. The current MMDF source release is otherwise tragically short of working configuration examples for use in today's Internet, in which DNS lookups may time out or provide bad information, maildrops may exist on temporarily unavailable NFS-mounted directories, and where other gotchas may provide general interference in the smooth operation of your mail system. This FAQ is one place to find help. Appeals to the MMDF2 list can also yield helpful information. Your best bet for understanding how to set up MMDF is to look at the sample configurations and an already-running configuration. Reading all of the available documentation is also a must (see the doc/ subdirectory in the MMDF source distribution). See also section 6 of this FAQ for a list of other materials. -- 2.2) Where to get MMDF At present there is no central authority that coordinates new releases of the publicly available MMDF source tree. However, the nearest claimant to being the official, latest, MMDF source release is version 2.44 from Universitaet Kaiserslautern. The previously generally recognized baseline release of MMDF was version 2.43 from Oklahoma State University, described below. SCO's version of MMDF for SCO Unix is proprietary--i.e. you can't get the source code for it. However, there have been some hints that SCO might someday release their modified MMDF sources to the world after some possibly proprietary or copyrighted elements from SCO's Microsoft-related era have been removed. The following is a list of publicly available source trees for MMDF. ---- What: MMDF 2.44 from Universitaet Kaiserslautern Where: http://www.mathematik.uni-kl.de/ftp/pub/Sources/mail+news/mmdf/mmdf-2.44a.tar ftp://www.mathematik.uni-kl.de/pub/Sources/mail+news/mmdf/mmdf-2.44a.tar Comments: This version is based on the work-in-progress MMDF (2.43+) source tree from Oklahoma State University. [ Kai Krueger <krueger@mathematik.uni-kl.de> 2-June-1998 ] MMDF II rel. 44 is now available for alpha testing since June 1st. This release mainly consists of cleanups. But there are also some new features that were important at our site. - configure may now be used for setting system dependent compile time options. These have been changed to feature dependent switches. - Files which existed in multiple versions ,like e.g. src/smtp/smtpd.*.c, lib/table/tb_ns.*.c, lib/util/lk_lock.*.c, have been cleaned up. - support for header lines longer than 256 characters - 8-bit clean transfer of E-mails (compile time option, default: on) - removal of routing information in the envelope "mail from:" lines (compile time option, default: on) - use of the tcpd/identd-package, if libwrap.a and tcpd.h exist (compile time option, default: on) - possibility to use gdbm, if dbm and ndbm are not available. Of course you can always use sequential tables, as before. - tables can now be accessed via NIS/NIS+ (compile time option, default: off) - possibility to change location of the tables mailids and users in mmdftailor (compile time option, default: off) - additional information, like e.g. real hostname, real ip-address, in the Received: line (run time option in mmdftailor) = no cleanups done on uip/ucbmail and uip/unsupported The new release has already been tested on the following architectures: + HP 9000/780 : HP-UX 10.20 (development package C compiler) + HP 9000/715 : HP-UX 9.05 (development package C compiler) + PC : Linux RedHat 4.2 (gcc-2.7.2, libc > 5.4.30) libc 4.6 - 5.3 do not work (not a problem of mmdf!) + Sun Sparc Ultra 2: Solaris 2.5.1 () + Sun Sparc 10 : Solaris 2.4 (gcc-2.6.3) We would be grateful, if some of you who have access to machines of different type of operating system would also test this release. Please send reports, bugs and comments to: krueger@mathematik.uni-kl.de ---- What: MMDF 2.43 base from Oklahoma State University Where: ftp://a.cs.okstate.edu:/pub/mmdf-2.43.tar.Z Comments: This is the previous long-standing base release of 2.43 MMDF. This was the core version of MMDF, maintained by Mark J. Vasoll, formerly Senior Software Specialist, Oklahoma State University. ---- What: the work-in-progress MMDF (2.43+) source Where: ftp://a.cs.okstate.edu:/pub/mmdfdev.tar.Z Comments: [ Mark Vasoll <vasoll@a.cs.okstate.edu> 22-Jan-1996 ] What is currently there is update 43 with some critical patches applied, such as the fix to MX handling. However, the contents are subject to change as this file is basically used by my friends on the okstate campus who help me test various pieces of the "slowly developing" update 44. ---- What: another source for MMDF (2.43?) Where: ftp://ftp.arl.army.mil/mmdf.tar.Z Comments: ---- What: Solaris 2.x port of MMDF (2.43?) Where: ftp://ftp.arl.army.mil/mmdf.sol2.2.Z Comments: [ Ran Atkinson <address omitted by request> 10-Oct-1998 ] Prior to the advent of version 2.44, this _was_ the recommended starting point for getting MMDF running under Solaris 2.x. Other sites have had good success compiling this with GCC in Solaris BSD-compatibility mode on later versions of Solaris (e.g. Solaris 2.4). The folks at ARL have helped everyone in the MMDF community for years (me in particular). However, at this point the 2.44 source tree [[described above]] is known to compile/work fine under Solaris 2.x and several other major OSs (e.g. HPUX, which is notoriously difficult to port to) ---- What: Linux port of MMDF 2.43 Where: ftp://sunsite.unc.edu/pub/Linux/system/mail/mta/mmdf-IIb-4.3.tar.gz Comments: This Linux port is fairly old and appears not to compile out-of-the-box under the newer versions of Linux. A better bet would be MMDF 2.44 from Universitaet Kaiserslautern, described above. ---- { Any other ports that are publicly available? } Contributed patches are sometimes posted to the MMDF2 discussion list. See http://www.irvine.com/~mmdf for a message archive. -- 2.3) A brief history of MMDF The following historical notes were compiled from information provided by Dave Crocker <dcrocker@brandenburg.com> and from the usual suspects. Any errors are the fault of the maintainer, so please do send us corrections or additions. For Dave's original historical note, see this URL: http://www.irvine.com/~mmdf/crocker-note.html 1976: Early morning on the ARPANET. Dave Farber and Dave Crocker work at RAND (the think tank) on "MS", a PDP-11 UNIX e-mail system project. This inspires Bruce Borden to create MH, the popular mail user agent. 1978: Dave Farber and Dave Crocker go to the University of Delaware (UDel) as professor and grad student. Grad student Ed Szurkowski writes phonenet protocol for telephone-based link-level transfer. Crocker develops MMDF to provide ARPANET e-mail connectivity over phonenet, using RAND as a relay. 1979: Experimental deployment of MMDF/phonenet by Army Materiel Command; there are claimed to be instances still running today. IBM provides some additional funding for MMDF. 1980: NSF funds creation of CSNet. MMDF I is used to link members, using UDel and RAND as relays. Others get involved: Doug Kingston (Ballistic Research Labs) and Steve Kille (University College London). 1981: Ira Winston (University of Pennsylvania) recodes MMDF I in Pascal to create PMDF running under VAX/VMS. 1982: Crocker finishes alpha version of MMDF II, which adds TCP/IP and DNS support, among other things. Mark Laubach propagates PMDF to Hewlett-Packard. 1984: Kingston, Kille, Dan Long (BBN), and Craig Partridge (BBN) complete MMDF II and release it for 4.3BSD. Julian Onions rewrites the local channel, contributes general maintenance and documentation. Phil Cockroft (University College London) adds (more or better?) DNS support. 1985: Kille uses MMDF as the basis for the PP X.400 system. Ned Freed (Oklahoma State) modifies PMDF to handle RFC-822; PMDF is released through CSNet. PMDF eventually becomes fairly widely used within the VMS community in the later 1980s. 1991: Ned Freed commercializes PMDF. { More brief history entries? } Other names and institutions appearing in the code, in no particular order: - Howard Walter -- 2.4) Glossary Every subculture needs its list of buzzwords. Here's a collection for MMDF. BIND the UC Berkeley implementation of DNS (aka "named") body the part of a message after the header (the "meat") channel typically a program for delivering mail CTE content transfer encoding (e.g. base64, quoted-printable, etc.) DNS the Internet Domain Name System (see also BIND) ESMTP Extended SMTP - RFC 1651 header the To, From, Subject, etc. at the start of a message mail transport the "post office", e.g. sendmail, smail, MMDF, etc. MMDF Multi-channel Memo Distribution Facility, an MTA MIME Multipurpose Internet Mail Extensions - RFC 1521 MTA Mail Transport Agent, see "mail transport" MUA Mail User Agent, see "user agent" PEM Privacy Enhanced Mail PGP Pretty Good Privacy RFC request for comments; proposed or standard Internet protocols SMTP Simple Mail Transfer Protocol - RFC 821 spam Mail sent indiscriminately to a large number of recipients URL WWW uniform resource locator; access-method://host/path user agent the end user's mail program, e.g. MH, ELM, /bin/mail, etc. WWW the worldwide web ---- 3) User-Level Questions ----------------------- 3.1) How can I achieve the same effect as the sendmail .forward file? Invoke the MMDF resend program in your $HOME/.maildelivery file. See also the resend(1) man page. Here is an example .maildelivery file entry using resend: default - | A "/usr/local/mmdf/bin/resend metoo@host.domain" Beware of resend's .signature file format expectations (see question 3.5). If you're an MH user, you might want to invoke the rcvdist program in your $HOME/.maildelivery file instead. See also the mhook(1) man page. Example: default - | A "/usr/local/lib/mh/rcvdist metoo@host.domain" The rcvdist program is somewhat finicky about header formats, and may reject a message if improperly formed Date or recipient address fields are present. MMDF does have a DOTFORWARD option that provides support for a file named "$HOME/.forward". [ John R MacMillan <john@interlog.com> 10-Aug-1997 ] The DOTFORWARD code allows pipes and multiple addresses in the same format as alias tables, not the sendmail format, but BE WARNED: the DOTFORWARD code has HUGE security problems. This is from memory and a quick look at the source, but I know when I first discovered this that I verified that the problems really do exist. Compiling with DOTFORWARD allows any user to overwrite any file on the system (eg. /etc/passwd) and run arbitrary programs as root. The problem is that the .forward files are treated like a little trusted alias table, which allows writing files and piped commands as any user. IMHO, DOTFORWARD should be removed from the MMDF source base, or at least cleaned up to be made safer. SCO's MMDF supports .forward files that are compatible with sendmail's, and does not use the DOTFORWARD code, and so does not suffer from these problems. { It's not clear whether the .forward file may contain a pipe command or a list of addresses to which to forward, a la sendmail. } -- 3.2) Is there a more powerful .maildelivery-like mechanism with Boolean operators and such? Yes, there are several such programs that you might invoke as a "*" or a "default" case in your .maildelivery file. Some examples (from the comp.mail.misc "UNIX Email Software Survey FAQ"): What: mailagent Where: ftp://ftp.univ-lyon1.fr/pub/unix/mail/tools/mailagent-3.0.tar.gz Comments: A set of programs to perform various e-mail sorting functions. See also: news:comp.mail.misc "UNIX Email Software Survey FAQ [Part 3 of 3]" What: majordomo Where: ftp://ftp.greatcircle.com/pub/majordomo/ Comments: Majordomo is a perl-based program for automated mailing list maintenance. [ Andy Powell <ccsap@bath.ac.uk> - 23-Jan-1996 ] I believe that there is also a patch required for the sendmail replacement if you want to use majordomo with MMDF. The patch is only required if you want to use majordomo's 'resend' script to process list messages. We run majordomo and MMDF here but use the normal MMDF list channel to process list messages - in doing so we lose some of the functionality of majordomo, for example moderated lists, but bypass the sendmail problem and, arguably, get better performance with large lists. There may also be more information available from the archives of the majordomo-users@greatcircle.com and majordomo-workers@greatcircle.com lists. In both cases send the word "help" (no quotes, put it in the body rather than the subject) to majordomo@greatcircle.com to start the process. [ Gunther Anderson <gunther@world.std.com> 5-Aug-1994 ] In getting Majordomo to work properly, I discovered a bug in [MMDF's] sendmail, as found in uip/other/sendmail.c. Basically, the real sendmail handles the -f{sender} flag differently. In standard sendmail, the -f flag changes the "From " header (the envelope From, and the Mail From: command in SMTP), and doesn't touch the "From:" header, the message From:. In RFC822 messages, these can indeed be very different from each other, and Majordomo uses them to separate ends. MMDF's sendmail stub deliberately chooses to use the -f parameter as both the envelope From and the message From:, rewriting the message From: as it goes. I removed the automatic From: rewriting from my version, and things like Majordomo are much happier. [ Gunther W Anderson <gunther@world.std.com> 24-Jan-1996 ] I posted instructions and a couple of patches to majordomo-workers year before last. These were for Majordomo 1.92, and were specifically designed to get Majordomo to work on SCO Unix. As a side effect, it also patched MMDF II 43b (the current version) to work properly. Check out the archives, and you'll find the data. See also: news:comp.mail.misc "Majordomo Frequently Asked Questions" What: procmail Where: ftp://ftp.informatik.rwth-aachen.de Comments: A set of programs to perform various e-mail sorting functions. See also: news:comp.mail.misc "UNIX Email Software Survey FAQ [Part 3 of 3]" There is also a mailing list related to procmail; subscribe by sending mail to "procmail-request@informatik.rwth-aachen.de" with Subject: subscribe. -- 3.3) How can I debug my .maildelivery file? [ Craig Partridge <craig@aland.bbn.com> 24-Jan-1996 ] I used to debug it by running the local channel by hand with "deliver -w -clocal" and then watching the output to see what .maildelivery did. The log files might also reveal some problems, for example: [ John DuBois <johnd@sco.COM> - 7-Oct-1997 ] +/usr/mmdf/log/chan.log + +10/ 7 3:36:49 local 8122: unidentified action type 0 +10/ 7 3:51:51 local 8147: Unknown action to perform 'Mailbox' This is a result of a line in a user's .maildelivery file having a bogus action field (the 3rd field). The lines preceding these in the log file should indicate the users that the messages were being delivered to (you may have to increase the logging level to get that). -- 3.4) Why doesn't my .maildelivery file work? MMDF is finicky about ownerships and permissions. Make sure that your .maildelivery file is (a) in your home directory, (b) owned by you, and (c) not writeable by anyone except you (e.g. chmod 644). See also the preceding item (3.3). -- 3.5) Why does "resend" bounce with the error "No valid author specification present"? This is caused by "resend" rejecting your .signature file. If you use "resend", then your .signature file must conform to its expectations. Unfortunately, the MMDF "resend" program has a different idea about .signature files than USENET news and most other things. Resend assumes that the .signature file contains exactly one text line, which is information to be placed in the outgoing message's From: field's full name area. [ Bela Lubkin <belal@sco.com> 7-Jun-1996 ] SCO's version of resend does not do this. It looks instead for a file called .fullname. HOWEVER, several other parts of SCO's MMDF *do* look at .signature: * rcvtrip uses it to construct some text along the lines of: "This is an automatic message, sent on behalf of %s" * v6mail [which SCO doesn't ship] uses it to create either the From: or the Sender: header (I didn't bother to tease out which it was) * ml_sender() uses it the same as v6mail. ml_sender() is called by ml_init(), which is in turn used by just about anything that delivers mail under MMDF (I think). It looks to me as if this ought to happen all the time; but I couldn't figure out how to get it to trigger even once. [ Gulraj Rijhwani <gdr@courtfld.demon.co.uk> 17-Oct-1996 ] In SCO 3.2v4.2 ... the "No valid author" error [occurred] following reconfiguration and recompilation of the MMDF table to reflect a change in the local domain. It appears that the general cause was a discrepancy between the local domain table and root domain tables. ---- 4) Administrator-Level Questions -------------------------------- 4.1) How can I arrange for a "hidden-host" effect, e.g. that outgoing "From" addresses of the form user@<host>.<domain> are rewritten simply as "user@<domain>"? [ Mark Vasoll <vasoll@a.cs.okstate.edu> - 22-Jan-1996 ] Answer #1: use the MLOCMACHINE feature (see section 5.4.1 of "Installing and Operating MMDF II"). Answer #2: use the POP channel to create a sort of "virtual host" where pop users don't need to have accounts on the MMDF host. We are doing both on the okstate campus, I'd be happy to send along config examples. It appears that MMDF won't rewrite a fully qualified domain address, even if MLOCMACHINE is set. For example, MH adds the fully qualified domain name of the local host even before the message is submitted to MMDF. Some persons consider this a feature. To prevent the FQDN from being added, you might try experimenting with the mtstailor file's "servers:" entry. Alternatively, MH may have to be compiled with the DUMB or REALDUMB configuration options. -- 4.2) How can I deliver mail to a POP mailbox? You need to set up the POP channel and an alias for each user that directs the mail to an address of the form "<popuser>@POP". See this URL for an example POP channel setup: http://www.irvine.com/~mmdf/pop/index.html Users with local non-POP maildrops may also do this for themselves by re-sending to their own POP addresses from their .maildelivery files. Note that the POP channel just handles the delivery end of the business. To enable users to retrieve mail from their POP mailboxes, you'll need to run a server daemon, such as "popd", "popper", "qpopper", "imapd", et al, that speaks one or more variants of the Post Office Protocol --typically POP-2 or POP-3--and that has a mailbox locking mechanism compatible with that used by MMDF's POP delivery channel. (Other POP variants include APOP, KPOP, and RPOP.) All of the aforementioned daemons are available via Internet anonymous FTP; use archie to search for a site that archives the sources. -- 4.3) Is there a way to make MMDF look up local hosts if DNS name service fails? [ Mark Vasoll <vasoll@a.cs.okstate.edu> - 22-Jan-1996 ] Create a channel running the 'smtp' channel program, but using a file style table. Then put IP addresses in it. -- 4.4) How can I avoid generating source-routed envelope addresses, such as @foo,bar:zot.edu? [ John DuBois <johnd@sco.COM> - 2-Oct-1997 ] A source route is used if the hostname returned by a resolver lookup on the source IP address is not the same as the hostname given in the return address, after both have been mapped through the domain tables. You might try mapping (in a domain file) each of the domains in use to the hostname returned by a reverse lookup on the host that handles that domain. Another possible way to fix this is to configure your user agent to submit mail via the SMTP server's canonical host name instead of, for example, "localhost". For example, to configure MH to do this, put the fully qualified name of the SMTP server in a "servers:" line in the mtstailor file, e.g. servers: myhost.mydomain.tld ...where "myhost.mydomain.tld" should match precisely whatever the SMTP server prints out in its 220 greeting line. If the SMTP server prints out "you are a charlatan" in response to the HELO command, then something's wrong, and your configuration is probably going to continue to generate source routes. -- 4.5) Why do I get duplicate mail sent to a mailing list? [ Dave Barr <barr@math.psu.edu> ] MMDF 2.43's list channel verifies the validity of the whole mailing list before returning from the Submit call. The thing calling Submit may time out and close, while leaving Submit itself running. The calling routine may believe that the message has failed in its delivery, when in fact the still-running Submit process may eventually succeed. The calling process tries again some time later, thus creating a duplicate. The larger the list gets, the more addresses there are to verify (verification just being a DNS search on the target machine name), and the more likely, under load, that the message duplicates. One solution is to use a different channel for submission and delivery, one which deliberately doesn't verify the addresses before accepting a job. Use the list-processor channel to check that the listname-request name is set properly (because list-processor insists on making listname-request the envelope "From " header name). Duplicate mail on Linux may be caused by the broken flock() implementation under some (<1.3.x?) versions of Linux. Avoid flock(). -- 4.6) How do I gate a list to and/or from a newsgroup? { Any examples? I know that UCI has come up with a pretty good way to do this, but their solution may not have made it back into the general release yet. } -- 4.7) How do I get MMDF to rotate its logs as documented? [ Bela Lubkin <belal@sco.COM> 19-Apr-1996 ] I think the MMDF log cycling code has never worked in any version of MMDF, so you will have to do your own external log cycling if you are having space problems. If you do your own external log cycling, be sure to configure MMDF to close the log files periodically, by using, for example, the parameter "stat=some" on the M*LOG entries in the mmdftailor file. -- 4.8) How can I bounce e-mail spams automatically? There are several policy choices, which may be implemented at the site level or at the individual level: 1. Reject all mail from any unknown sources. 2. Reject all mail from known "blacklisted" sources. 3. Reject all mail from unverifiable sources. Although we've included below a light discussion of these cases, a more wide-ranging treatment of the subject can be found at this URL: What: "Fight Spam on the Internet!" Where: http://www.vix.com/spam/ Some individuals feel that it's best simply to delete spam without comment rather than to build troublesome barriers or to complain about it. However, as the volume of spam increases, it doesn't take much to swamp the mail queues at large sites. For large sites, a site-level implementation of policy choice #2 may be necessary. Case 1: Reject all mail from any unknown sources. For individual implementations of policy choice #1, some persons employ "mail robot" programs that return polite rejection notices for mail originating from sources not on a list of acceptable addresses. Mail robots can be activated from individuals' .maildelivery files. An example of such a mail robot can be found in the Rose/Borenstein Safe-Tcl package, in the examples subdirectory: What: Safe-Tcl 1.2 Where: ftp://ftp.fv.com/pub/code/other/safe-tcl.tar.gz Comments: The example mail robot is located in "examples/receipt-time/mtr-receipt.tcl". Other persons use "procmail", which is somewhat more general purpose, to implement simple rejections for entire domains. Case 2: Reject all mail from known "blacklisted" sources. Thanks to John DuBois <spcecdt@armory.com>, we have a site-level implementation of policy choice #2. Check out his "smtpcull" script: What: smtpcull Where: ftp://ftp.armory.com/pub/admin/mmdf/smtpcull Comments: This is a very short shell script that works as a front end for smtpsrvr. It includes instructions for configuring and installing it. [ John DuBois <spcecdt@armory.com> 25-Jul-1996 ] } Next question: is it possible to do the same thing with the } built-in MMDF authorization stuff? I tried to set this up using MMDF auths. However, after reading assorted documentation and source and doing some fruitless experimentation, as far as I can tell there is a special exception for delivery via the 'local' channel; you can't prevent the transmission of a message to a local mailbox. I think the idea of MMDF auths is to prevent the abuse of your MTA by other hosts that would pass messages through it. A message being delivered to a local mailbox isn't being passed on, so it's always authorized. You could probably use auths for this purpose if all mail is handled by a central host and is passed off to other hosts were users' mailboxes actually reside. An auths-like facility would be much more useful for modern purposes if it did have the ability to restrict messages based on assorted information (with wildcards allowed for each and for e.g. entire domains rather than just hosts): - Claimed host of origin - Claimed hosts that the message has passed through - Claimed user of origin - Channel message is received via And for each recipient: - Channel message would be delivered via - Host that message would be passed to - Destination host - Destination user Case 3: Reject all mail from unverifiable sources. Invalid addresses might be one criterion by which incoming e-mail can be rejected, since many spammers use bogus e-mail addresses. Here is a utility program by Keith Moore that can help to check addresses: What: check_mail_addr Where: ftp://cs.utk.edu/pub/moore/check_mail_addr.tar.gz Comments: This is a handy C program for checking mail addresses. It uses an SMTP RCPT TO command (not VRFY) to check the validity of an address. -- 4.9) How can I prevent third-party mail relaying? The MMDF authorization facility may help to prevent third-party mail relaying. Included with the MMDF source tree are two documents that describe the authorization facility: Title: Authorisation and accounting in store and forward message handling systems Authors: D.H. Brink and S.E. Kille Where: http://www.irvine.com/~mmdf/doc/authorization.html Comments: Part of the standard MMDF documentation collection. Title: Configuring MMDF Authorisation Authors: Steve Kille Where: http://www.irvine.com/~mmdf/doc/auth.guide.html Comments: Part of the standard MMDF documentation collection. ---- 5) Miscellaneous Questions and Gotchas -------------------------------------- 5.1) Where is the MMDF discussion list? A mailing list for MMDF discussion is here: mailto:mmdf2-request@a.cs.okstate.edu Questions about the SCO version of MMDF may be posted to this USENET newsgroup: comp.unix.sco.misc This newsgroup is read by several knowledgeable and helpful persons at SCO, who often answer questions about MMDF very quickly. Although SCO's version of MMDF is slightly different from the publicly available version, particularly in the high-level administrative details, answers to questions posed by SCO MMDF users are often applicable to the publicly available versions of MMDF. 5.2) MMDF sendmail-replacement gotchas [ Andy Powell <ccsap@bath.ac.uk> - 23-Jan-1996 ] The sendmail supplied with MMDF is slightly defective in that it doesn't correctly hide Bcc: fields (if given a -t option). This can cause a problem for non-MMDF UAs (for example, Pine) if they are configured to send mail out using sendmail. In the case of Pine I suspect that this can be worked round by configuring it to talk directly to the MMDF smtpd running on localhost (assuming that you are running one). Note: SCO supplies a sendmail replacement called "execmail", in addition to the regular MMDF sendmail replacement. The execmail program is not officially documented, but it is thought to be a divergent version of the MMDF sendmail-replacement's source code. Execmail may or may not have any of the sendmail-replacement gotchas in the version supplied with the general release version of MMDF. [ Bela Lubkin <belal@sco.COM> 10-Jun-1996 ] execmail is a SCO-provided program similar to the MMDF `sendmail'. This was intended to allow drop-in replacement of SCO's old `MICNET' mail system with MMDF. SCO's own MUAs still use the execmail interface to inject mail into the MTA. 5.3) What new features are needed or planned for future releases of MMDF? [ Mark Vasoll <vasoll@a.cs.okstate.edu> - 22-Jan-1996 ] - Full RFC 1123 compliance (existing deviations are very minor). { RFC 1123: "Requirements for Internet hosts - application and support". ftp://ds.internic.net/rfc/rfc1123.txt } - MIME encapsulation of error/warning messages and citations. - Completely revamped #ifdef structure on a "per OS feature" basis (no more BSD vs Sys5, since they don't really exist anymore). - Completely new example configurations based on "current" systems (I have Sequent Dynix/PTX, Sun SunOS, Sun Solaris, IBM RS6000 AIX, Novell Unixware and Linux in house). - GDBM support for tables The time table for any new release is not known. This is an unfunded spare time project for me. What remains to be done is mailing the #ifdef revisions in the user interfaces (the core code is complete) and a revision of the "building" section of the documentation. Other items for the MMDF wish list: - SMTP service extensions: RFC 1869: SMTP Service Extensions RFC 1652: SMTP Service Extension for 8bit-MIMEtransport RFC 1870: SMTP Service Extension for Message Size Declaration RFC 1891: SMTP Service Extension for Delivery Status Notifications RFC 1985: SMTP Service Extension for Remote Message Queue Starting RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes RFC 2197: SMTP Service Extension for Command Pipelining { Any others? } ---- 6) An MMDF Bibliography ----------------------- { Please suggest additional entries. } Title: Addressing in MMDF II Authors: Steve Kille Where: http://www.irvine.com/~mmdf/doc/addressing.html Comments: Part of the standard MMDF documentation collection. Title: Authorisation and accounting in store and forward message handling systems Authors: D.H. Brink and S.E. Kille Where: http://www.irvine.com/~mmdf/doc/authorization.html Comments: Part of the standard MMDF documentation collection. Title: Configuring MMDF Authorisation Authors: Steve Kille Where: http://www.irvine.com/~mmdf/doc/auth.guide.html Comments: Part of the standard MMDF documentation collection. Title: Configuring MMDF in a TCP/IP Environment Authors: Christopher Durham <chrisdu@sco.com> Where: ftp://ftp.xenitec.on.ca/pub/doc/mmdf/tcp-ip Where: http://www.sco.com/Support/ssl.html (See also "SCO technical articles", below) Comments: This document explains how to configure MMDF's SMTP channel under SCO Unix 3.2. Title: Configuring MMDF in a UUCP Environment Authors: Christopher Durham <chrisdu@sco.com> Where: ftp://ftp.xenitec.on.ca/pub/doc/mmdf/uucp Where: http://www.sco.com/Support/ssl.html (See also "SCO technical articles", below) Comments: This document explains how to configure MMDF's UUCP channel under SCO Unix 3.2. Title: Example MMDF Tables Authors: Jerry Sweet <mmdf-faq@irvine.com> Where: http://www.irvine.com/~mmdf/tables/index.html Comments: Discusses an example Internet site mail system configuration. Title: How to use MMDF to sort incoming e-mail automatically Authors: Jerry Sweet <mmdf-faq@irvine.com> Where: http://www.irvine.com/~mmdf/auto-sort/index.html Comments: Discusses how to use features in MMDF and MH to manage incoming e-mail from different mailing lists. Title: HPMDF: An Experiment Placing CSNET Phonenet Services on the Hewlett-Packard 3000 Authors: Laubach, Mark, and Farber, Dave Where: IEEE Computer Networking Symposium Conference, Silver Springs, MD, December, 1983. Title: HPMDF: A Study of the Elements of Good Message Relaying Style and a Practical Implementation Authors: Mark Laubach <laubach@terra.com21.com> Where: Master's Thesis, Computer and Information Sciences Department, University of Delaware, May, 1987. Title: Installing and Operating MMDF-II Authors: Douglas P. Kingston III, Steve Kille, Julian Onions, Daniel B. Long Where: http://www.c2-tech.com/~vasoll/mmdf/admin.html Where: http://www.irvine.com/~mmdf/doc/admin.html Comments: This is the stock MMDF installation guide. Title: An Internetwork Memo Distribution Facility--MMDF Authors: David H. Crocker, E.S. Szurkowski, David J. Farber Where: Proceedings, Sixth Data Communications Symposium, November 1979; pages 18-25. Title: MMDF-II, the MTA for all jobs Authors: Mark Vasoll Where: http://www.c2-tech.com/~vasoll/mmdf/ Comments: Mark's handy MMDF information page Title: MMDF-II: A Technical review Authors: Douglas P. Kingston, III Where: Proceedings, Summer USENIX Conference and Exhibition, Salt Lake City, Utah; June 1984; pages 32-41. Where: http://www.c2-tech.com/~vasoll/mmdf/review.html (Web version) Where: http://www.irvine.com/~mmdf/doc/review.html (Web version) Where: http://www.c2-tech.com/~vasoll/mmdf/review.ps (PostScript version) Title: MMDF Users Group Authors: Ran Atkinson Where: http://www.mmdf.org Comments: A handy reference page containing links to MMDF resources, comments about the various MMDF ports, and a list of UAs that work with MMDF. Title: Notes about MMDF and POP Authors: Jerry Sweet <mmdf-faq@irvine.com> Where: http://www.irvine.com/~mmdf/pop/index.html Comments: This is sort of a cookbook for using the POP channel. Title: PMDF - A Pascal-Based Memo Distribution Facility Authors: Ira Winston <ira@cis.upenn.edu> Where: Master's Thesis, Computer and Information Science Department, University of Pennsylvania, May, 1983. Title: The PP Manual Authors: Steve Kille, Julian Onions Where: Part of the PP 6.0 source code distribution. December 19, 1991. Title: SCO documentation Authors: SCO Where: SCO Unix/OpenServer printed documentation Where: SCO OSR5 online documentation in HTML format is available on systems where it has been installed, using URLs of the following _example_ formats: http://your.machine.here:457/MailMsgG/CONTENTS.html http://your.machine.here:457/MailMsgG/mmdfN.intro.html http://your.machine.here:457/MailMsgG/mlocN.maint.html Comments: SCO itself doesn't make these documents available for browsing via WWW or FTP, although some specific manual pages occasionally can be found by following links from the SCO technical articles, described below. Title: SCO technical articles Authors: SCO Where: http://www.sco.com/Support/ssl.html Comments: When you apply a search for "MMDF" using the form at the aforementioned web page, you should be able to find these articles, among others: - Configure MMDF so that rmail accepts multiple addresses per message. - Configure MMDF to query Name Server for domain, channel and alias info. - Configure MMDF to redirect mail to unknown user; reply to sender. - Configure MMDF to use a different HELO name when initiating SMTP. - Configuring MMDF in a TCP/IP environment under SCO UNIX System V/386. - Configuring MMDF in a UUCP environment under SCO UNIX System V/386. - How do I configure MMDF to send warnings about undeliverable mail? - How do I configure MMDF to use XENIX format mailboxes? - How do I configure the MMDF deadhost timeout? - How does MMDF host authorization work? - How to configure MMDF over Point-to-Point Protocol (PPP). - How to configure MMDF to allow multiple domains for the local system. - How to configure MMDF to control mail routing on a per-host basis. - How to configure MMDF to control mail routing on a per-user basis. - How to configure MMDF to group hosts in SMTP channel for authorization. - How to configure MMDF to use nameserver to look up all hosts. - How to get MMDF to use the nameserver for alias information. - How to make the MMDF UUCP channel initiate transfer immediately (or not). - How to set up mail forwarding in MMDF. - Inconsistency in MMDF system name, and how to change the system name. - MMDF Troubleshooting Techniques. - MMDF mailbox locking problem and how to resolve it. - MMDF quick reference template - local or SMTP mail configuration. - Which named/DNS nameserver records can I configure MMDF to use? Although many of the questions and answers in the above documents are specific to the SCO version of MMDF, you may find information that applies to the general release of MMDF as well. Title: SCO Technical Library Supplements Authors: SCO Where: ftp://ftp.sco.COM/TLS/ Comments: See ftp://ftp.sco.COM/TLS/file.list for a list of files available via FTP; look for "MMDF". Title: A sendprog checklist Authors: Jerry Sweet <mmdf-faq@irvine.com> Where: http://www.irvine.com/~mmdf/sendprog.html Comments: An example of how to use MMDF's "sendprog" facility. Title: Supplement to the MMDF Frequently Asked Questions List Authors: MMDF FAQ Maintainer <mmdf-faq@irvine.com> (ed.) Where: http://www.irvine.com/~mmdf Comments: The Supplement is a collection of MMDF-related reference material for MMDF administrators and users both. ---- 7) Other Resources ------------------ 7.1) Free Software This section is for listings of free implementations of MMDF, packages based on MMDF, or packages that are known to interoperate with MMDF. Information for this section may be contributed by anyone, including the maintainers of the software. The FAQ maintainers look with favor on brief entries that are provided in the existing entry format, but it's fair simply to offer corrections or updated information. Notifications of obsolete or non-working URLs are also appreciated. Send new or updated entries to "mmdf-faq@irvine.com"; posting to the MMDF2 list isn't necessarily sufficient. See also: news:comp.mail.misc - "UNIX Email Software Survey FAQ" { Wanted: FTP-able sources for additional channel packages, mail administration tools, and other goodies. } ------- Name: MH 6.8 Product: MUA Platform: Unix Where: ftp://ftp.ics.uci.edu/pub/mh/mh-6.8.tar.Z Where: ftp://louie.udel.edu/portal/mh-6.8.tar.Z Author: Comments: MH, originally from RAND and presently maintained at the University of California Irvine, is a popular message handling system. MH runs on many different UNIX platforms, and can use either sendmail or MMDF. See also: news:comp.mail.mh news:comp.mail.mime -- Name: MMDF administrative utilities Product: toolset Platform: Unix Where: ftp://ftp.armory.com/pub/admin/mmdf/ Author: John DuBois <spcecdt@armory.com> Comments: MMDF administrative utilities. These were written for SCO XENIX and SCO UNIX, but most should be portable to other flavors of UNIX without too much trouble. If you don't have ksh for the #!/bin/ksh scripts, try pd-ksh, bash, or zsh. Many of them require gawk, version 2.15.5 or later. Some require gawk 3.0.0 or later. A gawk 3.0.0 binary for SCO 5.0 can be found in the scobins/ directory. These utilities are for the MMDF mail transport agent, as shipped with SCO UNIX and used by many sites as a replacement for shipped mail systems. Filename Description mmdfq List/manipulate MMDF queue (needs stat). mmdfsel Full-screen front end for mmdfq (oash prog; SCO UNIX only) phost Pseudo-host channel for MMDF (to implement virtual domains). smtpcull front end for smtpsrvr that lets specific sites be blocked. -- Name: mush 7.2.5 Product: MUA Platform: Unix Where: ftp://cse.ogi.edu/pub/mush Author: Dan Heller & Bart Schafer Comments: [ Ran Atkinson <address omitted by request> 5-Sep-1996 ] Mush is not actively maintained. Z-Mail, a commercial product, is related. Mush, the "Mail User's Shell", is a command-line mail user agent that was popular at some sites in the late 1980s and is still used today at some sites. It runs on most versions of UNIX and is compatible with either MMDF's submit or with BSD Sendmail. It understands both MMDF-style and Sendmail-style mailbox files. It includes a large scripting language and can be a good general substitute for BSD's Mail(1), since it has a superset of features. Although mush does not appear to be actively maintained any longer, a patch to let mush work under BSDI is available on ftp.bsdi.com in their contributed software section. -- Name: PP 6.0 Product: MTA Platform: UNIX Where: ftp://ftp.uninett.no Author: Steve Kille et al. Contact: Comments: PP is a large-scale X.400/SMTP mailer and gateway. The last non-commercial version was PP 6.0 (ca. 1992), which is still available for downloading from some Internet sites; one is listed above. PP has since been folded into a commercial software suite from the ISODE Consortium; see the entry for "ISODE Consortium MTA", below. Steve Kille used MMDF as the basis for the PP X.400 system. ---- 7.2) Commercial Software This section is for listings of commercial software based on MMDF, or that provides enhancements to MMDF. Contributions to this section may be made by anyone, including the firms offering the packages. The FAQ maintainers look with favor on _brief_ entries, preferably as non-hypeful as possible, that are provided in the existing entry format, but it's fair simply to offer corrections, updated information, or unbiased consumer-oriented comments. Send new or updated entries to the address "mmdf-faq@irvine.com"; posting to the MMDF2 list isn't necessarily sufficient. ---- Name: ISODE Consortium MTA Product: MTA Platform: UNIX Contact: ic-info@isode.com Where: http://www.isode.com/ [ Steve Kille <S.Kille@isode.com> 26-Oct-1995 ] { This entry has been brutally edited from the much longer version originally contributed to the comp.mail.mime FAQ. } The ISODE Consortium MTA is an X.400 and SMTP mailer, and a gateway between these, so you can communicate with "both worlds". This product is based on the older public domain PP MTA, but now includes many enhancements and features. The ISODE Consortium product is a source release. Binary Products based on the technology are available from commercial vendors who are members of the ISODE Consortium. Here's a URL for Nexor's version of the ISODEC MTA: http://www.nexor.co.uk/nexor/mkting/mware/mmta.html See also: http://domen.uninett.no/~hta/x400/products/ Name: PMDF Product: MTA Platform: VMS Contact: sales@innosoft.com, service@innosoft.com Author: Innosoft International Comments: Innosoft's PMDF is a mature commercial version of PMDF. Ned Freed, one of PMDF's maintainers, is notably active in Internet electronic mail specification and standardization efforts. He frequently participates in discussions in the comp.mail.mime newsgroup. [ Ned Freed <ned@innosoft.com> ] Send technical inquiries to service@innosoft.com. Product information, pricing, and literature can be obtained from sales@innosoft.com. The phone number is (909) 624-7907; FAX is (909) 621-5319. Street address is: Innosoft International, Inc. 250 W. First St., Suite 240 Claremont, CA 91711 See also: news:vmsnet.mail.pmdf Name: SCO OpenServer Product: Operating system Platform: x86 machines Contact: info@sco.com Where: http://www.sco.com/ [ Bela Lubkin <belal@sco.com> 07-Jun-1996 ] SCO OpenServer Release 5 is a greatly enhanced Unix System V Release 3.2 implementation for Intel x86 architecture machines. It is included here because its default mail transport agent is MMDF IIb version 43. SCO 400 Encinal St. POB 1900 Santa Cruz, CA 95060-1900 USA +1 800 846 2726 +1 408 425 7222 Note that SCO has made some private enhancements and bug fixes to MMDF. In particular, SCO moved some programs from ~mmdf/lib to ~mmdf/bin. There may be various functional differences in some of the channels and programs. A complete list of differences is not known to be enumerated anywhere. When reading SCO's documentation and technical articles, be mindful of possible differences when applying the information to non-SCO versions of MMDF. -- Name: Z-Mail for UNIX Product: MUA Platform: UNIX, Dos, Windows Contact: info@netmanage.com Where: http://www.netmanage.com/ [ Ran Atkinson <address omitted by request> 5-Sep-1996 ] Z-Mail is derived from the freely distributable Mail User's Shell (mush), described earlier. Z-Mail for UNIX platforms supports both MMDF-style mailboxes and Sendmail-style mailboxes, automatically detecting which mailbox format is in use on the system. Z-Mail for UNIX has both a X11/Motif GUI version and a command-line version. The command-line version is very similar to mush, though with additional features. Zmail includes support for MIME and also for Sun MailTool-format attachments. This software is available in binary form for most commercial versions of UNIX. It is included at no extra cost with SGI IRIX systems and is renamed "MediaMail" on the SGI systems. 8) Authorship ------------- The MMDF FAQ was boilerplated partially from the comp.mail.mime FAQ, originally by Ed Vielmetti. The cast of contributors to that FAQ is credited therein. Some MMDF-specific text was cribbed from these sources: Where: news:comp.mail.misc Source Subject: UNIX Email Software Survey FAQ [Part 3 of 3] From: clewis@ferret.ocunix.on.ca (Chris Lewis) Section: MMDF from a review by I.Sparry@gdt.bath.ac.uk Where: news:comp.mail.misc Source Subject: Majordomo Frequently Asked Questions From: barr@math.psu.edu (Dave Barr) Section: WHY DO I GET DUPLICATE MAIL SENT TO THE LIST? by Gunther Anderson The MMDF FAQ's current maintainer is Jerry Sweet <mmdf-faq@irvine.com>. Please note: Questions about MMDF and related issues, if not already answered in the FAQ, should be posted to comp.mail.misc or to the mmdf2 mailing list (see section 2.2 for its request address). Correspondence sent to the MMDF FAQ maintainer primarily should address information in the MMDF FAQ---corrections, additions, or suggestions for improvement. 8.1) Acknowledgements Written contributions specifically made for this FAQ have come from: { Your name and, optionally, e-mail address or URL, could be here! } Gunther Anderson mailto:gunther@world.std.com Ran Atkinson mailto:Ran Atkinson <address omitted by request> Dave Crocker mailto:dcrocker@brandenburg.com http://www.brandenburg.com Bela Lubkin mailto:belal@sco.com Julian Onions mailto:j.onions@nexor.co.uk http://www.nexor.co.uk/users/jpo/jpo.html Craig Partridge mailto:craig@aland.bbn.com Andy Powell mailto:ccsap@bath.ac.uk http://www.bath.ac.uk/~ccsap Jerry Sweet mailto:mmdf-faq@irvine.com http://www.irvine.com/~jsweet Mark Vasoll mailto:vasoll@a.cs.okstate.edu http://www.c2-tech.com/~vasoll Resources for maintaining the MMDF FAQ are provided by Irvine Compiler Corporation - "We Make Ada Fly!" { http://www.irvine.com } 8.2) Permissions Permission is granted for unlimited redistribution of the unedited MMDF FAQ.