Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

The MMDF Frequently Asked Questions List (FAQ)

1 view

Skip to first unread message

MMDF FAQ Maintainer

unread,

Nov 5, 1998, 3:00:00 AM11/5/98

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-...@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 <kru...@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:
kru...@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 <vas...@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 <dcro...@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 me...@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 me...@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 <jo...@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 <cc...@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 majordo...@greatcircle.com and majordom...@greatcircle.com
lists. In both cases send the word "help" (no quotes, put it in the
body rather than the subject) to majo...@greatcircle.com to start
the process.

[ Gunther Anderson <gun...@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 <gun...@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...@informatik.rwth-aachen.de"
with Subject: subscribe.

3.3) How can I debug my .maildelivery file?

[ Craig Partridge <cr...@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 <jo...@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 <be...@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 <g...@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 <vas...@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 <vas...@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 <jo...@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 <ba...@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 <be...@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 <spc...@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 <spc...@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-...@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 <cc...@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 <be...@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 <vas...@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: 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 <chr...@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 <chr...@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...@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...@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 <lau...@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...@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 <i...@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...@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...@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...@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 <spc...@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...@irvine.com"; posting to the MMDF2 list isn't necessarily
sufficient.

----

Name: ISODE Consortium MTA
Product: MTA
Platform: UNIX
Contact: ic-...@isode.com
Where: http://www.isode.com/

[ Steve Kille <S.K...@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

Name: PMDF
Product: MTA
Platform: VMS
Contact: sa...@innosoft.com, ser...@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 <n...@innosoft.com> ]

Send technical inquiries to ser...@innosoft.com. Product
information, pricing, and literature can be obtained from
sa...@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