Spamd pkg has several critical flaws

  • The spamd pkg has several flaws.  I'm working on patches to correct them.

    (1) The External Sources tab lets you specify blacklists and white-lists.  However, the white-lists will never be applied as expected.  spamd.conf's "all:" config line is rendered like:


    (Where DNSWL is a whitelist).

    But according to spamd.conf

    If a list is instead given the :white: capability, addresses in it will not be blacklisted.  The addresses in such a list are removed from the PRECEDING blacklist.

    In the above case, DNSWL will only subtract addrs from the Spews-Level-1 blacklist, not the others.  If suspect-IP is in the DNSWL, but is also found in any of the other blacklists, it will not be whitelisted.

    If I wanted the DNSWL to supercede any blacklists, I'd need an "all:" config like:


    (2) The default "all:" config begins by specifying whitelist: and blacklist:, both of which are text files in /var/db.  Unfortunately, whitelist will have no effect on spamd.conf because it's listed first; if suspect-IP is found in any of the other blacklists, suspect-IP will not be whitelisted.

    whitelist and blacklist (/var/db/whitelist.txt, /var/db/blacklist.txt) are better used within PF, anyway.  They should be removed from spamd.conf.  Or at least whitelist should be removed.

    (3) Because the GUI doesn't give you the capability of correctly deploying whitelists in spamd.conf, spamd.xml should be modified to allow only blacklists.  It should include messaging to the user that he can only configure blacklists.

    It would be better to put whitelists in the file-system, allow some mechanism to update them periodically (via http, ftp), and turn them into pf tables for use with spamd.  There's been talk of adding this kind of feature to pfsense.

    (4) spamd allows the creation of a custom white-list via spamd_whitelist.xml, stored in /var/db/whitelist.txt.  This white-list is loaded into the <spamd-white>pf table:

    table <spamd-white>persist file "/var/db/whitelist.txt"
    rdr pass on {$wanif} proto tcp from <blacklist>to port smtp -> port spamd
    rdr pass on {$wanif} proto tcp from <spamd>to port smtp -> port spamd
    rdr pass on {$wanif} proto tcp from ! <spamd-white>to port smtp -> port spamd
    rdr pass on {$wanif} proto tcp from <spamd-white>to port smtp -> {$nextmta} port smtp

    Unfortunately, <spamd-white>is a reserved table, used by spamd and spamlogd to list hosts which have successfully negotiated greylisting.  pf initially loads the table with the user's custom whitelist, but that is soon clobbered by spamd and spamlogd – thus mail from hosts in /var/db/whitelist.txt don't get whitelisted.

    A separate pf table needs to be created to hold /var/db/whitelist.txt.

    (5) When adding to /var/db/whitelist.txt through the GUI, it's not clear to the user that he can specify CIDRs.  The GUI is explicit about accepting IP addrs, not the various other forms that it can also accept.  Messaging should be clearer.

    (6) The spamd rdr ruleset should be simplified, modified.  rdr rules which allow whitelisted IPs should not use 'rdr pass'.  Instead, they should just use 'rdr', that way they go through your pf ruleset to your pf rule which allows SMTP to your mail server.  Ideally, you've enabled logging for this rule, so that spamlogd can monitor successful connections.

    per the man-pages:

    spamlogd updates the spamd database whenever a connection to port 25 is logged to the pflog interface. ... When spamlogd sees a successful connection, spamd in turn uses the db to decide whether someone is on the whitelist or greylist.  To provide spamlogd with the information it needs, you must log your mail server activity.

    There are various other philosophical issues with the rdr ruleset that could be improved.


    As I said, I'm working on some patches for this.  Because of (2), I'll probably disable the ability to create whitelists in spamd.xml.</spamd-white></spamd-white></spamd-white></spamd></blacklist></spamd-white></spamd-white>