The Linux Electronic Mail Administrator HOWTO
Guylhem Aznar <guylhem at oeil.qc.ca>
v3.2, January 2000
This document describes the setup, care and feeding of Electronic Mail
(e-mail) under Linux. It is primarily intended for administrators,
rather than users. (See the Mail-User's-HOWTO for information on user
issues and user agents.) You need to read this if you plan to commu-
nicate locally or to remote sites via electronic mail. You probably
do _*_n_o_t_* need to read this document if don't exchange electronic mail
with other users on your system or with other sites.
______________________________________________________________________
Table of Contents
1. Introduction, copyright and standard disclaimer
1.1 Email and spamming
1.2 Goals
1.3 New versions
1.4 Feedback
1.5 Copyright
1.6 Limited warranty
2. Other sources of information
2.1 Mail User's HOWTO There is a Mail User's HOWTO, which focuses on user issues. It is currently maintained by Eric S. Raymond; you should be able to view it on the World Wide Web at
2.2 USENET
2.3 Mailing Lists
2.4 Other documents from LDP
2.5 Books
3. How Electronic Mail Works
3.1 Mail between full-time Internet machines
3.2 Notifiers
3.3 Mail to part-time Internet machines
3.4 Remote mail and remote-mail protocols
3.5 Mailbox formats
4. Requirements
4.1 Hardware
5. Choosing a Mail Transport Agent
5.1 sendmail
5.2 smail v3.2
5.3 qmail
5.4 exim
6. Installing Transport Software
6.1 Qmail v1.03
6.1.1 Getting qmail
6.1.2 Uncompressing sources
6.1.3 Preparing for compilation
6.1.4 Configuring qmail
6.1.4.1 defaultdomain, me, plusdomain
6.1.4.2 locals, rcpthosts
6.1.4.3 virtualdomains
6.1.5 Testing qmail
6.1.6 Removing your other MTA
6.1.7 That's all, folks!
6.2 Smail v3.1
6.2.1 Configuring smail
6.2.1.1 "config" file
6.2.1.2 "directors" file
6.2.1.3 "fidopaths" file
6.2.1.4 "routers" file
6.2.1.5 "transports" file
6.2.1.6 "maps/" directory
6.2.2 Other good examples
6.2.3 Restarting inetd
6.2.4 Smail with smtp
6.3 OUTDATED SECTION: Sendmail+IDA
6.3.1 Source installation
6.3.2 The sendmail.m4 file
6.3.3 Defining a local mailer
6.3.4 The sendmail+IDA dbm tables
6.3.5 So which entries are really required?
6.4 Sendmail 8.x
6.4.1 A sample 8.7.x mc file
6.4.2 Sendmail v8 tidbits
6.5 Local Delivery Agents
7. User Agent Administration
7.1 Mutt
7.2 Elm
7.3 Mailx
8. Handling remote mail
8.1 History
8.2 Getting mail
8.3 Sending mail
8.4 Reading mail
8.5 Testing
8.6 Using
9. Acknowledgements
______________________________________________________________________
11.. IInnttrroodduuccttiioonn,, ccooppyyrriigghhtt aanndd ssttaannddaarrdd ddiissccllaaiimmeerr
11..11.. EEmmaaiill aanndd ssppaammmmiinngg
To send mail to anyone mentioned in this document, convert "at" in
email addresses to "@".
This conversion is simple for humans, but not spammers' address
harvesters; therefore it's useful to protect generous contributors
from being spammed!
11..22.. GGooaallss
The intent of this document is to answer some of the questions and
comments that appear to meet the definition of "frequently asked
questions" about e-mail software under Linux in general and the
version in the Linux Debian and RedHat distributions in particular.
11..33.. NNeeww vveerrssiioonnss
New versions of this document will be periodically posted to
comp.os.linux.announce, comp.answers and mail.answers. They will also
be added to the various anonymous ftp sites who archive such
information including _s_u_n_s_i_t_e_._u_n_c_._e_d_u_:_/_p_u_b_/_L_i_n_u_x_/_d_o_c_s_/_H_O_W_T_O.
In addition, you should be generally able to find this document on the
Linux WorldWideWeb home page at _h_t_t_p_:_/_/_s_u_n_s_i_t_e_._u_n_c_._e_d_u_/_m_d_w_/_l_i_n_u_x_._h_t_m_l.
11..44.. FFeeeeddbbaacckk
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.
Feedback concerning the actual format of the document should go to the
HOWTO coordinator : Tim Bynum (howto at wallybox.cei.net).
11..55.. CCooppyyrriigghhtt
The Mail-Administrator HOWTO is copyrighted (c) 1998 Guylhem Aznar.
Distributed under LDP copyright license. If you have questions,
please contact the Linux HOWTO coordinator, at howto at
wallybox.cei.net.
11..66.. LLiimmiitteedd wwaarrrraannttyy
Of course, I 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.
22.. OOtthheerr ssoouurrcceess ooff iinnffoorrmmaattiioonn
22..11.. TThheerree iiss aa MMaaiill UUsseerr''ss HHOOWWTTOO,, wwhhiicchh ffooccuusseess oonn uusseerr iissssuueess.. IItt
iiss ccuurrrreennttllyy mmaaiinnttaaiinneedd bbyy EErriicc SS.. RRaayymmoonndd;; yyoouu sshhoouulldd bbee aabbllee ttoo vviieeww
iitt oonn tthhee WWoorrlldd WWiiddee WWeebb aatt uurrllnnaamm <<
http://meta-
lab.unc.edu/LDP/HOWTO/Mail-User-HOWTO.html>. Mail User's HOWTO
22..22.. UUSSEENNEETT
There is nothing special about configuring and running mail software
under Linux (any more). Accordingly, you almost certainly do _N_O_T want
to be posting generic mail-related questions to the comp.os.linux.*
newsgroups.
Don't post in comp.os.linux hierarchy unless it's really linux
specific, for example : "Which options was Debian 1.2 sendmail
compiled with ?" or "RedHat 5.0 smail crashes when I run it".
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.
_I_F _Y_O_U _P_O_S_T _T_O _C_O_M_P_._O_S_._L_I_N_U_X_._* _F_O_R _N_O_N_-_L_I_N_U_X_-_S_P_E_C_I_F_I_C _Q_U_E_S_T_I_O_N_S_, _Y_O_U
_A_R_E _L_O_O_K_I_N_G _I_N _T_H_E _W_R_O_N_G _P_L_A_C_E _F_O_R _H_E_L_P_. _T_H_E _M_A_I_L _E_X_P_E_R_T_S _H_A_N_G _O_U_T _I_N
_T_H_E _P_L_A_C_E_S _I_N_D_I_C_A_T_E_D _A_B_O_V_E _A_N_D _G_E_N_E_R_A_L_L_Y _D_O _N_O_T _R_U_N _L_I_N_U_X_.
_P_O_S_T_I_N_G _T_O _T_H_E _L_I_N_U_X _H_I_E_R_A_R_C_H_Y _F_O_R _N_O_N_-_L_I_N_U_X_-_S_P_E_C_I_F_I_C _Q_U_E_S_T_I_O_N_S _W_A_S_T_E_S
_Y_O_U_R _T_I_M_E _A_N_D _E_V_E_R_Y_O_N_E _E_L_S_E_'_S _A_N_D _I_T _F_R_E_Q_U_E_N_T_L_Y _D_E_L_A_Y_S _Y_O_U_R _G_E_T_T_I_N_G
_T_H_E _A_N_S_W_E_R _T_O _Y_O_U_R _Q_U_E_S_T_I_O_N_.
GOOD PLACES are :
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.
22..33.. MMaaiilliinngg LLiissttss
There are many sendmail, smail and qmail mailing lists.
You can find addresses in /usr/doc/the_one_you_have_chosen.
22..44.. OOtthheerr ddooccuummeennttss ffrroomm LLDDPP
There is plenty of excellent material provided in the other Linux
HOWTO documents and from the Linux DOC project.
In particular, you might want to take a look at the following:
+o on your own computer in /usr/doc/ :-)
+o the Linux Networking Administrators' Guide
+o the Mail Users HOWTO
+o the Serial Communications HOWTO
+o the Ethernet HOWTO
+o the UUCP HOWTO if you're fed via UUCP
22..55.. BBooookkss
The following is a non-inclusive set of books that will help:
+o "Managing UUCP and USENET" from O'Reilly and Associates is in my
opinion the best book out there for figuring out the programs and
protocols involved in being a USENET site.
+o "Unix Communications" from The Waite Group contains a nice
description of all the pieces (and more) and how they fit together.
+o "Sendmail" from O'Reilly and Associates looks to be the definitive
reference on sendmail-v8 and sendmail+IDA. It's a "must have" for
anybody hoping to make sense out of sendmail without bleeding in
the process.
+o "The Internet Complete Reference" from Osborne is a fine reference
book that explains the various services available on Internet and
is a great source for information on news, mail and various other
Internet resources.
+o "The Linux Networking Administrators' Guide" from Olaf Kirch of the
Linux Documentation Project is available on the net and is also
published by (at least) O'Reilly and SSC.
It makes a fine one-stop shop to learn about everything you ever
imagined you'd need to know about Unix networking.
33.. HHooww EElleeccttrroonniicc MMaaiill WWoorrkkss
Now we'll explain the flow of information that typically takes place
when two people to communicate by email. Let us suppose that Alice,
on her machine wonderland.com, wants to send mail to Bob, on his
machine dobbs.com. Both machines are connected to the Internet.
It helps to know that an Internet mail message consists of two parts;
mail headers and a mail body, separated by a blank line. The mail
headers contain the source and destination of the mail, a user-
supplied subject line, the date it was sent, and various other kinds
of useful information. The body is the actual content of the message.
Here's an example:
From: "Alice" <
[email protected]>
Message-Id: <
[email protected]>
Subject: Have you seen my white rabbit?
To:
[email protected] (Bob)
Date: Thu, 13 Nov 1997 12:04:05 -0500 (EST)
Content-Type: text
I'm most concerned. I fear he may have fallen down a hole.
--
>>alice>>
The arrangement and meaning of Internet mail headers are defined by an
Internet standard called RFC822 <
ftp://ftp.isi.edu/in-
notes/rfc822.txt>.
33..11.. MMaaiill bbeettwweeeenn ffuullll--ttiimmee IInntteerrnneett mmaacchhiinneess
Here's a diagram of the whole process -- I'll explain all the stages
and terminology below.
______________________________________________________________________
+---------+ +-------+
+-------+ types | sending | calls |sending|
| Alice |--------->| MUA |--------->| MTA |::::>::::
+-------+ | | | | :: on the
+---------+ +-------+ :: sending
:: machine
.......................................................................
SMTP ::
::::::::::::::::::::::::::::<::::::::::::::::::::::::::::
::
:: +---------+ +-----+ +-------+
:: |receiving| calls | | delivers to | Bob's |
::::>| MTA |--------->| LDA |===============>|mailbox| on the
| | | | | | receiving
+---------+ +-----+ +-------+ machine
| |
| |
+----------------<-------------+ |
| |
+---------+ +-------+ |
| Bob's | | Bob's |<----------+
| notifier| | MUA |
+---------+ +-------+
| |
| +-----+ |
+----->| Bob |<----+
+-----+
______________________________________________________________________
To send mail, Alice will invoke a program called a mail user agent (or
MUA for short). The MUA is what users think of as `the mailer'; it
helps her compose the message, usually by calling out to a text editor
of her choice. When she hits the MUA `send' button, her part of the
process is done. Later in this HOWTO we will survey popular MUAs.
The MUA she uses immediately hands her message to a program called a
mail transport agent (or MTA). Usually this program will be sendmail,
though some alternative MTAs are gaining popularity and may appear in
future Linux distributions. Later in this HOWTO we will also survey
MTAs.
The MTA's job is to pass the mail to an MTA on Bob's machine. It
determines Bob's machine by analyzing the To header and seeing the
dobbs.com on the right-hand side of Bob's address. It uses that
address to open an Internet connection to Bob's machine. The
mechanics of making that connection are a whole other topic; for this
explanation, it's enough to know that that connection is a way for
Alice's MTA to send text commands to Bob's machine and receive replies
to those commands.
The MTA's commands don't go to a shell. Instead they go to a service
port on Alice's machine. A service port is a sort of rendezvous, a
known place where Internet service programs listen for incoming
requests. Service ports are numbered, and Alice's MTA knows that it
needs to talk to port 25 on Bob's machine to pass mail.
On port 25, Bob's machine has its own MTA listening for commands
(probably another copy of sendmail). Alice's MTA will go through a
dialogue with Bob's using Simple Mail Transfer Protocol (or SMTP).
Here is what an SMTP dialogue looks like. Lines sent by Alice's
machine are shown with S:, responses from Bob's machine are shown with
R:.
S: MAIL FROM:<
[email protected]>
R: 250 OK
S: RCPT TO:<
[email protected]>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: From: "Alice" <
[email protected]>
S: Message-Id: <
[email protected]>
S: Subject: Have you seen my white rabbit?
S: To:
[email protected] (Bob)
S: Date: Thu, 13 Nov 1997 12:04:05 -0500 (EST)
S: Content-Type: text
S:
S: I'm most concerned. I fear he may have fallen down a hole.
S: --
S: >>alice>>
S: .
R: 250 OK
Usually an SMTP command is a single text line and so is its response.
The DATA command is an exception; after seeing that, the SMTP listener
accepts message lines until it sees a period on a line by itself.
(SMTP is defined by the Internet standard RFC821
<
ftp://ftp.isi.edu/in-notes/rfc821.txt>.)
Now Bob's MTA has Alice's message. It will add a header to the
message that looks something like this:
Received: (from
[email protected])
by mail.dobbs.com (8.8.5/8.8.5) id MAA18447
for
[email protected]; Thu, 13 Nov 1997 12:04:05 -0500
This is for tracking purposes in case of mail errors (sometimes a
message has to be relayed through more than one machine and will have
several of these). Bob's MTA will pass the modified message to a
local delivery agent or LDA. On Linux systems the LDA is usually a
program called procmail, though others exist.
The LDA's job is to append the message to Bob's mailbox. It's
separate from the MTA so that both programs can be simpler, and so the
MTA can concentrate on doing Internet things without worrying about
local details like where the user mailboxes live.
Bob's mailbox will normally be a file called /usr/spool/mail/bob or
/var/mail/bob. When he reads mail, he runs his own MUA (mail user
agent) to look at and edit that file.
33..22.. NNoottiiffiieerrss
There's yet another kind of program that is important in the mail
chain, though it does not itself read or transmit mail. It's a _m_a_i_l
_n_o_t_i_f_i_e_r, a program that watches your email in-box for activity and
signals you when new mail is present.
The original notifier was a pair of Unix programs called biff(1) and
comsat(8). The biff program is a front end that enables you to turn on
the comsat service. When this service is on, the header of new mail
will be dumped to your terminal as it arrived. This facility was
designed for people using line-oriented programs on CRTs; it's not
really a good idea in today's environment.
Most Unix shells have built-in mailcheck facilities that allow them to
function as notifiers in a rather less intrusive way (by emitting a
message just before the prompt when new mail is detected). Typically
you can enable this by setting environment variables documented on the
shell's manual page. For shells in the sh/ksh/bash family, see the
MAIL and MAILPATH variables
Systems supporting X come with one of several little desktop gadgets
that check for new mail periodically and give you both visible and
audible indication of new mail. The oldest and most widely used of
these is called _x_b_i_f_f; if your Linux has a preconfigured X desktop
setup, xbiff is probably on it. See the xbiff(1) manual page for
details.
33..33.. MMaaiill ttoo ppaarrtt--ttiimmee IInntteerrnneett mmaacchhiinneess
If you were reading carefully, you may have noticed that the
information flow we described above depends on Alice's machine being
able to talk to Bob's machine immediately. What happens if Bob's
machine is down, or is up but not connected to the Internet?
If Alice's MTA can't reach Bob's immediately, it will stash Alice's
message in a mail queue on wonderland.com. It will then retry sending
the mail at intervals until an expiration time is reached, at which
point a bounce message notifying Alice of the failure will be sent
back to her. In the default configuration of the most popular MTA
(sendmail), the retry interval is 15 minutes and the expiration time
is 4 days.
33..44.. RReemmoottee mmaaiill aanndd rreemmoottee--mmaaiill pprroottooccoollss
Many Linux users nowadays are connected to the Internet via ISPs
(Internet Service Providers) and don't have their own Internet
domains. Instead they have accounts on an ISP machine. Their mail
gets delivered to a mailbox on that ISP machine. But typically these
users want to read and reply to their mail using their own machines,
which connect to the ISP intermittently using SLIP or PPP. Linux
supports remote mail protocols to support this.
Note how this is different from the scenario we discussed in the last
section. Mail sitting in a queue awaiting retransmission is not the
same as mail dispatched to a server mailbox; mail in a queue is not
considered to have been delivered and is subject to expiration, but
mail delivered to an ISP server mailbox _i_s considered `delivered' and
can sit there indefinitely.
A remote-mail protocol allows mail on a server to be pulled across a
network link by a client program (this is the opposite of normal
delivery in which an MTA pushes mail to a receiving MTA). There are
two remote-mail protocols in common use; POP3 (defined by the Internet
standard RFC1939 <
ftp://ftp.isi.edu/in-notes/rfc1939.txt>) and IMAP
(defined by the Internet standard RFC2060 <
ftp://ftp.isi.edu/in-
notes/rfc2060.txt>). Effectively all ISPs support POP3; a growing
number support IMAP (which is more powerful).
Here is what an example POP3 session looks like:
S: <client connects to service port 110>
R: +OK POP3 server ready <
[email protected]>
S: USER bob
R: +OK bob
S: PASS redqueen
R: +OK bob's maildrop has 2 messages (320 octets)
S: STAT
R: +OK 2 320
S: LIST
R: +OK 2 messages (320 octets)
R: 1 120
R: 2 200
R: .
S: RETR 1
R: +OK 120 octets
R: <the POP3 server sends message 1>
R: .
S: DELE 1
R: +OK message 1 deleted
S: RETR 2
R: +OK 200 octets
R: <the POP3 server sends message 2>
R: .
S: DELE 2
R: +OK message 2 deleted
S: QUIT
R: +OK dewey POP3 server signing off (maildrop empty)
S: <client hangs up>
An IMAP session uses different commands and responses, but is
logically very similar.
To take advantage of POP3 or IMAP, you need a remote mail client
program to pull your mail. Some mail user agents have client
capabilities built in (which one supports which is noted below), and
the Netscape browser's mail facility supports both POP and IMAP
natively.
The main drawback of POP client facilities built into MUAs is that you
have to explicitly tell your mailer to poll the server; you don't get
notified by xbiff(1) or equivalent, as you would for mail that is
either local or delivered by a conventional SMTP `push' connection.
Also, of course, not all MUAs can do POP/IMAP, so you may find
yourself compromising on other features.
Your Linux probably comes with a program called fetchmail
<
http://www.tuxedo.org/~esr/fetchmail> that is designed specifically
to talk to remote-mail servers, fetch mail, and feed it into your
normal mail delivery path by speaking SMTP to your listener.
Unless you need to keep your mail on the server (for example, because
you move around between client machines a lot) fetchmail is probably a
better solution than whatever POP/IMAP features your user agent has.
Fetchmail can be told to run in background and poll your server
periodically, so your xbiff(1) or other mail-notifier program will
work as it would for SMTP mail. Also, fetchmail is rather more
tolerant of various idiosyncracies and nonstandard server quirks than
the clients in MUAs, and has better error recovery.
Here's a diagram showing how both cases (with and without fetchmail)
work:
______________________________________________________________________
+---------+ +-------+
+-------+ types | sending | calls |sending|
| Alice |--------->| MUA |--------->| MTA |::::>::::
+-------+ | | | | ::
+---------+ +-------+ :: on the
:: sending
SMTP :: machine
::::::::::::::::::::::::::::<::::::::::::::::::::::::::::
::
.::.......................................................................
::
:: +---------+ +-----+ +-------+
:: |receiving| calls | | delivers | Bob's |
::::>| MTA |--------->| LDA |============>|server |::::>::::
| | | | to |mailbox| :: on the
+---------+ +-----+ +-------+ :: mail
:: server
POP or IMAP ::
::::::::::::::::::::::::::::<:::::::::::::::::::::::::::::::::::
::
.::........................................................................
::
:: +-----------+
:: | |
:::::::>::::::::::::| fetchmail |:::::::: on the
:: | | :: receiving
:: +-----------+ :: machine,
:: :: with fetchmail
:: ::::::::::::::::<:::::::::::::::::::
:: ::
:: :: +---------+ +-----+ +-------+
:: :: |receiving| calls | | delivers to | Bob's |
:: ::::>| MTA |--------->| LDA |===============>|mailbox|
:: | | | | | |
:: +---------+ +-----+ +-------+
:: | |
:: | |
:: +----------------<-------------+ |
:: | |
:: +---------+ +-------+ |
:: | Bob's | | Bob's |<----------+
:: | notifier| | MUA |
:: +---------+ +-------+
:: | |
.::........................................................................
:: . | |
:: without . | |
:: fetchmail . | |
:: . | +-----+ |
:: +----------+ . +----->| |<----+
:: | Bob's | . | Bob |
:::::| POP/IMAP |----.--------->| |
| MUA | . +-----+
+----------+ .
______________________________________________________________________
33..55.. MMaaiillbbooxx ffoorrmmaattss
When incoming mail gets appended to a mailbox, it's up to the MTA to
provide some kind of delimiters that tell where one message stops and
the next begins.
Under Unix, the convention almost all mailers use is that each line
beginning with ``From '' (the space is significant) begins a new
message. If ``From '' occurs at the beginning of a line in text, a
Unix MTA will generally prefix it with a greater-than sign, so it
looks like ``>From ''. RFC822 headers follow this From line (which
usually continues with the sender name and receipt date).
This convention originated with Unix Version 7, so this kind of
mailbox is referred to as a ``V7 mailbox''; it is also sometimes
called ``mbox format''. Unless otherwise noted, all programs
mentioned in this HOWTO expect this format. It is not, however, quite
universal, and tools expecting and generating different formats can
confuse each other badly.
The four other formats to know about (and beware of!) are BABYL, MMDF,
MH, and qmail maildir. Of these, MMDF is the simplest; it uses a
delimiter line consisting four control-As (ASCII 001) characters
followed by CR-LF. MMDF was an early and rather crude Internet mail
transport; a descendant is still in use on SCO systems.
BABYL is another survival, from an early mail system at MIT. It is
still used by Emacs's mail-reader mode.
MH and qmail maildir are `mailbox' formats which actually burst each
mailbox into a directory of files, one per message. Running grep on
such a `mailbox' will get you nowhere, since all grep will see are the
directory bits.
Microsoft Outlook Express .mbx mailboxes can be converted to RFC822
format with mbx2mbox app.
44.. RReeqquuiirreemmeennttss
44..11.. HHaarrddwwaarree
There are no specific hardware requirements for mail under Linux.
You'll need some sort of 'transport' software to connect to remote
systems, which means either TCP/IP or uucp.
This could mean that you need a modem or ethernet card, depending on
your setup. In most cases, you'll want the fastest modem you can
afford, i.e. V90 57 600 bps currently. In general, you want to have a
16550 UART on your serial board or built into your modem to handle
speeds of above 9600 baud.
If you don't know what that last sentence means, please consult the
comp.dcom.modems group or the various fine modem and serial
communications FAQs and periodic postings on USENET.
55.. CChhoooossiinngg aa MMaaiill TTrraannssppoorrtt AAggeenntt
Mail transport agents are the software that transfers mail from your
local system to remote systems. It is very seldom necessary to mess
with or replace your MTA on a modern Linux, and you're better off not
fixing what isn't broken. Nevertheless, here's a survey to get you
started on understanding what the tradeoffs are if you decide you need
more security or performance than your system's default can offer.
(There are other Unix MTAs besides these, but you are quite unlikely
to encounter them on a Linux box.)
Each has its own unique features, but the best compromise is qmail. It
features high security (even if vmail is more secure), high speed
(even if smail is faster for local uses) and ease of configuration.
Of course, feel free to choose any mail software. The information
provided here is intended to help you choose well.
Sendmail can be nice for many sites with complicated options, but I
think its configuration is too hard for beginners while it is not very
secure or very fast, so there is only a rreeaallllyy outdated sendmail
section in this HOWTO.
If you know what you're doing, choose sendmail (and you shouldn't be
reading this HOWTO!); otherwise I generally recommend qmail.
Detailed descriptions of these programs follow.
55..11.. sseennddmmaaiill
BSD sendmail is the grandaddy of Internet MTAs. It has outlasted a
few would-be successors. Most Linux distributions now use it and have
it preinstalled.
Sendmail has a long-standing reputation for being an administrator's
nightmare -- hard to understand, tricky to configure, rife with
security holes. As Internet technology and standards have stabilized,
however, many of the sendmail options and configurable rules that gave
rise to this reputation have ceased to require per-site tweaking (the
effective demise of non-TCP/IP network layers like UUCP has helped a
lot). Also, recent sendmail versions have an improved configuration
system that insulates you from the legendary hideousness of the
sendmail.cf configuration file. Most importantly, sendmail now
normally comes preconfigured, and you should never need to touch it
unless you have unusual requirements (such as needing to route mail
over a non-TCP/IP network).
There is a sendmail home page at <
http://www.sendmail.org>. It
includes references to extensive documentation of sendmail, should you
actually need to wrestle with custom-configuring it.
Other MTAs, if called as `sendmail', may mimic the semantics of
sendmail's command-line options. This is convenient for mail user
agents, which often assume they are talking to sendmail.
55..22.. ssmmaaiill vv33..22
Smail was the first serious attempt to replace sendmail. It has a
simpler and much more comprehensible configuration system than
sendmail's, and it's fairly secure. Some Linux distributions
preinstall it rather than sendmail.
At one time smail's excellent support for mixed TCP/IP and UUCP sites
was a major selling point for it, but as UUCP has declined, so has
smail. Also, smail is less efficient than sendmail on high-volume
connections.
As with sendmail, it is unlikely that you will need to tweak a
preinstalled smail configuration.
(Very occasionally you might run across references to an `smail 2.5'.
This program has been obsolete for a long time. Don't bother with
it.)
55..33.. qqmmaaiill
The qmail program is a sendmail-compatible MTA designed specifically
for high security. The author has a standing reward of $500 for
publication of the first verifiable security hole; this reward has
gone unclaimed since March 1997.
The qmail home page is at <
http://pobox.com/~djb/qmail.html>.
55..44.. eexxiimm
The exim program is similar to smail3, but with more features. It
advertises particular strengths in spam-blocking and support of
several virtual hosts (virtual DNS domains) on the same host.
The exim home page is at <
http://www.exim.org/>.
I tried it on my own computer, it looks like a nice merge between
smail configuration system and qmail security, moreover it has the
advantage of being GPL.
A section explaining how to replace your current MTA by exim will be
added soon.
66.. IInnssttaalllliinngg TTrraannssppoorrtt SSooffttwwaarree
66..11.. QQmmaaiill vv11..0033
Secured, fast and easy to use, this is my preferred MTA (mail
transport agent).
Currently, no distribution comes with qmail preinstalled. We will
focus on compiling and installing qmail, since this is the only tricky
part: configuration is really straightforward.
66..11..11.. GGeettttiinngg qqmmaaiill
Go to www.qmail.org to download the latest version.
66..11..22.. UUnnccoommpprreessssiinngg ssoouurrcceess
Then decompress it by running:
mv qmail.tar.gz /usr/local/src
cd /usr/local/src ; tar -zxvf qmail.tar.gz
If you find a bz2 version (new and better compression format), just
replace tar with:
bunzip2 qmail.tar.bz2
tar -xvf qmail.tar
66..11..33.. PPrreeppaarriinngg ffoorr ccoommppiillaattiioonn
Now enter the qmail directory to examine the configuration defaults:
cd qmail; more conf-*
You shouldn't need to change any defaults, but you could (for example)
specify an alternate installation directory or better compilation
flags.
Now run:
mkdir /var/qmail
to create target dir.
If you haven't installed a Debian distribution, you'll need to add
several user IDs for qmail's use: qmail's high security depends on
that.
The fact that qmail is divided into modules running each under their
own UID makes it much harder for an intruder to break your whole mail
system or gain root access by abusing it.
So run:
# groupadd nofiles
# useradd -g nofiles -d /var/qmail/alias alias
# useradd -g nofiles -d /var/qmail qmaild
# useradd -g nofiles -d /var/qmail qmaill
# useradd -g nofiles -d /var/qmail qmailp
# groupadd qmail
# useradd -g qmail -d /var/qmail qmailq
# useradd -g qmail -d /var/qmail qmailr
# useradd -g qmail -d /var/qmail qmails
or hand-edit /etc/passwd and /etc/group to add these users by
yourself.
Evan E. reported he had to use "-g groupid" parameter for a vanilla
groupadd (Caldera 1.2), else groupadd reported this error : "A group
with that name already exists."
For example you can respectively add:
qmail:*:2107:
nofiles:*:2108:
&
alias:*:7790:2108::/var/qmail/alias:/bin/true
qmaild:*:7791:2108::/var/qmail:/bin/true
qmaill:*:7792:2108::/var/qmail:/bin/true
qmailp:*:7793:2108::/var/qmail:/bin/true
qmailq:*:7794:2107::/var/qmail:/bin/true
qmailr:*:7795:2107::/var/qmail:/bin/true
qmails:*:7796:2107::/var/qmail:/bin/true
Now you can run
make setup check
to check your configuration, then :
./config
to configure qmail.
Attention, your server has to be resolvable by DNS or ./config will
get confused.
If you don't have DNS access, you can give your server name directly
via :
./config-fast foo.bar.com
Now you must install some aliases, since /etc/alias is not used by
qmail unless you compile and install an optional package.
Here's my setup :
File : ".qmail-MAILER-DAEMON"
&postmaster
File : ".qmail-bin"
&root
File : ".qmail-daemon"
&root
File : ".qmail-decode"
&root
File : ".qmail-dumper"
&root
File : ".qmail-games"
&root
File : ".qmail-ingres"
&root
File : ".qmail-mailer-daemon"
&postmaster
File : ".qmail-manager"
&root
File : ".qmail-news"
&root
File : ".qmail-nobody"
&root
File : ".qmail-operator"
&root
File : ".qmail-postmaster"
&root
File : ".qmail-root"
&guylhem
File : ".qmail-system"
&root
File : ".qmail-toor"
&root
File : ".qmail-uucp"
&root
File : ".qmail-uucp-default"
|preline -dr /usr/bin/uux - -r -gC -a"${SENDER:-MAILER-DAEMON}" lm!rmail "($DEFAULT@$HOST)"
You need to create each of these file in ~alias, replacing &guylhem in
.qmail-root by your own login to get root mail.
ATTENTION UUCP USERS !
DO NOT TRUST THE QMAIL FAQ FOR UUCP, USE MY .qmail-uucp-default
INSTEAD! ELSE YOU WILL NOT BE ABLE TO SEND ANY MAIL BY YOUR UUCP
CONNEXION!
Now you'll need to decide in which format your users will get their
mail.
Here's my suggestion :
+o For NFS mounted home dirs, use MAILDIR format with a patch for
local mail readers (patchs are available on www.qmail.org)
+o If no patch is available, prefer MAILFILE format : any mail reader
can read a file containing mail, people will only need to create an
alias (for bash) or a setenv (for csh) for their mail reader
+o Avoid /var/spool/mail/$USER format, too insecure
To fix the default format, read each file in /var/qmail/boot then copy
the one you best like to /var/qmail/rc.
home or proc are safe choices, but prefer home for security reasons.
66..11..44.. CCoonnffiigguurriinngg qqmmaaiill
In /var/qmail/control, edit:
66..11..44..11.. ddeeffaauullttddoommaaiinn,, mmee,, pplluussddoommaaiinn
+o me is you local FQDN (full qualified domain name), for example on
my machine it is barberouge.linux.lmm.com
+o defaultdomain will be added to any host name without dots,
including defaulthost, for example you can set it to localnetwork
so any mail sent to joe@hisbox will be completed to be sent to
[email protected] instead
+o plusdomain is the exception: it is added to any host name that ends
with a plus sign, including defaulthost (set in me) if it ends with
a plus sign.
These 3 examples show you the power and ease of configuration of
qmail!
66..11..44..22.. llooccaallss,, rrccpptthhoossttss
If you want to support virtual domain names, just put additional names
in these files. Any mail you receive for these names will be handled
locally.
The difference between locals and rcpthosts is the latter isn't
considered as a local alias, which is useful if you receive mail from
some free email address like yahoo.com or lemel.fr while you also send
mail to other users of these non local services, i.e. you don't want
to handle locally mail send to
[email protected]!
66..11..44..33.. vviirrttuuaallddoommaaiinnss
There can you specify default outgoing mode, for example :
#:alias-uucp
if you don't want to send outgoing mail by uucp but by smtp (default)
or
:alias-ucp
if you send your outgoing mail by uucp.
66..11..55.. TTeessttiinngg qqmmaaiill
Now it is configured, try:
sh -cf '/var/qmail/rc &'
to launch qmail (it won't interfere with your local MTA), then:
echo to: mylogin | /var/qmail/bin/qmail-inject
You should receive this mail in the format you've chosen in
/var/qmail/boot/.
66..11..66.. RReemmoovviinngg yyoouurr ootthheerr MMTTAA
If this test was successful, just kill your previous MTA:
killall -STOP daemon_name ; if any children are running, you should
killall -CONT their_name, wait, killall -STOP again, and repeat ad
nauseam.
If there aren't any children, killall -TERM and then killall -CONT.
Remove it (how you can do this depends on the distribution you
installed, for example rpm -e --nodeps on RedHat, Caldera and Suse, or
dpkg -r --force-depends on Debian) then run:
# ln -s /var/qmail/bin/sendmail /usr/lib/sendmail
# ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail
Now set up qmail-smtpd in /etc/inetd.conf (all on one line):
smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd
If you are using a old non-SYSV-init distribution like redhat, just
add to your boot scripts:
sh -cf '/var/qmail/rc &'
Usually this should be /etc/rc.local but your mileage may vary.
For actual SYSV-init compliant distributions (RedHat, Caldera, Suse,
Debian), add this script to /etc/init.d/ or /etc/rc.d/init.d/ :
DEBIAN version:
#!/bin/sh
test -x /var/qmail/rc || exit 0
case "$1" in
start)
echo -n "Starting mta: "
sh -cf '/var/qmail/rc &'
echo "qmail."
;;
stop)
echo -n "Stopping mta: "
killall qmail-lspawn
echo "qmail."
;;
restart)
echo -n "Restarting mta: "
killall -HUP qmail-lspawn
killall -ALRM qmail-lspawn
echo "qmail."
;;
*)
echo "Usage: /etc/init.d/qmail {start|stop|restart}"
exit 1
esac
exit 0
REDHAT version:
#!/bin/sh
#
# qmail This shell script takes care of starting and stopping qmail.
#
# description: qmail is a Mail Transport Agent, which is the program \
# that moves mail from one machine to another.
# processname: qmail
# config: /var/qmail/control/
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
export PATH=$PATH:/var/qmail/bin
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
[ -f /usr/sbin/sendmail ] || exit 0
# See how we were called.
case "$1" in
start)
# Start daemons.
echo -n "Starting qmail: "
qmail-start '|preline procmail' splogger qmail &
touch /var/lock/subsys/qmail
echo
;;
stop)
# Stop daemons.
echo -n "Shutting down qmail: "
killproc qmail-lspawn
echo
rm -f /var/lock/subsys/qmail
;;
restart)
$0 stop
$0 start
;;
status)
status qmail
;;
*)
echo "Usage: qmail {start|stop|restart|status}"
exit 1
esac
exit 0
And make symlinks to each /etc/rc.d/rcN.d/, for example:
ln -sf /etc/init.d/qmail /etc/rc1.d/K19qmail
If the first letter is K, you will kill qmail on this runlevel (1 for
single mode or 6 for boot), but if the first letter is S, you will
start qmail on this runlevel (each others runlevel).
+o How to decide whether you should put a K or a S? Do what the
majority of daemons in this runlevel do!
+o What number should you put after K or S? The number next to your
network daemon.
That means the MTA will be started and stopped respectively after
and before the network daemon.
Without this, your network will be unreachable while the MTA would
expect it to work.
RedHat, Caldera and Suse will use /etc/rc.d/ instead of plain /etc/
for Debian distribution, i.e. /etc/rc.d/rc1.d or /etc/rc.d/init.d for
example.
66..11..77.. TThhaatt''ss aallll,, ffoollkkss!!
No need to reboot (remember, you're using linux, not some other cheap
OS!) for the modifications to take effect, just run:
killall inetd
init 1
To go to single user mode, then:
init 2
to go back to your default runlevel (indicated in /etc/inittab with
initdefault label).
You could also hand-start qmail script but "init" method will show you
if qmail script is well positioned, i.e. launched after network
scripts but before any program which depends on email to warn you
(like inn).
66..22.. SSmmaaiill vv33..11
Smail3.1 seems to be a de-facto standard transport agent for uucp-only
sites and for some smtp sites. It's easy to configure, it compiles
without patching from the sources and it's fairly secure.
66..22..11.. CCoonnffiigguurriinngg ssmmaaiill
Install the smail binary from your distribution (I recommend you
choose this) or get the smail sources and build smail. If you're
building smail from sources, you need to have the following in your
os/linux file so that 'sed' gives you shell scripts that work
properly.
CASE_NO_NEWLINES=true
Once it's installed, config. files will certainly go in /etc/smail
(but your mileage may vary if you use old distributions); let's start
editing them!
66..22..11..11.. ""ccoonnffiigg"" ffiillee
# From
smart_path=polux
smart_transport=uux
# To
hostname=barberouge
domains=linux.lmm.com
visible_name=barberouge.linux.lmm.com
uucp_name=barberouge.linux.lmm.com
# max_message_size=512k
# auth_domains=foo.bar
# more_hostnames=barberouge.polux.freenix.fr
Well, first, who is feeding you? I'm fed by "polux" via uucp (i.e.
uux transport); naturally you need to change this file according to
your own situation. For example, you could by fed by
"bargw.bar.foobar.com" via "smtp", in that case you don't need a
transport file and can define "-transport_file " to indicate you don't
need one.
You can also use "postmaster_address = yourname", hide the network
topology in outgoing addresses (if you're a gateway) using
"visible_name", set which aliases address can also be used for the
email you receive, using "more_hostnames".
See smail documentation for more details or the examples in
/usr/doc/smail/examples to see if any match your situation.
66..22..11..22.. ""ddiirreeccttoorrss"" ffiillee
# aliasinclude - expand ":include:filename" addresses produced by alias files
# This entry and the next one are pretty much boiler-plate. Reasons
# for making significant changes are few. The sole purpose of these
# is to match and expand addresses of the form:
# :include:pathname
# which may occur in alias files or mailing-list/forward files
# (produced by any director with a driver of forwardfile).
aliasinclude:
driver = aliasinclude, # use this special-case driver
nobody; # associate nobody user with addresses
# when mild permission violations
# are encountered
copysecure, # get permissions from alias director
copyowners, # get owners from alias director
# forwardinclude - expand ":include:filename" addrs produced by forward files
forwardinclude:
driver = forwardinclude, # use this special-case driver
nobody;
copysecure, # get perms from forwarding director
copyowners, # get owners from forwarding director
# aliases - search for alias expansions stored in a database
# This is the standard aliases file. It is used for generic things,
# like mapping root, postmaster, MAILER-DAEMON and uucp to site
# admins, creating some small system alias expansions, and such. In
# this site configuration, the aliases file is used mostly for
# machine-specific aliasing/forwarding information. Global forwarding
# information should be put in the "forward" database.
aliases:
driver=aliasfile, # general-purpose aliasing director
-nobody, # all addresses are associated
# with nobody by default, so setting
# this is not useful.
sender_okay, # don't remove sender from expansions
owner=owner-$user; # problems go to an owner address
file=/etc/aliases,
modemask=002, # should not be globally writable
optional, # ignore if file does not exist
proto=lsearch, # unsorted ASCII file
# forward - search for expansions stored in a forwarding database
# This is the subdomain-wide user forwarding database. Entries are
# maintained here for current or past users, to forward their mail to
# their preferred mail-reading machine. The forward database is
# shipped around the TCP/IP network as changes are made, to keep the
# network consistent.
#forward:
# driver = aliasfile, # general-purpose aliasing director
# -nobody, # all addresses are associated
# # with nobody by default, so setting
# # this is not useful.
# owner = real-$user; # problems go to an owner address
#
# file = /etc/forward,
# modemask = 002,
# proto = dbm, # use dbm(3X) library for access
# dotforward - expand .forward files in user home directories
# For users that have an entry in the "forward" database, a ".forward"
# file is only used if it is on the "home" machine, as identified in
# the forward database. If used, it is treated as a list of addresses
# to which mail should be delivered, rather than (or in addition to)
# the user identified in the local address.
dotforward:
driver = forwardfile, # general-purpose forwarding director
owner = postmaster, nobody, sender_okay;
file = ~/.forward, # .forward file in home directories
checkowner, # the user can own this file
owners = root, # or root can own the file
modemask = 002, # it should not be globally writable
caution = daemon:root, # don't run things as root or daemon
# be extra careful of remotely accessible home directories
unsecure = "~uucp:/tmp:/usr/tmp:/var/tmp"
# forwardto - expand a "Forward to " in user mailbox files
# This emulates the V6/V7/System-V forwarding mechanism which uses a
# line of forward addresses stored at the beginning of user mailbox files
# prefixed with the string "Forward to "
forwardto:
driver = forwardfile,
owner = postmaster, nobody, sender_okay;
file = /var/spool/mail/${lc:user}, # point at user mailbox files
forwardto, # enable "Forward to " function
checkowner, # the user can own this file
owners = root, # or root can own the file
modemask = 0002, # under System V, group mail can write
caution = daemon:root # don't run things as root or daemon
# user - match users on the local host with delivery to their mailboxes
user: driver = user; # driver to match usernames
transport = local # local transport goes to mailboxes
# real_user - match usernames when prefixed with the string "real-"
# This is useful for allowing an address which explicitly delivers to a
# user's mailbox file. For example, errors in a .forward file expansion
# could be delivered here, or forwarding loops between multiple machines
# can be resolved by using a real-username address. Also, users that
# wish to use mail as a means of transferring data to a machine that
# is not their "home" machine can mail to
[email protected].
real_user:
driver = user;
transport = local,
prefix = "real-" # for example, match real-root
# lists - expand mailing lists stored in a list directory
# mailing lists can be created simply by creating a file in the
# /etc/smail/lists directory.
lists: driver = forwardfile,
caution, # flag all addresses with caution
nobody, # and then associate the nobody user
owner = owner-$user; # system V sites may wish to use
# o-$user, as owner-$user may be
# too long for a 14-char filename.
file = lists/${lc:user} # lists is under $smail_lib_dir
# owners - expand mailing lists stored in a list owner directory
# mailing lists owner lists can be created simply by creating a file
# in the /etc/smail/lists/owner directory. Mailing list owners
# are sent locally generated errors dealing with a mailing list of the
# same name. To create an owner list for a mailing list, create a
# file with the name of the list in /etc/smail/lists/owner. This
# will create a list address of owner-listname, as is used by the
# "lists" director above.
owners: driver = forwardfile,
caution, # flag all addresses with caution
nobody, # and then associate the nobody user
owner = postmaster; # system V sites may wish to use
# o-$user, as owner-$user may be
# too long for a 14-char filename.
prefix = "owner-",
file = lists/owner/${lc:user} # lists is under $smail_lib_dir
# request - expand mailing lists stored in a list request directory
# mailing lists request lists can be created simply by creating a file
# in the /etc/smail/lists/request directory. Request addresses
# are typically used as a standard address for queries about a mailing
# list. For example, requests for additions or deletions to a list
# will generally be sent to "list-request", which should be set up to
# forward to the appropriate person or persons.
request: driver = forwardfile,
caution, # flag all addresses with caution
nobody, # and then associate the nobody user
owner = postmaster; # system V sites may wish to use
# o-$user, as owner-$user may be
# too long for a 14-char filename.
suffix = "-request",
file = lists/request/${lc:user} # lists is under $smail_lib_dir
You shouldn't need to change anything here, only mailing list options
if you intend to run some using smail, or forwards options if, for
example, you want to disable forwarding.
66..22..11..33.. ""ffiiddooppaatthhss"" ffiillee
.f105.n324.z2.fidonet.org f105.n324.z2.fidonet.org!%s
.n324.z2.fidonet.org f105.n324.z2.fidonet.org!%s
.z2.fidonet.org f105.n324.z2.fidonet.org!%s
.fidonet.org f105.n324.z2.fidonet.org!%s
Create such a file only if you're using ifmail and FIDO.
66..22..11..44.. ""rroouutteerrss"" ffiillee
# forces - force certain paths
# This database exists as a means of hardcoding the paths to various
# machines or domains. It is for use in creating temporary tweaks to
# the other routing databases. To change the database, edit the file
# maps/force.path and type "make" in the maps/ subdirectory.
forces:
driver = pathalias, # router to search paths file
method = /etc/smail/maps/table; # transports are in this file
file = forcepaths, # file containing force path info
proto = lsearch, # use the sorted path file
optional,
reopen # close when not being used
uucp_neighbors:
driver=uuname, # use a program which returns neighbors
transport=uux;
cmd="/usr/bin/uuname -a", # specifically, use the uuname program
# domain=uucp # strip ending ".uucp"
# smart_host - a partially specified smarthost director
# If the config file attribute smart_path is defined as a path from the
# local host to a remote host, then hostnames not matched otherwise will
# be sent off to the stated remote host. The config file attribute
# smart_transport can be used to specify a different transport.
# If the smart_path attribute is not defined, this router is ignored.
smart_host:
driver = smarthost, # special-case driver
transport = uux # by default deliver over UUCP
# path=phreak
# ifmail - to send mails to fidonet and vice versa
ifmail:
driver=pathalias,
transport=ifmail;
file=fidopaths,
proto=lsearch
You should only include ifmail chapter if you use ifmail for FIDO
mails. Note you can also change transport mode from "uux" (ie UUCP)
to, for example, "smtp" or even 'hardcode the paths to various
machines or domains' in "/etc/smail/maps/table".
This is useful if you want outgoing mail for your local network to be
delivered immediately, since there's no need for it to be routed to
your uucp connexion of your internet access.
66..22..11..55.. ""ttrraannssppoorrttss"" ffiillee
# local - deliver mail to local users
# Tell smail to append directly to user mailbox files in the /var/spool/mail
# directory.
#local: driver = appendfile, # append message to a file
# -return_path, # include a Return-Path: field
# local, # use local forms for delivery
# from, # supply a From_ envelope line
# unix_from_hack; # insert > before From in body
#
# file = /var/spool/mail/${lc:user}, # use this location for Linux
# # Note, mail spool must be 1777
# file = ~/mailfile, # use this location for better security
# group = mail, # group to own file for System V
# mode = 0660, # under System V, group mail can access
# suffix = "\n", # append an extra newline
# append_as_user,
# This allows each user to have a ~/.procmailrc file to control filtering
# of mail and saving mail from mail lists in separate mailboxes if they wish.
local: +inet,
-uucp,
driver = pipe, # append message to a file
return_path, # include a Return-Path: field
local, # use local forms for delivery
from, # supply a From_ envelope line
unix_from_hack; # insert > before From in body
cmd = "/usr/bin/procmail", # use procmail for local delivery
parent_env, # environment info from parent addr
pipe_as_user, # use user-id associated with address
umask = 0022, # umask for child process
# -ignore_status, # exit status should be believed
# -ignore_write_errors, # retry on broken pipes
# pipe - deliver mail to shell commands
# This is used implicitly when smail encounters addresses which begin with
# a vertical bar character, such as "|/usr/lib/news/recnews talk.bizarre".
# The vertical bar is removed from the address before being given to the
# transport.
#pipe: driver = pipe, # pipe message to another program
# return_path, local, from, unix_from_hack;
#
# cmd = "/bin/sh -c $user", # send address to the Bourne Shell
# parent_env, # environment info from parent addr
# pipe_as_user, # use user-id associated with address
# umask = 0022, # umask for child process
# -log_output, # do not log stdout/stderr
# ignore_status, # exit status may be bogus, ignore it
# ignore_write_errors, # ignore broken pipes
# file - deliver mail to files
# This is used implicitly when smail encounters addresses which begin with
# a slash or squiggle character, such as "/usr/info/list_messages" or
# perhaps "~/Mail/inbox".
#file: driver = appendfile,
# return_path, local, from, unix_from_hack;
#
# file = $user, # file is taken from address
# append_as_user, # use user-id associated with address
# expand_user, # expand ~ and $ within address
# check_path,
# suffix = "\n",
# mode = 0644
# uux - deliver to the rmail program on a remote UUCP site
#
# As many as five recipient addresses will be delivered to the remote
# host in one UUCP transaction.
uux: driver = pipe,
-uucp,
inet,
# uucp, # use UUCP-style addressing forms
from, # supply a From_ envelope line
max_addrs = 5, # at most 5 addresses per invocation
max_chars = 200; # at most 200 chars of addresses
# the -r flag prevents immediate delivery, parentheses around the
# $user variable prevent special interpretation by uux.
cmd = "/usr/bin/uux - -r -g$grade $host!rmail $((${strip:user})$)",
# cmd="/usr/bin/uux - $host!rmail $(($user)$)",
ignore_write_errors, # ignore broken pipes
umask = 0022,
# pipe_as_sender,
# uux_one_addr - deliver mail over UUCP to a remote host that can take
# one address at a time.
# This is often necessary when delivering to a site running an unmodified
# version of 4.1BSD.
uux_one_addr:
driver = pipe,
uucp, # use UUCP-style addressing forms
from; # supply a From_ envelope line
# the -r flag prevents immediate delivery
cmd = "/usr/bin/uux - -r -g$grade $host!rmail (${strip:user})",
umask = 0022,
pipe_as_sender
queueonly:
driver = pipe; # send the message to a pipe
cmd = "/usr/lib/sendmail -Q -f $sender -bm $user",
# use getmail for local delivery
user=root, # execute getmail as "root"
group=mail, # execute getmail as "mail"
parent_env, # environment info from parent addr
-pipe_as_user, # use user-id associated with address
umask = 0007, # umask for child process
# to deliver the message. The smtp transport is included only if BSD
# networking exists.
# The uucp attribute can be specified for transfers within the UUCP
# zone. The inet attribute must be specified for transfers within the
# Internet.
# NOTE: This is hardly optimal, a backend should exist which can handle
# multiple messages per connection.
# ALSO: It may be necessary to restrict max_addrs to 100, as this is the
# lower limit SMTP requires an implementation to handle for one
# message.
smtp: driver=tcpsmtp,
inet, # if UUCP_ZONE is not defined
# uucp, # if UUCP_ZONE is defined
-max_addrs, -max_chars; # no limit on number of addresses
short_timeout=5m, # timeout for short operations
long_timeout=2h, # timeout for longer SMTP operations
service=smtp, # connect to this service port
# For internet use: uncomment the below 4 lines
use_bind, # resolve MX and multiple A records
defnames, # use standard domain searching
defer_no_connect, # try again if the nameserver is down
local_mx_okay, # fail an MX to the local host
ifmail:
from,received,max_addrs=5,max_chars=200,
driver=pipe;
pipe_as_sender,
cmd="/usr/local/bin/ifmail -x9 -r$host $((${strip:user})$)"
You should include an ifmail chapter only if you use ifmail for FIDO
mail. Apart from that, you shouldn't need to edit anything in this
file which defines transport agents (like uux, smtp ...) you can use
as parameters in other config. files.
Note I commented out some parts, like "pipes" or "file", to enhance
security.
66..22..11..66.. ""mmaappss//"" ddiirreeccttoorryy
It contains map and table files:
First, map file
#N foo.bar foo2.bar2
#S AT 486/RedHat Linux 1.2.13
#O organization
#C contact
#E administration (email)
#T phone
#P address
#R
#U hosts connected via uucp
#W created/edited by
#
hname polux
hname linux.eu.org
hname = polux
hname = polux.linux.eu.org
Once again, edit this file to match you situation (I'm fed by
polux.linux.eu.org).
Now table file
* uux
You can define different transports to different paths, for example
"smtp" for the machines in your local network, "uux" (i.e. uucp) for
the rest of the world or vice-versa (I'm using uucp for any outgoing
mail, therefore I use "*"!).
66..22..22.. OOtthheerr ggoooodd eexxaammpplleess
The previous files are the one I currently use for my site, you
shouldn't encounter any problem using them as samples/basis for your
own files.
The following files are provided only as good examples to configure
smail a different way.
#ident "@(#) transports,v 1.2 1990/10/24 05:20:46 tron Exp"
# See smail(5) for a complete description of the contents of this file.
# local - deliver mail to local users
#
# Tell smail to append directly to user mailbox files in the /usr/mail
# directory.
local: driver = appendfile, # append message to a file
return_path, # include a Return-Path: field
local, # use local forms for delivery
from, # supply a From_ envelope line
unix_from_hack; # insert > before From in body
file = /usr/mail/${lc:user}, # use this location for System V
group = mail, # group to own file for System V
mode = 0660, # under System V, group mail can access
suffix = "\n", # append an extra newline
append_as_user,
# pipe - deliver mail to shell commands
#
# This is used implicitly when smail encounters addresses which begin with
# a vertical bar character, such as "|/usr/lib/news/recnews talk.bizarre".
# The vertical bar is removed from the address before being given to the
# transport.
pipe: driver = pipe, # pipe message to another program
return_path, local, from, unix_from_hack;
cmd = "/bin/sh -c $user", # send address to the Bourne Shell
parent_env, # environment info from parent addr
pipe_as_user, # use user-id associated with address
umask = 0022, # umask for child process
-log_output, # do not log stdout/stderr
ignore_status, # exit status may be bogus, ignore it
ignore_write_errors, # ignore broken pipes
# file - deliver mail to files
#
# This is used implicitly when smail encounters addresses which begin with a
# slash or squiggle character, such as "/usr/info/list_messages" or perhaps
# "~/Mail/inbox".
file: driver = appendfile,
return_path, local, from, unix_from_hack;
file = $user, # file is taken from address
append_as_user, # use user-id associated with address
expand_user, # expand ~ and $ within address
suffix = "\n",
mode = 0644
# uux - deliver to the rmail program on a remote UUCP site
#
# As many as five recipient addresses will be delivered to the remote host in
# one UUCP transaction.
uux: driver = pipe,
uucp, # use UUCP-style addressing forms
from, # supply a From_ envelope line
max_addrs = 5, # at most 5 addresses per invocation
max_chars = 200; # at most 200 chars of addresses
# the -r flag prevents immediate delivery, parentheses around the
# $user variable prevent special interpretation by uux.
cmd = "/usr/bin/uux - -r -g$grade $host!rmail $((${strip:user})$)",
umask = 0022,
pipe_as_sender
# uux_one_addr - deliver mail over UUCP to a remote host that can take one
# address at a time.
#
# This is often necessary when delivering to a site running an unmodified
# version of 4.1BSD.
uux_one_addr:
driver = pipe,
uucp, # use UUCP-style addressing forms
from; # supply a From_ envelope line
# the -r flag prevents immediate delivery
cmd = "/usr/bin/uux - -r -g$grade $host!rmail (${strip:user})",
umask = 0022, pipe_as_sender
# demand - deliver to a remote rmail program, polling on demand
demand: driver = pipe,
uucp, from, max_addrs = 5, max_chars = 200;
# with no -r flag, try to contact remote site immediately
cmd = "/usr/bin/uux - -g$grade $host!rmail $(($user)$)",
umask = 0022, pipe_as_sender
# uusmtp - deliver to the rsmtp program on a remote UUCP site
#
# Deliver using a simple Batched SMTP protocol to the remote machine.
# This allows much more arbitrary addresses to be used. It also
# removes the limit on recipient addresses per invocation of uux.
uusmtp: driver = pipe,
bsmtp, # send batched SMTP commands
-max_addrs, # there is no limit on the number or
-max_chars; # total size of recipient addresses.
# supply -r to prevent immediate delivery, the recipient addresses
# are stored in the data sent to the standard input of rsmtp.
cmd = "/usr/bin/uux - -r -g$grade $host!rsmtp",
umask = 0022, pipe_as_sender
# demand_uusmtp - deliver to a remote rsmtp program, polling on demand
demand_uusmtp:
driver = pipe,
bsmtp, -max_addrs, -max_chars;
# with no -r flag, try to contact remote site immediately
cmd = "/usr/bin/uux - -g$grade $host!rsmtp",
umask = 0022, pipe_as_sender
# smtp - deliver using SMTP over TCP/IP
#
# Connect to a remote host using TCP/IP and initiate an SMTP conversation to
# deliver the message. The smtp transport is included only if BSD networking
# exists.
# NOTE: It may be necessary to restrict max_addrs to 100, as this is the
# lower limit SMTP requires an implementation to handle for one
# message.
smtp: driver = smtp,
-max_addrs,
-max_chars
#ident "@(#) table,v 1.2 1990/10/24 05:20:31 tron Exp"
# This file names the transports that are to be used in delivering
# to specific hosts from bargw.
#host transport
#-------- ---------
curdsgw demand_uusmtp # deliver using batched SMTP
oldbsd uux_one_addr # 4.1BSD sites cannot take more than one addr
sun demand # call sun when their is mail to send
* uux # for all others, poll at intervals
66..22..33.. RReessttaarrttiinngg iinneettdd
To run smail as a smtp daemon, add one of the following to
/etc/inetd.conf:
smtp stream tcp nowait root /usr/bin/smtpd smtpd
or:
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
Outgoing mail gets sent automatically, when using elm.
66..22..44.. SSmmaaiill wwiitthh ssmmttpp
Generally, ISPs use smtp, therefore you shouldn't have any problems
sending your mail. If your internet link is down when you send mail,
then the mail sits in "/var/spool/smail/input". When the link next
comes up, "runq" is run which causes the mail to be sent. However,
receiving mail is tthhee problem since your provider has many clients to
look after, not only you!
Usually, you can retrieve your mail via the POP protocol, see POP
section below.
66..33.. OOUUTTDDAATTEEDD SSEECCTTIIOONN:: SSeennddmmaaiill++IIDDAA
For big sites, sendmail is worth choosing, due to the "incredible ease
of use", (very relative feeling when you know qmail) but you must
decide which you want between sendmail+IDA and sendmail 8.x:
+o If you use an old kernel (1.0): sendmail+IDA
+o If you use a not so old kernel (1.2): sendmail+IDA and source code
editing
+o Recent kernel (2.0) will choose sendmail 8.x
Remember, linux newbies or people concerned by security / ease of
configuration should rather try using smail or qmail, which are easier
to use and safer.
66..33..11.. SSoouurrccee iinnssttaallllaattiioonn
If your distribution doesn't provide you with a ready-to-install
sendmail package (.rpm for RedHat, Caldera and Suse, .deb for Debian)
just download the sources and run:
+o cd / ; tar -zxvf sendmail5.67b+IDA1.5.tgz
+o cd to /usr/local/lib/mail/CF and copy the sample.m4 local.m4 file
to "yourhostname.m4".
Edit out the distributed hostname, aliases, smarthost and put in the
correct one for your site. The default file is for a uucp-only site
(no longer in 8.x) who has domainized headers and who talks to a smart
host. Then "make yourhostname.cf" and move the resulting file to
/etc/sendmail.cf
+o if you are uucp-only, you do *NOT* need to create any of the tables
mentioned in the README.linux file.
You'll just have to touch the files so that the Makefile works. Just
edit the .m4 file, make sendmail.cf and start testing it.
+o if you're uucp-only and you talk to sites in addition to your
"smart-host", you'll need to add uucpxtable entries for each (or
mail to them will also go through the smart host) and run dbm
against the revised uucpxtable.
+o If you run Rich Braun's original binary distribution of 5.67a,
you'll need to freeze the configuration if you change your .cf file
with "/usr/lib/sendmail -bz" to make the changes take effect.
You should also update your version to at least 5.67b since there is a
nasty security hole in 5.67a and earlier. Another nice thing is that
if you have mail.debug set and you run syslogd, your incoming and
outgoing mail messages will get logged. See the "/etc/syslog.conf"
file for details.
The sources for sendmail+IDA can be found at vixen.cso.uiuc.edu ; they
require no patching to run under Linux if you're running something
like a kernel of 1.00.
If you're running a kernel > 1.1.50, you get the fun of reversing most
of the Linux-specific patches that are now in the vanilla sources. (I
*did* told you this sendmail was only for old kernels:-)
It's extremely obvious where this needs to be done: just type "make"
and when it blows up, go to that line in the sources and comment out
the Linux-specific code that's in there.
If you're going to run sendmail+IDA, I strongly recommend you go to
the sendmail5.67b+IDA1.5 version since all required Linux-specific
patches are now in the vanilla sources and several security holes have
been plugged that WERE (!!!) in the older version you may have grabbed
or built before about December 1st, 1993.
Now linux kernel is 2.0, you should use sendmail 8.x instead of
sendmail+IDA, but I already told you'd better choose sendmail 8.x:-)
66..33..22.. TThhee sseennddmmaaiill..mm44 ffiillee
Sendmail+IDA requires you to set up a sendmail.m4 file rather than
editing the sendmail.cffile directly. The nice thing about this is
that it is simple to set up mail configurations that are extremely
difficult (if not totally impossible for most people to set up
correctly) in smail or traditional sendmail.
The sendmail.m4 file that corresponds to the above smail example looks
like the following:
dnl #------------------ SAMPLE SENDMAIL.M4 FILE ------------------
dnl #
dnl # (the string 'dnl' is the m4 equivalent of commenting out a line)
dnl # (well, not exactly, but use it for this purpose if you must :-)
dnl # you generally don't want to override LIBDIR from the compiled in paths
dnl #define(LIBDIR,/usr/local/lib/mail)dnl # where all support files go
define(LOCAL_MAILER_DEF, mailers.linux)dnl # mailer for local delivery
define(POSTMASTERBOUNCE)dnl # postmaster gets bounces
define(PSEUDODOMAINS, BITNET UUCP)dnl # don't try DNS on these
dnl #
dnl #-------------------------------------------------------------
dnl #
dnl # names we're known by
define(PSEUDONYMS, myhostname.subdomain.domain myhostname.UUCP)
dnl #
dnl # our primary name
define(HOSTNAME, myhostname.subdomain.domain)
dnl #
dnl # our uucp name
define(UUCPNAME, myhostname)dnl
dnl #
dnl #-------------------------------------------------------------
dnl #
define(UUCPNODES, |uuname|sort|uniq)dnl # our uucp neighbors
define(BANGIMPLIESUUCP)dnl # make certain that uucp
define(BANGONLYUUCP)dnl # mail is treated correctly
define(RELAY_HOST, my_uucp_neighbor)dnl # our smart relay host
define(RELAY_MAILER, UUCP-A)dnl # we reach moria via uucp
dnl #
dnl #--------------------------------------------------------------------
dnl #
dnl # the various dbm lookup tables
dnl #
define(ALIASES, LIBDIR/aliases)dnl # system aliases
define(DOMAINTABLE, LIBDIR/domaintable)dnl # domainize hosts
define(PATHTABLE, LIBDIR/pathtable)dnl # paths database
define(GENERICFROM, LIBDIR/generics)dnl # generic from addresses
define(MAILERTABLE, LIBDIR/mailertable)dnl # mailers per host or domain
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl # paths to hosts we feed
define(UUCPRELAYS, LIBDIR/uucprelays)dnl # short-circuit paths
dnl #
dnl #--------------------------------------------------------------------
dnl #
dnl # include the 'real' code that makes it all work
dnl # (provided with the source code)
dnl #
include(Sendmail.mc)dnl # REQUIRED ENTRY!!!
dnl #
dnl #------------ END OF SAMPLE SENDMAIL.M4 FILE -------
66..33..33.. DDeeffiinniinngg aa llooccaall mmaaiilleerr
Unlike most Unix distributions, Linux did not come with a local mail
delivery agent by default.
Slackware did! Well at least it is offered by the easy-to-use-but-
longwinded installation script. It uses procmail.
Now, deliver or procmail is generally installed, with a default
sendmail setup to handle local mail, so no complexity will be added to
this already very complex setup. I recommend using the commonly
available deliver or procmail programs, which can be optional packages
in a some Linux distributions.
In order to do so, you need to define a LOCAL_MAILER_DEF in the
sendmail.m4 file that points to a file that looks like:
# -- /usr/local/lib/mail/mailers.linux --
# (local mailers for use on Linux )
Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u
Mprog, P=/bin/sh, F=lsDFMeuP, S=10, R=10, A=sh -c $u
There is a also built-in default for deliver in the Sendmail.mc file
that gets included into the sendmail.cf file. To specify it, you would
not use the mailers.linux file but would instead define the following
in your sendmail.m4 file:
dnl --- (in sendmail.m4) ---
define(LOCAL_MAILER_DEF, DELIVER)dnl # mailer for local delivery
Unfortunately, Sendmail.mc assumes deliver is installed in /bin, which
is not the case with Slackware1.1.1 (which installs it in /usr/bin).
In that case you'd need to either fake it with a link or rebuild
deliver from sources so that it resides in /bin. Please note procmail
is generally better than deliver, for example for mail filtering.
66..33..44.. TThhee sseennddmmaaiill++IIDDAA ddbbmm ttaabblleess
Setting up special behavior for sites or domains is done through a
number of optional dbm tables rather than editing the sendmail.cf file
directly.
Refer to the July-1994 issue of Linux Journal (if you can still find
it:-), to the docs in the sources, or to the sendmail chapter in the
newest version of the Linux Documentation Project Networking
Administration Guide which will be available real-soon-now for more
details.
+o mailertable - defines special behavior for remote hosts or
domains.
+o uucpxtable - forces UUCP delivery of mail to hosts that are in
DNS format.
+o pathtable - defines UUCP bang-paths to remote hosts or domains.
+o uucprelays - short-circuits the pathalias path to well-known
remote hosts.
+o genericfrom - converts internal addresses into generic ones
visible to the outside world.
+o xaliases - converts generic addresses to/from valid internal
ones.
+o decnetxtable - converts RFC-822 addresses to DECnet-style
addresses.
66..33..55.. SSoo wwhhiicchh eennttrriieess aarree rreeaallllyy rreeqquuiirreedd??
When not using any of the optional dbm tables, sendmail delivers mail
via the RELAY_HOST and RELAY_MAILER) defined in the sendmail.m4 file
used to generate sendmail.cf. It is easily possible to override this
behavior through entries in the domaintable or uucpxtable.
A generic site that is on Internet and speaks Domain Name Service, or
one that is UUCP-only and forwards all mail via UUCP through a smart
RELAY_HOST, probably does not need any specific table entries at all.
Virtually all systems should set the DEFAULT_HOST and PSEUDONYMS
macros, which define the canonical site name and aliases it is known
by.
If all you have is a relay host and relay mailer, you don't need to
set these defaults since it works automagically. UUCP hosts will
probably also need to set UUCPNAME to their official UUCP name.
They will also probably set RELAY_MAILER and RELAY_HOST which enable
smart-host routing through a mail relay.
The mail transport to be used is defined in RELAY_MAILER and should
usually be UUCP-A for UUCP sites. If your site is SMTP-only and talks
`Domain Name Service', you would change the RELAY_MAILER.
If you're a SLIP site, you might want to take the easy way out and
just forward all outgoing mail to your service provider to do the
right thing with. To do so, you'd want to define ISOLATED_DOMAINS and
VALIDATION_DOMAINS to be your domain, you'd also want to define
RELAY_HOST to be your service provider and RELAY_MAILER to be TCP. Of
course, you want to ask permission before you set any system up as
your general purpose relay.
66..44.. SSeennddmmaaiill 88..xx
Sendmail 8.7.x from Berkeley was the latest major revision after
sendmail5. It had wonderful built-in support for building under Linux
: just "make linux" and all was set.
You'll probably be best served by grabbing one of the various binary
distributions off of the usual Linux archive sites rather than
fighting things like Berkeley dbm yourself.
There's a nice distribution of sendmail 8.6.12 from Jason Haar -
j.haar at lazerjem.demon.co.uk on sunsite.unc.edu in
/pub/Linux/system/Mail/delivery/sendmail-8.6.12-bin.tgz that has the
source documentation and a very nice quickie description of how to run
sendmail v8 for common configurations.
The bottom line with sendmail v8 is that you want to configure the
bare minimum necessary to get the job done ; the following is an
example that should get you close at least.
66..44..11.. AA ssaammppllee 88..77..xx mmcc ffiillee
Much like sendmail+IDA, sendmail v8 uses m4 to process a config file
into a full sendmail.cf that sendmail uses. The following is my
current mc file for my site (ppp to Internet for outgoing mail, uucp
for incoming mail).
dnl divert(-1)
#---------------------------------------------------------------------
#
# this is the .mc file for a linux host that's set up as follows:
#
# - connected to Internet for outbound mail (ppp here)
# - connected via UUCP for incoming mail
# - domainized headers
# - no local mailer (use 'deliver' instead)
# - no DNS running so don't canonicalize outgoing via DNS
# - all non-local outbound mail goes to the RELAY_HOST over smtp
# (we run ppp and let our service provider do the work)
#
# vds 3/31/95
#
#---------------------------------------------------------------------
include(`../m4/cf.m4')
VERSIONID(`linux nodns relays to slip service provider smarthost')dnl
Cwmyhostname.myprimary.domain myhostname.UUCP localhost
OSTYPE(linux)
FEATURE(nodns)dnl
FEATURE(always_add_domain)dnl
FEATURE(redirect)
FEATURE(nocanonify)
dnl MAILER(local)dnl
MAILER(smtp)dnl
MAILER(uucp)dnl
define(`RELAY_HOST', smtp:my.relay.host.domain)
define(`SMART_HOST', smtp:my.relay.host.domain)
define(`UUCP_RELAY', smtp:my.relay.host.domain)
define(`LOCAL_MAILER_PATH', `/bin/deliver')
define(`LOCAL_MAILER_ARGS', `deliver $u')
66..44..22.. SSeennddmmaaiill vv88 ttiiddbbiittss
There are a few differences I suppose to the 'IDA bigots' among us.
So far, I've found the following:
Instead of 'runq', you type 'sendmail -q' to run the queue!
66..55.. LLooccaall DDeelliivveerryy AAggeennttss
Unlike most operating systems, Linux did not have mail "built-in": you
needed a program to deliver the local mail, like "lmail", "procmail"
or "deliver".
However, every recent distribution includes a local mailer now!
Documentation for how to use either for local delivery is in the
sendmail5.67b+IDA1.5 binary release (on sunsite) mentioned above.
77.. UUsseerr AAggeenntt AAddmmiinniissttrraattiioonn
77..11.. MMuutttt
You should have no problem compiling, installing, or running mutt.
Users of qmail can either get the patch or run it with -f flag to read
their local mail folder.
If mutt bothers you with an "unknown terminal error" after a
distribution upgrading, just recompile it.
77..22.. EEllmm
Elm compiles, installs and runs flawlessly under Linux. For more
information, see the elm sources and installation instructions. Elm
and filter need to be mode 2755 (group mail) with /var/spool/mail mode
775 and group mail.
Qmail users can get a patch to use nifty qmail features, or will run
elm with the -f flag to point to their local mail folder.
One thing you want to be aware of is that if you have Elm compiled to
be MIME-able, you need metamail installed and in the standard path or
Elm will not be able to read MIME mail you've received. Metamail is
available on thumper.bellcore.com and of course via "archie".
If you use a binary distribution, you'll need to create a
"/usr/local/lib/elm/elm.rc" file to override the compiled-in hostname
and domain information:
+o replace "subdomain.domain" with your domain name replace
+o "myhostname" with you un-domainized hostname replace
#---------- /usr/local/lib/elm/elm.rc ------------------
#
# this is the unqualified hostname
hostname = myhostname
#
# this is the local domain
hostdomain = subdomain.domain
#
# this is the fully qualified hostname
hostfullname = myhostname.subdomain.domain
#
#--------------------------------------------------------
One thing you want to be aware of is that if you have Elm compiled to
be MIME enabled, you need metamail installed and in your path or Elm
will not be able to read MIME mail you've received. Metamail is
available on thumper.bellcore.com and of course via "archie".
In the "too cool to be true" category, there is a distribution of
Elm-2.4.24 that is "PGP-aware". To try it, grab the file
ftp://ftp.viewlogic.com/pub/elm-2.4pl24pgp3.tar.gz, which is elm2.4.24
with PGP hooks added. You configure and build it the same way you do
normal Elm, which means you probably need to add the patches mentioned
above. For what it's worth, I run it here and like it a lot. Of
course, there must be more recent versions available, including elm-
ME+.
While this item is not Linux-specific, it's perceived (wrongly) to be
a nagging Elm bug nevertheless. We've heard that Elm sometimes fails
with a message that it's unable to malloc() some massive number of
bytes. The identified workaround is to remove the post-processed
global mail aliases (aliases.dir and aliases.pag).
THIS IS NOT A BUG IN ELM, it's an error in configuration of Elm by
whomever you got your binary distribution of Elm from.
Elm has an enhanced and non-compatible, format for aliases ; you need
to ensure that the path Elm uses for aliases is different from the
path sendmail/smail uses. From the volume of reports of this problem,
it's apparent that at least one major distribution 'on the street' has
in the past been misconfigured. (from scot at catzen.gun.de (Scot W.
Stevenson) )
The current metamail package requires csh for some of its scripts.
Failure to have csh (or tcsh) will cause most interesting errors...
77..33.. MMaaiillxx
If you don't have a local mailx program, save yourself the pain --
just go and grab the mailx kit from Slackware 2.1.0 or later, which
has a nice implementation of mailx5.5. If you're into building from
sources, mailx v5.5 compiles without patching under Linux if you have
"pmake" installed.
If anybody is still using it, I strongly recommend removing the old
"edmail" stuff from SLS1.00 and replacing it with mailx.
88.. HHaannddlliinngg rreemmoottee mmaaiill
This section describes using POP or IMAP to handle remote mail.
Other options include nfs-mounting the spool partition on client
machines (Danger Will Robinson! Is everyone using the same lock
method?) or using a mail-to-web gateway (quite popular now).
88..11.. HHiissttoorryy
On a workstation network, mail has always been a problem:
+o Either you use "
[email protected]" with problems when
"computer" is down, making your network known to the people
outside, having different addresses for a same person switching to
another computer, ...
+o Or you take a mail hub, "mailhost.foo.com" with rules for
rewriting, so every user seems to post from the same address, even
if they are on different computers.
But in that case, how can users read their mail?
Using a rsh with elm? :-)
It would overload our mail hub! One method was forwarding or UUCP,
smtp, etc. but it's too complicated.
Then came POP/IMAP, both with security problems at the beginning, (now
fixed using ssh on new versions): a mail program has sometimes to be
set locally (like qmail, smail or vmail if, for example, you use elm,
but mozilla will avoid that!) however, getting and sending Email is
simpler.
88..22.. GGeettttiinngg mmaaiill
Here come POP's main drawbacks:
+o the password is sent as a clear text on the network,
+o you must choose a POP-aware mailer; many do now (like Pine, Emacs,
Mozilla, Netscape, Mutt, IE, Pegasus, Eudora, Claris...),
+o when a user may roam (read mail from different machines) having e-
mail popped on the computer used yesterday can be a nuisance,
+o some POP servers (e.g. qpopper, ipop3d) on high-use servers can
load the machine significantly. Consider controlling options (such
as not leaving mail on the server) and/or changing the pop server
(e.g. cucipop), as well as avoiding running it from inetd.
The password problem can be solved creating a crypted "channel" to
have POP on it or using APOP or RPOP extensions. The mail reader
problem can be solved either by changing mail reader (don't
underestimate the effort required to re-educate users!) or by using a
POP "mail sucker" with a local mail program.
IMAP can be preferable to POP in various situations like remote (and
especially roaming) access, while you restrict POP to a LAN where
snooping of passwords isn't so much of a concern. Mark Aitchison
reported a solution here is to use hosts.deny and hosts.allow files
(please see Net-3 HOWTO ; this assumes you are starting pop from
inet).
The policy of leaving mail on the server or not has implications for
server disk space and easier backup/security of the mail, as well as
allowing roaming, so the best solution depends on the type of
organization. Of course, this will not ensure your mail can't be read,
but nobody will be able to delete it ; if all your mail is pgp
encrypted this is a better solution.
Here are some pop programs worth trying:
+o gwpop (a Good Way to POP) is very protected since it creates a
crypted "channel" and puts mail directly in the "spool" ; however,
it depends on Perl.
+o popclient, simple to use:
For example if your login is john and your password PrettySecret,
you will run:
$ popclient -3 -v mail.acme.net -u john -p "PrettySecret" -k -o JOHN-INET-MAIL
It is strongly discouraged in case of multi-user machine; other user
can see your password by, for example with "ps auxw"
+o fetchmail, which is actively supported and incredibly simple to
use: it is configured in ~/.fetchmailrc, so you only need to run
fetchmail when you want to retrive your mail.
Here's my .fetchmailrc:
poll mail.server protocol pop3:
forcecr
password PrettySecret;
Don't forget to "chmod 600 /.fetchmailrc" or fetchmail will ask for
it.
Please note that the forcecr option is needed to use fetchmail with
qmail, which strictly respects RFCs.
88..33.. SSeennddiinngg mmaaiill
For this, you must use smtp-aware mail software, like qmail, smail,
vmail or mozilla (this one does everything: mail reader, POP receive,
smtp send!)
Go to one of the previous sections to install and configure the one
you like best. Then, when you will reach "Testing", try to send some
mail to a local account on the mail hub.
88..44.. RReeaaddiinngg mmaaiill
If your program doesn't do everything itself, you can install elm,
pgp, mush, pine ... many good programs are freely available for linux
platforms!
88..55.. TTeessttiinngg
To check whether your mail server has pop, try:
$ telnet mailhost 110
If it works, you will get something like "OK Pop server (...)
starting": type "quit"!
To install a ssh crypted "channel", first test your mail server
typing:
$ ssh mailhost date
If you get the date, you should be OK. Please note ssh will not ask
for a password, therefore you must create a ".shosts" file on the mail
server, containing client's name. To test ssh port redirection (which
gwpop uses), type:
$ ssh -n -f -L 12314:localhost:110 mailhost sleep 30
then
$ telnet localhost 12314
Then will you hopefully see mail hub's pop banner. If you don't use
ssh, don't forget to comment out $ssh on gwpop script. To check
whether procmail is running, try "procmail -v"
88..66.. UUssiinngg
Now you can edit gwpop Perl script to check everything is ok, then run
gwpop:
$ gwpop -v your-username
POP password on mailhost: yoursecretpasword
If gwpop "error messages" are normal, the mail from mail hub will be
downloaded to your local machine wherever you told gwpop to put it.
(please test with some mail!).
You can also use gwpop as a daemon:
$ gwpop -d $HOME/tmp your-username
gwpop messages are then sent to syslog and gwpop will run endlessly ;
a "HUP" signal will force gwpop to get your mail.
You can get POP software here used on:
ftp://ftp.unina.it/pub/Unix/pkgs/network/mail/gwpop
ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail
http://www.cs.hut.fi/ssh/
99.. AAcckknnoowwlleeddggeemmeennttss
The following people have helped in the assembly of the information
and experience that helped make this document possible:
Steve Robbins, Ian Kluft, Rich Braun, Ian Jackson, Syd Weinstein, Ralf
Sauther, Martin White, Matt Welsh, Ralph Sims, Phil Hughes, Scot
Stevenson, Neil Parker, Stephane Bortzmayer and especially many thanks
to Vince Skahan for his huge contribution.
Eric S. Raymond edited this document, correcting some mistakes and
transplanting the section on ``How Electronic Mail Works'' from his
Mail User's HOWTO.
Hitoshi Hayakawa checked qmail section, Jun Morimoto added various
notes about popclient & fetchmail and Takeo Nakano ispell'ed the
document :-)
If I forgot anybody, my apologies: just email me!
