home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / mail / setup / unix / part3 < prev   
Encoding:
Internet Message Format  |  2001-11-26  |  32.3 KB

  1. Message-ID: <mailfaq.3_1006754401@ferret.ocunix.on.ca>
  2. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!howland.erols.net!sunqbc.risq.qc.ca!torn!qcarhaaa.nortelnetworks.com!bcarh189.ca.nortel.com!zcarh46f.ca.nortel.com!ferret.ocunix.on.ca!not-for-mail
  3. Date: 26 Nov 2001 06:00:02 GMT
  4. Supersedes: <mailfaq.3_1004853601@ferret.ocunix.on.ca>
  5. Expires: 31 Dec 2001 06:00:01 GMT
  6. References: <mailfaq.1_1006754401@ferret.ocunix.on.ca>
  7. Subject: UNIX Email Software Survey FAQ [Part 3 of 3]
  8. From: clewis@ferret.ocunix.on.ca (Chris Lewis)
  9. Newsgroups: news.admin.misc,comp.mail.misc,news.answers,comp.answers
  10. Followup-To: poster
  11. Reply-To: mailfaq@ferret.ocunix.on.ca (Mail FAQ commentary reception)
  12. Summary: How to set up Email on UNIX systems.
  13. Approved: news-answers-request@mit.edu
  14. Keywords: mail software survey UNIX FAQ
  15. Organization: eh?
  16. Lines: 657
  17. Xref: senator-bedfellow.mit.edu news.admin.misc:78188 comp.mail.misc:62682 news.answers:219737 comp.answers:47911
  18.  
  19. Archive-name: mail/setup/unix/part3
  20. Last-modified: Mon Feb 21 09:57:37 EST 2000
  21.  
  22.         UNIX EMail Software - a Survey
  23.                Chris Lewis
  24.         clewis@ferret.ocunix.on.ca
  25.         [and a host of others - thanks]
  26.  
  27.         Copyright 1991, 1992, 1993, Chris Lewis
  28.  
  29.         Redistribution for profit, or in altered content/format
  30.         prohibited without permission of the author.
  31.         Redistribution via printed book or CDROM expressly
  32.         prohibited without consent of the author.  Any other
  33.         redistribution must include this copyright notice and
  34.         attribution.
  35.  
  36. Mailshield    Author: Lyris Technologies http://www.lyristechnologies.com
  37.  
  38. [Watch this space, see http://www.mailshield.com]
  39.  
  40. Exim*         Author: Philip Hazel (ph10@cus.cam.ac.uk)
  41.  
  42.     [Author note: Exim is very highly regarded in the industry, and it,
  43.     along with qmail, are the most frequently recommended replacements
  44.     for sendmail on UNIX.]
  45.  
  46.     Exim is a mail transport agent (MTA) developed at the University
  47.     of Cambridge for use on Unix systems connected to the Internet.
  48.     It is freely available under the terms of the GNU General Public
  49.     Licence. In style it is similar to Smail 3, but its facilities
  50.     are more extensive, and in particular it has options for
  51.     verifying incoming sender and recipient addresses, for refusing
  52.     mail from specified hosts, networks, or senders, and for
  53.     controlling mail relaying.
  54.  
  55.     Exim is intended for use as an Internet mailer, and therefore
  56.     handles addresses in RFC 822 domain format only. It cannot handle
  57.     'bang paths', though simple two-component bang paths can be
  58.     converted by a straightforward rewriting configuration. However, 
  59.     there is no problem in interfacing Exim to UUCP systems, provided 
  60.     they use domain-style addressing.
  61.  
  62.     Exim is in production use at quite a few sites, some of which
  63.     move hundreds of thousands of messages per day.
  64.  
  65.     The following operating systems are currently supported: AIX, BSDI, DGUX,
  66.     FreeBSD, HI-OSF (Hitachi), HP-UX, IRIX, Linux, MIPS RISCOS, NetBSD,
  67.     OpenBSD, DEC OSF1 (aka Digital UNIX), SCO, SCO SVR4.2 (aka UNIX-SV),
  68.     SunOS4, SunOS5 (Solaris 2), Ultrix, and Unixware.
  69.  
  70.     Further information can be obtained from the Exim web sites:
  71.  
  72.     http://www.exim.org      (main site, in the UK)
  73.     http://www.us.exim.org   (a mirror in the USA)
  74.  
  75. |qmail:      Author Daniel Bernstein <djb@pobox.com>
  76. |
  77. |    [Ed note: Qmail, along with Exim, is the most often recommended
  78. |    sendmail replacement.  Qmail is capable of handling very high mail
  79. |    volumes. Qmail is one of the few mailers capable of integrating
  80. |    spam filters directly, however, given how this is done, qmail probably
  81. |    could not match the volumes of, say, Mailshield - which was designed
  82. |    for the purpose of filtering spam from the beginning.]
  83. |
  84. |    Web page:   http://www.qmail.org
  85. |    also:   ftp://koobera.math.uic.edu/www/qmail.html
  86. |
  87. |    Download:
  88. |    ftp://koobera.math.uic.edu/pub/software/qmail-1.03.tar.gz
  89. |    ftp://koobera.math.uic.edu/www/software/dot-forward-0.71.tar.gz
  90. |    ftp://koobera.math.uic.edu/www/software/fastforward-0.51.tar.gz
  91. |    ftp://koobera.math.uic.edu/www/software/ucspi-tcp-0.84.tar.gz
  92. |
  93. |    RPMs:       ftp://moni.msci.memphis.edu/pub/qmail
  94. |
  95. |    Lists:      mailto:qmail-help@list.cr.yp.to
  96. |        mailto:qmailannounce-help@list.cr.yp.to
  97. |
  98. |    qmail is an MTA for UNIX and UNIX-like systems (including FreeBSD,
  99. |    Linux, SunOS, Solaris, HP/UX, AIX, amongst others).  It was written by
  100. |    Dan Bernstein to overcome the limitations of and flaws in sendmail, and
  101. |    to demonstrate by example that there are better ways of doing some
  102. |    things (see Maildirs below).
  103. |
  104. |  * qmail is Modular
  105. |
  106. |    qmail follows the UNIX philosophy of combining small single-purpose
  107. |    tools together.  Instead of being one enormous setuid-root binary,
  108. |    qmail comprises a suite of small programs, each of which does one
  109. |    particular job.  This makes qmail flexible, allowing substitutions
  110. |    to be made for individual parts of the system according to one's
  111. |    requirements.
  112. |
  113. |    Substituting qmail-qmqpc for qmail-queue, for example, turns qmail
  114. |    into "mini-qmail" (see below).  For another example, all user
  115. |    authentication in the POP3 server is done by calling a separate
  116. |    external utility program, checkpassword, so changing the
  117. |    authentication scheme merely involves replacing that program.
  118. |
  119. |    Even qmail's configuration is modular.  qmail doesn't have large
  120. |    monolithic configuration files with complex structures, that have to
  121. |    be read and parsed every time that a new mail process is created,
  122. |    only to have 70% or more of that information remain unused because
  123. |    it is irrelevant to the task at hand.  qmail's configuration
  124. |    comprises individual files in /var/qmail/control, each file having a
  125. |    single job.  The names of the local domains are listed, one per
  126. |    line, in /var/qmail/control/locals, for example.  Many configuration
  127. |    tasks (and FAQ answers!)  are, as a result of this philosophy,
  128. |    one-liners involving `echo' and `cat'.
  129. |
  130. |  * qmail is Secure
  131. |
  132. |    qmail was designed to be secure.  Not only does the mail system not
  133. |    trust the outside world, but different modules in the mail system
  134. |    don't even trust one another.  Different parts of the mail system
  135. |    run under different non-privileged UIDs ("qmaild", "qmailr",
  136. |    "qmailq", &c.).  So, for example, even if the SMTP server
  137. |    (qmail-smtpd, which runs as user "qmailr") were compromised, the
  138. |    rest of the system will not be.
  139. |
  140. |    qmail has only one setuid binary, qmail-queue which is setuid to one
  141. |    of the qmail user IDs, not root.  qmail has only two programs that
  142. |    run as root, qmail-start which spawns the other daemon processes
  143. |    under the correct UIDs and qmail-lspawn which spawns the local
  144. |    delivery program qmail-local under the UID and GID of the user being
  145. |    delivered to.  Neither program writes to any files or spawns any
  146. |    program under the root user ID.
  147. |
  148. |    And, of course, qmail doesn't treat root as a "real" user, and so
  149. |    never delivers mail as root.
  150. |
  151. |  * qmail provides a flexible aliasing/forwarding mechanism, qmail files
  152. |    qmail supports /etc/aliases and .forward with its fastforward and
  153. |    dot-forward packages.  However, it is a testament to the power and
  154. |    versatility of qmail's own "native" aliasing and forwarding
  155. |    mechanism that both are merely plug-ins that run off it.
  156. |
  157. |    With qmail, each user controls all local parts that begin with the
  158. |    user's username, allowing each user to have an unlimited number of
  159. |    different local parts.  Delivery to each local part is (optionally)
  160. |    controlled by a separate .qmail-* file in the user's home directory
  161.  
  162.  
  163. uumail:
  164.  
  165.     Uumail is a very old and obsolete precursor to smail 2.5.  Included
  166.     here only because I know that uumail sites still exist.  You
  167.     should not install uumail in new configurations, and existing
  168.     uumail sites should convert to something more modern.
  169.  
  170. smail 2.5: author The UUCP Mapping Project
  171.  
  172.     [Not recommended for general use now.  UUCP is very little used.]
  173.  
  174.     Smail 2.5 is a small, simple and hard-coded rule MTA for use on
  175.     UUCP networks.  It understands RFC compliant headers, will
  176.     generate RFC compliant Internet-style headers, can
  177.     use domains, aliases, a pathalias UUCP routing database, and
  178.     is very simple to install.  For full functionality, you will
  179.     also want pathalias and a map unpacker.  The one thing
  180.     it cannot do by itself is mail-to-pipe and mail-to-file aliasing.
  181.     For that, you need Zeeff's lmail, deliver or procmail.
  182.  
  183.     Smail 2.5 has the capability of coalescing addresses into single
  184.     UUCP transfers, and knows how to query UUCP for the names
  185.     of UUCP neighbors, and autoroute if necessary.
  186.  
  187.     Smail 2.5 has a few bugs that are (usually) pretty rarely seen
  188.     in operation.  There have been a number of patches posted for it,
  189.     but it is recommended that you do not apply them - some were
  190.     ill-conceived, buggy in their own right, or conflicting with others.
  191.     The only patches that I feel safe in recommending is Chip
  192.     Salzenberg's patches for use with Xenix MICNET - which are
  193.     unnecessary unless you are in the unfortunate position of having
  194.     to actually *use* MICNET.  Chip Salzenberg's "deliver" package
  195.     (see below) combined with "smail-deliver.pch" from comp.sources.unix,
  196.     volume 25 issue 107, makes the MICNET modifications to smail
  197.     itself unnecessary.
  198.  
  199.     In particular, do not apply the "mail-to-pipe/file" patches that
  200.     float around for smail 2.5.  These are a major security hole.
  201.  
  202.     Smail 2.5 can also be used with sendmail as a UUCP router.
  203.  
  204.     Smail 2.5 was posted in comp.sources.unix in 1987, volume 11
  205.     with archive name "smail3" (but it isn't the same thing as
  206.     smail 3 below).
  207.  
  208. lmail: Author Jon Zeeff <zeeff@b-tech.ann-arbor.mi.us, zeeff@ais.org>
  209.  
  210.     When you install smail 2.5, you link the original /bin/mail (binmail
  211.     above) to /bin/lmail to perform the task of actually delivering the
  212.     mail to the user's mailbox (LDA).
  213.  
  214.     Since smail 2.5 was not capable of doing mail-to-pipe and mail-to-file
  215.     aliasing, Jon Zeeff wrote a replacement lmail that implemented
  216.     these (along with user mailbox delivery).
  217.  
  218.     Jon's program is okay for casual use, but has some pretty serious
  219.     bugs.  Fixed versions are available, but you're probably better
  220.     off installing deliver or procmail.
  221.  
  222. smail 3: Author Ronald S. Karr* <tron@veritas.com> and Landon Curt Noll.
  223.  
  224.     Smail3.x is a domain-capable mail router and delivery program that
  225.     works in the UUCP zone and on the Internet and that is capable of
  226.     gatewaying between the two.  It was written primarily by me (Ronald
  227.     S.  Karr) and Landon Curt Noll, with the blessings of the original
  228.     Smail1 and Smail2 authors.
  229.  
  230.     Smail3 supports SMTP, UUCP mail, alias files, .forward files, mailing
  231.     list directories, pathalias files, /etc/hosts files, the domain name
  232.     system, and can also query uucp for neighboring sites, automatically.
  233.     It also supports use of encapsulated SMTP commands for delivery over
  234.     UUCP connections, which allows batching of multiple messages into a
  235.     single UUCP transaction, and allows many addresses to be passed with a
  236.     single message transfer, which can greatly decrease the traffic
  237.     generated for large mailing lists.  It is also very simple to configure
  238.     with a reasonable certainty of correctness.
  239.  
  240.     Smail3 includes pathalias and a reliable map unpacker.
  241.  
  242.     Rather than using configuration files to resolve addresses based on
  243.     their syntax, ala sendmail, Smail3 uses a database metaphore for
  244.     resolving addresses based on their contents.  The set of methods that
  245.     Smail3 uses for resolving local addresses and hosts is configurable and
  246.     extensible.  Smail3's methods for parsing addresses are not
  247.     configurable.  It is the opinion of the authors that addressing on the
  248.     Internet and in the UUCP zone has become sufficiently standardized that
  249.     attempts to allow configurability in this area are now a hindrance to
  250.     the correct working of the network.
  251.  
  252.     Questions related to Smail3 are usually discussed in comp.mail.smail.
  253.     There are also two discussion mailing lists.  To join the mailing
  254.     lists, send mail to:
  255.  
  256.     smail3-users-request@cs.athabascau.ca
  257.  
  258.     The current release of Smail3 is 3.3.x, and can be found on uunet,
  259.     in the directory /archive/networking/mail/smail/smail-3.1.29.1.tar.Z.
  260.  
  261.     Smail 3 is covered under the GPL (if it matters)
  262.  
  263. sendmail: Original author Eric Allman
  264.  
  265.     Sendmail is the granddaddy of all intelligent MTA's.  It can do just
  266.     about anything.  It's main problem is that it can do just about
  267.     anything.  Modification of sendmail's configuration tables (which is
  268.     necessary with most vendor-supplied versions) is NOT for novices.
  269.     The language of the sendmail.cf is cryptic, but that isn't really
  270.     the problem.  The problem is that it's extremely difficult
  271.     to know when the rules you are implementing are the right thing--
  272.     many sendmail configurations do slightly buggy, or even extremely
  273.     buggy, or illegal things.  Default configurations and minimal changing
  274.     is the approach to take.  The Sendmail 8.9 configuration  environment
  275.     is recommended.
  276.  
  277.     Worse, every vendor's version of sendmail is different, and many
  278.     of their sendmail.cf's don't work at all.  HPUX is one example
  279.     of where the sendmail.cf is actually pretty sane.  HP is to
  280.     be congratulated.  On the other hand, some vendors, who shall
  281.     remain nameless, can't even get their sendmail to deliver to local
  282.     users, let alone get their sendmail to speak SMTP on a LAN.
  283.  
  284.     The major problem with sendmail is that it tries to do too many
  285.     things.  Rather than confining itself to handling local mail, and
  286.     simply routing external mail and leaving transport-specific
  287.     format/standards conversions to transport software, it attempts
  288.     (nay virually *insists*) that you have to do all of the
  289.     format/standards conversions for different transports all at once.
  290.     Which results in configuration files that are veritable nightmares
  291.     to maintain.  And that many sendmail.cf files depend on out-of-date
  292.     standards for different transports, rather than trying to unify
  293.     them (as in RFC976).
  294.  
  295.     Indeed, while common wisdom and practice mandates that MTAs don't
  296.     rewrite headers, sendmail makes it extremely difficult to *not*
  297.     rewrite headers.  Which results in many major systems attempting to
  298.     "be nice", yet, totally scramble return addresses and the like.
  299.  
  300.     There are several different sendmail lineages in the world but they
  301.     seem to be coming together now with Eric Allman's work creating
  302.     sendmail V8.x.  Sendmail V8.1 was shipped with BSD 4.4 UNIX.
  303.  
  304.     It is strongly recommended that anyone contemplating running sendmail
  305.     upgrade to at least 8.9.x (see www.sendmail.org), which has a number
  306.     of serious security problems fixed, or at least configurable w.r.t.
  307.     email spam.  Ie: anti-relay, HELO overflow etc.
  308.  
  309.     Another point to remember is that sendmail, historically, has been
  310.     where a large number of severe security holes have been found.  From
  311.     the infamous RTM Internet Worm, to the latest ones "CERT"d in
  312.     witthin the past few months.  Indeed, if your application is
  313.     security-critical, I recommend that you should *not* use sendmail on
  314.     your security-critical systems, such as your firewalls.
  315.  
  316.     Unless your vendor has provided sendmail 8.9 or better, do not expose
  317.     it to the Internet.  In particular, SunOS and up to recent Solaris are
  318.     extremely susceptable to abuse, _are_ being abused, and cannot be fixed
  319.     without upgrading.  The latest Solaris sendmail patch resolves these
  320.     problems.
  321.  
  322.     Administrators wishing something easier to configure than sendmail,
  323.     particularly with the addition of filtering rules, are best advised
  324.     to consider using qmail, exim instead, or, using mailshield SMTP
  325.     relaying to stand in "front" of sendmail.
  326.  
  327.     Theoretically, all of these problems have been removed from sendmail
  328.     8.6.5 (now 8.9) or later, but, there's bound to be more found.  While
  329.     some of this can be due to the much larger installed base of sendmail,
  330.     other mailers with improved function partitioning (such as the
  331.     channel-oriented MMDF or PP) will usually be inherently more secure.
  332.  
  333.     I am being harsh on sendmail - sendmail programming is, after all, a
  334.     good source of revenue for consultants ;-) But, if you obtain a good
  335.     sendmail 8.9.x, or are willing to spend the time to learn it,
  336.     sendmail will do what you want.  Well.  Don't, however, even think
  337.     of playing with the configuration files without a copy of the
  338.     Sendmail book by Costales, Allman and Rickert mentioned in the book
  339.     list above.  It is *absolutely* essential.
  340.  
  341.     Sendmail is discussed in comp.mail.sendmail.
  342.  
  343.  
  344. ZMailer: Original author  Rayan Zachariassen* <rayan@cs.toronto.edu>
  345.          Current author   Matti Aarnio <mea@nic.funet.fi>
  346.  
  347.     ZMailer is intended for gateways or mail servers or other large site
  348.     environments that have extreme demands on the abilities of the mailer.
  349.  
  350.     Code and Design features:
  351.  
  352.     + Strong limits on host impact.
  353.     + Secure design (and hopefully implementation).
  354.     + Natural fit for client/server environments.
  355.     + Extremely customizable configuration mechanism.
  356.     + Flexible database interface with support for: sorted files, unsorted
  357.       files, dbm, ndbm, gdbm, nis (yellow pages), dns (BIND resolver),
  358.       /etc/hosts file, and in-core data.
  359.     + Efficient message queue management.
  360.     + Fast binary-transparent SMTP server and client.
  361.     + MIME-facilities for message transport.
  362.     + Low-technology implementation, with high-tech options for performance.
  363.  
  364.     Default configuration file features:
  365.  
  366.     + Default configuration will work for most sites.
  367.     + Network protocol support for: smtp, uucp, bitnet, mail to news.
  368.     + An easy way of overriding any external routing information.
  369.     + Automatic handling of mailing lists.
  370.  
  371.     It is available by anonymous FTP from:
  372.         ftp://ftp.funet.fi/pub/unix/mail/zmailer/   (Mr. Aarnio's versions)
  373.     Alternate (some of them old) versions:
  374.         ftp://ftp.cs.toronto.edu/pub/edwin/zmailer2.2.e4.tar.Z
  375.         ftp://ftp.cs.toronto.edu/pub/zmailer.tar.Z
  376.  
  377. MMDF: [reviewed by I.Sparry@gdt.bath.ac.uk, updated by Randall Atkinson
  378.     2000/02/21]
  379.  
  380.     MMDF is a MTA. It works on the principle that you have communications
  381.     channels, both incoming and outgoing, and it arranges for messages to
  382.     pass between them.
  383.  
  384.     Strong points include:
  385.     * Ability to turn up and down debugging level on the fly
  386.     * Very strong on authentication, and permission checking.
  387.     * Can block mail based on who it came from, how it got there,
  388.       who it is going to.
  389.  
  390.     It is older than sendmail, simpler than sendmail, and it is a great
  391.     pity that it was not shipped as standard instead of sendmail.
  392.  
  393.     [MMDF is standard on some systems - primarily SCO UNIX.]
  394.  
  395.     It has one major advantage to people in the UK, in that it knows how to
  396.     handle mail addresses in our 'correct' format (Most significant part first,
  397.     e.g. net.uu.uunet), as well as the thing the rest of the world uses :-) :-)
  398.  
  399. |    A mailing list for MMDF discussion is at mmdf2@skymaster.c2-tech.com
  400. |    requests for addition to the list to mmdf2-request@skymaster.c2-tech.com.
  401. |
  402. |    MMDF is being maintained at the University Kaisers-Lauten in
  403. |    Germany:
  404. |
  405. |    http://www.mathematik.uni-kl.de/ftp/pub/Sources/mail+news/mmdf and
  406. |    ftp://www.mathematik.uni-kl.de/pub/Sources/mail+news/mmdf
  407. |
  408. |    The MMDF Users Group has a web site at http://www.mmdf.org
  409.  
  410. PP: Author University College London
  411.  
  412.     PP is a Message Transfer Agent, intended for high volume message
  413.     switching, protocol conversion, and format conversion. It is targeted for
  414.     use in an operational environment, but may also be useful for investigating
  415.     Message related applications. Good management features are a major
  416.     aspect of this system. PP supports the 1984 and 1988 versions of the
  417.     CCITT X.400 / ISO 10021 services and protocols. Many existing RFC 822
  418.     based protocols are supported, along with RFC 1148 conversion to X.400.
  419.     PP is an appropriate replacement for MMDF or Sendmail, and also supports
  420.     SMTP and UUCP mail.
  421.  
  422.     For more information contact: support@xtel.co.uk or xtel@cs.nott.ac.uk
  423.     The latest version is PP-6.0, which was posted in comp.sources.misc,
  424.     volume 27.
  425.  
  426.     [Ed note:]
  427.     PP is usually used in combination with the ISODE package, which
  428.     also provides copious documentation for PP.  PP itself is
  429.     "freeware", but ISODE and the PP documentation is not - site
  430.     licenses are rather pricy.  PP is *very* large, and has quite a
  431.     number of more esoteric functions, such as FAX transmission using
  432.     the appropriate modems.  PP is ideal for large organizations with
  433.     demanding email requirements (eg: 100s of machines and 1000s of
  434.     users), where PP would be used as "backbone mail servers", and something
  435.     simpler on the "client" computers.  It does have _substantial_
  436.     learning and support requirements, and is *not* suitable for smaller
  437.     installations.  It does, however, shine in large production environments,
  438.     where policy-based routing, high levels of security, or extensive
  439.     gatewaying to different transports is required.
  440.  
  441. SVR4 mail: Author AT&T (description written by Tony Hansen,
  442.     hansen@pegasus.att.com)
  443.  
  444.     The System V Release 4 mail system is a domain-capable mail router and
  445.     delivery program that works in the UUCP zone and on the Internet and
  446.     that is capable of gatewaying between the two.
  447.  
  448.     SVR4 mail supports SMTP, UUCP mail, alias files, forwarding files,
  449.     mailing list directories, /etc/hosts files, the domain name system, and
  450.     can also query uucp for neighboring sites, automatically.  (System V
  451.     Release 4.1 also allows batching of multiple messages into a single UUCP
  452.     transaction, and allows many addresses to be passed with a single
  453.     message transfer, which can greatly decrease the traffic generated for
  454.     large mailing lists.)  It is also very simple to configure with a
  455.     reasonable certainty of correctness.
  456.  
  457.     It also supports mail-to-pipe and mail-to-file.
  458.  
  459.     SVR4 mail uses configuration files to resolve addresses based on their
  460.     syntax, somewhat similar to sendmail, but using regular expressions and
  461.     a more easily understood syntax. The set of methods that SVR4 mail uses
  462.     for resolving local and remote addresses and hosts is configurable and
  463.     extensible.
  464.  
  465.     Questions related to SVR4 mail are usually discussed in comp.mail.misc.
  466.  
  467.     SVR4 mail is a standard part of System V Release 4; unfortunately, some
  468.     vendors have not realized that SVR4 mail is not the same mailer as the
  469.     SVR3 mail system, and have replaced it with other inferior mail systems.
  470.  
  471. deliver: Author Chip Salzenberg* <chip@fin!chip@dg_rtp.dg.com>
  472.  
  473.     Deliver allows any user to write a shell script that processes all
  474.     incoming mail messages for that user.  The system administrator may
  475.     also install scripts that process all messages by installing
  476.     it as the Local Delivery Agent (lmail replacement).
  477.  
  478.     The output of a script is a list of mail addresses, files and programs
  479.     that should receive the message.  It has access to each message as it
  480.     is processed, so the action can be content dependent.  The script may
  481.     also generate automatic replies, like the "vacation" program, or pass
  482.     along a modified version of the original message.
  483.  
  484.     Deliver can be used to construct mail-based services (e.g. automatic
  485.     mailing list maintenance).  It can also be used to filter mail
  486.     automatically in prearranged ways (e.g. encryption and decryption,
  487.     tossing junk mail, or vacation notices).
  488.  
  489.     Deliver was last posted in comp.sources.reviewed, volume 1.  The
  490.     current version is 2.1.12.
  491.     It can be retrieved from <ftp:ftp.cs.uni-sb.de/pub/mail/deliver>
  492.  
  493. procmail: Author Stephen R. van den Berg*
  494.                 <berg@pool.informatik.rwth-aachen.de>
  495.  
  496.     Can be used to create mail-servers, mailing lists, sort your incoming
  497.     mail into separate folders/files (real convenient when subscribing to
  498.     one or more mailing lists or for prioritising your mail), preprocess your
  499.     mail, start any programs upon mail arrival (e.g. to generate different
  500.     chimes on your workstation for different types of mail) or selectively
  501.     forward certain incoming mail automatically to someone.
  502.  
  503.     Procmail can be used:
  504.         - and installed by an unprivileged user (for himself only).
  505.     - as a drop in replacement for the local delivery agent /bin/mail
  506.       (with biff/comsat support).
  507.     - as a general mailfilter for whole groups of messages (e.g. when
  508.       called from within sendmail.cf rules).
  509.  
  510.     The accompanying formail program enables you to generate autoreplies,
  511.     split up digests/mailboxes into the original messages, do some very
  512.     simple header-munging/extraction, or force mail into mail-format (with
  513.     leading From line).
  514.  
  515.     Also included is a comprehensive mailinglist/archive management system.
  516.  
  517.     Since procmail is written entirely in C, it poses a very low impact
  518.     on your system's resources (under normal conditions, when you don't
  519.     start other programs/scripts from within it).
  520.  
  521.     Procmail was designed to deliver the mail under the worst conditions
  522.     (file system full, out of swap space, process table full, file table
  523.     full, missing support files, unavailable executables; it all doesn't
  524.     matter).  Should (in the unlikely event) procmail be unable to deliver
  525.     your mail somewhere, the mail will bounce back to the sender or reenter
  526.     the mailqueue (your choice).
  527.  
  528.     A recent version can be picked up at various comp.sources.misc archives.
  529.     The latest version (3.03) can be obtained directly from the ftp-archive at:
  530.         ftp.informatik.rwth-aachen.de (137.226.225.3)
  531.         (g)zipped:          pub/packages/procmail/procmail.tar.gz       <160KB
  532.         compressed:         pub/packages/procmail/procmail.tar.Z        <224KB
  533.  
  534.     [Ed note: I had noted reported difficulties in integrating procmail
  535.     with System V and/or smail 2.5.  The 2.70 version of Procmail eliminated
  536.     these difficulties.]
  537.  
  538.  mailagent: Author Raphael Manfredi* <ram@hptnos02.grenoble.hp.com>
  539.  
  540.     The mailagent is yet another mail filter, written in perl, which
  541.     will let you do anything with your mail. It has all the features
  542.     you may expect from a filter: mailing lists sorting, forwarding to
  543.     MTA or to inews, pre-processing of message before saving into
  544.     folder, vacation mode, etc... It was initially written as an
  545.     ELM-filter replacement, but has now enough power to also supplant
  546.     MMDF's .maildelivery. There is also a support for @SH mail hooks,
  547.     which allows you to automatically distribute patches or software
  548.     via command mails.
  549.  
  550.     The mailagent was designed to make mail filtering as easy as it can
  551.     be. It is highly configurable and fairly complete. Rules are
  552.     specified in a lex-like style, with the full power of perl's
  553.     regular expressions. The automaton supports the notion of mode, and
  554.     header selection has many magic features built-in, to ease the rule
  555.     writing process.
  556.  
  557.     To give a simple example, the two following rules:
  558.  
  559.         Subject: /cron output/    { SAVE cron };
  560.         To Cc: dist-users        { FORWARD friend@acri.fr; LEAVE };
  561.  
  562.     would save in a folder 'cron' all cron-related mail, and forward
  563.     mail from the dist-users mailing list to a friend, leaving a copy
  564.     in the system mailbox for immediate processing...
  565.  
  566.     It supports delivery to plain UNIX folder, to MMDF-style folders or
  567.     to MH folders with built-in unseen sequence updates, as specified
  568.     in your ~/.mh_profile. It may therefore replace MH's slocal program
  569.     as well.
  570.  
  571.     Mailagent can be dynamically extended (that's the advantage of
  572.     having it written in perl) with new filtering commands that will
  573.     behave exactly like built-in ones; this operation being done
  574.     without changing a single source line in the program itself, of
  575.     course. It also provides a generic mail server layer, where
  576.     user-defined commands can be easily plugged in, mailagent taking
  577.     care of the lower-level stuff.
  578.  
  579.     The distribution comes with a set of examples, an exhaustive test
  580.     suite, and naturally a detailed manual page. It should be noted
  581.     that the mailagent will work even if your system administrator
  582.     forbids "| programs" hooks in the ~/.forward, provided you have
  583.     access to some sort of cron daemon.
  584.  
  585.     The mailagent program is available from any comp.source.misc
  586.     archive and thanks to Christophe Wolfhugel
  587.     <Christophe.Wolfhugel@grasp.insa-lyon.fr>, from ftp.univ-lyon1.fr
  588.     (134.214.100.6) under /pub/unix/mail/tools, file
  589.     mailagent-3.0.tar.gz
  590.  
  591. pathalias: Author Peter Honeyman
  592.  
  593.     [Not recommended anymore, due to the shift away from UUCP.  Included
  594.     for historical interest, and the occasional use in very special
  595.     situations.]
  596.  
  597.     Pathalias reads the UUCP Map Project maps (they need to be extracted
  598.     from the postings first) and constructs a database containing the
  599.     minimum cost route to any machine in the maps.  This database can
  600.     then be used with any mailer that knows how to search the database
  601.     (eg: smail 2.5, Zmailer?, and some versions of sendmail.  Smail 3
  602.     comes bundled with pathalias).
  603.  
  604.     There were previous versions of this program.  You must use
  605.     pathalias version 10 (latest version), because some map format
  606.     changes have been made and only pathalias 10 can parse them.
  607.     If your pathalias doesn't give a syntax error on:
  608.     echo "file {foo}" | pathalias
  609.     It's the new one.
  610.  
  611.     There were other route-generating programs, but all (as far as
  612.     I know) are very obsolete, and none run as fast as pathalias
  613.     (still, which can be rather hard on machines with smallish virtual
  614.     memory or RAM capacities).
  615.  
  616.     pathalias 10 is available from comp.sources.unix archives,
  617.     volume 22.  A patch was just released in comp.sources.unix
  618.     (vol 25) that addresses an oddity when used with smail (not that
  619.     I've ever noticed it).
  620.  
  621. uuhosts: Author John Quarterman
  622.  
  623.    [Not recommended anymore.  Included for historical interest.]
  624.  
  625.     The "defacto" standard UUCP Map Project map unpacker.  Includes
  626.     a program to arbitrarily view individual map entries.  Uuhosts
  627.     implements trojan horse/virus security by running under
  628.     a "chroot()" system call.  Uuhosts does not appear to be
  629.     actively maintained, and the last versions that I have inspected
  630.     were unable to easily compress the maps (a full set of maps
  631.     is >6000 blocks), had no provision for automatically
  632.     running pathalias, and will not work with the newest version
  633.     of cnews.  Further, uuhost's header checking is so picky
  634.     that the slightest change in the map format will cause
  635.     uuhosts to reject map updates.
  636.  
  637.     Use of uuhosts now will require some minor hacking - and this
  638.     hacking will stretch your knowledge of Bourne shell programming.
  639.  
  640.     The last edition, "uuhost4" (version 1.69) appears to have
  641.     been posted in comp.sources.unix in volume 3, 1986.
  642.  
  643.     Do not be confused by Jan-Piet Mons "uuhost 2.0" program posted
  644.     in alt.sources.  This is not a map unpacker.  It is just
  645.     a map viewer, and is a subset of the real uuhosts.
  646.  
  647. unpackmaps: Author Chris Lewis* <clewis@ferret.ocunix.on.ca>
  648.  
  649.     [Not recommended anymore, sniff ;-)]
  650.  
  651.     Unpackmaps is a superset of the functionality of uuhosts.
  652.     It obtains its security by doing the map unpacking with
  653.     a specialized parser that knows the map article format
  654.     rather than invoking a shar/shell.  Compression and pathalias
  655.     invocation is automatic, correctly takes into account
  656.     the change date of local configuration files, and will
  657.     work with the latest Cnews.
  658.  
  659.     The newest version of unpackmaps, version 4.1, has been
  660.     released to comp.sources.misc, and appeared in volume 34.
  661.     This version is entirely written in C, is considerably faster
  662.     than unpackmaps 3 or uuhosts, has considerably more features,
  663.     and will work with Brian Reids PostScript net maps too.
  664.  
  665. unshar: Author Lee Ward, modified by Mark Moraes* <moraes@deshaw.com>
  666.  
  667.     unshar is evolved from getmaps by Lee Ward.  It is has a specialized
  668.     and limited parser that understands most simple shar formats.  It is
  669.     capable of automatically unpacking new files from a newsgroup spool
  670.     directory, and requires no interaction whatsoever with the news
  671.     system.  Apart from UUCP maps, it can be used to automatically and
  672.     safely unpack shar files from the sources newsgroups.  It does not
  673.     handle some of the newer, esoteric shar formats that do automatic
  674.     uudecodes, etc.  Ftp'able from
  675.     ftp.cs.toronto.edu:/pub/moraes/unshar.tar.gz.
  676.