/
STATUS
87 lines (55 loc) · 2.92 KB
/
STATUS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
Qpsmtpd is a very good SMTP daemon for developers and hackers.
Current goals are making it easier to install, reducing code duplication,
reducing complexity, and cooperation between plugins. Anything covered
in Perl Best Practices is fair game.
Recent changes have been made towards 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/smtpd/qpsmtpd/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