206 lines
11 KiB
HTML
206 lines
11 KiB
HTML
<!--startcut ==============================================-->
|
|
<!-- *** BEGIN HTML header *** -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML><HEAD>
|
|
<title>An Overview of Linux Mail Software LG #56</title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
|
|
ALINK="#FF0000">
|
|
<!-- *** END HTML header *** -->
|
|
|
|
<CENTER>
|
|
<A HREF="http://www.linuxgazette.com/">
|
|
<H1><IMG ALT="LINUX GAZETTE" SRC="../gx/lglogo.jpg"
|
|
WIDTH="600" HEIGHT="124" border="0"></H1></A>
|
|
|
|
<!-- *** BEGIN navbar *** -->
|
|
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="correa.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue56/dennis.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="eyler.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
|
<!-- *** END navbar *** -->
|
|
<P>
|
|
</CENTER>
|
|
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4 ALIGN="center">
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H1><font color="maroon">An Overview of Linux Mail Software</font></H1>
|
|
<H4>By <a href="mailto:jimd@starshine.org">Jim Dennis</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
<!-- END header -->
|
|
|
|
|
|
|
|
|
|
<P> There are many packages that can supply standard mail services
|
|
under Linux. Basically the UNIX/Linux e-mail model involves
|
|
MTA (mail transport agents), MSA (mail storage/access agents)
|
|
and MUAs (mail user agents). There are also a variety of
|
|
utilities that don't really quite fit in any of these categories.
|
|
|
|
<P> Under Linux there are several MTAs including sendmail, the
|
|
most common across most forms of UNIX; and D.J. Bernstein's
|
|
qmail and Wietse Venema's Postfix. These accept and relay
|
|
mail. This sounds quite simple, but in practice it can be
|
|
quite complex. There are a number of routing and masquerading
|
|
options that can be set by administrative policy --- and these
|
|
amount to programming languages that filter and modify the
|
|
headers of each message as it is relayed. In addition the
|
|
process of routing mail and finding user mail boxes (mail
|
|
stores) can involve arbitrarily complex interactions with
|
|
various directory services (DNS, passwd files, NIS, LDAP
|
|
alias/dbm files, and all manner of custom databases).
|
|
|
|
<P> These days MTAs also have to implement anti-spam features that
|
|
amount to access control lists and rules about the address formats
|
|
(to and from headers) that are allowed from specific domains and
|
|
address ranges. (Those generally also involve queries on tables or
|
|
directory services, including those like Paul Vixie's RBL
|
|
(real-time blackhole list: or MAPS, mail abuse prevention system)
|
|
and it's ilk, like Dorkslayer/ORBS. Recently, MTAs are being
|
|
increasing required to enforce other policies and implement
|
|
anti-virus/anti-worm features.
|
|
|
|
<P> The most common cases are easy enough to install and configure.
|
|
However, all that power and flexibility comes at a price. As your
|
|
organization chooses to tailor its MTA to meet your special
|
|
routing, nomenclature, security and anti-spam requirements you'll
|
|
require more sophisticated configuration options and many of those
|
|
will involve choreographing complex relationships between your MTA
|
|
and various other subsystems (such as any LDAP and DNS servers
|
|
you use).
|
|
|
|
<P> Once you've selected, installed and configured an MTA you
|
|
generally will also need to go through the same process for
|
|
an MSA. Most organizations these days don't deliver mail
|
|
directly to desktop client systems. They store the mail
|
|
on servers and have the users fetch their mail via POP or
|
|
IMAP. There are various protocols for managing a mail store
|
|
but the only two that really count these days are POP3 and
|
|
IMAP4 (there are also older versions of each of these
|
|
protocols, of course). As with the MTAs there are a number
|
|
of programs (daemons) can can provide each of these services.
|
|
Most MSAs can work with any common MTA. In addition these
|
|
systems usually do locking and/or use other mechanisms so that
|
|
multiple MSAs can be concurrently in use without conflict.
|
|
|
|
<P> That means that you can have some users who access their mail
|
|
via POP, while others use IMAP and others might even log in
|
|
and use a local MUA (such as pine, mutt, or elm). Individual
|
|
users can swith from what mail access method to another, usually
|
|
without requiring any sysadmin intervention. Clever users can
|
|
often bypass the normal MSA/MUA tools and use normal UNIX commands
|
|
(like cp, and mv) and FTP or rsync to move their mail around.
|
|
(This is generally too clunky for normal use, but can be quite
|
|
handy when fixing corrupted mailboxes, etc).
|
|
|
|
<P> The first time I was ever called upon to set up a POP server on
|
|
an existing general purpose Linux server, I was surprised to
|
|
find that there was no work required. A POP daemon had been
|
|
installed and enabled when I did the initial OS installation;
|
|
I had disabled it (commenting out a line in the /etc/inetd.conf
|
|
file) during my routine system hardening. So "setting" up the
|
|
service simply require that I uncomment one line in one file,
|
|
and restart one service/daemon.
|
|
|
|
<P> IMAP is similar. Where POP generally transfers mail to the
|
|
client system and removes it from the server, IMAP allows one
|
|
to store the mail on server side folder, and the copies on
|
|
client systems are essentially a cache or "working copy" ---
|
|
this usually costs more server storage space, but it allows
|
|
the IT teams to focus on server backup/recovery and allows the
|
|
client systems to be considered more-or-less disposable. IMAP
|
|
can be used just like POP (where the mail is expunged from the
|
|
server by the clients after delivery). Operationally, there
|
|
isn't much difference. Both services are normally started by
|
|
inetd (the network dispatcher service; Linux's "receptionist"
|
|
if you will).
|
|
|
|
<P> A POP or IMAP server can run for years, serving hundreds, even
|
|
thousands of mailboxes and users without ever requiring any special
|
|
attention. Usually you're users or their e-mail correspondents
|
|
will occasionally do something stupid, or some software they run
|
|
will exhibit some bug that will require the system administrator to
|
|
go in and do some troubleshooting or cleanup.
|
|
|
|
<P> For example, one time I had some complaining that his POP e-mail
|
|
was broken. I found out that one of his customers had sent him a
|
|
bit of e-mail with a 100Mb file attachment! (It was a Netware
|
|
crash dump image). This was bumping into some diskspace and
|
|
speed/capacity limits on the old 32Mb 486 what we were using to
|
|
serve mail to him and the other 50 people in the department. I
|
|
fixed it in a few minutes with some shell commands, used some
|
|
command line tools to uudecode the attachment back into a file
|
|
which I put in the user's home directory. I tossed together a
|
|
quick throwaway script to extract the rest of his e-mail by
|
|
building a new mailbox for him. (mbox files under UNIX are simple
|
|
text files. qmail mail stores are directories with individual
|
|
small text files, one for each message). Any competent
|
|
intermediate system administrator could have done the same thing.
|
|
|
|
<P> So most of the problems you might encounter with MSAs and MTAs
|
|
can be fixed with text editors and common UNIX filters and
|
|
utilities.
|
|
|
|
<P> There are many MUAs that will work with POP and IMAP servers,
|
|
including Microsoft's Outlook. Under Linux many people use
|
|
'fetchmail' to fetch their mail to a local mail spool (mailbox).
|
|
Then they can use any MUA (elm, pine, mutt, MH/exmh, EMACS' rmail,
|
|
vmail, mh-e, gnus, and the plethora of GUIs like Balsa, Mahogany,
|
|
etc). Many other Linux users choose Netscape Communicator's
|
|
built-in mail client.
|
|
|
|
<P> Under Linux and UNIX there are other tools like procmail, vacation,
|
|
biff, and fetchmail which, as I said before, don't fall into any of
|
|
the three classic categories (MTA, MSA, MUA) that I describe
|
|
earlier.
|
|
|
|
<P> procmail is usually used as a "local delivery agent" and as a mail
|
|
processing agent. It's generally used to filter the part of the
|
|
final delivery of a message to its end recipients. This allows a
|
|
user to write scripts to automatically refile, reject, respond to,
|
|
forward or otherwise work with selected bits of mail as they are
|
|
received. (It can also be used to post process mailboxes and as a
|
|
more general e-mail programming language/library).
|
|
|
|
<P> (vacation is an old program that can be used to simply provide
|
|
an automated response to e-mail upon reciept. It was originally
|
|
used to warn correspondents that the recipient was "on vacation."
|
|
This can be also done with a simple two line procmail recipe).
|
|
|
|
<P> biff is a utility to notify a user that mail has arrived. (There
|
|
are various similar utilities for doing this in GUIs, displaying
|
|
icons, animations, emitting music or vocal announcements, relaying
|
|
biff notifications over a network and using various backend
|
|
MSA protocols, etc).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- *** BEGIN copyright *** -->
|
|
<P> <hr> <!-- P -->
|
|
<H5 ALIGN=center>
|
|
|
|
Copyright © 2000, Jim Dennis<BR>
|
|
Published in Issue 56 of <i>Linux Gazette</i>, August 2000</H5>
|
|
<!-- *** END copyright *** -->
|
|
|
|
<!--startcut ==========================================================-->
|
|
<HR><P>
|
|
<CENTER>
|
|
<!-- *** BEGIN navbar *** -->
|
|
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="correa.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue56/dennis.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="eyler.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
|
<!-- *** END navbar *** -->
|
|
</CENTER>
|
|
</BODY></HTML>
|
|
<!--endcut ============================================================-->
|