On Fri, 29 Jan 2010 14:34:46 -0500 Adam Katz <antis...@khopis.com> wrote:
> Robert Fitzpatrick wrote: > >>> http://mx1.webtent.net/test.msg > > http://mx1.webtent.net/test2.msg > > The first one now also hits razor ... can't say one way or another > about how it hit earlier, but I'd suggest double-checking to ensure > you use the plugin as it's pretty useful across the board. > > > I suppose this is more an sa-dev question, but perhaps it might be > worthwhile to have a freemail_networks category (much like > trusted_networks) that would allow limited parsing beyond the freemail > providers' networks into the system that connected to it. This must > not affect the last-external checks as it would then trigger all the > dynamic rDNS detectors, and we'd also have to be wary about SPF etc, > but it might be quite useful for DNSBL. > > I'm sure the freemail plugin already does much of this work. I'm not sure that it does - looking at the comments at the top of the .pm it says; "# If From-address is freemail, and Reply-To or address found in mail body is # a different freemail address, return success." In the context we have here, and in general terms for the variety of spam received via Hotmail - it's a vector, but not overly useful with this specific type of 'hotspam'. Looking back at my Hotmail spam it consists of a 50/50ish mix of 419 (where the freemail plugin could be useful) and links. Many are to staging posts like groups.yahoo.com and can be trivially wiped out with stuff like: header __HOTMAIL_SPX1 ALL =~ /Received\:.{1,30}hotmail\.com/i body __HOTMAIL_SPX2 /http\:\/\/groups\.yahoo\.com/ meta HOTMAIL_SPAM_GY (__HOTMAIL_SPX1 && __HOTMAIL_SPX2) score HOTMAIL_SPAM_GY 0.0 But where random, changing domain names are used this tactic will never work. You'll spend your life writing rules. It's not conceivable to block HOTMAIL as we have a generation of money spending customers who use it as their primary mail. It would result in a serious loss of genuine mail. So the vectors that can be used are very narrow. This brings me back to the X-Originating-IP: [x.x.x.x] header. We can't block this on a PBL, but we *can* on a REPUTATION based list like that offered by Barracuda. In fact one of those is catching on the BBL: [78.175.50.246 listed in b.barracudacentral.org] - but I can't say how long it's been on there - I've only checked it this morning. It would also be very useful to GEO check this IP as often it's from somewhere like Turkey, Brazil, China et al. It seems logical to extend the functionality of the Relay Countries plugin to look for this header - or add an 'originates from' section to it. I'm no developer so I can't say if this would be trivial - but I feel it would be a useful thing to do.