-------- Original-Nachricht -------- > Datum: Fri, 31 Jul 2009 11:17:24 -0700 > Von: "Michael Watkins" <[email protected]> > An: [email protected] > Betreff: Re: [Dspam-user] RBL Configuration
> On Fri, July 31, 2009 10:32, Steve wrote: > > That Geo-IP patch you are talking about can be easy avoided. Just use > > stock policyd-weight and DNSBL functionality to increase score for them. > > If you are from Europe then you could use lookups to *.countries.nerd.dk > > and all others could use lookups to *.countries.blackholes.us. > > I used to use nerd.dk/blackholes.us; am not completely sure why I stopped > - I didn't log the reason. I have a vague recollection that I was seeing > problems with certain addresses/blocks not being accurately reported by > nerd where geoip was more up to date at the time. > > While I am a bit of an efficiency geek, I doubt I implemented the patch > for that reason, although doing one lookup rather than several is always > appealing to me. > Okay. This is possible with nerd.dk but not without patching the DNSBL code. That said... you can lookup zz.countries.nerd.dk with reverse octets and get in one lookup the ISO 3166-2 country code. So your geekness in efficiency can get satisfied :) > > So in your case I would use: > > # Give a better score to our Canadian mail servers > > 'ca.countries.nerd.dk', -1.00, 0.00, 'NERD-CA', > > # Set the bar higher for some high-rate spam countries > > 'vn.countries.nerd.dk', 0.00, 2.00, 'NERD-VN', > > Indeed I have always done that regardless of the method of IP location > identification -- very little spam hits me from CA sources; I give US > servers a minor negative score just so they show up in the output. > Ouch! I punish US servers the most. The reason is because I automatically download the list from Spamhaus TOP 10 Spam Origins (http://www.spamhaus.org/statistics/countries.lasso) and compute on the numbers from there an score for the TOP 10 and inject that into policyd-weight and reload it after the injection. US is number one on that list - I think since God helped Moses to part the sea and long, long before my time and I think they will stay there long, long after my time. > > But it does not stop here. Wanting to set the bar high for certain ASN? > No > > problem (just an example): > > 'AS5617.rbl.cluecentral.net', 2.500, 0.00, 'AS5617', # > > Telekomunikacja Polska S.A. > > 'AS4134.rbl.cluecentral.net', 1.606, 0.00, 'AS4134', # > > Aha, now there is a new use I'd not "clued" into - weighting by ASN. > Thanks! > :) > In addition to the usual offenders in CN, KR, VN, BR I have a particular > hate on for TPNET in Poland. > Those Poland guys used to keep my infrastructure busy but not anymore :) > /mw goes off to adjust policyd-weight.conf accordingly. > LOL > > But I have as well patched my policyd-weight. Added p0f integration, > > (will I make it through that gauntlet? my firewall blocks such queries!) > I doubt that you block p0f. You can have a gazillion of rules but p0f = PASSIVE OS fingerprint. So I am not scanning your IP at all. I just scan the patterns your IP is producing while communicating with my SMTPD. Block as much you like. It's not going to affect my ability to guess your OS :) > > additional sender based reputation lookups, > > > S25R rules, etc... > > Ok, something new for me - I wasn't aware of that initiative. > It's ultra cheep to compute and jet very effective. I kinda like that. > /mw heads for a quick read of: > http://www.gabacho-net.jp/en/anti-spam/paper.html > > I too have extended the regex tests associated with the "seems like > dialup" rejection / test of $revhost. I'll steal some ideas from the rule > sets discussed in the paper. > They help. Really. That guy took so much time to figure out a common pattern that it would be a pity to not use his findings. > > It's kind of hard to not patch since Robert has stopped developing it > any further. > > Agreed. It seems that policyd-weight will live on in various patches and > permutations and that isn't altogether a bad thing. > Well... at least they are now on SF as well. > It works, is simple (a > good thing) > Indeed. > and is reliable, and for those reasons I don't feel like > diving into the postfix "firewall" alternative. > The alternative used to be not so good as policyd-weight. But newer editions have improved and in some areas already way more powerful then policyd-weight. But again: Who is going to write all the rules for postfwd to be on par with policyd-weight? Me not. Not now. Maybe later but now I feel like you: Why changing something that works so beautiful without issues? > Because it works I don't have to muck with policyd-weight very much, but > as I don't do much work in Perl, each time I do open up the script I have > been tempted to rewrite policyd-weight in Python. > Ohhh boy! Perl is nothing new to me but I feel your pain. Believe it or not. I have done the coding of policyd-weight from Perl to Python. Yes, yes. Stupid. Crazy. Well... what should I say? I could not resist and ported the whole ruleset from policyd-weight to be a ruleset in PPolicy. Ach. It took me much time and at the end somewhere before going crazy I asked myself: What the F* are you doing here? Why are you doing that? WHY? Have you not other more important things to do? And I switched back to policyd-weight. PPolicy is ultra cool but at the end it used more resources (mostly because of twisted) then pure naked policyd-weight and so my geek soul had to step aside and let my normal mind take control and decide to use the more economical solution. But that was some time ago and maybe things changed inside PPolicy. I don't know. If however the main developer is so unresponsive as he was the last time then I would step back from even considering PPolicy again. > Of course I'd only do > that if there was some longer term benefit in doing so. I can think of > some integration I'd like to do with spam reporting / feeding / > maintaining my firewall's blocked ip table, some country analysis for > interest sake (and perhaps auto-adjusting the weighting rules) - just to > name a few. > I do that with stock policyd-weight. It's nothing special. If I however would have more time then I would implement something totally redesigned and made as flexible as possible and maybe using something like Stackless Python and using asynchronous communication where ever possible (for example using something like ares/c-ares for DNS lookups (btw: c-ares would perfectly fit into DSPAM). > Cheers > Mike > Steve -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
