Using queue plug-ins with your MTA
As I discussed in part 2 of this tip, the key configuration file for qpsmtpd is the plugins file. This file lists all the plug-ins that qpsmtpd will use when processing email. You can see the postfix-queue plug-in listed at the bottom of the plugins file. You can see the example file from part 2 below:
check_earlytalker greylisting count_unrecognized_commands 4 check_basicheaders rcpt_ok virus/clamdscan clamd_socket /tmp/clamd spamassassin spamd_socket /tmp/spamd queue/postfix-queue
You can see the postfix-queue plug-in listed at the bottom of the plugins file. The queue plug-in tells qpsmtpd how to dispose of email after processing; in this case, it is written to the Postfix cleanup daemon. Any queue plug-in you use should be listed last in the plugins file. Let's look at how this plug-in works and how we can put qpsmtpd in front of your MTA.
The normal method for placing qpsmtpd in front of your MTA is to run it on port 25 of your external interface(s) instead
There are a variety of queue plug-ins that can feed email from qpsmtpd into your MTA, or even directly to a mailbox. In the qpsmtpd package, there are queue plug-ins to support sending email to Exim, Postfix, qmail. There are plug-ins that can even support the forwarding of email to an SMTP daemon or write directly to a Maildir mailbox.
I'm going to demonstrate how to place qpsmtpd in front of the Postfix MTA. With qpsmtpd we can do this with two potential queue plug-ins: postfix-queue or smtp-forward. The first queue plug-in, postfix-queue, assumes the Postfix MTA is running on the same server as qpsmtpd and injects mail from qpsmtpd into the Postfix cleanup daemon. The second plug-in, smtp-forward, forwards email to a specified SMTP server, either running locally or on another server. I am going to use the first plug-in, postfix-queue and assume the Postfix MTA is running locally.
Implementing the postfix-queue plug-in
To implement the postfix-queue plug-in and place qpsmtpd in front of Postfix, we first need to make some changes to the Postfix smtpd daemon to run it on another interface. To change where the smtpd daemon runs we need to adjust the inet_interfaces option in the main.cf configuration file.
To run all interfaces inet_interfaces is to set it like so:
inet_interfaces = all
And change it to:
inet_interfaces = localhost
The smtpd daemon now only runs on 127.0.0.1. This provides us with the ability to submit mail on the local host without it going through qpsmtpd. If you want, you can also change the port number Postfix listens on or stop the daemon entirely by editing or removing the smtpd line from the master.cf file.
We also need to add the user qpsmtpd is running, with regards to the postdrop group, to allow qpsmtpd to submit mail to the cleanup daemon. In part 1, we created a user called smtpd to run qpsmtpd. You can add this user to the postdrop group this like so:
# gwpasswd -a smtpd postdrop
Remember that after making any Postfix configuration changes you need to reload:
# postfix reload
Now that we've configured Postfix, we need to run qpsmtpd on the external interface that Postfix previously ran on. For example, if our external interface was IP address 192.168.0.1 we would start the qpsmtpd-forkserver on this interface like this:
# qpsmtpd-forkserver -l 192.168.0.1 -p 25 -u smtpd
Testing your plug-ins with swaks
After configuring qpsmtpd and re-configuring Postfix, you need to make sure that you are receiving email and that your plug-ins are functioning correctly. The best tool to test this is swaks, or the Swiss Army Knife SMTP tool. Swaks provides the ability to conduct command-line SMTP testing. It is available as an RPM for Red Hat Enterprise Linux, Fedora and other RPM-based distributions or is available for download.
You can use swaks like so:
# swaks -s 192.168.0.1 -p 25 -t firstname.lastname@example.org
The -s option specifies the server to test, -p the port to connect to and -t the email recipient to send the test message to. You can also specify options to enable TLS and authentication amongst other features and review the man page for further information. This will allow you to submit test messages to your qpsmtpd server and monitor the effects of your plug-ins. When combined with the contents of the qpsmtpd log files, this will allow you to test and debug your installation.
When you are happy that your qpsmtpd installation is functioning correctly, then you can introduce it into your production environment. I believe you will find, as I have, that it significantly reduces the amount of spam that reaches your MTA. If you need additional help with qpsmtpd you can consult the qpsmtpd Wiki or the qpsmtpd mailing list.
This was first published in January 2007