mirror of https://github.com/tLDP/LDP
549 lines
22 KiB
Plaintext
549 lines
22 KiB
Plaintext
<!doctype linuxdoc system>
|
|
<article>
|
|
<title>The Linux Mail User HOWTO
|
|
<author>Eric S. Raymond, <tt><esr@thyrsus.com></tt>
|
|
<date>v2.2, 07 May 1999
|
|
|
|
<abstract>
|
|
This document is an introduction to the world of <idx>electronic
|
|
mail</idx> (<idx>email</idx>) 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 <em>not</em> 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.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect>Introduction
|
|
<p>
|
|
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
|
|
<idx>sendmail-v8</idx>. 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 <url url="http://metalab.unc.edu/LDP/HOWTO/ISP-Hookup-HOWTO.html"
|
|
name="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.
|
|
|
|
<sect1>New versions of this document
|
|
<p>
|
|
This document will be posted monthly to the newsgroup <url
|
|
url="news:comp.os.linux.answers" name="comp.os.linux.answers"> You
|
|
should also be able to view the latest version of this HOWTO on the
|
|
World Wide Web at <url
|
|
url="http://metalab.unc.edu/LDP/HOWTO/Mail-User-HOWTO.html">.
|
|
|
|
<sect1>Hardware requirements for email programs
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Software sources for email programs
|
|
<p>
|
|
The software you will need for email support is probably preinstalled
|
|
in your Linux distribution. You will find updates on the
|
|
<url url="http://metalab.unc.edu/pub/Linux" name="Metalab Linux
|
|
Archive">, especially in the <url
|
|
url="http://metalab.unc.edu/pub/Linux/system/mail"
|
|
name="mail subdirectory">.
|
|
|
|
<sect>Mail User Agents
|
|
<p>
|
|
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).
|
|
|
|
<sect1>Setting your mail editor<label id="emacsclient">
|
|
<p>
|
|
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:
|
|
|
|
<code>
|
|
(autoload 'server-edit "server" nil t)
|
|
(server-edit)
|
|
</code>
|
|
|
|
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.
|
|
|
|
<sect1>mutt
|
|
<p>
|
|
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 <url
|
|
name="http://www.mutt.org" url="http://www.mutt.org">.
|
|
|
|
Mutt respects the EDITOR/VISUAL convention.
|
|
|
|
<sect1>elm
|
|
<p>
|
|
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 <url
|
|
url="http://metalab.unc.edu/pub/Linux/system/mail" name="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.
|
|
|
|
<sect1>pine
|
|
<p>
|
|
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 <url
|
|
name="http://www.washington.edu/pine"
|
|
url="http://www.washington.edu/pine">.
|
|
|
|
Pine respects the EDITOR/VISUAL convention.
|
|
|
|
<sect1>Netscape
|
|
<p>
|
|
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).
|
|
|
|
<sect1>Emacs rmail/smail and vm.
|
|
<p>
|
|
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 <ref id="emacsclient" name="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 <tt>M-x unrmail</tt>
|
|
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 <url
|
|
url="http://www.wonderworks.com/vm/"
|
|
name="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.
|
|
|
|
<sect1>BSD mail
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Other user agents
|
|
<p>
|
|
The following also are known to run under Linux. Consult `archie' to
|
|
find them...
|
|
<itemize>
|
|
<item>mush - mail user's shell, very powerful for filtering and
|
|
batch processing
|
|
<item>mh - mail handler, yet another mail user agent
|
|
</itemize>
|
|
|
|
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.
|
|
|
|
<sect>Advanced topics
|
|
<p>
|
|
<sect1>Aliases
|
|
<p>
|
|
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
|
|
|
|
<code>
|
|
alias esr Eric S. Raymond <esr@thyrsus.com>
|
|
</code>
|
|
|
|
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 <file>/etc/aliases</file>
|
|
(the location depends on your MTA). It may be instructive for you to
|
|
look at the <file>/etc/aliases</file> 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.
|
|
|
|
<sect1>Forwarding
|
|
<p>
|
|
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 <tt><idx>.forward</idx></tt> 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.
|
|
|
|
<sect1>Auto-answering
|
|
<p>
|
|
Another common use for the <tt>.forward</tt> 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.
|
|
|
|
<sect1>Mailing lists
|
|
<p>
|
|
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 <file>/etc/aliases</file>
|
|
that includes the contents of a given mailing list file in the target
|
|
side of an alias. It looks like this:
|
|
|
|
<code>
|
|
admin-list: ":include:/usr/home/admin/admin-list"
|
|
</code>
|
|
|
|
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 `<idx>mail reflectors</idx>'.
|
|
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 <idx>mailing list manager</idx> 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 <file>/etc/aliases</file>.
|
|
For example, if the admin-list above were going through the mailing
|
|
list manager called SmartList on a sendmail system, a portion of
|
|
<file>/etc/aliases</file> might look like this:
|
|
|
|
<code>
|
|
admin-list: "|/usr/home/smartlist/bin/flist admin-list"
|
|
admin-list-request: "|/usr/home/smartlist/bin/flist admin-list-request"
|
|
</code>
|
|
|
|
Note that this is a pair of aliases. It is conventional for real
|
|
mailing lists to have a <idx>request address</idx> 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 <url name="list"
|
|
url="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
|
|
<url name="List-Managers Mailing List"
|
|
url="http://www.greatcircle.com/list-managers/">, including the FAQ
|
|
(note: this list is <em>not</em> appropriate for how-to questions).
|
|
|
|
<sect1>Mail filters
|
|
<p>
|
|
A <idx>mail filter</idx> 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 <url name="part 3"
|
|
url="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).
|
|
|
|
<sect1>Coping with spam
|
|
<p>
|
|
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...").
|
|
<p>
|
|
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.
|
|
<p>
|
|
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 <url
|
|
url="http://spam.abuse.net/" name="Fight Spam on the Internet!"> page.
|
|
The <url url="http://www.mindworkshop.com/alchemy/nospam.html"
|
|
name="Death To Spam!"> page is particularly effective on methods for
|
|
stopping or backtracking spam.
|
|
|
|
<sect>Other sources of information
|
|
<p>
|
|
<sect1>USENET
|
|
<p>
|
|
There are a number of Usenet groups devoted to electronic-mail
|
|
technical issues:
|
|
|
|
<itemize>
|
|
<item><htmlurl url="news:comp.mail.elm" name="comp.mail.elm">
|
|
the ELM mail system.
|
|
<item><htmlurl url="news:comp.mail.mh" name="comp.mail.mh">
|
|
The Rand Message Handling system.
|
|
<item><htmlurl url="news:comp.mail.mime" name="comp.mail.mime">
|
|
Multipurpose Internet Mail Extensions.
|
|
<item><htmlurl url="news:comp.mail.misc" name="comp.mail.misc">
|
|
General discussions about computer mail.
|
|
<item><htmlurl url="news:comp.mail.multi-media" name="comp.mail.multi-media">
|
|
Multimedia Mail.
|
|
<item><htmlurl url="news:comp.mail.mush" name="comp.mail.mush">
|
|
The Mail User's Shell (MUSH).
|
|
<item><htmlurl url="news:comp.mail.sendmail" name="comp.mail.sendmail">
|
|
the BSD sendmail agent.
|
|
<item><htmlurl url="news:comp.mail.smail" name="comp.mail.smail">
|
|
the smail mail agent.
|
|
<item><htmlurl url="news:comp.mail.uucp" name="comp.mail.uucp">
|
|
Mail in the uucp environment.
|
|
</itemize>
|
|
|
|
<sect1>Books
|
|
<p>
|
|
The following is a non-inclusive set of books that will help...
|
|
|
|
<itemize>
|
|
<item>``<em>Sendmail</em>" 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.
|
|
|
|
<item>"<em>The Internet Complete Reference</em>" 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.
|
|
|
|
<item>"<em>The Linux Networking Administrators' Guide</em>" 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.
|
|
</itemize>
|
|
|
|
<sect1>Periodic USENET Postings
|
|
<p>
|
|
Also worth mentioning, is Chris Lewis' periodic posting on unix e-mail
|
|
software, which is available on
|
|
<url url="ftp://rtfm.mit.edu/pub/usenet/comp.mail.misc">
|
|
as the files named ``UNIX_Email_Software_Survey_*''. An HTMLized
|
|
version is at <url url="http://www.faqs.org/faqs/mail/setup/unix/"
|
|
name="http://www.faqs.org/faqs/mail/setup/unix/">. At time writing in
|
|
1999 this posting has not been seriously updated since 1996, however.
|
|
|
|
<sect1>Where <em>NOT</em> to look for help
|
|
<p>
|
|
There is no longer anything special about configuring and running mail
|
|
under Linux, relative to other Unixes. Accordingly, you almost
|
|
certainly do <em>NOT</em> 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 <em>ALL</em> your questions.
|
|
|
|
<em>
|
|
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.
|
|
</em>
|
|
|
|
<em>
|
|
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.
|
|
</em>
|
|
|
|
<sect>Administrivia
|
|
<p>
|
|
<sect1>Feedback
|
|
<p>
|
|
(Vince wrote this section, but my policy is the same.)
|
|
<p>
|
|
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 <url url="mailto:linux-howto@metalab.unc.edu"
|
|
name="linux-howto@metalab.unc.edu">).
|
|
|
|
<sect1>Copyright Information
|
|
<p>
|
|
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 <em>all</em> information provided in the HOWTOS
|
|
is disseminated. If you have questions, please contact the Linux
|
|
HOWTO coordinator, at <tt>linux-howto@metalab.unc.edu</tt>.
|
|
|
|
<sect1>Standard Disclaimer
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Acknowledgements
|
|
<p>
|
|
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.
|
|
</article>
|