mirror of https://github.com/tLDP/LDP
2386 lines
87 KiB
Plaintext
2386 lines
87 KiB
Plaintext
<!doctype linuxdoc system>
|
|
<!-- <date>$Id$ -->
|
|
<!-- to add: - how to avoid spamming with procmail or directly with MTA -->
|
|
<!-- exim section -->
|
|
<!-- howto install pop/imap server -->
|
|
<!-- web mail interface -->
|
|
|
|
<article>
|
|
|
|
<title>The Linux Electronic Mail Administrator HOWTO
|
|
<author>Guylhem Aznar <tt><guylhem at metalab.unc.edu></tt>
|
|
<date>v3.2, January 2000
|
|
|
|
<abstract>
|
|
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 communicate locally or to remote
|
|
sites via electronic mail.
|
|
|
|
You probably do <em>*not*</em> need to read this document if don't
|
|
exchange electronic mail with other users on your system or with other
|
|
sites.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect>Introduction, copyright and standard disclaimer<p>
|
|
|
|
<sect1> Email and spamming <p>
|
|
|
|
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!
|
|
|
|
<sect1> Goals <p>
|
|
|
|
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.
|
|
|
|
<sect1> New versions <p>
|
|
|
|
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 <em>sunsite.unc.edu:/pub/Linux/docs/HOWTO</em>.
|
|
|
|
In addition, you should be generally able to find this document on the
|
|
Linux WorldWideWeb home page at <em>http://sunsite.unc.edu/mdw/linux.html</em>.
|
|
|
|
<sect1> Feedback <p>
|
|
|
|
I am interested in any feedback, positive or negative, regarding the content
|
|
of this document via e-mail. Definitely contact me if you find errors or
|
|
obvious omissions.
|
|
|
|
I read, but do not necessarily respond to, all e-mail I receive. Requests for
|
|
enhancements will be considered and acted upon based on that day's combination
|
|
of available time, merit of the request and daily blood pressure :-)
|
|
|
|
Flames will quietly go to /dev/null so don't bother.
|
|
|
|
Feedback concerning the actual format of the document should go to the HOWTO
|
|
coordinator : Tim Bynum (<tt>howto at wallybox.cei.net</tt>).
|
|
|
|
<sect1> Copyright <p>
|
|
|
|
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 <tt>howto at wallybox.cei.net</tt>.
|
|
|
|
<sect1> Limited warranty <p>
|
|
|
|
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.
|
|
|
|
<sect>Other sources of information<p>
|
|
|
|
<sect1>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
|
|
<url url="http://metalab.unc.edu/LDP/HOWTO/Mail-User-HOWTO.html">.
|
|
|
|
<sect1> USENET <p>
|
|
|
|
There is nothing special about configuring and running mail software under
|
|
Linux (any more). Accordingly, you almost certainly do <em>NOT</em> 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.
|
|
|
|
<em>
|
|
IF YOU POST TO COMP.OS.LINUX.* FOR NON-LINUX-SPECIFIC QUESTIONS, YOU ARE
|
|
LOOKING IN THE WRONG PLACE FOR HELP. THE MAIL EXPERTS HANG OUT IN THE PLACES
|
|
INDICATED ABOVE AND GENERALLY DO NOT RUN LINUX.
|
|
</em>
|
|
|
|
<em>
|
|
POSTING TO THE LINUX HIERARCHY FOR NON-LINUX-SPECIFIC QUESTIONS WASTES YOUR
|
|
TIME AND EVERYONE ELSE'S AND IT FREQUENTLY DELAYS YOUR GETTING THE ANSWER
|
|
TO YOUR QUESTION.
|
|
</em>
|
|
|
|
GOOD PLACES are :
|
|
<verb>
|
|
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.
|
|
</verb>
|
|
|
|
<sect1> Mailing Lists <p>
|
|
|
|
There are many sendmail, smail and qmail mailing lists.
|
|
|
|
You can find addresses in /usr/doc/the_one_you_have_chosen.
|
|
|
|
<sect1> Other documents from LDP <p>
|
|
|
|
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:
|
|
|
|
<itemize>
|
|
<item>on your own computer in /usr/doc/ :-)
|
|
<item>the Linux Networking Administrators' Guide
|
|
<item>the Mail Users HOWTO
|
|
<item>the Serial Communications HOWTO
|
|
<item>the Ethernet HOWTO
|
|
<item>the UUCP HOWTO if you're fed via UUCP
|
|
</itemize>
|
|
|
|
<sect1> Books <p>
|
|
|
|
The following is a non-inclusive set of books that will help:
|
|
|
|
<itemize>
|
|
<item>"<tt>Managing UUCP and USENET</tt>" 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.
|
|
|
|
<item>"<tt>Unix Communications</tt>" from The Waite Group contains a nice
|
|
description of all the pieces (and more) and how they fit together.
|
|
|
|
<item>"<tt>Sendmail</tt>" 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.
|
|
|
|
<item>"<tt>The Internet Complete Reference</tt>" from Osborne is a fine
|
|
reference book that explains the various services available on Internet and is
|
|
a great source for information on news, mail and various other Internet
|
|
resources.
|
|
|
|
<item>"<tt>The Linux Networking Administrators' Guide</tt>" 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.
|
|
<p>
|
|
</itemize>
|
|
|
|
<sect>How Electronic Mail Works
|
|
<p>
|
|
Now we'll explain the flow of information that typically takes place when
|
|
two people to communicate by <idx>email</idx>. Let us suppose that
|
|
Alice, on her machine <tt>wonderland.com</tt>, wants to send mail to
|
|
Bob, on his machine <tt>dobbs.com</tt>. Both machines are connected
|
|
to the Internet.
|
|
|
|
It helps to know that an Internet mail message consists of two parts;
|
|
<idx>mail headers</idx> 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:
|
|
|
|
<verb>
|
|
From: "Alice" <alice@wonderland.com>
|
|
Message-Id: <199711131704.MAA18447@wonderland.com>
|
|
Subject: Have you seen my white rabbit?
|
|
To: bob@dobbs.org (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>>
|
|
</verb>
|
|
|
|
The arrangement and meaning of Internet mail headers are defined by
|
|
an Internet standard called <url name="RFC822"
|
|
url="ftp://ftp.isi.edu/in-notes/rfc822.txt">.
|
|
|
|
<sect1>Mail between full-time Internet machines
|
|
<p>
|
|
Here's a diagram of the whole process -- I'll explain all the stages
|
|
and terminology below.
|
|
<p>
|
|
<code>
|
|
+---------+ +-------+
|
|
+-------+ 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 |<----+
|
|
+-----+
|
|
</code>
|
|
|
|
To send mail, Alice will invoke a program called a <idx>mail user agent</idx>
|
|
(or <idx>MUA</idx> 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
|
|
<idx>mail transport agent</idx> (or <idx>MTA</idx>). Usually this
|
|
program will be <tt>sendmail</tt>, 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
|
|
<tt>dobbs.com</tt> 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 the 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 <idx>
|
|
service port</idx> 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 <idx>Simple Mail Transfer Protocol</idx>
|
|
(or <idx>SMTP</idx>). 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:.
|
|
|
|
<verb>
|
|
S: MAIL FROM:<alice@wonderland.com>
|
|
R: 250 OK
|
|
S: RCPT TO:<bob@dobbs.com>
|
|
R: 250 OK
|
|
S: DATA
|
|
R: 354 Start mail input; end with <CRLF>.<CRLF>
|
|
S: From: "Alice" <alice@wonderland.com>
|
|
S: Message-Id: <199711131704.MAA18447@wonderland.com>
|
|
S: Subject: Have you seen my white rabbit?
|
|
S: To: bob@dobbs.org (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
|
|
</verb>
|
|
|
|
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 <url name="RFC821"
|
|
url="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:
|
|
|
|
<verb>
|
|
Received: (from alice@wonderland.com)
|
|
by mail.dobbs.com (8.8.5/8.8.5) id MAA18447
|
|
for bob@dobbs.com; Thu, 13 Nov 1997 12:04:05 -0500
|
|
</verb>
|
|
|
|
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
|
|
<idx>local delivery agent</idx> or <idx>LDA</idx>. On Linux systems
|
|
the LDA is usually a program called <tt>procmail</tt>, 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.
|
|
|
|
<sect1>Notifiers
|
|
<p>
|
|
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 <em>mail notifier</em>, 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 <em>xbiff</em>; if your Linux has a preconfigured X desktop
|
|
setup, xbiff is probably on it. See the xbiff(1) manual page for
|
|
details.
|
|
|
|
<sect1>Mail to part-time Internet machines
|
|
<p>
|
|
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 <idx>mail queue</idx> on <tt>wonderland.com</tt>. It will
|
|
then retry sending the mail at intervals until an expiration time is
|
|
reached, at which point a <idx>bounce message</idx> 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.
|
|
|
|
<sect1>Remote mail and remote-mail protocols
|
|
<p>
|
|
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 <idx>ISP</idx> 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
|
|
<idx>SLIP</idx> or <idx>PPP</idx>. Linux supports <idx>remote mail
|
|
protocols</idx> to support this.
|
|
<p>
|
|
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 <em>is</em> considered
|
|
`delivered' and can sit there indefinitely.
|
|
<p>
|
|
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 <url name="RFC1939" url="ftp://ftp.isi.edu/in-notes/rfc1939.txt">)
|
|
and IMAP (defined by the Internet
|
|
standard <url name="RFC2060" url="ftp://ftp.isi.edu/in-notes/rfc2060.txt">).
|
|
Effectively all ISPs support POP3; a growing number support IMAP (which
|
|
is more powerful).
|
|
<p>
|
|
Here is what an example POP3 session looks like:
|
|
|
|
<verb>
|
|
S: <client connects to service port 110>
|
|
R: +OK POP3 server ready <1896.697170952@mailgate.dobbs.org>
|
|
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>
|
|
</verb>
|
|
|
|
An IMAP session uses different commands and responses, but is
|
|
logically very similar.
|
|
<p>
|
|
|
|
To take advantage of POP3 or IMAP, you need a <idx>remote mail
|
|
client</idx> 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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
Your Linux probably comes with a program called <url name="fetchmail"
|
|
url="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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
Here's a diagram showing how both cases (with and without fetchmail) work:
|
|
<p>
|
|
<code>
|
|
+---------+ +-------+
|
|
+-------+ 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 | . +-----+
|
|
+----------+ .
|
|
</code>
|
|
|
|
|
|
<sect1>Mailbox formats
|
|
<p>
|
|
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.
|
|
|
|
<sect>Requirements<p>
|
|
|
|
<sect1> Hardware <p>
|
|
|
|
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
|
|
<tt>comp.dcom.modems</tt> group or the various fine modem and serial
|
|
communications FAQs and periodic postings on USENET.
|
|
|
|
<sect>Choosing a Mail Transport Agent
|
|
<p>
|
|
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 <bf/really/ 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.
|
|
|
|
<sect1>sendmail
|
|
<p>
|
|
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.<p>
|
|
|
|
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 <idx>UUCP</idx> 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).<p>
|
|
|
|
There is a sendmail home page at <url url="http://www.sendmail.org">.
|
|
It includes references to extensive documentation of sendmail, should
|
|
you actually need to wrestle with custom-configuring it.<p>
|
|
|
|
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.<p>
|
|
|
|
<sect1>smail v3.2
|
|
<p>
|
|
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.<p>
|
|
|
|
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.<p>
|
|
|
|
As with sendmail, it is unlikely that you will need to tweak a
|
|
preinstalled smail configuration.<p>
|
|
|
|
(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.)
|
|
|
|
<sect1>qmail
|
|
<p>
|
|
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 <url url=" http://pobox.com/~djb/qmail.html">.
|
|
|
|
<sect1>exim
|
|
<p>
|
|
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 <url url=" 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.
|
|
|
|
<sect>Installing Transport Software<p>
|
|
|
|
<sect1>Qmail v1.03<p>
|
|
|
|
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.
|
|
|
|
<sect2> Getting qmail <p>
|
|
|
|
Go to www.qmail.org to download the latest version.
|
|
|
|
<sect2> Uncompressing sources <p>
|
|
|
|
Then decompress it by running:
|
|
<tscreen><verb>
|
|
mv qmail.tar.gz /usr/local/src
|
|
cd /usr/local/src ; tar -zxvf qmail.tar.gz
|
|
</verb></tscreen>
|
|
|
|
If you find a bz2 version (new and better compression format), just
|
|
replace tar with:
|
|
<tscreen><verb>
|
|
bunzip2 qmail.tar.bz2
|
|
tar -xvf qmail.tar
|
|
</verb></tscreen>
|
|
|
|
<sect2> Preparing for compilation <p>
|
|
|
|
Now enter the qmail directory to examine the configuration defaults:
|
|
<tscreen><verb>
|
|
cd qmail; more conf-*
|
|
</verb></tscreen>
|
|
|
|
You shouldn't need to change any defaults, but you could (for example)
|
|
specify an alternate installation directory or better compilation
|
|
flags.
|
|
|
|
Now run:
|
|
<tscreen><verb>
|
|
mkdir /var/qmail
|
|
</verb></tscreen>
|
|
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:
|
|
<tscreen><verb>
|
|
# 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
|
|
</verb></tscreen>
|
|
|
|
or hand-edit <tt>/etc/passwd</tt> and <tt>/etc/group</tt> 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:
|
|
|
|
<tscreen><verb>
|
|
qmail:*:2107:
|
|
nofiles:*:2108:
|
|
</verb></tscreen>
|
|
|
|
&
|
|
|
|
<tscreen><verb>
|
|
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
|
|
</verb></tscreen>
|
|
|
|
|
|
Now you can run
|
|
<tscreen><verb>
|
|
make setup check
|
|
</verb></tscreen>
|
|
|
|
to check your configuration, then :
|
|
<tscreen><verb>
|
|
./config
|
|
</verb></tscreen>
|
|
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 :
|
|
<tscreen><verb>
|
|
./config-fast foo.bar.com
|
|
</verb></tscreen>
|
|
|
|
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 :
|
|
<tscreen><verb>
|
|
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)"
|
|
</verb></tscreen>
|
|
|
|
You need to create each of these file in <tt/˜alias/, replacing
|
|
<tt/&guylhem/ in <tt/.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 :
|
|
<itemize>
|
|
<item> For NFS mounted home dirs, use MAILDIR format with a patch for local
|
|
mail readers (patchs are available on www.qmail.org)
|
|
<item> 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
|
|
<item> Avoid /var/spool/mail/$USER format, too insecure
|
|
</itemize>
|
|
|
|
To fix the default format, read each file in <tt>/var/qmail/boot</tt>
|
|
then copy the one you best like to <tt>/var/qmail/rc</tt>.
|
|
|
|
<tt/home/ or <tt/proc/ are safe choices, but prefer <tt/home/ for security
|
|
reasons.
|
|
|
|
<sect2> Configuring qmail <p>
|
|
|
|
In /var/qmail/control, edit:
|
|
|
|
<sect3> defaultdomain, me, plusdomain <p>
|
|
|
|
<itemize>
|
|
<item> me is you local FQDN (full qualified domain name), for example on
|
|
my machine it is <tt/barberouge.linux.lmm.com/
|
|
|
|
<item> defaultdomain will be added to any host name without dots, including
|
|
defaulthost, for example you can set it to <tt/localnetwork/ so any mail sent
|
|
to joe@hisbox will be completed to be sent to joe@hisbox.localnetwork instead
|
|
|
|
<item>plusdomain is the exception: it is added to any host name that ends
|
|
with a plus sign, including defaulthost (set in <tt/me/) if it ends with a
|
|
plus sign.
|
|
</itemize>
|
|
|
|
These 3 examples show you the power and ease of configuration of qmail!
|
|
|
|
<sect3> locals, rcpthosts <p>
|
|
|
|
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 <tt/locals/ and <tt/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 someone@yahoo.com!
|
|
|
|
<sect3> virtualdomains <p>
|
|
|
|
There can you specify default outgoing mode, for example :
|
|
<tscreen><verb>
|
|
#:alias-uucp
|
|
</verb></tscreen>
|
|
|
|
if you don't want to send outgoing mail by uucp but by smtp (default) or
|
|
<tscreen><verb>
|
|
:alias-ucp
|
|
</verb></tscreen>
|
|
|
|
if you send your outgoing mail by uucp.
|
|
|
|
<sect2> Testing qmail <p>
|
|
|
|
Now it is configured, try:
|
|
<tscreen><verb>
|
|
sh -cf '/var/qmail/rc &'
|
|
</verb></tscreen>
|
|
to launch qmail (it won't interfere with your local MTA), then:
|
|
|
|
<tscreen><verb>
|
|
echo to: mylogin | /var/qmail/bin/qmail-inject
|
|
</verb></tscreen>
|
|
|
|
You should receive this mail in the format you've chosen in
|
|
<tt>/var/qmail/boot/</tt>.
|
|
|
|
<sect2> Removing your other MTA <p>
|
|
|
|
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:
|
|
<tscreen><verb>
|
|
# ln -s /var/qmail/bin/sendmail /usr/lib/sendmail
|
|
# ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail
|
|
</verb></tscreen>
|
|
|
|
Now set up qmail-smtpd in /etc/inetd.conf (all on one line):
|
|
<tscreen><verb>
|
|
smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd
|
|
</verb></tscreen>
|
|
|
|
If you are using a old non-SYSV-init distribution like redhat, just add to your
|
|
boot scripts:
|
|
<tscreen><verb>
|
|
sh -cf '/var/qmail/rc &'
|
|
</verb></tscreen>
|
|
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
#!/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
|
|
</verb></tscreen>
|
|
|
|
REDHAT version:
|
|
|
|
<tscreen><verb>
|
|
#!/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
|
|
</verb></tscreen>
|
|
|
|
And make symlinks to each /etc/rc.d/rcN.d/, for example:
|
|
<tscreen><verb>
|
|
ln -sf /etc/init.d/qmail /etc/rc1.d/K19qmail
|
|
</verb></tscreen>
|
|
|
|
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).
|
|
|
|
<itemize>
|
|
<item>How to decide whether you should put a K or a S?
|
|
Do what the majority of dæmons in this runlevel do!
|
|
|
|
<item>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.
|
|
</itemize>
|
|
|
|
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.
|
|
|
|
<sect2> That's all, folks! <p>
|
|
|
|
No need to reboot (remember, you're using linux, not some other cheap OS!) for
|
|
the modifications to take effect, just run:
|
|
|
|
<tscreen><verb>
|
|
killall inetd
|
|
init 1
|
|
</verb></tscreen>
|
|
|
|
To go to single user mode, then:
|
|
<tscreen><verb>
|
|
init 2
|
|
</verb></tscreen>
|
|
|
|
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).
|
|
|
|
<sect1>Smail v3.1<p>
|
|
|
|
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.
|
|
|
|
<sect2> Configuring smail <p>
|
|
|
|
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.
|
|
|
|
<verb>CASE_NO_NEWLINES=true </verb>
|
|
|
|
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!
|
|
|
|
<sect3> "config" file <p>
|
|
|
|
<tscreen><verb>
|
|
# 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
|
|
</verb></tscreen>
|
|
|
|
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.
|
|
|
|
<sect3> "directors" file <p>
|
|
|
|
<tscreen><verb>
|
|
# 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 real-login-name@remote.host.
|
|
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
|
|
</verb></tscreen>
|
|
|
|
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.
|
|
|
|
<sect3> "fidopaths" file <p>
|
|
|
|
<tscreen><verb>
|
|
.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
|
|
</verb></tscreen>
|
|
|
|
Create such a file only if you're using ifmail and FIDO.
|
|
|
|
<sect3> "routers" file <p>
|
|
|
|
<tscreen><verb>
|
|
# 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
|
|
</verb></tscreen>
|
|
|
|
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.
|
|
|
|
<sect3> "transports" file <p>
|
|
|
|
<tscreen><verb>
|
|
# 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})$)"
|
|
</verb></tscreen>
|
|
|
|
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.
|
|
|
|
<sect3> "maps/" directory <p>
|
|
|
|
It contains <tt>map</tt> and <tt>table</tt> files:
|
|
|
|
First, <tt>map</tt> file
|
|
|
|
<tscreen><verb>
|
|
#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
|
|
</verb></tscreen>
|
|
|
|
Once again, edit this file to match you situation (I'm fed by
|
|
polux.linux.eu.org).
|
|
|
|
Now <tt>table</tt> file
|
|
|
|
<tscreen><verb>
|
|
* uux
|
|
</verb></tscreen>
|
|
|
|
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 "*"!).
|
|
|
|
<sect2> Other good examples <p>
|
|
|
|
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.
|
|
|
|
<tscreen><verb>
|
|
#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
|
|
</verb></tscreen>
|
|
|
|
<tscreen><verb>
|
|
#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
|
|
</verb></tscreen>
|
|
|
|
<sect2> Restarting inetd <p>
|
|
|
|
To run smail as a smtp daemon, add one of the following to /etc/inetd.conf:
|
|
<verb>
|
|
smtp stream tcp nowait root /usr/bin/smtpd smtpd
|
|
|
|
or:
|
|
|
|
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
|
|
|
|
|
|
</verb>
|
|
|
|
Outgoing mail gets sent automatically, when using elm.
|
|
|
|
<sect2> Smail with smtp <p>
|
|
|
|
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 "<tt>/var/spool/smail/input</tt>". When the link
|
|
next comes up, "<tt>runq</tt>" is run which causes the mail to be
|
|
sent. However, receiving mail is <bf>the</bf> 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.
|
|
|
|
<sect1>OUTDATED SECTION: Sendmail+IDA<p>
|
|
|
|
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:
|
|
|
|
<itemize>
|
|
<item> If you use an old kernel (1.0): sendmail+IDA
|
|
<item> If you use a not so old kernel (1.2): sendmail+IDA and source code editing
|
|
<item> Recent kernel (2.0) will choose sendmail 8.x
|
|
</itemize>
|
|
|
|
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.
|
|
|
|
<sect2> Source installation <p>
|
|
|
|
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:
|
|
|
|
<itemize>
|
|
<item>cd / ; tar -zxvf sendmail5.67b+IDA1.5.tgz
|
|
</itemize>
|
|
|
|
<itemize>
|
|
<item>cd to /usr/local/lib/mail/CF and copy the sample.m4 local.m4 file to
|
|
"yourhostname.m4".
|
|
</itemize>
|
|
|
|
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
|
|
|
|
<itemize>
|
|
<item>if you are uucp-only, you do *NOT* need to create any of the tables
|
|
mentioned in the README.linux file.
|
|
</itemize>
|
|
|
|
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.
|
|
|
|
<itemize>
|
|
<item>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.
|
|
</itemize>
|
|
|
|
<itemize>
|
|
<item>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.
|
|
</itemize>
|
|
|
|
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:-)
|
|
|
|
<sect2> The sendmail.m4 file <p>
|
|
|
|
Sendmail+IDA requires you to set up a <tt>sendmail.m4</tt> file rather than
|
|
editing the <tt>sendmail.cf</tt>file 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:
|
|
|
|
<verb>
|
|
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 -------
|
|
</verb>
|
|
|
|
<sect2> Defining a local mailer
|
|
|
|
<p>
|
|
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
|
|
<tt>deliver</tt> or <tt>procmail</tt> programs, which can be optional
|
|
packages in a some Linux distributions.
|
|
|
|
In order to do so, you need to define a <tt>LOCAL_MAILER_DEF</tt> in the
|
|
<tt>sendmail.m4</tt> file that points to a file that looks like:
|
|
|
|
<verb>
|
|
# -- /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
|
|
</verb>
|
|
|
|
There is a also built-in default for <tt>deliver</tt> in the
|
|
<tt>Sendmail.mc</tt> file that gets included into the
|
|
<tt>sendmail.cf</tt> file. To specify it, you would not use the
|
|
<tt>mailers.linux</tt> file but would instead define the following in
|
|
your sendmail.m4 file:
|
|
|
|
<verb>
|
|
dnl --- (in sendmail.m4) ---
|
|
define(LOCAL_MAILER_DEF, DELIVER)dnl # mailer for local delivery
|
|
</verb>
|
|
|
|
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.
|
|
|
|
<sect2> The sendmail+IDA dbm tables <p>
|
|
|
|
Setting up special behavior for sites or domains is done through a number of
|
|
optional <tt>dbm</tt> tables rather than editing the <tt>sendmail.cf</tt> file
|
|
directly.
|
|
|
|
Refer to the July-1994 issue of <tt>Linux Journal</tt> (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 <tt>Networking Administration Guide</tt> which
|
|
will be available real-soon-now for more details.
|
|
|
|
<itemize>
|
|
<item>mailertable - defines special behavior for remote hosts or domains.
|
|
<item>uucpxtable - forces UUCP delivery of mail to hosts that are in DNS format.
|
|
<item>pathtable - defines UUCP bang-paths to remote hosts or domains.
|
|
<item>uucprelays - short-circuits the pathalias path to well-known remote hosts.
|
|
<item>genericfrom - converts internal addresses into generic ones visible to the outside world.
|
|
<item>xaliases - converts generic addresses to/from valid internal ones.
|
|
<item>decnetxtable - converts RFC-822 addresses to DECnet-style addresses.
|
|
</itemize>
|
|
|
|
<sect2> So which entries are really required?
|
|
|
|
<p> When not using any of the optional dbm tables, sendmail delivers
|
|
mail via the <tt>RELAY_HOST</tt> and <tt>RELAY_MAILER)</tt>
|
|
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
|
|
<tt>RELAY_HOST</tt>, probably does not need any specific table entries at all.
|
|
|
|
Virtually all systems should set the <tt>DEFAULT_HOST</tt> and
|
|
<tt>PSEUDONYMS</tt> 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 <tt>UUCPNAME</tt> to their official UUCP
|
|
name.
|
|
|
|
They will also probably set <tt>RELAY_MAILER</tt> and <tt>RELAY_HOST</tt>
|
|
which enable smart-host routing through a mail relay.
|
|
|
|
The mail transport to be used is defined in <tt>RELAY_MAILER</tt> and
|
|
should usually be UUCP-A for UUCP sites. If your site is SMTP-only and
|
|
talks `Domain Name Service', you would change the
|
|
<tt>RELAY_MAILER</tt>.
|
|
|
|
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.
|
|
|
|
<sect1>Sendmail 8.x<p>
|
|
|
|
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 - <tt>
|
|
j.haar at lazerjem.demon.co.uk </tt> 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.
|
|
|
|
<sect2> A sample 8.7.x mc file <p>
|
|
|
|
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).
|
|
|
|
<verb>
|
|
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')
|
|
</verb>
|
|
|
|
<sect2> Sendmail v8 tidbits <p>
|
|
|
|
There are a few differences I suppose to the 'IDA bigots' among us.
|
|
So far, I've found the following:
|
|
|
|
<p> Instead of 'runq', you type 'sendmail -q' to run the queue! <p>
|
|
|
|
<sect1> Local Delivery Agents <p>
|
|
|
|
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.
|
|
|
|
<sect>User Agent Administration <p>
|
|
|
|
<sect1> Mutt <p>
|
|
|
|
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.
|
|
|
|
<sect1> Elm <p>
|
|
|
|
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 <tt>thumper.bellcore.com</tt> 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:
|
|
|
|
<itemize>
|
|
|
|
<item>replace "subdomain.domain" with your domain name replace
|
|
|
|
<item>"myhostname" with you un-domainized hostname replace
|
|
|
|
</itemize>
|
|
|
|
<verb>
|
|
#---------- /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
|
|
#
|
|
#--------------------------------------------------------
|
|
</verb>
|
|
|
|
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 <tt>thumper.bellcore.com</tt> 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
|
|
<tt>ftp://ftp.viewlogic.com/pub/elm-2.4pl24pgp3.tar.gz</tt>, 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).
|
|
<p>
|
|
<tt>THIS IS NOT A BUG IN ELM</tt>, 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 <tt> scot at catzen.gun.de (Scot
|
|
W. Stevenson) </tt>)
|
|
|
|
The current metamail package requires csh for some of its scripts.
|
|
Failure to have csh (or tcsh) will cause most interesting errors...
|
|
|
|
<sect1> Mailx <p>
|
|
|
|
If you don't have a local <tt/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 <tt>"pmake"</tt> installed.
|
|
|
|
If anybody is still using it, I strongly recommend removing the old "edmail"
|
|
stuff from SLS1.00 and replacing it with mailx.
|
|
|
|
<sect>Handling remote mail<p>
|
|
|
|
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).
|
|
|
|
<sect1> History <p>
|
|
|
|
On a workstation network, mail has always been a problem:
|
|
|
|
<itemize>
|
|
<item>Either you use "user@computer.foo.com" 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, ...
|
|
|
|
<item>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.
|
|
</itemize>
|
|
|
|
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.
|
|
|
|
<sect1> Getting mail <p>
|
|
|
|
Here come POP's main drawbacks:
|
|
|
|
<itemize>
|
|
<item>the password is sent as a clear text on the network,
|
|
<item>you must choose a POP-aware mailer; many do now (like Pine,
|
|
Emacs, Mozilla, Netscape, Mutt, IE, Pegasus, Eudora, Claris...),
|
|
<item>when a user may roam (read mail from different machines) having
|
|
e-mail popped on the computer used yesterday can be a nuisance,
|
|
<item>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.
|
|
</itemize>
|
|
|
|
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:
|
|
|
|
<itemize>
|
|
<item> 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.
|
|
<item> popclient, simple to use:
|
|
|
|
For example if your login is john and your password
|
|
PrettySecret, you will run:
|
|
|
|
<tscreen><verb>
|
|
$ popclient -3 -v mail.acme.net -u john -p "PrettySecret" -k -o JOHN-INET-MAIL
|
|
</verb></tscreen>
|
|
|
|
It is strongly discouraged in case of multi-user machine;
|
|
other user can see your password by, for example with "ps auxw"
|
|
|
|
<item> fetchmail, which is actively supported and incredibly simple to use:
|
|
it is configured in <tt>˜/.fetchmailrc</tt>, so you only need to run
|
|
<tt/fetchmail/ when you want to retrive your mail.
|
|
|
|
Here's my .fetchmailrc:
|
|
<tscreen><verb>
|
|
poll mail.server protocol pop3:
|
|
forcecr
|
|
password PrettySecret;
|
|
</verb></tscreen>
|
|
|
|
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.
|
|
</itemize>
|
|
|
|
<sect1> Sending mail <p>
|
|
|
|
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.
|
|
|
|
<sect1> Reading mail <p>
|
|
|
|
If your program doesn't do everything itself, you can install elm, pgp, mush,
|
|
pine ... many good programs are freely available for linux platforms!
|
|
|
|
<sect1> Testing <p>
|
|
|
|
To check whether your mail server has pop, try:
|
|
|
|
<tscreen><verb>
|
|
$ telnet mailhost 110
|
|
</verb></tscreen>
|
|
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
$ ssh mailhost date
|
|
</verb></tscreen>
|
|
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
$ ssh -n -f -L 12314:localhost:110 mailhost sleep 30
|
|
|
|
then
|
|
|
|
$ telnet localhost 12314
|
|
</verb></tscreen>
|
|
|
|
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"
|
|
|
|
<sect1> Using <p>
|
|
|
|
Now you can edit gwpop Perl script to check everything is ok, then run gwpop:
|
|
|
|
<tscreen><verb>
|
|
$ gwpop -v your-username
|
|
POP password on mailhost: yoursecretpasword
|
|
</verb></tscreen>
|
|
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
$ gwpop -d $HOME/tmp your-username
|
|
</verb></tscreen>
|
|
|
|
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:
|
|
<tscreen><verb>
|
|
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/
|
|
</verb></tscreen>
|
|
|
|
<sect>Acknowledgements<p>
|
|
|
|
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!
|
|
|
|
</article>
|