The Linux Mail User HOWTO


Eric Steven Raymond

Thyrsus_Enterprises

    <esr@thyrsus.com>
    
Copyright © 2005 Eric S. Raymond
Abstract
This document is an introduction to the world of electronic mail (email) under
Linux. It focuses on user-level issues and typical configurations 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-replying

        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_not_to_look_for_help


  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.)
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 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,
especially in the mail_subdirectory.

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 a GNU 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.
If you're running XEmacs rather than GNU Emacs, these directions change
slightly. In this case you waant to set EDITOR to gnuclient. In recent
versions, your init file will live at ~/.xemacs/init.el rather than ~/.emacs.

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 on the web.
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. 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.
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). It does, however, support
LDAP and SSL.
Netscape 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/.
The most popular mailreader for emacs is probably GNUS, distributed with GNU
Emacs. It is a client for USENET news as well as mail.
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...


  mush
      mail user's shell, very powerful for filtering andbatch processing

  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	<esr@thyrsus.com>

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
`esr@thyrsus.com', 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 or /etc/mail/aliases (the location depends
on your MTA). It may be instructive for you to look at the 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; it should be a
single address. The most common use for this facility is to redirect your mail
to an account on another machine.
To amplify: The existence of the .forward file, regardless of whats in it,
tells the system to treat the contents of the file as an alias target for all
your mail. If you create an empty .forward file, your mail disappears. Most
people use this to forward their mail to another machine, so most often there
is just one email address in the first line, and nothing else. The MTA will
honor whatever is on the first line of your .forward file as the target of an
alias. Everything else is ignored. If the target is misformatted, just like any
other alias, then the mail disappears.

3.3. Auto-replying

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 or 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. Recently, mailman, a list manager with a rather nice Web-based signon/
signoff/administration interface, has become very popular and may be in the
pricess of obsolescing the older programs. There is a rather comprehensive list
of such packages on the Web.
For more about mailing list managers, consult the resources at the List-
Managers_Mailing_List, 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 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.
If you're being deluged with spam, get educated. Browse the Fight_Spam_on_the
Internet! page. The Death_To_Spam! 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:


  comp.mail.elm
      the ELM mail system.

  comp.mail.mh
      The Rand Message Handling system.

  comp.mail.mime
      Multipurpose Internet Mail Extensions.

  comp.mail.misc
      General discussions about computer mail.

  comp.mail.multi-media
      Multimedia Mail.

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

  comp.mail.sendmail
      the BSD sendmail agent.

  comp.mail.smail
      the smail mail agent.

  comp.mail.uucp
      Mail in the uucp environment.


4.2. Books

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


  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.

  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.

  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/. At time of writing in 2005 this posting has
not been seriously updated since 2000, 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 linux-howto@metalab.unc.edu).

5.2. Copyright Information

The Mail-User-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 <linux-
howto@metalab.unc.edu>.

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.

Revision History
Revision 3.4 2005-08-17 esr
Minor revisions.
Revision 3.3 2003-02-22 esr
LDP site and my home site moved.
Revision 3.2 2001-02-22 esr
LDP Styleguide markup fixes.
Revision 3.1 2000-12-08 esr
Mention Mailman.
Revision 3.0 2000-08-08 esr
First DocBook version.