|
|
Part 18 - Maintaining your qmail server
|
Once you've got your qmail server up and running, how do you take
careof it? This page will cover the many answers to that question. So
here
goes.
Making sure that all services start on boot
If you've installed qmail correctly, it should already automatically
start when you boot your server. However, you will want to make sure
that all of the other needed services start as well.
Make sure the following startup commands exist in your system's /etc/rc.d/rc.local file:
Starting Courier-authlib
/etc/rc.d/rc.authdaemond start
Starting Courier-imap
/etc/rc.d/rc.imap start
/etc/rc.d/rc.imaps start
Starting SpamAssassin
/etc/rc.d/rc.spamd start
Starting Apache
/etc/rc.d/rc.httpd start (If you already have Apache configured to
start on boot, you can omit this line)
Maintaining the qmail queue
It's usually not a bad idea to keep your qmail server's queue in check.
Your qmail server's queue is located at /var/qmail/queue. However, it's
just about impossible to look directly at the queue folders and be able
to tell what's going on.
qmailctl stat - This, of course, shows you your qmail server's current
status. Included in the stats is the current condition of the queue.
You can use this to see how many messages are sitting in the queue.
qmHandle - This add-on tool allows more in depth viewing of the queue
and it also allows you to perform administrative functions on the
queue. You can find instructions about installing qmHandle here. Once
qmHandle is properly installed, running the command
"qmHandle" will provide a listing of all the possible commands
possible. I'll go over a couple of them right now. The "qmHandle -l"
command will give you a complete listing all every message in the queue
and a summary containing the date the message was sent, the sender and
the intended recipient. The output for a single message might look like
this:
6406395 (195, R)
Return-path: bob@somewhere.com[]
From: Bob Smith <bob@somewhere.com>
To: Frank Smith <frank@wherever.com>
Subject: Re: This weekend
Date: Mon, 16 Feb 2004 12:14:31 -0700
Size: 1482 bytes
The message number, 6406395, can be seen at the top of the message. If
we wanted to delete this single message from the queue, we could do so
with a command of "qmHandle -d6406395". The entire queue can be cleared
out with the command "qmHandle -D".
queuelifetime - The "queuelifetime" setting for qmail determines how
long messages can stay in the queue. By default, your qmail server will
keep messages in the queue for 604,800 seconds, or 7 days. However, you
can set a custom queuelifetime by creating a file called
/var/qmail/control/queuelifetime. The content of that file is a single
line containing a number which represents the number of seconds the
queue will hold any given message. If you want to set a custom
queuelifetime, you might want to whip out the old calculator.
A little advice on handling your queue
You need to keep in mind that a queued message is NOT necessarily a BAD
thing. The only time a message is queued for any length of time is when
it is undeliverable at the time it is originally sent. A message is
usually undeliverable for 1 of 2 reasons:
1) The receiving mail server is offline. If this is the case, when that
mail server comes back online at a later time your qmail server will
then be able to deliver that message. A perfect example of this is the
Qmailrocks.org mailing list. At any given time there lots of messages
in the mailing list server's queue. However, these messages usually get
delivered eventually. As you can imagine, some people on the mailing
list are probably using a new qmail server to house the mailbox with
which they have signed up on the list with. Well, of course, since that
person is new the qmail there is a chance that their server may go down
for periods of time while they are working on it and perfecting their
qmail skills. It is at these times when their server is unreachable and
when my list server then queues the message for later delivery. No big
deal.
2) The recipient address is bogus or incorrect. If you get hit with a
lot of spam on your server, or if you have a spammer on your server,
this will probably happen to you at some point. Your queue gets filled
with message bound for bogus addresses OR it gets filled with bounce
messages that your server is trying to deliver back to spammers who
sent spam to bogus addresses on your server. A good way to cut down on
this is to set the domains on your server to "delete" catchall mail
instead of bouncing it. This can be done from within the Qmailadmin
interface. Setting a domain's catchall setting to "bounce" is a bad
idea in my experience as it only results in a queue full of bounced
bounce messages. If you don't need a catchall for your domain, do
yourself a favor and set it to "delete". This is also the case if you
are running Qmail-scanner. Qmail-scanner has an option to notify the
sender when a virus is found in an e-mail. Bad idea. Most of the time,
the address from which that virus laden e-mail came is bogus. So trying
to "notify" the sender usually results in nothing but a bunch of double
bounces flying all over your server.
Fortunately, since your qmail server has a built in queue lifetime,
messages will eventually drop out of the queue if they are
undeliverable. The last thing I want to mention is that it is a common
misconception that if your queue is full, mail being sent presently
will not be delivered quickly. This is a misconception. As I said, the
queue is a repository for messages that are not immediately
deliverable. If a message is being sent to a valid address it will get
sent immediately, regardless of the size of the queue. So, in summary,
you don't need to panic every time you have messages in your queue.
Most of the time, the best thing to do is to just let your queue take
care of itself. However, there are time when you may deem it necessary
to clean out the queue or take other administrative action, and that's
what the "qmHandle" tool above is good for.
Maintaining qmail-scanner
Qmail-scanner is fairly easy to maintain. Once you get it configured
how you want it to be, the main items your going to want to worry about
are 1) the log files and 2) the virus quarantine area. Here's some info
on both.
1) qmail-scanner logs - Qmail-scanner, when Clam Anti Virus and
SpamAssassin are hooked into it, logs the virus scanning activities to
/var/spool/qmailscan/qmail-queue.log. This log file can get REALLY big,
so you will want to keep it in check. You may want to set up a rotation
schedule for this log file or some other sort of scheduled task that
deals with this log file on a routine basis. If this log file exceeds
the linux file size limit of 2GB, your mail server will start freaking
out and all hell will break lose. So do yourself a favor and keep an
eye on this log file.
2) The virus quarantine area - When qmail-scanner pipes the mail out to
Clam Anti Virus and virus is found, the virus laden message is
quarantined at /var/spool/qmailscan/quarantine/new. Those e-mails will
usually not pose any threat to your server, since there are very few
Linux/Unix viruses and since they are not being executed. However, on a
busy mail server, that folder can get filled up pretty quickly, so you
may want to keep an eye on it and have it emptied on a routine basis. I
empty mine out with a crontab that runs once a week.
Anytime you upgrade qmail-scanner, it's a good idea to refresh the
qmail-scanner perlscanner database:
Slackware:
setuidgid qscand /var/qmail/bin/qmail-scanner-queue.pl -g
Maintaining SpamAssassin
SpamAssassin is relatively maintenance free one you get it up and
running. It logs it's activities to /var/log/maillog, so you can always
reference the logs for any investigations. New versions of SpamAssassin
are released fairly often, so you may want to occasionally check
http://www.spamassassin.org to see if there have been any new releases.
In my experience, I've always been able to install the new version over
the older version with no problems. If you upgrade, just make sure the
/etc/mail/spamassassin/local.cf file still contains the setting you
want and you should be in good shape.
Anytime you upgrade SpamAssassin, it's a good idea to refresh the
qmail-scanner perlscanner database:
Slackware:
setuidgid qscand /var/qmail/bin/qmail-scanner-queue.pl -g
Maintaining Clam Antivirus
The only things you really need to do to maintain Clam AV are:
1) Make sure your server is running the automatic virus definition
updates on a regular basis. I run the following command out of crontab
on a routine basis:
/usr/bin/freshclam --quiet -l /var/log/clamav/clam-update.log
2) Keep your version relatively current. New releases are put out
fairly often, so keep an eye on it. Again, in my experience I've been
able to install the newer version over the older one with no problems.
3) Anytime you do decide to upgrade Clam Antivirus, you will need to
update qmail-scanner's version file. This is easily done by running the
following command:
Slackware:
setuidgid qscand /var/qmail/bin/qmail-scanner-queue.pl -z
Maintaining current software versions in general
Naturally, as time passes new and improved versions of software will be
released from their respective venders. It's always nice to have to
latest versions of everything, but unless the newer version fixes a
security hole or a major bug you don't need to lose sleep over it. You
can check the venders' websites every now and then to see if a new
version is out. I try to keep the QMR software package as current as
possible and I'm pretty good at it. Most of the time, the
qmailrocks.tar.gz package will contain the latest versions of
everything.
I've never had any big problems with upgrading any of the software. For
source packages. you can usually simply compile and install the latest
version right over the older version with no problems. I mention this
in the above paragraphs on SpamAssassin and Clam AV, but it generally
applies to all of the software found on this site. The same goes for
RPMs. You can usually just install the new RPM right over the older one
using the command syntax "rpm -Uvh whatever.rpm".
Qmail itself has not had a new version release in a very long time, but
you can bet if there is a new release I will have it here. As you
probably know by this point, the current qmail version is version 1.03.
Many people have noticed that qmail.org offers a version of qmail
called "netqmail-1.05". At first glance this may appear to be a newer
version of qmail. IT IS NOT. Netqmail is simply qmail-1.03 with some of
the patches (which I use on this site anyway) already built in. If you
follow the QMR installation guide using 1.03, the resulting
installation of qmail is not different that if you used netqmail.
Understand? If you don't trust me, check out the full description of
netqmail here.
Maintaining the qmail logs
Fortunately, qmail's logs take care of themselves. They automatically
rotate all on their own, so you never have to worry about them. The
only thing worth noting is that you CAN customize the rotation schedule
for the logs. This is done the "logs" supervise script for each
supervised function. Confused? Ok, I'll explain.
In the QMR qmail installation, there are 3 supervise scripts and,
subsequently, 3 logs for those scripts.
/var/qmail/supervise/qmail-pop3d/run operated the pop server and is
logged via /var/qmail/supervise/qmail-pop3d/log/run
/var/qmail/supervise/qmail-smtpd/run operates the smtp server and is
logged via /var/qmail/supervise/qmail-smtpd/log/run
/var/qmail/supervise/qmail-send/run operates the mail processor and is
logged via /var/qmail/supervise/qmail-send/log/run
Each of the above "log/run" scripts tells the server how it wants those
activities logged. Let's take the
/var/qmail/supervise/qmail-pop3d/log/run logging script as an example:
#!/bin/sh
PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
export PATH
exec setuidgid qmaill multilog t s100000 n20 /var/log/qmail/qmail-pop3d
2>&1
The last line of this script sets some of the logging options. We can
break that last line into several parts:
exec setuidgid qmaill multilog t s100000 n20 /var/log/qmail/qmail-pop3d
2>&1
So let's break it down:
exec setuidgid qmaill multilog - run the multilog program as the
"qmail" user.
t - inserts an @, a precise timestamp, and a space in front of each
line.
The above "t" is why the rotated logs take on names like this:
@40000000402d1c562cbf3534.s
s100000 - logs will rotate when they reach 100000 bytes.
n20 - number of rotations to keep on hand before they fall off.
/var/log/qmail/qmail-pop3d 2>&1 - the directory to where
the logs will be written, silently.
Maintaining administrative mailboxes
This may seem a bit silly, but you'd be surprised how many people
neglect the administrative e-mail account on their server. But what is
the administrative e-mail account? Well, that depends on you.
Administrative mail would be mail destined for the server's root user
as well as any notification settings you may have. The destination for
most the server's administrative addresses is usually determined by the
aliases you have created at /var/qmail/aliases. If you've followed the
QMR install guide, you should have a "postmaster" alias as well as
"root", "mailer-daemon" and "anonymous" aliases. If you're like me, you
direct all of these aliases to a single mailbox on your qmail server.
For example, on the qmailrocks.org server, I direct all of these
aliases to the qmailrocks.org postmaster account. This means that my
postmaster account gets all of the administrative mail on the server. I
get bounce failure messages, crontab reports, log watch reports and
many other admin type emails. In addition, since I also have
qmail-scanner set up to send virus reports to this same address. So, as
you can see, my postmaster account is the central locus for all the
server's administrative mail. You probably want to do the same with
your server, as these administrative e-mails can often help you to find
and correct problems that might otherwise go unnoticed. A mistake that
people make a lot is to have the administrative mail directed to some
mail account that they never check. This inevitably leads to that
person being surprised when they find out that they have a mailbox on
their server that's a couple Gigs in size. These people will also be
surprised when they find that that mailbox is full of error messages
that have been coming in for months indicating that something on the
server is misconfigured. They never checked the mailbox, so they never
knew. Well, I guess ignorance is bliss. So my point of this whole
paragraph is that you should keep your administrative mail
configuration organized and well cared for. It will save you a lot of
heartache down the road.
Maintaining other mailboxes
Managing all other mailboxes on your server is made easy my simply
setting quotas on all domains. It is inevitable that if you host mail
on your server, there will be some idiot who either never checks his
mailbox or decides that he has to store a lifetime worth of mail on the
server. Setting quotas for your domains is a way of keeping these
idiots in check and preventing you from having a disk space crisis
because of these idiots. If you have a 120GB drive in your server and
no quotas, there WILL be some fool who fills up all 120GB with his
mail. So take my advise and set rigid quotas for your domains.
Backing up your qmail server
Backing up a qmail server is relatively easy. While different people
may give you slightly different recommendations, you can ensure a safe
backup of your qmail server if you backup the following 2 directories
on a routine basis.
/home/vpopmail - backs up all your domain information, including
mailboxes, passwords and the messages themselves.
/var/qmail - backs up all of your qmail settings. The
/var/qmail/control directory is the most important directory in there
to back up, but it won't hurt to just back up the whole damn qmail
directory.
|
|
