At a point [svn rev] early in development, Ask Bjorn Hansen, rebuilt qpsmtpd with a plugin architecture. Many people since then have contributed plugins to the project but the documentation of these has fallen behind.

Plug-ins are the heart of qpsmtpd, but as of yesterday, there was no good central repository for them. Today we begin the process of fixing that. Please register plugins here.

It has been reported on the mailing list recently that qpmsptpd works “out of the box”, as advertised. However, the default configuration includes a number of plugins which require custom configuration and may depend on external programs. Also, the default configuration assumes that the back-end is qmail-queue but there are many people using qpsmtpd as a front-end for other MTAs and there are plugins included for both postfix and exim.

I am going to set up my installation of qpsmtpd by turning off everything in the config.sample, which has an external dependency and then slowly turn things on. I will document this as I go. I will add separate pages here to keep this readable for someone new to qpsmtpd. –gh, 2007-01-22

Because of the plugin architecture it is possible for one developer to introduce new features and another to introduce the same thing but implemented in a different, and possibly, incompatible way. For now, I am cutting and pasting a remark from the mailing list, yesterday. –gh 2007-01-22

On 2007-01-21 16:42:28 +0100, Michael Holzt wrote:

I'm not up to date about the current stock implementation (if any) of
per recipient configuration, but i think qpsmtpd should have this for
each and every content filtering plugin. I think this is a killer feature
because spam filtering got very complex and involves lots of methods with
various risks. Especially on large mailservers there is no one-size-fits-
them-all spam filter configuration.

Right. Most plugins I wrote support per-recipient configuration. Unfortunately there's no standard mechanism to do this, so even my plugins aren't consistent, and it gets worse if you mix plugins from several authors.

The mechanism I currently use extends the Qpsmtpd::Address class with a notes() method (this is done by the address_notes plugin[0]). This allows arbitrary notes to be attached to recipient objects. The plugins then check for the existence of certain notes (for example, my modified spamassassin plugin uses

my $reject_threshold = $rcpt→notes('spamassassin_reject_threshold')

                      || $self->{_args}->{reject_threshold}
                      || 99;

to determine the reject threshold.

Another plugin (called from the rcpt hook) populates the recipient object with notes. I currently use address_notes_aliases[1] which gets the data from transaction notes set by aliases_check[2] which gets the config from a plain text file, but it should be easy to write a plugin which gets the per-recipient config from LDAP or an SQL database.

I think this mechanism is quite flexible and I would appreciate it if other plugin authors would adopt it.

      hp

[0] http://svn.perl.org/qpsmtpd/contrib/hjp/address_notes/address_notes

[1] http://svn.perl.org/qpsmtpd/contrib/hjp/address_notes/address_notes_aliases

[2] http://svn.perl.org/qpsmtpd/contrib/hjp/aliases/aliases_check