ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/mail/mmdf-faq/part1

Internet Message Format | 1998-11-05 | 57.8 KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!eecs-usenet-02.mit.edu!nntprelay.mathworks.com!peerfeed.ncal.verio.net!nntp2.cerf.net!news.cerf.net!nntp.irvine.com!jsweet
From: MMDF FAQ Maintainer <[e-mail]>
Newsgroups: comp.mail.misc,comp.unix.sco.misc,comp.answers,news.answers
Subject: The MMDF Frequently Asked Questions List (FAQ)
Supersedes: <[e-mail]>
Followup-To: comp.mail.misc
Date: 5 Nov 1998 07:30:07 GMT
Organization: Irvine Compiler Corporation - Irvine, CA, USA
Lines: 1538
Approved: [e-mail]
Expires: 29 Dec 1998 07:30:01 GMT
Message-ID: <[e-mail]>
Reply-To: MMDF FAQ Maintainer <[e-mail]>
NNTP-Posting-Host: flash.irvine.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Summary: This document contains answers to frequently asked
    questions about MMDF, the Multi-channel Memo Distribution
    Facility, a popular MTA.
Content-Description: MMDF FAQ $Revision: 1.11 $
Originator: [e-mail]
Xref: senator-bedfellow.mit.edu comp.mail.misc:46860 comp.unix.sco.misc:73198 comp.answers:33727 news.answers:143727

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:[e-mail]) 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 <[e-mail]> 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:
           [e-mail]

----

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 <[e-mail]> 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 <[e-mail]> 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 [e-mail]"

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 [e-mail]"

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 <[e-mail]> 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 <[e-mail]> - 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 [e-mail] and [e-mail]
    lists.  In both cases send the word "help" (no quotes, put it in the
    body rather than the subject) to [e-mail] to start
    the process.

    [ Gunther Anderson <[e-mail]> 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 <[e-mail]> 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 "[e-mail]"
                with Subject: subscribe.

--

3.3) How can I debug my .maildelivery file?

    [ Craig Partridge <[e-mail]> 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 <[e-mail]> - 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> - 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 <[e-mail]> - 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 <[e-mail]> - 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 <[e-mail]> ]

    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 <[e-mail]> 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 <[e-mail]>, 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 <[e-mail]> 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:[e-mail]

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 <[e-mail]> - 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 <[e-mail]> 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 <[e-mail]> - 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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]> (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 "[e-mail]"; 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 <[e-mail]>
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
"[e-mail]"; posting to the MMDF2 list isn't necessarily
sufficient.

----

Name:     ISODE Consortium MTA
Product:  MTA
Platform: UNIX
Contact:  [e-mail]
Where:    http://www.isode.com/

    [ Steve Kille <[e-mail]> 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:  [e-mail], [e-mail]
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 <[e-mail]> ]

    Send technical inquiries to [e-mail]. Product
    information, pricing, and literature can be obtained from
    [e-mail]. The phone number is [phone]; FAX is
    [phone]. 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:  [e-mail]
Where:    http://www.sco.com/

    [ Bela Lubkin <[e-mail]> 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
      [phone]
      [phone]

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:  [e-mail]
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:           [e-mail] (Chris Lewis)
Section:        MMDF
                from a review by [e-mail]

Where:          news:comp.mail.misc
Source Subject: Majordomo Frequently Asked Questions
From:           [e-mail] (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 <[e-mail]>.

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:[e-mail]
Ran Atkinson
        mailto:Ran Atkinson <address omitted by request>
Dave Crocker
        mailto:[e-mail]
        http://www.brandenburg.com
Bela Lubkin
        mailto:[e-mail]
Julian Onions
        mailto:[e-mail]
        http://www.nexor.co.uk/users/jpo/jpo.html
Craig Partridge
        mailto:[e-mail]
Andy Powell
        mailto:[e-mail]
        http://www.bath.ac.uk/~ccsap
Jerry Sweet
        mailto:[e-mail]
        http://www.irvine.com/~jsweet
Mark Vasoll
        mailto:[e-mail]
        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.