Des Berryman wrote:

ordb.org - they only list servers that technically fail anti-relaying measures.

Does it also cover open proxies? In my limited experience, that's where the majority of spam comes from today. relays.osirusoft.com lists proxies as well, there's of course the monkeys.org lists as well. As for TMDA, how useful is it for stopping dictionary attacks, and spammers just ignoring any 550 and blasting away at your mail server(s)? If TMDA sends out a confirmation request each time, it could easily become part of the problem, and not the solution. -- Juha

I agree with Juha. We are seeing more and more spam hitting the mail servers that is being relayed via open socks proxies. At this rate, I think its just going to be a matter of time before we're forced to block inbound connections on proxy ports. I've had good results with the Osirusoft RBL's - Joe combines the more commonly used ones. Be aware that you may need to whitelist some regions - keep any eye on your rejections. Spamcop seems to be fairly conservative in its listings. I'd disagree with Mike Beattie's comments - the rant on the link posted is just that, a misguided rant. I'm sure we're all aware of the additional workload created by UCE. Unfortunately, it would seem that at least one ISP (that of Mr. Felton) failed to perform due diligence. Gordon

Sorry, guess I wasn't clear on blocking open proxies. I was meaning that if the current trend of abusing open proxies continues, we'll end up denying any inbound traffic destined for customers on proxy ports. Those that don't will end up blocklisted as more and more people bounce spam off their customers. We've already started denying port 25 connections from DSL netblocks in parts of the U.S. We're returning a 553 with a message to relay through their ISP. It helps, but I don't think its an ideal solution. The lack of any form of redress against spammers doesn't help the issue either. Unfortunately, we end up carrying the traffic costs. Joe Jared's lists at relays.osirusoft.com do contain open proxies, but these aren't actively maintained. Once listed, the user must request re-testing before the block is removed. Re-tests are not automatic. The biggest problem, especially with DSL, is those users on dynamic addresses and running open proxies. In that case, the only solution is to block the entire range. Given the wide range of client software used, I don't think there's any easy answer to this issue. If the SMTP protocol is re-written to enhance security and accountability for traffic, the negative effects on legacy systems would be huge. Attacking the problem at the client end would pose similar problems. Spamassassin still looks to be one of the best options at this stage. Gordon

Simon Byrnand wrote:

The days of straight RBL based connection rejection for spam filtering are over IMHO, spammers are just too clever now and have too many different methods of attack.

I think that was part of the rationale for SPEWS. They know it's impossible to react quickly enough to stop the spam flooding from relays and proxies, so they block the spam sources instead, with a fair bit of collateral damage (that's the nuts ;-)) so that the ISP takes notice. Lots of people disagree with SPEWS, but it does seem to work to some extent. -- Juha

On Fri, 28 Feb 2003, Mike Beattie wrote:

Mike Beattie ZL4TXK, IRLP Node 6184

Be warned, I might call you on that tonight. :-) Ive got no idea what our local node number is though.. In terms of spam, ive adopted essentially the same policy as Nathan Ward pointed out, which has been useful so far - except for the completely noncooperative nature of the one network I can positively identify as having sold an address on my domain in their spamlist... So the second part of my personal system is to actively do the following: 1) Watch my web server logs for crawlers from 'dodgy' networks. (read: *.cn, *.kr, *.br etc) 2) Firewall said networks from my MTA/Webserver (same box) entirely 3) Look up individual spam source IPs with whois, send abuse complaints in the first instance.. 4) Block spamming MTA (smtp only) in the second instance. 5) skip step 3 where source IP is *.cn. *.kr, *.br, or where spam type is persistant. The amount of spam ive dealt with of late has dropped significantly as a result of the above. Essentially what ive done is built my own RBL, because at least this way im personally responsible for what gets blocked and what is permitted, and not at the whim of some 3rd party block list... And personally while I see TMDA as quite effective, I also see it as a serious inconvenience. Mark.

My personal approach is this: *@daork.net by default goes to me. I sign up for something, say CCO, with CCO(a)daork.net. If someone spams me with that address, I then can go and retaliate against the organisation who sold my 'E-Mail address', dependant on how motivated/bored I feel, and that address then goes to /dev/null. Same goes for mailing lists. I sub to nznog with say nznog(a)daork.net, it gets spammed, deleted and resubbed as nznog1(a)daork.net. Or when I give my E-Mail address out to people, I say they must use <thiername>@daork.net, so if they CC me in the hope that it will give the small goat in western Alaska new horns, and I get spammed to that address, I can delete it too (after notifying the person of course). This way I know who sold/leaked my address, I don't let the spammer know that there is someone listening on the other end, and if say, a big corporation were to spam me after saying in some privacy statement that they won't, I can apply lawyer technology and get some free $. Maybe. At work I have just one E-Mail address which get spammed all the time, though this could work just as well there with nward-*@esphion.com. Which is something I really should get around to doing. Nathan Ward Dean Pemberton wrote:

It's a little off topic, and not really suitable for deployment on an isp central mail server, but..

I think I've 100% solved my personal spam problem. I 0wn it, it is my b***h =)

Tune out now if you don't care, read on if you want to know how.

I've been using TMDA for about a year now, and I recently added Spam Assassin to that.

The first piece of spam that made it through this system arrived today. Thats out of about 4000 bits of spam. The only reason that made it through was that the spammer actually replied to the confirmation email that TMDA sends back (I'll get him later).

TMDA works like a treat. You have to make the decision that you're willing to inconvienience people who mail you the first time (with a confirmation process). Out of the 294 people on my whitelist I've only had two complain. And both of them thought it was a better idea after I phoned/had beer with them. I worry that some people will not respond nor complain, but a quick check of unconfirmed messages shows me that this is not the case. Even my grandmother managed to work it out. This will not be appropriate for you work email account however. Telling customers to prove who they are is never good. I also have email aliases which mypass some or all of my spam system. eg if I know someone is going to hate being annoyed then they might get blah(a)deanpemberton.com which has no checking on it.

The downside to TMDA is that it tries to send a confirmation email for each suspect email that it receives. The postmaster for the box where I have this set up had a bit of a whinge that this was causing too much postmaster mail (because most of them will die because they are sent to bogus spam addresses). His solution to this was to front end the system with Spam Assassin.

I was pretty dubious at first. The reason I had gone with TMDA was that I never wanted to miss a real message. I didn't think that packages like SA did a very good job.

I'm happy to say that I've been proved 100% wrong. SA sits at the front and looks at the messages - if it thinks it's spam then it tags it with why and places it in my Spam folder (which I think I'd check once a day when I'm bored). I think it has tagged real mail as spam once and that was because a friend forwarded me some spam.

If the message makes it through SA, and about 10% of spam does, then TMDA gets it and sends off a confirmation email if the address is not in it's whitelist.

This is so effective that as I say only one piece of spam in the last 4000 has made it to my inbox. And that needed to a) not look like spam to SA, and b) have the spammer give his real address and then take the time to reply to a confirmation message from me. Quite rare eh.

SA is doing such a good job that I've started to apply some statistical modeling to how it ranks my spam. It fits a weibul distribution almost perfectly and I plan to use this to tune the parameters so that I can prove that it's catching the maximum amount of spam while minimising the risk of it tagging real mail. The graphs look pretty =)

So this double approach really works for me.

If you want to know anything else then just mail me offline. If you want to see it in action (TMDA that is) then mail me offline =)

Here are some links

http://tmda.net/ http://spamassassin.org/

Later

Dean

On Fri, Feb 28, 2003 at 07:49:41AM +1300, Craig Whitmore wrote:

...

As the amount of spam grows as the internet grows bigger, using RBL's is growing as well (to try and stop/slow the spam).

I am wondering what RBL's other ISP's/Companies in NZ Use?

There are quite a number (of RBL's) but a few can't be used as they still have Xtra's Network in them (for "Sueing ORBS" they say), but the best I've found so far has been http://relays.osirusoft.com.

Can anyone suggest a better one/comments/pitfalls on using RBL's for slowing down spam.

Thanks Craig Whitmore Orcon Internet http://www.nzdsl.co.nz

_______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

A lot of lists do, for example everything at lists.debian.org goes through SpamAssasin. On Fri, 2003-02-28 at 10:51, Dean Pemberton wrote:

Juniper does. tags subject lines with ****SPAM**** and then delivers.

Seems to work really well.

Dean

On Fri, Feb 28, 2003 at 10:48:47AM +1300, Don Stokes wrote:

...

Further to this, is anyone using SpamAssassin for large-ish scale filtering? With RBLs or without? Or anything else?

-- don

"Craig Whitmore" wrote:

...

As the amount of spam grows as the internet grows bigger, using RBL's is growing as well (to try and stop/slow the spam).

I am wondering what RBL's other ISP's/Companies in NZ Use?

There are quite a number (of RBL's) but a few can't be used as they still have Xtra's Network in them (for "Sueing ORBS" they say), but the best I've found so far has been http://relays.osirusoft.com.

Can anyone suggest a better one/comments/pitfalls on using RBL's for slowing down spam.

Thanks Craig Whitmore Orcon Internet http://www.nzdsl.co.nz

_______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

---

Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- James Tyson

We have tested mimedefang, a milter filter for sendmail (which has DCC/Razor/Spamassassin/Anti Virus plugins etc) and it works really well finding most Spam (TAG's info in the header). Scales very well for usage. Alot more customiseable/less load than alot of commercial packages out there at the moment and all open source software. Thanks Craig ----- Original Message ----- From: "Gordon Smith" To: "'NZNOG'" Sent: Friday, February 28, 2003 11:01 AM Subject: RE: [nznog] RBL's used

It is possible to set SpamAssassin up so that users can control their own spam filters. This does require a reasonable amount of coding to get it to work.

I believe that Steve Phillips was working on something like this a while ago. Getting something like that working in conjunction with RBL queries on a per-user level would be great for allowing the customers more control over their mailbox.

At 11:19 28/02/03 +1300, Dean Pemberton wrote:

What do people think of Razor?

I've had times when it's just a pain in the arse (blank messages get tagged, as to messages with a single 'test' in them).

It adds to network traffic if you have alot of email too. I'm looking at my spam and seeing if SA would have caught the spam anyway. If thats the case then Razor is pretty useless. Nice idea though

Yeah, nice idea, but it doesn't seem to work as well as it could. The extra latency doing the network checks can be a problem, and I noticed an unacceptable number of false positives, even with the "confidence level" in razor2 set to 100%. A bit of discussion on the SA mailing list suggests that the problem is a combination of people overzelously reporting non-spam as spam (or using auto-reporters) and bugs in the code that would falsely match messages it shouldn't. Definately not reliable enough for any kind of sitewide system. Regards, Simon

At 11:27 28/02/03 +1300, Russell Fulton wrote:

On Fri, 2003-02-28 at 11:01, Gordon Smith wrote:

...

It is possible to set SpamAssassin up so that users can control their own spam filters. This does require a reasonable amount of coding to get it to work.

I believe that Steve Phillips was working on something like this a while ago. Getting something like that working in conjunction with RBL queries on a per-user level would be great for allowing the customers more control over their mailbox.

This isn't really feasible since the whole point of the RBL is that you dump the session before it sends anything so you don't know who its for.

And thats one of the big problems with plain RBL checks. I suspect whats being refered to here, is the fact that Spamassassin queries several RBL lists as part of its testing. However rather than a match causing the mail session to be rejected before you even know who a message is from or to, matches in various RBL lists add "points" to the spam score towards indicating the message is spam. With enough corroboration the message is regarded as spam. The RBL checks in Spamassassin are a useful part of the set of tests it performs, and like all other spamassassin rules, can be per-user customized. Regards, Simon

On Fri, 28 Feb 2003, Simon Lyall wrote:

I was thinking about doing a talk about this at nznog this year if enough peoiple are interested.

Yip yip! I'd come and egg you ... on I mean. Especially if you were to include a section on defensive strategies against large dictionary attacks and similar abuses. -- Juha Saarinen