Jacob Yocom-Piatt <[EMAIL PROTECTED]> writes: > the MX record for our contact's company is in the 222.73.0.0/16 netblock and > spamd's china list includes that block in the 222.64.0.0/11 netblock. this > means > that the default pf.conf spamd rdrs won't quite cut it since IPs in <spamd> > will > always go to spamd and never deliver. preceding the usual
One rather big issue with all blacklists is the problem of maintaining them in a way that keeps your false positives to a minimum. Some of the lists have been known to include entries covering entire ISPs' netblocks. Assuming that those ISPs have a few non-spammer customers as well, it's fairly obvious that false positives can turn out to be real and embarrasing problems. The china and a few others example are there, I suppose, for people who do not expect to receive legitimate email from certain parts of the world, ever. If you do business with eg China, it is probably better to err on the side of caution and not use those black lists. A few suggestions - it is possible to run spamd in pure greylisting mode, without any blacklists at all. On my systems, I've greylisted for quite a while, but I was never quite happy with any of the blacklists until I ended up using Bob Beck's traplist supplemented with local greytrapping. It is well worth taking in Bob Beck's NYCBSDCon 2006 presentation[1] about these matters; my PF tutorial [2] touches on this too. [1] http://www.ualberta.ca/~beck/nycbug06/spamd/ [2] http://home.nuug.no/~peter/pf/, specifically about spamd with greylisting and greytrapping http://home.nuug.no/~peter/pf/en/spamd.html onwards. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
