95 lines
3.2 KiB
Plaintext
95 lines
3.2 KiB
Plaintext
|
|
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 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
|
|
|