638 lines
25 KiB
Plaintext
638 lines
25 KiB
Plaintext
The Linux Mail User HOWTO
|
|
|
|
Eric Steven Raymond
|
|
|
|
[http://www.catb.org/~esr/] Thyrsus Enterprises
|
|
|
|
|
|
<esr@thyrsus.com>
|
|
|
|
|
|
Copyright (C) 2005 Eric S. Raymond
|
|
|
|
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
|
|
[news:comp.os.linux.answers] 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] 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 [http://www.mutt.org] 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] 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/] 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 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, [http://www.gnu.org/software/mailman/
|
|
mailman.html] 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
|
|
[http://www.catalog.com/vivian/mailing-list-software.html] 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 [http://
|
|
spam.abuse.net/] 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:
|
|
|
|
[news:comp.mail.elm] comp.mail.elm
|
|
|
|
the ELM mail system.
|
|
|
|
[news:comp.mail.mh] comp.mail.mh
|
|
|
|
The Rand Message Handling system.
|
|
|
|
[news:comp.mail.mime] comp.mail.mime
|
|
|
|
Multipurpose Internet Mail Extensions.
|
|
|
|
[news:comp.mail.misc] comp.mail.misc
|
|
|
|
General discussions about computer mail.
|
|
|
|
[news:comp.mail.multi-media] comp.mail.multi-media
|
|
|
|
Multimedia Mail.
|
|
|
|
[news:comp.mail.mush] comp.mail.mush
|
|
|
|
The Mail User's Shell (MUSH).
|
|
|
|
[news:comp.mail.sendmail] comp.mail.sendmail
|
|
|
|
the BSD sendmail agent.
|
|
|
|
[news:comp.mail.smail] comp.mail.smail
|
|
|
|
the smail mail agent.
|
|
|
|
[news:comp.mail.uucp] 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] 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 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 [mailto:linux-howto@metalab.unc.edu]
|
|
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.
|
|
|