Racker Hacker

Normally, qmail will be able to process the mail queue without any interaction from the system administrator, however, if you want to force it to process everything that is in the queue right now, you can do so:

kill -ALRM `pgrep qmail-send`

If for some peculiar reason you don’t have pgrep on your server, you can go about it a slightly different way:

kill -ALRM `ps ax | grep qmail-send | grep -v grep | awk '{print $1}'`

Your logs should begin filling up with data about e-mails rolling through the queue.

If you’re working in Plesk and you receive this error:

mchk: Unable to initialize quota settings for someuser@somedomain.com

Run this command to fix the issue, but be patient:

find /var/qmail/mailnames -type d -name '.*' ! -name '.spamassassin' -ls -exec touch '{}'/maildirfolder \; -exec chown popuser:popuser '{}'/maildirfolder \;

Thanks to Mike Jackson for this one.

On a Plesk server, the maximum size for an individual e-mail sent through qmail is unlimited. You can limit this size by adding a number to the /var/qmail/control/databytes file.

If you wanted to limit this to something like 10MB, you can just run the following command:

echo “10485760″ > /var/qmail/control/databytes

This will limit the size of messages (including attachments) to 10MB as a maximum.

I really dislike qmail. But, since I use Plesk, I’m stuck with it. However, I found a way to improve it’s awful mail queue performance by putting the mail queue onto a ramdisk. This is actually pretty darned easy to do.

First, toss a line like this into your /etc/fstab:

none    /mailqueue      tmpfs   defaults,size=100m,nr_inodes=999k,mode=775      0       0

This will make a 100MB ramdisk on /mailqueue. Now, just symlink /var/qmail/mqueue to /mailqueue and move your e-mail over:

# mount /mailqueue
# chmod 750 /mailqueue
# chown qmailq:qmail /mailqueue
# mv /var/qmail/mqueue /var/qmail/mqueue-old
# ln -s /mailqueue /var/qmail/mqueue
# rsync -av /var/qmail/mqueue-old /mailqueue

This has significantly cut the iowait on my server during heavy e-mail periods. In addition, tools like qmHandle now fly through my mail queue and give me reports very quickly.

I saw a ticket the other day where a customer received this error from Horde when trying to expand items on the left pane of the interface:

Fatal error: Cannot use string offset as an array in /www/horde/lib/Horde/Block/Layout/Manager.php on line 389

It turns out that Plesk 8.1.1 bundles Horde 3.1.3 which has an occasional bug within the interface. Upgrading to Plesk 8.2.0 corrects the issue as Horde 3.1.4 is installed with the upgrade.

See Horde’s bug page for more information.

If you see a large mail queue and your system’s I/O is increasing, you may find messages like these in your syslog:

Losing q5/qfg9N5EwE3004499: savemail panic
SYSERR(root): savemail: cannot save rejected email anywhere

In this situation, there’s some reason why sendmail cannot deliver e-mail to the postmaster address. There’s a few issues that can create this problem:

• Missing postmaster alias in /etc/aliases
• Hard disk is full
• The mail spool for the postmaster has the wrong ownership
• The mbox file for the postmaster is over 2GB and procmail can’t deliver the e-mail

First, correct the situation that is preventing sendmail from delivering the e-mail to the postmaster user. Then, stop sendmail, clear the e-mail queue, and start sendmail again.

I found this issue on a Red Hat Enterprise Linux 4 server and then found the solution on Brandon’s site.

One of my biggest complaints on RHEL 4 is the large resource usage by the version of SpamAssassin that is installed. When it runs, it uses a ton of CPU time and causes a lot of disk I/O as well. When running top, you may see multiple spamd processes. For a high-volume e-mail server (like the one I administer), this is simply unacceptable.

I decided to do something about it, and here are the steps:

First, you will need two RPMs:
Latest SpamAssassin RPM from Dag
The psa-spamassassin RPM from SWSoft/Parallels.

Once you have them both on the server, install the new SpamAssassin package from Dag:

# rpm -Uvh spamassassin-(version).el4.rf.(arch).rpm

At this point, Plesk’s spamassassin scripts will be non-functional, but the next step will fix it:

# rpm -Uvh --force psa-spamassassin-(version).(arch).rpm

NOTE: DO NOT REMOVE the psa-spamassassin RPM. This will begin stripping your system of all SpamAssassin configurations and it cannot be reversed!

Plesk’s SpamAssassin scripts have been restored at this point in the process. Now, we need to do the part that really makes SpamAssassin work efficiently:

# sa-update; sa-compile;

This will update the SpamAssassin rules, and it will compile the rules with re2c (you may also need to get this RPM from Dag). This compilation means less disk access, and less CPU time being used to process e-mails.

To activate the compiled rules within SpamAssassin, uncomment the plugin line in /etc/mail/spamassassin/v320.pre:

# Rule2XSBody - speedup by compilation of ruleset to native code
#
loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody

Please bear in mind that this process is done at your own risk. This may cause issues getting support from SWSoft or your hosting company. This has been tested on Red Hat Enterprise Linux 4 64-bit with Plesk 8.1.1, 8.2.0, and 8.2.1 with SpamAssassin 3.2.3 and 3.2.4.

If you have a new Plesk installation and the following option is greyed out in Server -> Mail:

Switch on spam protection based on DNS blackhole lists

Just install the following RPM from Plesk:

psa-qmail-rblsmtpd

I stumbled upon this peculiar bounce message recently while working on a server:

Hi. This is the qmail-send program at yourmailserver.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

Return-Path:
Received: (qmail 14418 invoked by uid 110); 9 Jan 2008 13:04:33 -0600
Delivered-To: 54-user2@domain.com
Received: (qmail 14411 invoked by uid 110); 9 Jan 2008 13:04:33 -0600
Delivered-To: 53-user1@domain.com
Received: (qmail 14404 invoked from network); 9 Jan 2008 13:04:33 -0600
Received: from otherdomain.com (HELO otherdomain.com) (11.22.33.44)
by yourmailserver.com with SMTP; 9 Jan 2008 13:04:33 -0600

Basically, this is qmail’s way of letting you know that your e-mails are stuck in a mail loop. One e-mail user is redirecting to another e-mail user, and that e-mail user is redirecting back to the first one. If q-mail already has a delivered to line which matches one that it already added, it bounces the e-mail and halts delivery.

You may catch this error when you attempt to start dovecot on a Red Hat Enterprise Linux 5.1 system with the 64-bit architecture:

dovecot: imap-login: imap-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory
dovecot: pop3-login: pop3-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory

If you start dovecot, the main dovecot daemon will run with one auth child process, but there will be no POP/IMAP processes started. To fix the issue, open the /etc/dovecot.conf and adjust the following directive:

login_process_size = 64

Restart dovecot after making the change:

# /etc/init.d/dovecot restart

This was tested on RHEL 5.1 x86_64.