There are a number of different ways to deploy the qpsmtpd daemon.

The qpsmtpd-forkserver is one of the most popular deployment options for qpsmtpd. The forkserver forks for every connection. A service supervision tool, e.g. runit or daemontools, is recommended for starting up and monitoring the qpsmtpd-forkserver service. SysV init scripts are also available and are in the RPM and .deb packages. The qpsmtpd-forkserver method is used by perl.org and cpan.org.

The pre-fork daemon is high performance pre-forking qpsmtpd daemon designed by ScanSoft in the UK. It is executed by running the qpsmtpd-prefork binary in the qpsmtpd package. It should provide considerably faster performance than the qpsmtpd-forkserver implementation.

Apache::Qpsmtpd embeds qpsmtpd in an Apache 2 server with mod_perl 2. This method was used by apache.org to handle 2.4 million messages per day. The Apache.org configuration is distributed between a primary and secondary MX. The primary typically carries at least twice the load of the secondary, and is a dual 2.80GHz Xeon dell box equipped with 3GB ram. Typical CPU load was around 1. The introduction of qpsmtpd reduced the spam load on Apache.org from 2.4 millions messages per day to 750,000 messages per day.

Apache::Qpsmtp is currently included in the trunk. A setup example is available here.

An older deployment method that is used by the run script. This method has dependencies on the tcpserver and daemontools tools that come with the typical qmail installations but not other MTAs such as Postfix.

The pollserver is based on the Danga socket and currently in the SVN trunk. It is being used in production environments, however there are reports that it is unstable on Red Hat 8 and has a memory leak.

Invoking qpsmtpd via inetd or xinetd (instead of tcpserver) did not work with version 0.32 but a patch has been applied that has enabled support. Two additional files required, in.qpsmtpd and qpsmtpd-xinetd will be placed into the repository but are currently available from a January 2007 mailing list post. The x(inetd) deployment method also works in the RPM.

Running from xinetd is generally fine for light traffic. It is also nice for test sites, because new plugins and configurations will be picked up automatically without any need to restart the qpsmtpd service.

PPerl, or Persistent Perl, is an old deployment option and should no longer be used.