Hi,
for those that don't use SpamAssassin and would like to make SURBL checks on their mail, I've adapted Devin Carraway's plugin to qpsmtp, making a daemon that is independent, forking itself as needed. I believe it performs well, even on high traffic mail.
Its simple usage interface, that was made with amavisd antivirus code in mind, is possibly usable by other services. Whenever a mail comes, one should connect to it and order it to scan the dir or file that message is on.
# telnet 127.0.0.1 20098 SCAN /tmp/ Scanning /tmp/ Checking /tmp/filex8QBXY Checking /tmp/ldap18775 OK. OK Connection closed by foreign host. #
# echo 'http://123getnow.com' > /tmp/a
# telnet 127.0.0.1 20098 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. SCAN /tmp/ Scanning /tmp/ Checking /tmp/a
SPAMMEDURL: 123getnow.com in surblgoiano.com.br (SPAMMER 123getnow.com) Action: deny DENY Connection closed by foreign host. #
Just check for "DENY" or "OK" and you're done. In this example, "surblgoiano.com.br" is my local RBL zone for bad URIs.
It's easy to plug it into amavis:
/etc/amavisd.conf: @av_scanners : (...) ['Suri', &ask_daemon, ["SCAN {}/../email.txt\n", '127.0.0.1:20098'], qr/^OK/, qr/^DENY/, qr/^SPAMMEDURL:.*[(](.+)[)]/], (...)
The important part there is:
SCAN {}/../email.txt
As you can see, there is a problem here. In this case, all messages with a spamvertised URI will be considered a virus, and actions will be taken aproprietely as per amavis config. In this case, I'd recommend using initially a non-deny "$action" setting, for seeing any potential problems in the logs (syslog) before really applying this "dangerous" policy. In any case, it is very recommended too that you quarantine these "infected" messages.
This is a perl beginner's work, so please excuse any mistakes. It was made to fit my needs, as I maintain my own suribl zone, which is small, yet made for as little false positives as possible and with a special attention to brazilian domains. I haven't tested it with SURBL.org zones, yet.
I am also making a transparent SMTP proxy for using with Postfix in servers with low traffic and/or running a local RBL daemon (rbldnsd). It would prevent losing e-mail. Any potential false positive would be notified by the SMTP reject code after the end of the DATA command block. Do you think it could be useful?
You can get this plugin, that I called SURI, at http://i-admin.blogspot.com . I'd appreciate any comments very much. It's my first free software ever relased :-P
Yves Junqueira wrote:
I am also making a transparent SMTP proxy for using with Postfix in servers with low traffic and/or running a local RBL daemon (rbldnsd). It would prevent losing e-mail. Any potential false positive would be notified by the SMTP reject code after the end of the DATA command block. Do you think it could be useful?
Hi Yves!
I'd be a good potential victim for this. Running rbldnsd and postfix.
Let me know if you need any testing
thanks
Alex
On Thursday, September 23, 2004, 7:54:45 AM, Yves Junqueira wrote:
for those that don't use SpamAssassin and would like to make SURBL checks on their mail, I've adapted Devin Carraway's plugin to qpsmtp, making a daemon that is independent, forking itself as needed. I believe it performs well, even on high traffic mail.
Its simple usage interface, that was made with amavisd antivirus code in mind, is possibly usable by other services. Whenever a mail comes, one should connect to it and order it to scan the dir or file that message is on.
[...]
I am also making a transparent SMTP proxy for using with Postfix in servers with low traffic and/or running a local RBL daemon (rbldnsd). It would prevent losing e-mail. Any potential false positive would be notified by the SMTP reject code after the end of the DATA command block. Do you think it could be useful?
You can get this plugin, that I called SURI, at http://i-admin.blogspot.com . I'd appreciate any comments very much. It's my first free software ever relased :-P
It's definitely interesting to see new implementations of SURBL checking, and it could perhaps be useful to other applications even if it's perhaps not a perfect fit for amavisd.
Do you mind if I link to it and also announce it? Perhaps it can be useful to other folks.
Cheers,
Jeff C. -- "If it appears in hams, don't list it."
On Thu, 23 Sep 2004 21:23:38 -0700, Jeff Chan jeffc@surbl.org wrote:
It's definitely interesting to see new implementations of SURBL checking, and it could perhaps be useful to other applications even if it's perhaps not a perfect fit for amavisd.
Do you mind if I link to it and also announce it? Perhaps it can be useful to other folks.
I'd be happy if you linked and announce it.
I agree it's not a perfect fit for amavisd. I'd be curious, though, to hear if anyone else find any other use for it.
Maybe you'd want to use the permanent URL to link to that:
http://i-admin.blogspot.com/2004/09/suri-spamvertised-uris-filter-using.html
A blog is not an apropriate place to host a software, sorry about that.