UNIX Email Software Survey FAQ Part 3

archived information

Return to UNIX Info for Net Administration page.

From news.admin.misc Fri Sep 15 03:11:12 1995
From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Subject: UNIX Email Software Survey FAQ [Part 3 of 3]
Message-ID: <mailfaq.3_811084805@ferret.ocunix.on.ca>
Date: Thu, 14 Sep 1995 13:20:34 GMT

Archive-name: mail/setup/unix/part 3 of 3
Last-modified: Thu Jan 26 01:29:12 EST 1995

UNIX EMail Software - a Survey
Chris Lewis
[and a host of others - thanks]

Copyright 1991, 1992, 1993, Chris Lewis

Redistribution for profit, or in altered content/format prohibited without permission of the author. Redistribution via printed book or CDROM expressly prohibited without consent of the author. Any other redistribution must include this copyright notice and attribution.


Uumail is a very old and obsolete precursor to smail 2.5. Included here only because I know that uumail sites still exist. You should not install uumail in new configurations, and existing uumail sites should convert to something more modern.

smail 2.5: author The UUCP Mapping Project

Smail 2.5 is a small, simple and hard-coded rule MTA for use on UUCP networks. It understands RFC compliant headers, will generate RFC compliant Internet-style headers, can use domains, aliases, a pathalias UUCP routing database, and is very simple to install. For full functionality, you will also want pathalias and a map unpacker. The one thing it cannot do by itself is mail-to-pipe and mail-to-file aliasing. For that, you need Zeeff's lmail, deliver or procmail.

Smail 2.5 has the capability of coalescing addresses into single UUCP transfers, and knows how to query UUCP for the names of UUCP neighbors, and autoroute if necessary.

Smail 2.5 has a few bugs that are (usually) pretty rarely seen in operation. There have been a number of patches posted for it, but it is recommended that you do not apply them - some were ill-conceived, buggy in their own right, or conflicting with others. The only patches that I feel safe in recommending is Chip Salzenberg's patches for use with Xenix MICNET - which are unnecessary unless you are in the unfortunate position of having to actually *use* MICNET. Chip Salzenberg's "deliver" package (see below) combined with "smail-deliver.pch" from comp.sources.unix, volume 25 issue 107, makes the MICNET modifications to smail itself unnecessary.

In particular, do not apply the "mail-to-pipe/file" patches that float around for smail 2.5. These are a major security hole.

Smail 2.5 can also be used with sendmail as a UUCP router.

Smail 2.5 was posted in comp.sources.unix in 1987, volume 11 with archive name "smail3" (but it isn't the same thing as smail 3 below).

lmail: Author Jon Zeeff <zeeff@b-tech.ann-arbor.mi.us, zeeff@ais.org>

When you install smail 2.5, you link the original /bin/mail (binmail above) to /bin/lmail to perform the task of actually delivering the mail to the user's mailbox (LDA).

Since smail 2.5 was not capable of doing mail-to-pipe and mail-to-file aliasing, Jon Zeeff wrote a replacement lmail that implemented these (along with user mailbox delivery).

Jon's program is okay for casual use, but has some pretty serious bugs. Fixed versions are available, but you're probably better off installing deliver or procmail.

smail 3: Author Ronald S. Karr* <tron@veritas.com> and Landon Curt Noll./

Smail3.1 is a domain-capable mail router and delivery program that works in the UUCP zone and on the Internet and that is capable of gatewaying between the two. It was written primarily by me (Ronald S. Karr) and Landon Curt Noll, with the blessings of the original Smail1 and Smail2 authors.

Smail3 supports SMTP, UUCP mail, alias files, .forward files, mailing list directories, pathalias files, /etc/hosts files, the domain name system, and can also query uucp for neighboring sites, automatically. It also supports use of encapsulated SMTP commands for delivery over UUCP connections, which allows batching of multiple messages into a single UUCP transaction, and allows many addresses to be passed with a single message transfer, which can greatly decrease the traffic generated for large mailing lists. It is also very simple to configure with a reasonable certainty of correctness.

Smail3 includes pathalias and a reliable map unpacker.

Rather than using configuration files to resolve addresses based on their syntax, ala sendmail, Smail3 uses a database metaphore for resolving addresses based on their contents. The set of methods that Smail3 uses for resolving local addresses and hosts is configurable and extensible. Smail3's methods for parsing addresses are not configurable. It is the opinion of the authors that addressing on the Internet and in the UUCP zone has become sufficiently standardized that attempts to allow configurability in this area are now a hindrance to the correct working of the network.

Questions related to Smail3 are usually discussed in comp.mail.misc. There are also two discussion mailing lists. To join the mailing lists, send mail to:


The current release of Smail3 can be found on uunet, in the file /archive/networking/mail/smail/smail- New versions are released on a haphazard basis. Official releases are always made available in the /archive/networking/mail/smail directory on uunet.

Smail 3 is covered under the GPL (if it matters)

sendmail: Original author Eric Allman

Sendmail is the granddaddy of all intelligent MTA's. It can do just about anything. It's main problem is that it can do just about anything. Modification of sendmail's configuration tables (which is necessary with most vendor-supplied versions) is NOT for novices. The language of the sendmail.cf is cryptic, but that isn't really the problem (and this problem can be solved by using "EASE", a sendmail.cf writing language, or the UIUC IDA kit's configuration file building tools). The problem is that it's extremely difficult to know when the rules you are implementing are the right thing-- many sendmail configurations do slightly buggy, or even extremely buggy, or illegal things. The default configurations generated by the UIUC IDA kit are, however, very good at Doing the Right Thing under most, if not all, circumstances. I hear similar things about the Sendmail 8.6 package.

Worse, every vendor's version of sendmail is different, and many of their sendmail.cf's don't work at all. HPUX is one example of where the sendmail.cf is actually pretty sane. HP is to be congratulated. On the other hand, some vendors, who shall remain nameless, can't even get their sendmail to deliver to local users, let alone get their sendmail to speak SMTP on a LAN.

The major problem with sendmail is that it tries to do too many things. Rather than confining itself to handling local mail, and simply routing external mail and leaving transport-specific format/standards conversions to transport software, it attempts (nay virually *insists*) that you have to do all of the format/standards conversions for different transports all at once. Which results in configuration files that are veritable nightmares to maintain. And that many sendmail.cf files depend on out-of-date standards for different transports, rather than trying to unify them (as in RFC976).

Indeed, while common wisdom and practice mandates that MTAs don't rewrite headers, sendmail makes it extremely difficult to *not* rewrite headers. Which results in many major systems attempting to "be nice", yet, totally scramble return addresses and the like.

There are several different sendmail lineages in the world but they seem to be coming together now with Eric Allman's work creating sendmail V8.x. Sendmail V8.1 was shipped with BSD 4.4 UNIX. V8.2 and above (available from ftp.cs.berkeley.edu) is the latest. V8.6.9 is now current. Another solid "modern" version is UIUC IDA version 5.65c (5.65d in alpha test), from ftp.uu.net or uxc.cso.uiuc.edu. This version has been pretty stable since 1991. Paul Pomes, <Paul-Pomes@uiuc.edu>, is controlling the IDA Sendmail releases.

If you want to use sendmail, it is strongly recommended that you obtain the UIUC IDA or sendmail 8.6+ versions. They are much more likely to do the right things with mail coming from, or ultimately going to, UUCP sites and is much easier to maintain. IDA sendmail can handle pathalias-style UUCP routing quite well.

Another point to remember is that sendmail, historically, has been where a large number of severe security holes have been found. From the infamous RTM Internet Worm, to the two latest ones "CERT"d in the past 6 months. Indeed, if your application is security-critical, you should *not* use sendmail on your security-critical systems, such as your firewalls. Theoretically, all of these problems have been removed from sendmail 8.6.5 or later, but, there's bound to be more found. While some of this can be due to the much larger installed base of sendmail, other mailers with improved function partitioning (such as the channel-oriented MMDF or PP) will usually be inherently more secure.

I am being harsh on sendmail - sendmail programming is, after all, a good source of revenue for consultants ;-) But, if you obtain a good configuration (like the aforementioned HPUX version), or are willing to spend the time to learn it, sendmail will do what you want. Well. IDA or 8.x sendmail is STRONGLY recommended. Don't, however, even think of playing with the configuration files without a copy of the Sendmail book by Costales, Allman and Rickert mentioned in the book list above. It is *absolutely* essential.

Sendmail is discussed in comp.mail.sendmail.

EASE version 3.5 was posted in volume 25 of comp.sources.unix and is available from wuarchive.wustl.edu [] (directory /usenet/comp.sources.unix/volume25/ease) and many other c.s.u archives.

ZMailer: Original author Rayan Zachariassen* <rayan@cs.toronto.edu>

Current author Matti Aarnio <mea@nic.funet.fi>

ZMailer is intended for gateways or mail servers or other large site environments that have extreme demands on the abilities of the mailer.

Code and Design features:

  • + Strong limits on host impact.
  • + Secure design (and hopefully implementation).
  • + Natural fit for client/server environments.
  • + Extremely customizable configuration mechanism.
  • + Flexible database interface with support for: sorted files, unsorted files, dbm, ndbm, gdbm, nis (yellow pages), dns (BIND resolver), /etc/hosts file, and in-core data.
  • + Efficient message queue management.
  • + Fast binary-transparent SMTP server and client.
  • + MIME-facilities for message transport.
  • + Low-technology implementation, with high-tech options for performance.

Default configuration file features:

  • + Default configuration will work for most sites.
  • + Network protocol support for: smtp, uucp, bitnet, mail to news.
  • + An easy way of overriding any external routing information.
  • + Automatic handling of mailing lists.

It is available by anonymous FTP from:

ftp://ftp.funet.fi/pub/unix/mail/zmailer/ (Mr. Aarnio's versions)

Alternate (some of them old) versions:



MMDF: [reviewed by I.Sparry@gdt.bath.ac.uk]

MMDF is a MTA. It works on the principle that you have communications channels, both incoming and outgoing, and it arranges for messages to pass between them.

Strong points include:

  • * Ability to turn up and down debugging level on the fly
  • * Very strong on authentication, and permission checking.
  • * Can block mail based on who it came from, how it got there, who it is going to.

It is older than sendmail, simpler than sendmail, and it is a great pity that it was not shipped as standard instead of sendmail.

[MMDF is standard on some systems - primarily SCO UNIX.]

It has one major advantage to people in the UK, in that it knows how to handle mail addresses in our 'correct' format (Most significant part first, e.g. net.uu.uunet), as well as the thing the rest of the world uses :-) :-)

A mailing list for MMDF discussion is at mmdf2@a.cs.okstate.edu requests for addition to the list to mmdf2-request@a.cs.okstate.edu. The most recent release of MMDF is available for anonymous FTP from a.cs.okstate.edu:/pub/mmdf-2.43.tar.Z.

.PP: Author University College London

PP is a Message Transfer Agent, intended for high volume message switching, protocol conversion, and format conversion. It is targeted for use in an operational environment, but may also be useful for investigating Message related applications. Good management features are a major aspect of this system. PP supports the 1984 and 1988 versions of the CCITT X.400 / ISO 10021 services and protocols. Many existing RFC 822 based protocols are supported, along with RFC 1148 conversion to X.400. PP is an appropriate replacement for MMDF or Sendmail, and also supports SMTP and UUCP mail.

For more information contact: support@xtel.co.uk or xtel@cs.nott.ac.uk The latest version is PP-6.0, which was posted in comp.sources.misc, volume 27.

[Ed note:]

PP is usually used in combination with the ISODE package, which also provides copious documentation for PP. PP itself is "freeware", but ISODE and the PP documentation is not - site licenses are rather pricy. PP is *very* large, and has quite a number of more esoteric functions, such as FAX transmission using the appropriate modems. PP is ideal for large organizations with demanding email requirements (eg: 100s of machines and 1000s of users), where PP would be used as "backbone mail servers", and something simpler on the "client" computers. It does have _substantial_ learning and support requirements, and is *not* suitable for smaller installations. It does, however, shine in large production environments, where policy-based routing, high levels of security, or extensive gatewaying to different transports is required.

SVR4 mail: Author AT&T (description written by Tony Hansen, hansen@pegasus.att.com)

The System V Release 4 mail system is a domain-capable mail router and delivery program that works in the UUCP zone and on the Internet and that is capable of gatewaying between the two.

SVR4 mail supports SMTP, UUCP mail, alias files, forwarding files, mailing list directories, /etc/hosts files, the domain name system, and can also query uucp for neighboring sites, automatically. (System V Release 4.1 also allows batching of multiple messages into a single UUCP transaction, and allows many addresses to be passed with a single message transfer, which can greatly decrease the traffic generated for large mailing lists.) It is also very simple to configure with a reasonable certainty of correctness.

It also supports mail-to-pipe and mail-to-file.

SVR4 mail uses configuration files to resolve addresses based on their syntax, somewhat similar to sendmail, but using regular expressions and a more easily understood syntax. The set of methods that SVR4 mail uses for resolving local and remote addresses and hosts is configurable and extensible.

Questions related to SVR4 mail are usually discussed in comp.mail.misc.

SVR4 mail is a standard part of System V Release 4; unfortunately, some vendors have not realized that SVR4 mail is not the same mailer as the SVR3 mail system, and have replaced it with other inferior mail systems.

deliver: Author Chip Salzenberg* <chip@fin!chip@dg_rtp.dg.com>

Deliver allows any user to write a shell script that processes all incoming mail messages for that user. The system administrator may also install scripts that process all messages by installing it as the Local Delivery Agent (lmail replacement).

The output of a script is a list of mail addresses, files and programs that should receive the message. It has access to each message as it is processed, so the action can be content dependent. The script may also generate automatic replies, like the "vacation" program, or pass along a modified version of the original message.

Deliver can be used to construct mail-based services (e.g. automatic mailing list maintenance). It can also be used to filter mail automatically in prearranged ways (e.g. encryption and decryption, tossing junk mail, or vacation notices).

Deliver was last posted in comp.sources.reviewed, volume 1. The current version is 2.1.12.

It can be retrieved from <ftp:ftp.cs.uni-sb.de/pub/mail/deliver&#62;

procmail: Author Stephen R. van den Berg*


Can be used to create mail-servers, mailing lists, sort your incoming mail into separate folders/files (real convenient when subscribing to one or more mailing lists or for prioritising your mail), preprocess your mail, start any programs upon mail arrival (e.g. to generate different chimes on your workstation for different types of mail) or selectively forward certain incoming mail automatically to someone.

Procmail can be used:

  • - and installed by an unprivileged user (for himself only).
  • - as a drop in replacement for the local delivery agent /bin/mail (with biff/comsat support).
  • - as a general mailfilter for whole groups of messages (e.g. when called from within sendmail.cf rules).

The accompanying formail program enables you to generate autoreplies, split up digests/mailboxes into the original messages, do some very simple header-munging/extraction, or force mail into mail-format (with leading From line).

Also included is a comprehensive mailinglist/archive management system.

Since procmail is written entirely in C, it poses a very low impact on your system's resources (under normal conditions, when you don't start other programs/scripts from within it).

Procmail was designed to deliver the mail under the worst conditions (file system full, out of swap space, process table full, file table full, missing support files, unavailable executables; it all doesn't matter). Should (in the unlikely event) procmail be unable to deliver your mail somewhere, the mail will bounce back to the sender or reenter the mailqueue (your choice).

A recent version can be picked up at various comp.sources.misc archives. The latest version (3.03) can be obtained directly from the ftp-archive at:

ftp.informatik.rwth-aachen.de (

(g)zipped: pub/packages/procmail/procmail.tar.gz <160KB>

compressed: pub/packages/procmail/procmail.tar.Z <224KB>

[Ed note]: I had noted reported difficulties in integrating procmail with System V and/or smail 2.5. The 2.70 version of Procmail eliminated these difficulties.]

mailagent: Author Raphael Manfredi* <ram@acri.fr>

The mailagent is yet another mail filter, written in perl, which will let you do anything with your mail. It has all the features you may expect from a filter: mailing lists sorting, forwarding to MTA or to inews, pre-processing of message before saving into folder, vacation mode, etc... It was initially written as an ELM-filter replacement, but has now enough power to also supplant MMDF's .maildelivery. There is also a support for @SH mail hooks, which allows you to automatically distribute patches or software via command mails.

The mailagent was designed to make mail filtering as easy as it can be. It is highly configurable and fairly complete. Rules are specified in a lex-like style, with the full power of perl's regular expressions. The automaton supports the notion of mode, and header selection has many magic features built-in, to ease the rule writing process.

To give a simple example, the two following rules:

Subject: /cron output/ { SAVE cron };

To Cc: dist-users { FORWARD friend@acri.fr; LEAVE };

would save in a folder 'cron' all cron-related mail, and forward mail from the dist-users mailing list to a friend, leaving a copy in the system mailbox for immediate processing...

It supports delivery to plain UNIX folder, to MMDF-style folders or to MH folders with built-in unseen sequence updates, as specified in your ~/.mh_profile. It may therefore replace MH's slocal program as well.

Mailagent can be dynamically extended (that's the advantage of having it written in perl) with new filtering commands that will behave exactly like built-in ones; this operation being done without changing a single source line in the program itself, of course. It also provides a generic mail server layer, where user-defined commands can be easily plugged in, mailagent taking care of the lower-level stuff.

The distribution comes with a set of examples, an exhaustive test suite, and naturally a detailed manual page. It should be noted that the mailagent will work even if your system administrator forbids "| programs" hooks in the ~/.forward, provided you have access to some sort of cron daemon.

The mailagent program is available from any comp.source.misc archive and thanks to Christophe Wolfhugel <Christophe.Wolfhugel@grasp.insa-lyon.fr>, from ftp.univ-lyon1.fr ( under /pub/unix/mail/tools, file mailagent-3.0.tar.gz

pathalias: Author Peter Honeyman

Pathalias reads the UUCP Map Project maps (they need to be extracted from the postings first) and constructs a database containing the minimum cost route to any machine in the maps. This database can then be used with any mailer that knows how to search the database (eg: smail 2.5, Zmailer?, and some versions of sendmail. Smail 3 comes bundled with pathalias).

There were previous versions of this program. You must use pathalias version 10 (latest version), because some map format changes have been made and only pathalias 10 can parse them. If your pathalias doesn't give a syntax error on:

echo "file {foo}" | pathalias
It's the new one.

There were other route-generating programs, but all (as far as I know) are very obsolete, and none run as fast as pathalias (still, which can be rather hard on machines with smallish virtual memory or RAM capacities).

pathalias 10 is available from comp.sources.unix archives, volume 22. A patch was just released in comp.sources.unix (vol 25) that addresses an oddity when used with smail (not that I've ever noticed it).

uuhosts: Author John Quarterman

The "defacto" standard UUCP Map Project map unpacker. Includes a program to arbitrarily view individual map entries. Uuhosts implements trojan horse/virus security by running under a "chroot()" system call. Uuhosts does not appear to be actively maintained, and the last versions that I have inspected were unable to easily compress the maps (a full set of maps is >6000 blocks), had no provision for automatically running pathalias, and will not work with the newest version of cnews. Further, uuhost's header checking is so picky that the slightest change in the map format will cause uuhosts to reject map updates.

Use of uuhosts now will require some minor hacking - and this hacking will stretch your knowledge of Bourne shell programming.

The last edition, "uuhost4" (version 1.69) appears to have been posted in comp.sources.unix in volume 3, 1986.

Do not be confused by Jan-Piet Mons "uuhost 2.0" program posted in alt.sources. This is not a map unpacker. It is just a map viewer, and is a subset of the real uuhosts.

unpackmaps: Author Chris Lewis* <clewis@ferret.ocunix.on.ca>

Unpackmaps is a superset of the functionality of uuhosts. It obtains its security by doing the map unpacking with a specialized parser that knows the map article format rather than invoking a shar/shell. Compression and pathalias invocation is automatic, correctly takes into account the change date of local configuration files, and will work with the latest Cnews.

The newest version of unpackmaps, version 4.1, has been released to comp.sources.misc, and appeared in volume 34. This version is entirely written in C, is considerably faster than unpackmaps 3 or uuhosts, has considerably more features, and will work with Brian Reids PostScript net maps too.

unshar: Author Lee Ward, modified by Mark Moraes* <moraes@deshaw.com>

unshar is evolved from getmaps by Lee Ward. It is has a specialized and limited parser that understands most simple shar formats. It is capable of automatically unpacking new files from a newsgroup spool directory, and requires no interaction whatsoever with the news system. Apart from UUCP maps, it can be used to automatically and safely unpack shar files from the sources newsgroups. It does not handle some of the newer, esoteric shar formats that do automatic uudecodes, etc. Ftp'able from

Chris Lewis: _Una confibula non sat est_

Latest psroff: ftp://ftp.uunet.ca/distrib/chris_lewis/psroff3.0pl17/*

Latest hp2pbm: ftp://ftp.uunet.ca/distrib/chris_lewis/hp2pbm/*

NNTP AUTHINFO GENERIC info: ftp://ftp.uunet.ca/distrib/chris_lewis/generic/*