The Linux Mail User HOWTO
 Eric S. Raymond, <[email protected]>
 v2.2, 07 May 1999

 This document is an introduction to the world of electronic mail
 (email) under Linux. It focuses on user-level issues and typical con-
 figurations for Linux home and small-business machines connected to
 the net via an ISP.  You need to read this if you plan to communicate
 locally or to remote sites via electronic mail.  You probably do not
 need to read this document if don't exchange electronic mail with
 other users on your system or with other sites.  For information on
 configuring and administering mail, see the Mail Administrator HOWTO.
 ______________________________________________________________________

 Table of Contents


 1. Introduction

    1.1 New versions of this document
    1.2 Hardware requirements for email programs
    1.3 Software sources for email programs

 2. Mail User Agents

    2.1 Setting your mail editor
    2.2 mutt
    2.3 elm
    2.4 pine
    2.5 Netscape
    2.6 Emacs rmail/smail and vm.
    2.7 BSD mail
    2.8 Other user agents

 3. Advanced topics

    3.1 Aliases
    3.2 Forwarding
    3.3 Auto-answering
    3.4 Mailing lists
    3.5 Mail filters
    3.6 Coping with spam

 4. Other sources of information

    4.1 USENET
    4.2 Books
    4.3 Periodic USENET Postings
    4.4 Where

 5. Administrivia

    5.1 Feedback
    5.2 Copyright Information
    5.3 Standard Disclaimer
    5.4 Acknowledgements


 ______________________________________________________________________

 1.  Introduction

 The intent of this document is to explain how email works, and answer
 some of the questions that appear to meet the definition of
 `frequently asked questions' about e-mail software under Linux.

 Modern Linux distributions give you a usable, preconfigured setup for
 electronic mail out of the box, usually featuring a late version of
 sendmail-v8.  This HOWTO will assume that you have such a setup and a
 working Internet connection.

 (For information on how to set up a PPP or SLIP link to an ISP, see
 the ISP Hookup HOWTO <http://metalab.unc.edu/LDP/HOWTO/ISP-Hookup-
 HOWTO.html>.)

 Accordingly, unlike Vince Skahan's 1.x versions, this HOWTO focuses on
 user issues and architecture; most technical hair about UUCP, IDA
 sendmail and other formerly important topics has been dropped.


 1.1.  New versions of this document

 This document will be posted monthly to the newsgroup
 comp.os.linux.answers <news:comp.os.linux.answers> You should also be
 able to view the latest version of this HOWTO on the World Wide Web at
 <http://metalab.unc.edu/LDP/HOWTO/Mail-User-HOWTO.html>.


 1.2.  Hardware requirements for email programs

 There are no specific hardware requirements for mail under Linux.  If
 you have the hardware necessary to connect to the Internet, it can
 support email over that link.


 1.3.  Software sources for email programs

 The software you will need for email support is probably preinstalled
 in your Linux distribution.  You will find updates on the Metalab
 Linux Archive <http://metalab.unc.edu/pub/Linux>, especially in the
 mail subdirectory <http://metalab.unc.edu/pub/Linux/system/mail>.


 2.  Mail User Agents

 This section contains information related to user agents, which means
 the software the user sees and uses.  This software relies on the
 transport agents described in the Mail Administrator's HOWTO (which
 also include user=agent configuration and troubleshooting tips for
 administrators).


 2.1.  Setting your mail editor

 Mail user agents call out to some editor to assist composition of
 mail.  Which editor is the default varies.  Most of them respect a
 convention going back to Unix's early days; the contents of the
 environment variable VISUAL, if it exists, is taken as the name of
 your preferred editor.  If VISUAL is not set, the variable EDITOR is
 checked.

 Popular values for EDITOR include `vi' and `emacs'.  But if you are,
 like me, the sort who always has an Emacs running, the most useful way
 to set EDITOR is to the value `emacsclient'.  Use this with the
 following lines in your .emacs file:


 ______________________________________________________________________
 (autoload 'server-edit "server" nil t)
 (server-edit)
 ______________________________________________________________________

 The emacsclient program, when it runs, tries to establish
 communication with an Emacs instance you already have running and hand
 the mail message temporary file to that Emacs to be edited.  The
 effect of this will be that when your mailer calls out for an editor,
 a mail composition window pops open inside your Emacs.

 When you are ready to hand the file back to the mailer for sending,
 type C-x #.  The mail buffer will leave your display and the
 emacsclient instance your mailer called will return, handing control
 back to the mailer.

 It is possible to have more than one emacsclient instance open at once
 without confusing Emacs.  However, calling up another Emacs while an
 emacsclient session is running can confuse emacsclient enough that it
 won't be able to find either instance afterwards.  If this happens,
 shut down all your Emacs instances and restart just one.


 2.2.  mutt

 This is what I use and recommend.  It is descended from elm and has
 similar commands by default, but is much more powerful and
 configurable.  It can be a POP3 or IMAP client, and includes excellent
 support for MIME and PGP.  There is a Mutt home page at
 http://www.mutt.org <http://www.mutt.org>.

 Mutt respects the EDITOR/VISUAL convention.


 2.3.  elm

 Elm was the first modern, screen-oriented Unix mailer, but has been
 stagnant for years now and is being displaced by Mutt.  Some versions
 of elm have POP3 support built in. For more information, see the elm
 sources and installation instructions in the Metalab mail user agents
 directory <http://metalab.unc.edu/pub/Linux/system/mail>.  Here are a
 few points that occasionally trip people up:

 No, stock elm is not PGP-aware.  There are PGP support patches, but
 Mutt's PGP support is superior.  If you want to use PGP, I recommend
 Mutt.

 Elm respects the EDITOR/VISUAL convention.


 2.4.  pine

 Pine is a user agent designed for novices; it includes news-reading
 capability and built-in support for the IMAP remote-mail protocol.  A
 lot of people swear by it for new users.  I find its impoverished
 command set, limited configurability and native editor hard to take.
 It has excellent built-in IMAP support, however.  If you want to check
 it out, the distribution is available at
 http://www.washington.edu/pine <http://www.washington.edu/pine>.

 Pine respects the EDITOR/VISUAL convention.


 2.5.  Netscape

 The Netscape browser has POP3 and IMAP remote-mail capability built
 into it, so it can be used as a mail user agent.  I don't recommend
 this; it doesn't specialize in being an MUA, and therefore does not
 offer many of the services that real MUAs do (such as aliases and PGP
 handling).

 Neetscape supplies its own mini-editor, the same one used throughout
 the browser (e.g. for text fields in forms).


 2.6.  Emacs rmail/smail and vm.

 Emacs has a mode called smail that can send mail, and another called
 rmail that can read mail.  The smail mode can be quite useful, as you
 get to compose mail inside a full Emacs environment (but see also the
 discussion of ``emacsclient'' elsewhere in this document).

 The rmail mode, on the other hand, is not recommended.  Every time you
 run it, it converts your inbox to BABYL format; ordinary mail tools
 will choke on that.  (If this happens to you, do M-x unrmail from the
 Emacs command line.)

 There is a mailreader for emacs called `vm' that writes and reads
 standard V7 mailboxes.  It is not distributed with GNU Emacs, but you
 can find its home page at http://www.wonderworks.com/vm/
 <http://www.wonderworks.com/vm/>.

 Emacs smail/rmail/vm do not respect the EDITOR/VISUAL convention.
 Instead, you use the Emacs they're embedded in.


 2.7.  BSD mail

 If you simply type `mail' to the shell on a Linux or any other modern
 Unix, you will invoke some variant of the BSD Mail program.  It has a
 line-oriented interface originally designed for use on TTYs.  It is,
 at this point, only of historical interest.

 BSD Mail invented the EDITOR/VISUAL convention.


 2.8.  Other user agents

 The following also are known to run under Linux.  Consult `archie' to
 find them...

 o  mush      - mail user's shell, very powerful for filtering and
    batch processing

 o  mh      - mail handler, yet another mail user agent

 I don't know enough about mh or mush to describe them in detail.  They
 both have rather complex interfaces and are designed for sophisticated
 mail users.


 3.  Advanced topics


 3.1.  Aliases

 An `alias' is a way to set up a pseudo-address that simply directs
 mail to another (single) address.  There are two kinds of aliases: MUA
 aliases and MTA aliases.

 An MUA alias is one you set up in your MUA as a kind of personal
 shorthand.  Other people will not be able to see or use this alias.
 For example, you could write



 ______________________________________________________________________
 alias esr       Eric S. Raymond <[email protected]>
 ______________________________________________________________________



 in your mutt configuration file.  This would tell mutt that when it
 sees `esr' in an address line, it should behave as through you had
 typed `[email protected]',  Or you can type `mutt esr' and the expanded
 address will be automatically filled in on the `to' line.

 An MTA alias is one your MTA expands; it will be usable by everyone,
 both on your machine and remotely.  To create MTA aliases you must
 modify a system file, usually but not always /etc/aliases (the
 location depends on your MTA).  It may be instructive for you to look
 at the /etc/aliases on your system; it should contain a number of
 standard aliases such as `postmaster'.

 Your MTA may also allow the target of an alias to be a filename, which
 will be treated as a mailbox the mail is to be appended to (this is
 useful for archiving mail).  It may also allow the target of an alias
 to be a program, in which case mail to that alias will be passed to an
 instance of the program on its standard input.


 3.2.  Forwarding

 MTA aliases usually require administrator privileges to set up.  But
 it is desirable for mail users to be able to set up forwarding of
 their own mail without administrator intervention.

 To support this, most MTAs follow sendmail's lead and look for a file
 called .forward in your home directory.  The contents of this file is
 interpreted like the target of an alias which should receive all your
 mail.  The most common use for this facility is to redirect your mail
 to an account on another machine.


 3.3.  Auto-answering

 Another common use for the .forward facility is to pass your mail to a
 `vacation' program.  A vacation program reads incoming mail and
 automatically generates a canned reply to it; they are so called
 because the most common form of canned reply is to inform the sender
 that you are on vacation and will not be reachable until a given date.

 There is no one standard vacation program that is in universal use.
 There are two good reasons for this: one, that such a program is very
 easy to write as a shellscript of filter rule (see below); and two,
 that vacation programs interact badly with mailing lists.

 You should temporarily unsubscribe from all mailing lists you are on
 before setting up auto-answering; otherwise, all members of the
 mailing lists mail find they are being flooded with canned messages by
 your vacation program.  This is considered very rude behavior and will
 guarantee you quite a frosty reception on your return.


 3.4.  Mailing lists

 A mailing list is a pseudo-address that sends mail to more than one
 user.

 In its simplest form, mailing list is just an MTA alias with more than
 one recipient. Some small mailing lists are maintained this way.
 Sendmail assists by supporting a syntax in /etc/aliases that includes
 the contents of a given mailing list file in the target side of an
 alias.  It looks like this:


 ______________________________________________________________________
 admin-list:     ":include:/usr/home/admin/admin-list"
 ______________________________________________________________________



 with the advantage that the admin-list file can live in unprivileged-
 user space somewhere (root is only needed to set up the original
 inclusion). Some other MTAs have similar features.

 These simple lists are commonly called `mail reflectors'.  There are a
 couple of problems with mail reflectors.  One is that bounce messages
 from failed attempts to broadcast goes to all users.  Another is that
 all subscriptions and unsubscriptions have to be done manually by the
 mailing list administrator.

 A kind of software called a mailing list manager has evolved to
 address these problems and other related ones.  Its most important
 function is to permit mailing list users to subscribe and unscubscribe
 without going through the list maintainer.

 A mailing-list manager keeps its own user-list information and hooks
 up to the MTA through a program alias in /etc/aliases.  For example,
 if the admin-list above were going through the mailing list manager
 called SmartList on a sendmail system, a portion of /etc/aliases might
 look like this:


 ______________________________________________________________________
 admin-list: "|/usr/home/smartlist/bin/flist admin-list"
 admin-list-request: "|/usr/home/smartlist/bin/flist admin-list-request"
 ______________________________________________________________________



 Note that this is a pair of aliases.  It is conventional for real
 mailing lists to have a request address to be used for user
 subscription and unsubscription requests.  It is considered rude and
 ignorant to send subscription/unsubscription requests to the main
 address of such a list -- don't do it.

 The robot sitting behind the request address may offer other features
 besides just subscription/unsubscription.  It may respond to help
 requests, allow you to query who is on the list, or give you automated
 access to list archives.  It may also allow list administrators to
 restrict posting to known members, set the list to auto-subscribe
 nonmembers when they first post, or set various security policy
 options.  Mailing-list managers differ primarily in the design and
 range of these secondary features.

 Unfortunately, the format for sending commands to mailing-list request
 robots is not standard.  Some expect commands in the subject line,
 some ignore the subject line and expect commands in the message body.
 You need to pay attention to the response mail you get when you first
 subscribe; it's a good idea to save such mail to a subscriptions
 mailbox for later reference.

 The most important mailing-list managers to know about are majordomo,
 listserv, listproc, and smartlist; majordomo is the most popular by a
 considerable margin.  There is a rather comprehensive list
 <http://www.catalog.com/vivian/mailing-list-software.html> of such
 packages on the Web.
 For more about mailing list managers, consult the resources at the
 List-Managers Mailing List <http://www.greatcircle.com/list-
 managers/>, including the FAQ (note: this list is not appropriate for
 how-to questions).


 3.5.  Mail filters

 A mail filter is a program that sits between your local delivery agent
 and you, automatically dispatching or rejecting mail before you see
 it.

 Mail filters have a number of uses.  The most important are spam
 filtering, dispatching to multiple mailboxes by topic or sender, and
 auto-answering mail.

 Typically, you set up mail filtering by putting a program alias for
 the filter program in your .forward file, and writing a file of
 filtering rules.  The format and location of the filter rules file
 varies between filter programs.

 There are good feature summaries of the three major mail filters
 (procmail, mailagent, and deliver) in part 3
 <http://www.faqs.org/faqs/mail/setup/unix/part3/index.html> of Chris
 Lewis's Email Software Survey.  The most popular of these is (despite
 its rather nasty rule syntax) procmail, which is universally present
 on Linux systems (and, indeed, is generally used as the system's local
 delivery agent).


 3.6.  Coping with spam

 Spam is sometimes known as `UCE' (Unsolicited Commercial Email) or
 `UBE' (Unsolicited Bulk Email).  As these names imply, it is an
 obnoxious form of advertising that stuffs your mailbox with form
 letters.  (The term `spam' comes from a Monty Python's Flying Circus
 skit in which a choir of Vikings endlessly repeats the chant "Spam
 spam spam spam...").

 Most spam seems to consist of solicitations for pyramid schemes, ads
 for pornography, or (annoyingly) attempts to sell spam-sending
 programs.  A few individual spams (like MAKE MONEY FAST or the Craig
 Shergold postcard hoax) have been so persistent as to become
 legendary.  Spam tends to be both verbose and illiterate.  It's a
 waste of time and a huge waste of network bandwidth.

 The spam epidemic seems to have peaked in mid-1997 and been slowly in
 decline since, but it can still be a serious annoyance.  If you're
 being deluged with spam, get educated.  Browse the Fight Spam on the
 Internet! <http://spam.abuse.net/> page.  The Death To Spam!
 <http://www.mindworkshop.com/alchemy/nospam.html> page is particularly
 effective on methods  for stopping or backtracking spam.


 4.  Other sources of information



 4.1.  USENET

 There are a number of Usenet groups devoted to electronic-mail
 technical issues:


 o  comp.mail.elm the ELM mail system.

 o  comp.mail.mh The Rand Message Handling system.

 o  comp.mail.mime Multipurpose Internet Mail Extensions.

 o  comp.mail.misc General discussions about computer mail.

 o  comp.mail.multi-media Multimedia Mail.

 o  comp.mail.mush The Mail User's Shell (MUSH).

 o  comp.mail.sendmail the BSD sendmail agent.

 o  comp.mail.smail the smail mail agent.

 o  comp.mail.uucp Mail in the uucp environment.


 4.2.  Books


 The following is a non-inclusive set of books that will help...


 o  ``Sendmail" from O'Reilly and Associates is the definitive
    reference on sendmail-v8 and sendmail+IDA.  It's a ``must have''
    for anybody hoping to make sense out of sendmail without bleeding
    in the process.

 o  "The Internet Complete Reference" from Osborne is a fine reference
    book that explains the various services available on Internet and
    is a great source for information on news, mail, and various other
    Internet resources.

 o  "The Linux Networking Administrators' Guide" from Olaf Kirch of the
    LDP is available on the net and is also published by (at least)
    O'Reilly and SSC.  It makes a fine one-stop shopping guide to learn
    about everything you ever imagined you'd need to know about Unix
    networking.


 4.3.  Periodic USENET Postings

 Also worth mentioning, is Chris Lewis' periodic posting on unix e-mail
 software, which is available on
 <ftp://rtfm.mit.edu/pub/usenet/comp.mail.misc> as the files named
 ``UNIX_Email_Software_Survey_*''.  An HTMLized version is at
 http://www.faqs.org/faqs/mail/setup/unix/
 <http://www.faqs.org/faqs/mail/setup/unix/>.  At time writing in 1999
 this posting has not been seriously updated since 1996, however.


 4.4.  Where NOT  to look for help

 There is no longer anything special about configuring and running mail
 under Linux, relative to other Unixes.  Accordingly, you almost
 certainly do NOT want to be posting generic mail-related questions to
 the comp.os.linux.* newsgroups.

 Unless your posting is truly Linux-specific (ie, ``please tell me what
 routers are already compiled into the SLS1.03 version of
 smail3.1.28'') you should be asking your questions in one of the
 newsgroups or mailing lists referenced above.

 Let me repeat that.


 There is virtually no reason to post anything mail-related in the
 comp.os.linux hierarchy any more.  There are existing newsgroups in
 the comp.mail.* hierarchy to handle ALL your questions.

 If you post to comp.os.linux.* for non-Linux-specific questions, you
 are looking in the wrong place for help.  The electronic mail experts
 hang out in the places indicated above and generally not in the Linux
 groups.

 Posting to the Linux hierarchy for non-linux-specific questions wastes
 your time and everybody else's...and it frequently delays you from
 getting the answer to your question.


 5.  Administrivia


 5.1.  Feedback


 (Vince wrote this section, but my policy is the same.)

 I am interested in any feedback, positive or negative, regarding the
 content of this document via e-mail.  Definitely contact me if you
 find errors or obvious omissions.

 I read, but do not necessarily respond to, all e-mail I receive.
 Requests for enhancements will be considered and acted upon based on
 that day's combination of available time, merit of the request, and
 daily blood pressure :-)

 Flames will quietly go to /dev/null so don't bother.

 In particular, the Linux filesystem standard for pathnames is an
 evolving thing.  What's in this document is there for illustration
 only based on the current standard at the time that part of the
 document was written and in the paths used in the distributions or
 `kits' I've personally seen.  Please consult your particular Linux
 distribution(s) for the paths they use.

 Feedback concerning the actual format of the document should go to the
 HOWTO coordinator - mail to [email protected] <mailto:linux-
 [email protected]>).


 5.2.  Copyright Information


 The Mail-HOWTO is copyrighted (c)1999 Eric S. Raymond.  Copyright is
 retained for the purpose of enforcing the Linux Documentation Project
 license terms.

 A verbatim copy may be reproduced or distributed in any medium
 physical or electronic without permission of the author.  Translations
 are similarly permitted without express permission if it includes a
 notice on who translated it.

 Short quotes may be used without prior consent by the author.
 Derivative work and partial distributions of the Mail-HOWTO must be
 accompanied with either a verbatim copy of this file or a pointer to
 the verbatim copy.

 Commercial redistribution is allowed and encouraged; however, the
 maintainer would appreciate being notified of any such distributions
 (as a courtesy).

 In short, we wish to promote dissemination of this information through
 as many channels as possible. However, we do wish to retain copyright
 on the HOWTO documents.

 We further want that all information provided in the HOWTOS is
 disseminated.  If you have questions, please contact the Linux HOWTO
 coordinator, at [email protected].


 5.3.  Standard Disclaimer


 Of course, we disavow any potential liability for the contents of this
 document.  Use of the concepts, examples, and/or other content of this
 document is entirely at your own risk.


 5.4.  Acknowledgements

 This was originally authored by Vince Skahan.  I have rewritten it for
 the modern ISP-centric world in which UUCP is little more than a
 memory.

 In May 1999, the name was changed from "The Linux Electronic Mail
 HOWTO" to avoid a collision with Guylhem Aznar's Mail HOWTO, which
 will become the Mail Administrator HOWTO.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.