Forum OpenACS Development: New Package: Spamassassin/TMDA Control Panel

I did some searches on openacs.org and found very few mentions on spamassassin (mostly in irclogs)

Has anyone already developed a Spamassassin or TMDA control panel package for OpenACS?

Spamassassin: http://www.spamassassin.org/
TMDA: http://www.tmda.net/

Collapse
Posted by Jade Rubick on
Chris, I've thought about using Gatekeeper to connect to tmda-cgi's apache based control panel. But it would be cool to have a TMDA control panel in OpenACS. That would rock!

The easiest way to do it would be via gatekeeper, though.

Collapse
Posted by Luigi Martini on
Jade, the nice system I experienced when writing to you on rubick.com, requiring to confirm the email in order to have it  accepted: how does it work?
Collapse
Posted by Chris Davies on
Based on Jade's prior comment, I can probably guarantee you that it is TMDA.  :)

TMDA can work on the machine that receives your mail, intercepts it and checks user-defined rules to see whether it should challenge the email.

You can do a number of things with it and your email like giving out email addresses with an expiration date, keyword emails, emails for particular senders.  You can then define the rules if someone hands out your email address from one of the above.

Combined with SpamAssassin, I have seen 2 spams in the last 72 hours (down from ~70/day) that have gotten through.  If I wasn't using TMDA as a backup to spamassassin, I would have never seen the spam.  I decided that if the spamassassin score was <1.0, I wouldn't pass it to TMDA -- which allowed two 0.0 spams to come through.  It also doesn't challenge people aggressively, because I personally find the system quite obnoxious.  For my setup, TMDA stopped 1 legitimate email (I don't know why they didn't reply -- perhaps they were confused, perhaps they were out of the office before the reply came back), allowed 1 to come through that did confirm, and stopped 2 payment receipts from our merchant bank and stopped the rest of the spam.  If I had let TMDA take over completely, I would still be writing rules  :)

You can define the challenge email message that gets sent to the sender, define incoming (and outgoing) filters to be applied to mail, and much more.  Most of the spam I receive came from 2 places -- 1, an innocent link on my personal home page, 2, bugs I filed with debian.org.

In both cases I could have used TMDA's disposable email addresses.  On the home page, since it is a mailto and quite likely to be an impulse thing, handing out an email that has expired already would require everyone to confirm.  You could be nice and offer up a mailto link that expired in 1 day, allowing the person clicking to send through, but the next time they would be challenged.

As for the bugs, I could have set an email address that expired in 15 days to allow the developers to contact me in regards to the bug without being challenged.  After 15 days, it would then challenge subscribers.

There are other ways to disguise mailto: urls and allow communication.  You could use javascript which the spambots don't currently decode.  You could use entities, which currently the spambots don't decode.  You could use a mailform (and there is a mailform package in contrib I believe), or you could roll your own using ad_form and acs-mail-lite.

There are many ways to use TMDA -- I just hope that it doesn't get abused too much.

Just think -- if you used a keyword email address for your login at sites like OpenACS.org, if you ever forgot your password, you'd probably be out of luck remembering what the email address was that you signed up with.  Then you have to sign up again.

A keyword address for openacs.org with TMDA might look something like:

mailto:username-keyword-openacs.bda9d0@domain.com

So, don't forget your username/password  :)

Collapse
Posted by Chris Davies on
I'm not sure what the right procedure is for announcing a package, but, here goes...

SpamAssassin Package for OpenACS.

SpamAssassin is a mail filter that tries to identify incoming messages and issue a score based on how likely it is that the message is spam.

This package attempts to make the task of tweaking the filters a little easier and was inspired from php-sa project (which appears to have vanished). The documentation inside shows how to set up SpamAssassin using PostgreSQL rather than using disk based preference files.

Screenshot 1: http://daviesinc.com/openacs/sa1.png
Screenshot 2: http://daviesinc.com/openacs/sa2.png

http://daviesinc.com/openacs/apm/spamassassin.apm

Collapse
Posted by Jade Rubick on
Chris, would you be willing to put this in /contrib in CVS on openacs.org?
Collapse
Posted by Brad Duell on
Thanks Chris!

BTW, I noticed that the /www/index.tcl file is referencing the sa_update_insert proc incorrectly (needs to be spamassassin::sa_update_insert and directly pass the -preference, -value, and -user_email flags).

Thanks again!

Collapse
Posted by Chris Davies on
Jade,

sure, I just put a new copy online with some fixes
http://daviesinc.com/openacs/apm/spamassassin.apm

Brad,

Those were fixed and I must have uploaded an older package.  That has been fixed.  Also, two more queries have been moved to the .xql that I missed in the first run-through.  Some fluff was removed from the testcases that is accomplished from the rollback.

So, try the above link -- it contains the fixes you mentioned as well as the changes above.