Qpsmtpd: MTA integration and testing

Qpsmtpd is a Perl-based smtpd daemon used for spam prevention. In the final installment, we'll learn how to integrate qpsmtpd with the mail transfer agent and debug the setup.

Qpsmtpd is a Perl-based smtpd daemon that is used for spam prevention. Developed by Ask Bjørn Hansen, Qpsmtpd is

used for spam protection on apache.org, cpan.org and perl.org. In this series, we learned how to install and configure qpsmtpd, as well as various plug-ins that work with programs such as SpamAssassin and Post-fix. In this final installment, we'll learn about how to test and debug the setup with swaks.

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 of your MTA. The qpsmtpd daemon receives email for you, processes it and passes it to your MTA, which could be running on another interface or port or even another server. To pass the email to the MTA, qpsmtpd uses a special type of qpsmtpd plug-in, called a queue plug-in.

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

More on qpsmtpd:
Installing qpsmtpd

Qpsmtpd: Configuration and plug-ins

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 postmaster@mail.domain.com

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

Dig deeper on Linux security risks and threats

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchDataCenter

SearchServerVirtualization

SearchCloudComputing

SearchEnterpriseDesktop

Close