For the past several weeks, our ESA Sink has been clogging up once in a while. This is because spamc.exe, the SpamAssassin client program spawned by ESA, simply hung (probably due to a particularly large email).
I was thinking of rewriting spamc using Uwe Keim's ZetaSpamAssassin Wrapper, but that's probably a weekend type of project that I might entertain in the future. In the mean time, I wrote this simple little Windows service that occasionally checks and reaps stale spamc.exe processes, allowing the filter to continue. Source code (C#) and binary are available here.
Showing posts with label SpamAssassin. Show all posts
Showing posts with label SpamAssassin. Show all posts
spamc.exe hangs
Posted by
Thanh Hai Tran
on Thursday, June 12, 2008
/
Labels:
admin,
csharp,
IT,
SpamAssassin
/
Comments: (0)
AppConnector Cookbook: A Spam Flood Notifier
Posted by
Thanh Hai Tran
on Wednesday, December 07, 2005
/
Labels:
AppConnector,
SpamAssassin
/
Comments: (2)
End-user Problem Statement:
You're an IT Director. Your mail server runs on Windows 2000 and uses a directory to queue incoming messages. You want to be notified as soon as this queue becomes heavily loaded, by excessive spamming for instance, so that you can take the appropriate action in time to avoid mail delays for your users.
Motivation:
I'm that "IT Director"! 8-|
I got up this morning and found that my mail server has been so heavily bombarded by excessive spams for the last 12 hours that our SpamAssassin filter was fuming, and there were in excess of 2000 messages stuck in the queue, and the number was rising. All hell broke loose! It took me three hours to stabilize the spam filter and clear out the message queue.
A couple times a year, we tend to run into little fiascos like these. Alas, with each problem comes opportunity.
Techie Translation of Problem Statement:
Need a utility that lets grumpie here monitor a directory for changes, and it should email him when a directory content has exceeded a certain maximum number of files (say 1000).
Solution:
I don't know if Windoze server provides any built-in way to do what's required, but as the old adage goes: Stick with what you know. So here goes...
Use AppConnector with the following recipe:
Ingredients:
- 1 Default Adapter
- 1 File Monitor event
- 1 Script task, with 1 input parameter
- 1 Mail Task
- some angel dust
Instructions:
Test well before serving.
You're an IT Director. Your mail server runs on Windows 2000 and uses a directory to queue incoming messages. You want to be notified as soon as this queue becomes heavily loaded, by excessive spamming for instance, so that you can take the appropriate action in time to avoid mail delays for your users.
Motivation:
I'm that "IT Director"! 8-|
I got up this morning and found that my mail server has been so heavily bombarded by excessive spams for the last 12 hours that our SpamAssassin filter was fuming, and there were in excess of 2000 messages stuck in the queue, and the number was rising. All hell broke loose! It took me three hours to stabilize the spam filter and clear out the message queue.
A couple times a year, we tend to run into little fiascos like these. Alas, with each problem comes opportunity.
Techie Translation of Problem Statement:
Need a utility that lets grumpie here monitor a directory for changes, and it should email him when a directory content has exceeded a certain maximum number of files (say 1000).
Solution:
I don't know if Windoze server provides any built-in way to do what's required, but as the old adage goes: Stick with what you know. So here goes...
Use AppConnector with the following recipe:
Ingredients:
- 1 Default Adapter
- 1 File Monitor event
- 1 Script task, with 1 input parameter
- 1 Mail Task
- some angel dust
Instructions:
- Start warming an empty KAP in 23C temperature environment for comfort
- Add new application using Default Adapter
- Add Script Task, sprinkle in 1 input parameter for flavour.
- Add File Monitor event, set monitored directory to be the mail queue directory, notification type to ONLY ADDED FILES, and let it simmer.
- Back to Script task, add a couple of lines of script to check number of files in the the directory. Set script so that if this number is below the set limit, it should FAIL. Otherwise, it should SUCCEED, to allow the successor task to run.
- Add Mail task as a successor of Script task. Configure it to send email to IT director with an appropriate message body. Sprinkle in some angel dust for taste and stir well.
Test well before serving.
SpamAssassin kills spam dead on its track!
Got the new spam filter for our Microsoft Exchange server up and running in the office network for a few weeks now, and I'm totally thrilled as to how well it works straight out-of-the-box, so to speak. SpamAssassin is another testament to the power of free and open source software development.
There are a couple of available SpamAssassin plugins for Exchange Server, but I used Christoper Lewis'
Exchange SpamAssassin SMTP Sink (Thanks, Christopher!) since it worked best for me. Initiallly, I installed SpamAssassin on the same server as the Exchange Server, but soon found that Perl's performance on Windows platform was really bad. Some of our incoming emails eventually arrived at their recipient's inbox six, eight hours late. So I switched to running it (spamd) on a Linux server, and then made the Exchange sink connect remotely to the SpamAssassin daemon. It seems sort of counter-intuitive, doesn't it, when you first think about it, but the performance is much, much better this way. Perl likes being run on Linux better than on Windows.
So far, the spam filter has caught about 99% of the spams that have come through our server. That's an acceptable success rate--And no false positives, unlike the spam filter that we've tried previously. The installation was relatively straight-forward, a credit to the documentation. I also like the fact that in addition to the usual DNS black list lookup approach, which other typical spam filters use, SpamAssassin's Bayesian filter weeds out spam contents quite well. That's smart stuff! And that's with me barely scratching the surface of functionalities after a couple of days of playing with it, without training the filter whatsoever.
Who would have thought ten, fifteen years ago that spam e-mails would become such a big problem to our corporate netizens. They are a complete waste of bandwidth, not to mention a waste of every body's time spent in deleting them. But thanks to great open source tools like SpamAssassin, coupled with strong legislation from our law makers, we'll soon put an end to this net parasite yet.
There are a couple of available SpamAssassin plugins for Exchange Server, but I used Christoper Lewis'
Exchange SpamAssassin SMTP Sink (Thanks, Christopher!) since it worked best for me. Initiallly, I installed SpamAssassin on the same server as the Exchange Server, but soon found that Perl's performance on Windows platform was really bad. Some of our incoming emails eventually arrived at their recipient's inbox six, eight hours late. So I switched to running it (spamd) on a Linux server, and then made the Exchange sink connect remotely to the SpamAssassin daemon. It seems sort of counter-intuitive, doesn't it, when you first think about it, but the performance is much, much better this way. Perl likes being run on Linux better than on Windows.
So far, the spam filter has caught about 99% of the spams that have come through our server. That's an acceptable success rate--And no false positives, unlike the spam filter that we've tried previously. The installation was relatively straight-forward, a credit to the documentation. I also like the fact that in addition to the usual DNS black list lookup approach, which other typical spam filters use, SpamAssassin's Bayesian filter weeds out spam contents quite well. That's smart stuff! And that's with me barely scratching the surface of functionalities after a couple of days of playing with it, without training the filter whatsoever.
Who would have thought ten, fifteen years ago that spam e-mails would become such a big problem to our corporate netizens. They are a complete waste of bandwidth, not to mention a waste of every body's time spent in deleting them. But thanks to great open source tools like SpamAssassin, coupled with strong legislation from our law makers, we'll soon put an end to this net parasite yet.