Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk1.iso/answers/mail/setup/unix/part2

Text File | 1994-09-22 | 27.4 KB | 605 lines

Newsgroups: news.admin.misc,comp.mail.misc,news.answers,comp.answers
Path: bloom-beacon.mit.edu!hookup!nic.ott.hookup.net!ecicrl!clewis
From: [e-mail] (Chris Lewis)
Subject: UNIX Email Software Survey FAQ [Part 2 of 3]
Summary: How to set up Email on UNIX systems.
Message-ID: <[e-mail]>
Supersedes: <[e-mail]>
Approved: [e-mail]
Date: Thu, 22 Sep 1994 13:20:13 GMT
Expires: Thu, 27 Oct 1994 13:20:04 GMT
Reply-To: [e-mail] (Mail FAQ commentary reception)
References: <[e-mail]>
Organization: Elegant Communications Inc., Ottawa, Canada
Keywords: mail software survey UNIX FAQ
Followup-To: poster
Lines: 586
Xref: bloom-beacon.mit.edu news.admin.misc:22646 comp.mail.misc:9498 news.answers:26158 comp.answers:7417

Archive-name: mail/setup/unix/part2
Last-modified: Sat Mar 19 23:14:03 EST 1994

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

        Copyright 1991, 1992, 1993, Chris Lewis

    Redistribution for profit or altered content/format
    prohibited without permission of the author.  Other
    redistribution must contain this copyright notice
    and attribution.

------------------------------
Subject: Configuration Issues:

What you need for email connectivity is determined by:

    1 What networks you intend to connect to.
      The Internet (hence SMTP)?  UUCP sites?  X.400?
      Bitnet?  Others?  Combinations?
    2 What links you have or are willing to install
      Internet T1?  T2?  UUCP?  Other?  [Details on how to
      make your connections is beyond the scope of this FAQ,
      but can usually be found out from the provider (other end)
      of the link]
    3 what user interface you want to use.  This is largely
      an independent issue, so consult the Specific Package
      Reviews directly.

------------------------------
Subject: Recommended MTA Configurations:

These configurations are based upon my own experience, and the
experience of others.  Careful installation of any of these
configurations will result in a solid, reliable mail system
that respects the appropriate "do's and don'ts".  Each configuration
represents a compromise of ease of installation and maintenance
versus sophistication and capabilities.

One thing you should consider is what you already have on your
system.  You will invariably have "binmail", and will have a good
chance at already having sendmail.  Some systems come with
smail (if 2.3, junk it)  The configurations shown below are *minimal*
configurations, so you should consider whether you want to use what
you already have or not.

Scenario 1:  Only UUCP connections.

    Smail 2.5.  If you want to set up a routing database of
    your own, you will also need pathalias, and unpackmaps or
    uuhosts.  Instead, though, you can configure smail 2.5 to
    smart-host most destinations to a nearby friendly site
    who'll do your routing for you without having to run
    the routing software.  Note further, that you can run
    pathalias on just a subset of the full set of maps.
    [Unpackmaps makes this particularly easy to do]

    Smail 2.5, as shipped, does not support mail-to-pipeline
    or mail-to-file aliasing.  If you need these, at a minimum,
    you should obtain lmail.  If you intend more than casual
    use of these features, it is recommended that you obtain
    deliver or procmail instead of lmail.

    Even if you have sendmail already, you can integrate smail 2.5
    with it to do your UUCP routing.  (though, some later versions
    of sendmail can do routing themselves)

    If you're a little more demanding of your mail connections, smail 3
    is also a good choice, and works particularly well for systems that
    are UUCP connected to Internet sites.

Scenario 2:  SMTP connections (optionally, some UUCP connections too).

    Generally speaking, sendmail will do this for you and you have
    a good chance to have it already.  However, for the novice, it
    is recommended that smail 3 be used instead [see review of
    sendmail below].  Smail 3 includes all of the routing software
    and can do mail-to-pipeline and mail-to-file, so none of the auxiliary
    programs mentioned in scenario 1 are necessary.

    Most sendmails don't include UUCP routing mechanisms, so you would
    need pathalias and unpackmaps or uuhosts if you wish to set up
    a UUCP routing database.  Further, most sendmails don't know
    how to query a pathalias database directly, so you may have to hack
    your own path lookup program into the sendmail.cf (smail 2.5 can
    be used for this purpose provided that you will have a UUCP link
    to the outside world)

    Both MMDF and PP can also be used, but PP is usually overkill.

    Deliver or procmail are still quite useful in this configuration
    for extended alias facilities.

Scenario 3:  Connections to other networks (optionally including
    SMTP or UUCP), or very high loading.

    Your best bets are MMDF, PP or zmailer.

    You can implement other network interfaces with sendmail, but
    not only will you probably have to roll your own, but sendmail
    can't cope with high loading very well.  Ditto smail 3.

There are other configurations.  See the Package Reviews to
determine which packages are appropriate.

------------------------------
Subject: Package Reviews

Honesty requires me to point out which software packages were
reviewed by their author (including me ;-).  I do so by appending
a "*" to the name of the author.  In some cases, the material
has been cribbed from FAQ's or general information blurbs.

It is worth noting, though, that most of these packages are well
known, and have been in operation at many sites for periods of
a year or more.  These packages do their job well, and have been
extensively thrashed out in the best debugging laboratory in the
universe (USENET ;-)

A few packages have been mentioned prior to their release.
(unpackmaps 4, the occasional beta version).  It is
recommended that these versions be avoided by novices until they
have had a chance to settle for a little while.  This FAQ will
note when such software seems (according to rumour *I* hear) to be
stable enough for general use.

Some of these packages are capable, by various bits of hackery,
of doing a lot more than is claimed for them.  But I refrain
on telling you how to "take the covers off".  Given the
intended audience, that would be tantamount to trying to
teach preschoolers do-it-yourself brain surgery.  Please don't
take this as condescending - I've been working on/in/with email
systems for over 12 years and I *still* won't play with (as
just one example) sendmail.cf's.

Therefore, I restrict myself largely to "out-of-the-box" functionality,
"fill-in-the-blank" configurability, and normal documented installation
procedures.  Beyond that, you're on your own.

binmail

    binmail is usually really called "mail". On System V prior to
    Release 4, it is a really simple UA that does dual duty as the
    TA.  It's pretty awful because it doesn't know how to set up
    headers properly, doesn't even know what a "Subject:" line is,
    and there's no way to do any kind of aliases.

    On BSD, binmail invokes sendmail to do the MTA function.  On
    System V prior to Release 4, you really do want to replace binmail's
    MTA functionality with something else.  However, you should not
    replace it in its "mail" (UA) functionality, because many
    system-level administration mechanisms will break.  Any new UA
    should be installed as a different name than "mail".

    Beginning with System V Release 4, "binmail"'s transfer agent
    capabilities were considerably enhanced to have similar capabilities
    to Smail 3 and sendmail.  There is usually no need to replace it with
    another mail agent.  (See SVR4 mail discussion below)

    Binmail stores mail in "mbox" format.

rmail

    binmail's TA functionality is implemented by linking mail
    to rmail.  It's rmail that you'd want to replace with smail 2.5
    etc.

Mail

    The original BSD UA.  It can support local profiles, aliases, folders,
    header previewing, out-going mail recording and all sorts of good stuff.
    An "okay" UA.  Available from BSD "freed-sources" archives.

    Mail stores mail in "mbox" format.

mailx

    AT&T's answer to BSD "Mail", from which it is descended.  Some versions,
    such as the 3b1 one, should be avoided because of a buggy port.  Not
    available in source form (it's proprietary but ubiquitous enough to be
    mentioned here).

    Mailx stores mail in "mbox" format.

mush: author Dan Heller* <[e-mail]>

    The "Mail User's Shell" is a "shell" for mail users.  That is, it
    has its own environment where you can configure not only the user
    interface, but the actual internal mechanisms.  Internally, mush
    has a csh-like scripting language, altho it's not as powerful as
    csh.  It has command-line aliases, file completion, if-else state-
    ments, command piping, and so on.  Because you can build your own
    commands, you can virtually build your own library of email features.

    Mush has two tty-based interfaces: the standard tty-mode (ala BSD
    Mail or sys-v mailx) and the fullscreen/curses mode (ala vi, emacs
    or even Elm).  You can set up key bindings that execute one or more
    mush commands, personalized commands or even UNIX commands.  You
    can even emulate keyboard input with keyboard macros and mappings.

    Mush also has a SunView interface that is more powerful than Sun's
    Mailtool, yet backwards compatible with most versions.  Most sunview
    users (if there are any left these days) prefer MushView over Mailtool.

    The current version of Mush is 7.2.3, last posted in comp.sources.misc
    volume 18 (with subsequent patches).  All three interfaces are
    available in one runtime binary.  Except for the MushView interface
    (which is only available on for suns), Mush is portable to everything
    that runs UNIX.  There is also a DOS port available for PCs and can
    run on most 286 machines. An older version of Mush (6.5) can run on
    as little as 640 of RAM.  (Mush-PC is typically used with UUPC.)

    The "next generation" of Mush is a commercial product called Z-Mail
    from Z-Code Software (mail [e-mail] for details).  All aspects
    of Mush are retained, yet it has grown to be far more powerful.  It
    runs under X windows with either a Motif or Open Look interface
    and also supports multi-media, user "functions" and a suite of new
    features.


    Mush stores its messages in "mbox" format, or MMDF format if you're
    using MMDF as your MTA.

    The newsgroup comp.mail.mush is dedicated to it.

    [Note: Z-Mail is not related at all to Zmailer.  Zmailer is a MTA]

elm: coordinator Syd Weinstein* <[e-mail]>

    (cribbed from comp.mail.elm FAQ)

    Elm is designed to run with "sendmail" or "/bin/rmail"
    (according to what's on your system) and is a full
    replacement of programs like "/bin/mail" and "mailx".  The
    system is more than just a single program, however, and
    includes programs like "frm" to list a 'table of contents'
    of your mail, "printmail" to quickly paginate mail files (to
    allow 'clean' printouts), and "autoreply", a systemwide
    daemon that can autoanswer mail for people while they're on
    vacation without having multiple copies spawned on the
    system.

    The most significant difference between Elm and most other
    mail systems is that Elm is screen-oriented.  Upon further
    use, however, users will find that Elm is also quite a bit
    easier to use, and quite a bit more "intelligent" about
    sending mail and so on.

    Current release is Elm 2.4 PL21..  Information on access is
    available from the server at DSI.COM:
    send mail to [e-mail]
    send elm index

    [Ed: elm is particularly good for novices.  The only drawback
    that I've heard is that elm is a bit less user configurable than,
    say, mush]

MM: Contact Joseph Brennan* <[e-mail]>
                Columbia University in the City of New York

    (cribbed from MM man page.)

    mm is a powerful electronic mail system which allows you to send, read,
    edit and manage messages quickly and easily.  It is designed to have the
    same interface as the MM program written and developed for DEC20s over a
    period of many years.

    mm was written using the CCMD package developed at Columbia.  Thus, it
    has copious internal help, completion of partially typed commands on use
    of the TAB key, and help on partial commands when ?    is typed.

    mm can read several mail-file formats.  Its default is mbox, the same
    format used by unix mail.  It also can read babyl, used by emacs rmail,
    and mtxt and MH.  It can copy messages from one file type to another.

    MM is a Freeware MUA copyright by Columbia University (as is this
    description).

    MM is available by anonymous ftp from cunixf.cc.columbia.edu, directory mm.
    The file mm-intro.txt there is a longer description of how it was developed.

    [Ed: MM also appears to be a good UA for novices.  From the examples
    in the manual page, it handholds extensively and is not screen oriented.]

MH: Maintainer John Romine <[e-mail]>

    The big difference between MH and most other "mail user agents" is
    that you can use MH from a UNIX shell prompt.  In MH, each command
    is a separate program, and the shell is used as an interpreter.  So,
    all the power of UNIX shells (pipes, redirection, history, aliases,
    and so on) works with MH--you don't have to learn a new interface.
    other mail agents have their own command interpreter for their
    individual mail commands (although the mush mail agent simulates a
    UNIX shell).  Mail messages are stored in individual files.

    The current version of MH is 6.8.3 and supports MIME.  MH comes
    standard with Ultrix 4.0 and later, and AIX 3.1 and later.
    via anonymous ftp:

    ftp.ics.uci.edu [128.195.1.1]      pub/mh/mh-6.8.tar.Z    1.6MB
    louie.udel.edu [128.175.1.3]  portal/mh-6.8.tar.Z    1.6MB

    comp.mail.mh discusses MH, and contains a FAQ article.

    Jerry Peek wrote a book about MH called "MH & xmh: E-mail for Users &
    Programmers", ISBN 1-56592-027-9, published by O'Reilly and Associates,
    second edition, September 1992.

XMH: <extracted from the manual page>

     The xmh program provides a graphical user interface  to  the
     MH Message Handling System.  To actually do things with your
     mail, it makes calls to the  MH  package.   Electronic  mail
     messages  may  be composed, sent, received, replied to, for-
     warded, sorted, and stored in folders.  xmh provides  exten-
     sive mechanism for customization of the user interface.

     xmh is part of the standard X distribution from the X Consortium.

EXMH: Author Brent Welch* <[e-mail]>

    As well as providing the usual layer on top of MH commands, exmh
    has a number of other features:

    MIME support!  Displays richtext and enriched directly.  Parses
    multipart messages.  Displays hot buttons that invoke external viewers
    (metamail) for things not directly supported.  Built-in editor allows
    simple composition of text/enriched format.

    Color feedback in the scan listing so you can easily identify
    unseen messages (blue), the current message (red), deleted
    messages (gray background), and moved messages (yellow background).
    Xresources control these color choices.

    A folder display with one label per folder.  Color highlights
    indicate the current folder (red), folders with unseen messages
    in them (blue), and the target folder for moves (yellow background).
    Nested folders are highlighted by a shadow box.  A cache of
    recently visted folder buttons is also maintained.  Monochrome
    highlights are reverse video for the current folder, bold box
    for folders with unseen messages, and stippled box for the
    target of move operations.

    Clever scan caching.  MH users know that scan is slow, so
    exmh tries hard to cache the current state of the folder to
    avoid scanning.  Moves and deletes within exmh do not
    invalidate the cache, and background incs that add new messages
    are handled by merging them into the scan listing.  The
    scan cache is compatible with xmh.

    Numerous other features, such as "facesaver" display, backgrounds,
    dialog-box interface to MH "pick", folder searching and listing,
    designed for inclusion of user "hooks" and interfaces etc.

GNU Emacs Rmail:

    Rmail is an Emacs subsystem for reading and disposing of mail.  Rmail
    stores mail messages in Rmail files in BABYL format (originally used
    under the ITS operating system), although it can incorporate new mail
    from MMDF and Unix format files, or mixed-format files.  Reading the
    messages in an Rmail file is done in a special major mode, Rmail mode,
    which redefines most letters to run commands for managing mail.

    Rmail can do the standard things such as displaying, deleting, filing,
    or replying to messages.  Replying uses another Emacs subsystem, Mail
    mode.  Messages can be saved in either BABYL or Unix format.  Rmail
    maintains per-message attributes and user-defined labels.  Rmail can
    burst message digests.

VM: Author Kyle Jones* <[e-mail]>

    VM (View Mail) is a GNU Emacs subsystem that allows UNIX mail to be read
    and disposed of within Emacs.  Commands exist to do the normal things
    expected of a mail user agent, such as generating replies, saving
    messages to folders, deleting messages and so on.  There are other more
    advanced commands that do tasks like bursting and creating digests,
    message forwarding, and organizing message presentation according to
    various criteria.

    The current version of VM is VM 4.41.
    FTPable from:

    ftp.uu.net            mail/vm/vm-4.41.tar.Z
    archive.cis.ohio-state.edu    pub/gnu/emacs/elisp-archive/packages/vm-4.41.tar.Z

    VM is discussed in gnu.emacs.vm.info, or by mailing list by sending
    an e-mail request to [e-mail].

MH-E: Maintainer: Stephen Gildea <[e-mail]>

    MH-E is an interface to MH from within GNU Emacs.  It helps if MH was
    compiled with the MHE compiler flag.  MH-E is distributed with both GNU
    Emacs and MH.  Choose the later version.

C-Client: Author Mark Crispin <[e-mail]>

    Software writers only:

    C-client is a general library useful for creating MUA's.  It provides
    a high level logical interface for retrieving and manipulating
    mail messages.  It supports the latest draft of MIME (proposed
    Internet standard for multipart, multimedia, typed electronic mail).
    It is driver based, and easily ported to new platforms and MTA's,
    already supports BSD, SysV, DOS, Macintosh and TOPS-20(!),
    and supports present mail and mailbox formats.

    Just the thing if you want to write a new MUA.

    Contact the author for more details.

Metamail: Author N. Borenstein
    [Described by Paul Eggert, [e-mail]]

    Metamail is a software implementation of Mime, designed for easy
    integration with traditional mail-reading interfaces -- typically,
    users do not invoke metamail directly.  Ideally, extending the local
    email or news system to handle a new media format is a simple matter
    of adding a line to a mailcap file.  Mailcap files are described in
    RFC 1343: N Borenstein, ``A user agent configuration mechanism for
    multimedia mail format information'' (June 1992).  The source code
    for metamail can be found in ftp.uu.net:mail/metamail/mm.tar.Z.
    To join its mailing list, write [e-mail].


MailManager: Author Mark Crispin <[e-mail]>

    A MUA implemented using C-Client for NeXT computers.

Pine: Authors Lundblade, Seibel, and Crispin <[e-mail]>

    Pine is a mailer developed by the University of Washington Office of
    Computing and Communications. It has been designed for ease-of-use and
    with the novice computer user in mind. It is based on Internet mail
    protocols (e.g. RFC-822, SMTP, IMAP, and MIME) and currently runs on
    a variety of UNIX platforms, and a version is apparently available for
    MSDOS.

    The guiding principles for achieving ease-of-use in Pine were:
    careful limitation of features, one-character mnemonic commands,
    always-present command menus, immediate user feedback, and high
    tolerance for user mistakes. It is intended that Pine can be learned
    by exploration rather than reading manuals.

    A stand-alone version of Pico, Pine's message composition editor, is also
    included. It is a very simple and easy to use text editor with text
    justification and a spelling checker.

    Features:
       - Mail index showing a message summary which includes the status,
     sender, size, date and subject of messages.

       - View and process mail with the following commands:  forward, reply,
     save, export, print, delete, capture address and search.

       - Address book for saving long complex addresses and personal
     distribution lists under a nickname.

       - Multiple folders and folder management screen for filing messages.

       - Message composer with easy-to-use editor and spelling checker.
     The message composer also assists entering and formatting
     addresses and provides direct access to the address book.

       - Online help specific to each screen and context.

       - Supports access to remote mail repositories via the IMAP2 protocol
     defined in RFC-1176.

       - Soon to support multi-part mail conforming to proposed MIME Internet
     standard, allowing sending of sounds, graphics such as GIF and TIFF
     files, and binary files such as spreadsheets.

    Pine, including source code, is freely available via anonymous FTP from
    ftp.cac.washington.edu on the Internet. Other provisions for distribution
    have not been made. From the Internet, you may try out Pine and leave
    comments by telneting to "demo.cac.washington.edu" and logging in as
    "pinedemo". To join the Pine mailing list for announcements send a
    request to "[e-mail]".

    Pine is very portable and runs on a variety of UNIX machines including
    DECstations, NeXTs, VAX's and Suns. Pine was originally based on Elm,
    but it has evolved much since, ("Pine Is No-longer Elm").

    For further information send e-mail to [e-mail]. Pine is
    the work of Mike Siebel, Mark Crispin, and Laurence Lundblade at the
    University of Washington.

Ream: Author: Paul Dourish* <[e-mail]>

    Ream is a curses-based mail user agent for a variety of UNIX flavours;
    at one time or another, it's run on everything from a PC running Linux
    to a Cray Y/MP running UNICOS. It was originally written at the
    University of Edinburgh, and has spread not least through the
    subsequent geographical distribution of alumni. It remains minimally
    supported by its author (Paul Dourish <[e-mail]>).

    Ream is similar to elm in a number of ways, but considerably smaller
    and with a stronger separation between MUA and MTA behaviours. It runs
    over sendmail, mmdf and PP. It is available by anonymous ftp from
    parcftp.xerox.com, in pub/europarc/reamXXX.tar.Z, where XXX is a
    slowly incrementing version number.

XLView: Author: Several.  Mike Macgirvin* <[e-mail]>

    Current version 1.1 (Developer Release).  XLView (previously known as
    "Ximap") is an X based mail reader using the IMAP (IMAP2bis) protocol,
    for managing complex mail tasks.  It utilizes the X window system to
    allow independant processing of multiple mailboxes (even on multiple
    servers) simultaneously.  Each "read" and "compose" process is handled
    in an independant window as well.  It handles many complex MIME messages
    with the help of external multi-media handlers based partially on
    "metamail", and include facilities for file attachments of several
    common types.  It includes an address book with insert completion
    abilities and for maintaining addresses.  Of course it has the normal
    move/copy/save/reply/forward/print etc., functions one would expect and
    text may be cut and pasted from other open X sessions.  The most
    powerful feature of the latest release is the "Logical Viewer" which
    allows one to create rule based sorting of their mailbox based on
    addresses, dates, contents, message flags and other criteria.  Each
    existing message (and each new message) is evaluated and stored in the
    appropriate logical view, which may be opened as if it were a separate
    mailbox (but all the while it only represents a different ``view'' of
    your system mailbox).  Each mailbox or saved folder may have independant
    rulesets.  Status changes also are evaluated as they occur and the rules
    applied accordingly.  The rule language is powerful, yet easy to grasp;
    i.e.

    FROM [e-mail] OR jim SINCE YESTERDAY AND UNSEEN

    Currently tested with SunOS4.1.x and Ultrix running X11R5.
    Several alternate system ports including SVR4 are due shortly.

    FTP: SUMEX-AIM.Stanford.EDU:/imap/clients/ximap/xlview-1.1.tar.Z
    Information: [e-mail]

    Principal Authors: Kevin Brock, Bill Yeager and Mike Macgirvin at the
    Center for advanced Medical Informatics at Stanford.

Z-Mail: Z-code Software Corp, Carlyn Lowry* <[e-mail]>

    Z-Mail, a UNIX World Magazine "Product of the Year" winner for 1991, is
    a complete electronic mail system for workstations.  Z-Mail provides
    Motif and Open Look graphical user interfaces, as well as two character
    modes.  The software has been ported to nearly every system that runs
    UNIX, and it works with all standard UNIX mail transport agents
    including sendmail, binmail, smail, MMDF and X.400 gateways.  Z-Mail can
    replace or coexist with standard mail user agents on the system,
    including BSD Mail, AT&T mailx, Sun Mail Tool, Elm or Mush.  Most anyone
    can use Z-Mail "off the shelf" and immediately benefit from its simple
    interface and advanced features.

    Z-Mail also includes Z-Script, a powerful scripting language that
    enables users to customize and extend Z-Mail's capabilities.  Z-Mail's
    multi-media capabilities allow easy integration with best-of-class
    products including spreadsheets, desk-top publishing, graphics, fax,
    voice, and video.  For example, when users receive a spreadsheet file,
    Z-Mail can be configured to automatically launch the associated
    application and load the the attachment automatically and transparently
    to the user.  Z-Mail understands MIME-format documents and is also
    compatible with Sun's multimedia Mailtool.

    Mac, DOS, and Windows versions, as well as native MIME support, are
    planned for this summer.

    For more information on Z-Mail, contact:
    Z-Code Software Corp.
    4340 Redwood Hwy., Suite B-50
    San Rafael, CA 94903
    tel: [phone]
    fax: [phone]
    e-mail: [e-mail]

    Also, you can anonymous-ftp a demo copy of Z-Mail from "ftp.ora.com" in
    the directory pub/z-code/zmail/2.1.  (The file you want is named
    zm.XXX.tar.Z, where XXX is your type of machine.)  You'll need to call
    us after you do so we can send you an activation key.

    [As mentioned previously, Z-Mail is the commercial variant of mush. Ed]
--
Chris Lewis: _Una confibula non sat est_
Phone: Canada 613 832-0541  Ferret list: [e-mail]
Latest psroff: FTP://ftp.uunet.ca/distrib/chris_lewis/psroff3.0pl17/*
Latest hp2pbm: FTP://ftp.uunet.ca/distrib/chris_lewis/hp2pbm/*