Well, it's no secret that spammers suck.

My old .Text blog is still up and running (because I've just been too busy to execute on a killer idea I have for content redirection - I'm thinking about doing it in a week or so as an Xml4Fun article)....

But while it's up, it's been getting OOOOOooodles of spam from some crap-head moron in Italy. (Nothing against Italians, it's just that spam in Italian really isn't that focused if you ask me). But, that's really let me set up kind of a 'honeypot' that's been getting hit with like 100 or so 'spams' per day. Very nice... especially as I've been able to analyze some of their 'attack' patterns.

So, I've been doing some thinking. And in another few weeks I'm going to add some more functionalilty to ReverseDOS. (I'll probably also add a way for people to sign up for notifications of future changes - just as a service, as I'm getting about 100 or so downloads of Rdos per month now... and I'd like to keep people 'in the know' if they want to be in the know.)

Some features:
1) I'm going to add an stroke of pure genius to the rules processing engine. No, the genius isn't mine, it's Phil Haack's. His idea? Simple: plunk an HttpContext.Current.User.IsAuthenticated in to the code before we start checking for spam. If the user is authenticated, then they're logged in as an admin, or a trusted user, etc... so if they happen to use the term Viagra... no worries (well, I guess it depends on how they refer to it - but let's say there's no worry with SPAM). 
Like I said: pure genius. (Much better than the lame thing I set up where a) you'd tell it what directories had authentication, b) just trust that authentication picked up the slack..)
I've already done some testing on this feature, and it just plain works. And it also looks like it adds absolutely no overhead (which makes sense: I'm not figuring out if the user is authenticated (that's already been done) - I'm just asking what the determination is).

2) I'm going to add some new.... verbs let's call them. They'll be combined with regexes defining paths that you either want to allow or limit certain types of activities on. (Think of it kindof as a 'firewall' for your site... if that makes any sense). 
Current ideas are: GET, POST, REFER, QUERY, and PROXY. These can then be used with bitflags in your config to either allow or deny specified 'verbs' to any pattern/path. So... you could deny POST, QUERY, and REFER to a certain directory, which would make it so that people could only GET from that directory. (That would immediately solve my problems with my Italian friend - who's posting all sorts of goofy content against a .Text comment submission form that isn't accepting comments.) 
I'm still trying to figure out if it would make sense to use these with 'spam' filters or just as directory paths... (comments welcome).

In addition to those changes, I'll also be looking at making a few other changes (such as trying to fit in some logic that will let Phil Haack and the SubText folks incorporate RDos directly into SubText (especially for 'multi-user' blogs)). I'll also try laying the foundation for a system that will let RDos users 'download' spam definitions from a central repository (I'm a bit worried about spammers finding that repository though... and using it to subvert everyone's filters... ), and I'll try making a few other changes that will make modifying filters and rules a bit easier.

Hopefully I'll get to that in a few weeks.

Then, after that, if I get enough feedback telling me that people thing it would be worthwhile, I may just end up open-sourcing the piglet completely...