BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Greylisting with PF
Pages: 1, 2, 3, 4, 5, 6, 7

I waited for another attempt, and there it was:

Nov  9 07:12:59 zip sm-mta[60044]:
kA8HThYO059822: to=<>,
ctladdr=<> (1001/1001), delay=00:43:13,
xdelay=00:00:02, mailer=esmtp, pri=210391,
[], dsn=4.3.0, stat=Deferred: 451 Temporary failure,
please try again later.

Remember how I said spamlogd will monitor the mail logs and move entries to the whitelist? Look here on nyi:

$ spamdb | grep

There you go, the entry has been whitelisted. Three delivery attempts have occurred, and none have succeeded. Actually, as I type this, the mail is still sitting on zip, waiting to attempt another delivery. This time, PF will redirect the incoming connection directly to my mail server, not to spamd.

Coincident with that attempt was a log entry:

*** /var/log/debug.log ***
Nov  8 13:13:19 nyi spamd[27526]: whitelisting in /var/db/spamd

That is spamlogd reporting that it has whitelisted the client. On the next delivery attempt, the message should go straight through:

Nov  9 07:43:06 zip sm-mta[60179]:
kA8HThYO059822: to=<>,
ctladdr=<> (1001/1001), delay=01:13:20,
xdelay=00:00:09, mailer=esmtp, pri=300391,
[], dsn=2.0.0, stat=Sent (Ok: queued as

Here is the receipt on nyi:

Nov  8 13:42:56 nyi postfix/smtpd[2847]: connect from[]
Nov  8 13:42:58 nyi postfix/smtpd[2847]: 661DC50849:[]
Nov  8 13:42:59 nyi postfix/cleanup[2873]: 661DC50849: message-id=<>

Nov  8 13:42:59 nyi postfix/qmgr[47862]: 661DC50849: from=<>, size=852, nrcpt=1 (queue active)
Nov  8 13:42:59 nyi postfix/local[2874]: 661DC50849: to=<>,
    relay=local, delay=2.3, delays=2.3/0.01/0/0.01, dsn=2.0.0, status=sent
    (delivered to command: exec /usr/local/bin/procmail -t -a ${EXTENSION})
Nov  8 13:42:59 nyi postfix/qmgr[47862]: 661DC50849: removed

The host is now in the spamd database:

$ spamdb | grep
WHITE||||1163006999|1163009572|1166121773|3|1 will remain on the whitelist until 36 days of no sent email. While on the whitelist, it will not be subject to greylisting. If if falls off the whitelist, it will go through the above greylisting process again.

Problems I Encountered

Yes, I had a problem. The <spamd-white> table was always empty, even after spamlogd moved something from the greylist to the whitelist. My thread whitelists clients still being greylisted in the FreeBSD PF mailing list found the missing piece for me:

mount -t fdescfs fdescfs /dev/fd

Now the whitelist table has some entries!

# pfctl -t spamd-white -T show 
No ALTQ support in kernel
ALTQ related functions disabled

My thanks to LI Xin.

Now I had an even bigger problem. Despite having the whitelist updated, my email still wasn't getting through. Whitelisted clients were still subject to greylisting. Delo found the answer. My rules were wrong. I had:

  1. rdr pass inet proto tcp from <spamd-mywhite> to $external_addr port smtp -> port smtp
  2. rdr pass inet proto tcp from <spamd> to $external_addr port smtp -> port spamd
  3. rdr pass inet proto tcp from !<spamd-mywhite> to $external_addr port smtp -> port spamd

See the problem? Line 1. That table name is wrong. It should be <spamd-white>, the table maintained by spamlogd. D'oh! When I found this problem, I corrected /etc/pf.rules and updated PF by issuing the command:

pfctl -f /etc/pf.rules

Later on, I found out about this option:

-N   Load only the NAT rules present in the rule file.  Other rules
     and options are ignored.

Pages: 1, 2, 3, 4, 5, 6, 7

Next Pagearrow

Sponsored by: