2012-06-22 11:38:01 +02:00
2013-04-21 02:12:21 +02:00
Qpsmtpd-dev is a fork of Qpsmtpd. Qpsmtpd is a very good SMTP daemon for
2013-04-21 05:47:53 +02:00
developers and hackers (admittedly, its focus). The plugin system is great
but the plugin organization, documentation, and consistency left much
to be desired.
2013-04-21 02:12:21 +02:00
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.
2013-04-21 05:47:53 +02:00
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.
2013-04-21 02:12:21 +02:00
So far, the main changes between the release and dev branches have focused
on these goals:
2013-04-24 22:20:07 +02:00
- plugins use is_immune and is_naughty instead of a local methods
2013-04-21 05:47:53 +02:00
- plugins log a single entry summarizing their disposition
2013-04-21 02:12:21 +02:00
- plugin logs prefixed with keywords: pass, fail, skip, error
2013-04-21 05:47:53 +02:00
- plugins use 'reject' and 'reject_type' settings
2013-04-21 02:12:21 +02:00
- plugins support deferred rejection via 'naughty' plugin
- plugins get a resolver via $self->init_resolver
2013-04-21 05:47:53 +02:00
- new plugins: fcrdns, dmarc, naughty, karma
2013-04-21 02:12:21 +02:00
2013-04-21 05:47:53 +02:00
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.
2012-06-22 11:38:01 +02:00
Roadmap
=======
2013-04-21 02:12:21 +02:00
- https://github.com/qpsmtpd-dev/qpsmtpd-dev/issues
2012-06-22 11:38:01 +02:00
- 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
