LDP/LDP/howto/docbook/Mail-User-HOWTO.xml

<?xml version="1.0"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
    "http://docbook.org/xml/4.1.2/docbookx.dtd" [
<!ENTITY ldpsite       "http://www.tldp.org/">
<!ENTITY howto         "&ldpsite;HOWTO/">
<!ENTITY mini-howto    "&ldpsite;HOWTO/mini/">
<!ENTITY home          "http://www.catb.org/~esr/">
]>
<article id="Mail-User-HOWTO">
<articleinfo>
<title>The Linux Mail User HOWTO</title>

<author>
  <firstname>Eric</firstname>
  <othername>Steven</othername>
  <surname>Raymond</surname>
  <affiliation>
    <orgname><ulink url="&home;">
    Thyrsus Enterprises</ulink></orgname> 
    <address>
    <email>esr@thyrsus.com</email>
    </address>
  </affiliation>
</author>
<copyright>
  <year>2005</year>
  <holder role="mailto:esr@thyrsus.com">Eric S. Raymond</holder> 
</copyright>

<abstract>
<para>This document is an introduction to the world of electronic
mail<indexterm><primary>electronic mail</primary></indexterm>
(email<indexterm><primary>email</primary></indexterm>) 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.</para>

<para>You need to read this if you plan to communicate locally or to
remote sites via electronic mail.  You probably do
<emphasis>not</emphasis> need to read this document if don't exchange
electronic mail with other users on your system or with other
sites.</para>

<para>For information on configuring and administering mail, see the
Mail Administrator HOWTO.</para>
</abstract>
</articleinfo>

<sect1 id="introduction"><title>Introduction</title>

<para>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.</para>

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

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

<para>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.</para>

<sect2 id="newversions"><title>New versions of this document</title>

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

</sect2>
<sect2 id="hardware"><title>Hardware requirements for email programs</title>

<para>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.</para>

</sect2>
<sect2 id="sources"><title>Software sources for email programs</title>

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

</sect2>
</sect1>
<sect1 id="mua"><title>Mail User Agents</title>

<para>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).</para>

<sect2 id="editor"><title>Setting your mail editor</title>

<para>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 <envar>VISUAL</envar>, if it exists, is taken as the name
of your preferred editor.  If VISUAL is not set, the variable 
EDITOR is checked.</para>

<para>Popular values for <envar>EDITOR</envar> include
<command>vi</command> and <command>emacs</command>.  
<anchor id="emacsclient"/>But if you are,
like me, the sort who always has a GNU Emacs running, the most useful way
to set <envar>EDITOR</envar> is to the value
<command>emacsclient</command>.  Use this with the following lines in
your <filename>~/.emacs</filename> file:</para>

<programlisting>
(autoload 'server-edit "server" nil t)
(server-edit)
</programlisting>

<para>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.</para>

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

<para>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.</para>

<para>If you're running XEmacs rather than GNU Emacs, these directions
change slightly.  In this case you waant to set <envar>EDITOR</envar>
to <command>gnuclient</command>.  In recent versions, your init file
will live at <filename>~/.xemacs/init.el</filename> rather than 
<filename>~/.emacs</filename>.</para>

</sect2>
<sect2 id="mutt"><title>mutt</title>

<para>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 <ulink
url="http://www.mutt.org">Mutt home page</ulink> on the web.</para>

<para>Mutt respects the EDITOR/VISUAL convention.</para>

</sect2>
<sect2 id="elm"><title>elm</title>

<para>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 <ulink
url="http://metalab.unc.edu/pub/Linux/system/mail">Metalab mail user
agents directory</ulink>.  Here are a few points that occasionally
trip people up:</para>

<para>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.</para>

<para>Elm respects the EDITOR/VISUAL convention.</para>

</sect2>
<sect2 id="pine"><title>pine</title>

<para>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 <ulink
url="http://www.washington.edu/pine">http://www.washington.edu/pine</ulink>.
</para>

<para>Pine respects the EDITOR/VISUAL convention.</para>

</sect2>
<sect2 id="netscape"><title>Netscape</title>

<para>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.</para>

<para>Netscape supplies its own mini-editor, the same one used throughout 
the browser (e.g. for text fields in forms).</para>

</sect2>
<sect2 id="emacs"><title>Emacs rmail/smail and vm.</title>

<para>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 <link linkend="emacsclient">emacsclient</link>
elsewhere in this document).</para>

<para>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 <command>M-x
unrmail</command> from the Emacs command line.)</para>

<para>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 <ulink
url="http://www.wonderworks.com/vm/">
http://www.wonderworks.com/vm/</ulink>.</para>

<para>The most popular mailreader for emacs is probably GNUS, distributed
with GNU Emacs.  It is a client for USENET news as well as mail.</para>

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

</sect2>
<sect2 id="bsdmail"><title>BSD mail</title>

<para>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.</para>

<para>BSD Mail invented the EDITOR/VISUAL convention.</para>

</sect2>
<sect2 id="othermuas"><title>Other user agents</title>

<para>The following also are known to run under Linux.  Consult `archie' to
find them...</para>
<variablelist>
<varlistentry>
<term>mush</term>
<listitem>
<para>mail user's shell, very powerful for filtering andbatch processing</para>
</listitem>
</varlistentry>
<varlistentry>
<term>mh</term>
<listitem><para>mail handler, yet another mail user agent</para></listitem>
</varlistentry>
</variablelist>

<para>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.</para>

</sect2>
</sect1>
<sect1 id="advanced"><title>Advanced topics</title>

<sect2 id="aliases"><title>Aliases</title>

<para>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.</para>

<para>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:</para>

<programlisting>
alias esr	Eric S. Raymond	&lt;esr@thyrsus.com&gt;
</programlisting>

<para>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.</para>

<para>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
<filename>/etc/aliases</filename> or
<filename>/etc/mail/aliases</filename> (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'.</para>

<para>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.</para>

</sect2>
<sect2 id="forwarding"><title>Forwarding</title>

<para>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.</para>

<para>To support this, most MTAs follow sendmail's lead and look for a file
called
<filename>.forward</filename><indexterm><primary>.forward</primary></indexterm>
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.</para>

<para>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.</para>

</sect2>
<sect2 id="autoreply"><title>Auto-replying</title>

<para>Another common use for the <filename>.forward</filename>
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.</para>

<para>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.</para>

<para>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.</para>

</sect2>
<sect2 id="lists"><title>Mailing lists</title>

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

<para>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 <filename>/etc/aliases</filename>
that includes the contents of a given mailing list file in the target
side of an alias.  It looks like this:</para>

<programlisting>
admin-list:     ":include:/usr/home/admin/admin-list"
</programlisting>

<para>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.</para>

<para>These simple lists are commonly called `mail
reflectors<indexterm><primary>mail reflectors</primary></indexterm>'.
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.</para>

<para>A kind of software called a mailing list
manager<indexterm><primary>mailing list manager</primary></indexterm>
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.</para>

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

<programlisting>
admin-list: "|/usr/home/smartlist/bin/flist admin-list"
admin-list-request: "|/usr/home/smartlist/bin/flist admin-list-request"
</programlisting>

<para>Note that this is a pair of aliases.  It is conventional for
real mailing lists to have a request
address<indexterm><primary>request address</primary></indexterm> 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.</para>

<para>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.</para>

<para>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.</para>

<para>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, <ulink
url="http://www.gnu.org/software/mailman/mailman.html">mailman</ulink>, 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 <ulink
url="http://www.catalog.com/vivian/mailing-list-software.html">list</ulink>
of such packages on the Web.</para>

<para>For more about mailing list managers, consult the resources at
the <ulink
url="http://www.greatcircle.com/list-managers/">List-Managers Mailing
List</ulink>, including the FAQ (note: this list is
<emphasis>not</emphasis> appropriate for how-to questions).</para>

</sect2>
<sect2 id="filters"><title>Mail filters</title>

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

<para>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.</para>

<para>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.</para>

<para>There are good feature summaries of the three major mail filters
(procmail, mailagent, and deliver) in <ulink
url="http://www.faqs.org/faqs/mail/setup/unix/part3/index.html">part
3</ulink> 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).</para>

</sect2>
<sect2 id="spam"><title>Coping with spam</title>

<para>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...").</para>

<para>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.</para>

<para>If you're being deluged with spam, get educated.  Browse the <ulink
url="http://spam.abuse.net/">Fight Spam on the Internet!</ulink> page.  The
<ulink url="http://www.mindworkshop.com/alchemy/nospam.html">Death To
Spam!</ulink> page is particularly effective on methods for stopping or
backtracking spam.</para>

</sect2>
</sect1>
<sect1 id="resources"><title>Other sources of information</title>

<sect2 id="usenet"><title>USENET</title>

<para>There are a number of Usenet groups devoted to electronic-mail
technical issues:</para>

<variablelist>
<varlistentry>
<term><ulink url="news:comp.mail.elm">comp.mail.elm</ulink></term>
<listitem><para>the ELM mail system.</para></listitem>
</varlistentry>
<varlistentry>
<term><ulink url="news:comp.mail.mh">comp.mail.mh</ulink></term>
<listitem><para>The Rand Message Handling system.</para></listitem>
</varlistentry>
<varlistentry>
<term><ulink url="news:comp.mail.mime">comp.mail.mime</ulink></term>
<listitem><para>Multipurpose Internet Mail Extensions.</para></listitem>
</varlistentry>
<varlistentry>
<term><ulink url="news:comp.mail.misc">comp.mail.misc</ulink></term>
<listitem><para>General discussions about computer mail.</para></listitem>
</varlistentry>
<varlistentry>
<term><ulink url="news:comp.mail.multi-media">comp.mail.multi-media</ulink></term>
<listitem><para>Multimedia Mail.</para></listitem>
</varlistentry>
<varlistentry>
<term><ulink url="news:comp.mail.mush">comp.mail.mush</ulink></term>
<listitem><para>The Mail User's Shell (MUSH).</para></listitem>
</varlistentry>
<varlistentry>
<term><ulink url="news:comp.mail.sendmail">comp.mail.sendmail</ulink></term>
<listitem><para>the BSD sendmail agent.</para></listitem>
</varlistentry>
<varlistentry>
<term><ulink url="news:comp.mail.smail">comp.mail.smail</ulink></term>
<listitem><para>the smail mail agent.</para></listitem>
</varlistentry>
<varlistentry>
<term><ulink url="news:comp.mail.uucp">comp.mail.uucp</ulink></term>
<listitem><para>Mail in the uucp environment.</para></listitem>
</varlistentry>
</variablelist>

</sect2>
<sect2 id="books"><title>Books</title>
   
<para>The following is a non-inclusive set of books that will help...</para>

<variablelist>
<varlistentry>
<term>Sendmail</term>
<listitem><para>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.</para></listitem>
</varlistentry>

<varlistentry>
<term>The Internet Complete Reference</term>
<listitem><para>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.</para></listitem>
</varlistentry>

<varlistentry>
<term>The Linux Networking Administrators' Guide</term>
<listitem><para>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.</para></listitem>
</varlistentry>
</variablelist>

</sect2>
<sect2 id="periodic"><title>Periodic USENET Postings</title>

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

</sect2>
<sect2 id="dontgo"><title>Where <emphasis>not</emphasis> to look for help</title>

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

<para>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.</para>

<para>Let me repeat that....</para>

<para>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 <emphasis>all</emphasis> your questions.</para>

<para><emphasis>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.</emphasis></para>

<para><emphasis> 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.</emphasis></para>

</sect2>
</sect1>
<sect1 id="administrivia"><title>Administrivia</title>

<sect2><title>Feedback</title>

<para>(Vince wrote this section, but my policy is the same.)</para>

<para>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.</para>

<para>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 :-)</para>
   
<para>Flames will quietly go to /dev/null so don't bother.</para>

<para>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.</para>

<para>Feedback concerning the actual format of the document should go
to the HOWTO coordinator - mail to <ulink
url="mailto:linux-howto@metalab.unc.edu">linux-howto@metalab.unc.edu</ulink>).
</para>

</sect2>
<sect2 id="copyright"><title>Copyright Information</title>

<para>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.</para>

<para>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.</para>
   
<para>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.</para>
   
<para>Commercial redistribution is allowed and encouraged; however,
the maintainer would appreciate being notified of any such
distributions (as a courtesy).</para>
   
<para>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.</para>
   
<para>We further want that <emphasis>all</emphasis> information
provided in the HOWTOS is disseminated.  If you have questions, please
contact the Linux HOWTO coordinator, at
<email>linux-howto@metalab.unc.edu</email>.</para>

</sect2>
<sect2 id="disclaimer"><title>Standard Disclaimer</title>

<para>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.</para>

</sect2>
<sect2 id="acknowledgements"><title>Acknowledgements</title>

<para>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.</para>

<para>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.</para>

<remark>
<revhistory id="revhistory">
   <revision>
      <revnumber>3.4</revnumber>
      <date>2005-08-17</date>
      <authorinitials>esr</authorinitials>
       <revremark>
	 Minor revisions.
      </revremark>
   </revision>
   <revision>
      <revnumber>3.3</revnumber>
      <date>2003-02-22</date>
      <authorinitials>esr</authorinitials>
       <revremark>
	 LDP site and my home site moved.
      </revremark>
   </revision>
   <revision>
      <revnumber>3.2</revnumber>
      <date>2001-02-22</date>
      <authorinitials>esr</authorinitials>
       <revremark>
	 LDP Styleguide markup fixes.
      </revremark>
   </revision>
   <revision>
      <revnumber>3.1</revnumber>
      <date>2000-12-08</date>
      <authorinitials>esr</authorinitials>
       <revremark>
	 Mention Mailman.
      </revremark>
   </revision>
   <revision>
      <revnumber>3.0</revnumber> <date>2000-08-08</date>
      <authorinitials>esr</authorinitials>
       <revremark>
	 First DocBook version.
      </revremark>
   </revision>
</revhistory>
</remark>

</sect2>
</sect1>
</article>

<!--
The following sets edit modes for GNU EMACS
Local Variables:
fill-column:75
compile-command: "mail -s \"Mail User HOWTO update\" submit@en.tldp.org <Mail-User-HOWTO.xml"
End:
End:
-->