qpsmtpd/STATUS

Qpsmtpd-dev is a fork of Qpsmtpd. Qpsmtpd is a very good SMTP daemon for
developers and hackers (admittedly, its focus). The plugin system is great
but the plugin organization, documentation, and consistency left much
to be desired.

The primary focus of the -dev branch is improving the consistency and
behavior of the plugins. After using one plugin, the knowledge gained
should carry over to other plugins.

Secondary goals are making it easier to install, reducing code duplication,
reducing complexity, and cooperation between plugins. Anything covered
in Perl Best Practices is also fair game.

So far, the main changes between the release and dev branches have focused
on these goals:

  - plugins use is_immune and is_naughty instead of a local methods
  - plugins log a single entry summarizing their disposition
  - plugin logs prefixed with keywords: pass, fail, skip, error
  - plugins use 'reject' and 'reject_type' settings
  - plugins support deferred rejection via 'naughty' plugin
  - plugins get a resolver via $self->init_resolver
  - new plugins: fcrdns, dmarc, naughty, karma

An example of plugin cooperation is karma. Karma is a scorekeeper that aggregates bits of information from many plugins. Those bits alone are insufficient for acting on.  Examples of such data are:

  FcRDNS - whether or not hostname has Forward confirmed reverse DNS
  GeoIP distance - how many km away the sender is
  p0f    - senders Operating System
  helo   - helo hostname validity

For most sites, even DNSBL, SPF, DKIM, and SpamAssassin tests alone are insufficient rejection criteria. But when these bits are combined, they can create an extremely reliable means to block spam.


Roadmap
=======

 - https://github.com/qpsmtpd-dev/qpsmtpd-dev/issues

 - Bugfixes - qpsmtpd is extremely stable (in production since 2001), but
   there are always more things to fix.

 - Add user configuration plugin infrastructure
   - Add plugin API for checking if a local email address is valid

 - Add API to reject individual recipients after the RCPT has been
   accepted and generate individual bounce messages.

Issues
======

------ The rest of the list here might be outdated. ------
------ Patches to remove things are welcome.        ------

plugin support;

  allow plugins to return multiple response lines (does it have to
  join them to one for SMTP?)

  support plugins for the rest of the commands.

  specify a priority in register_hook. ("LAST", "FIRST", "MIDDLE", or
  maybe a number)

  plugin access to the data line by line during the DATA phase
  (instead of just after)

  if qmail-queue can't be loaded we still return 250 ?!

Make a system for configuring the plugins per user/domain/...

  support databytes per user / domain

localiphost - support foo@[a.b.c.d] addresses 

Move dispatch() etc from SMTP.pm to Qpsmtpd.pm to allow other similar
protocols to use the qpsmtpd framework. 



Future Ideas
============

Methods to create a bounce message easily; partly so we can accept a
mail for one user but bounce it right away for another RCPT'er.

The data_post hook should be able to put in the notes what addresses
should go through, bounce and get rejected respectively, and qpsmtpd
should just do the right thing.  See also
http://nntp.perl.org/group/perl.qpsmtpd/170

David Carraway has some thoughts for "user filters"
http://nntp.perl.org/group/perl.qpsmtpd/2