[Mimedefang] Re: Graphdefang graph order
I have the same graphdefang-config and index.pl files on 2 different machines. One puts it in the order that they are in the graphdefang-config and the other doesn't. HELP James Sorry about the last SUBJECT line... I hit send a tad too soon. I have always found that if I delete all of the png files in the output directory, and then run graphdefang, the graphs will be displayed in the same order as the config file. Regards, John ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Re: milter-greylist
To my inexperienced eye it seems extremely elegant/sensible to separate this functionality out of MimeDefang - gives MimeDefang less to do, simplifies filters, etc. Does anyone know better? The very first greylisting implementation that I used was milter-greylist, but I found that some virus senders were getting whitelisted because their traffic travelled through normal mail servers. This meant that future viruses from this same computer to the same recipient would go through without being greylisted. In the MimeDefang-based greylisting implementation that I use now (www.bl.org/~jpk/md-greylist), an IP number is removed from the whitelist if a spam or virus is received from it. This cut down on repeat virus traffic quite a bit. Regards, John ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Graphdefang + High CPU Load when processing
On Tue, 10 Aug 2004, Rich West wrote: Just curious, but what, exactly, does the --trim option do? The documentation states that it cuts out old data from the SummaryDB, but doesn't that defeat the purpose of graphdefang when looking for longer-term trends and such? You should use the --trim option regularly. When I added it to the code, it reduced the size of my DB by 10x. It deletes all of the detailed data that is for months previous to the current month. It keeps all of the summarized data, and it keeps all of the top 25 data per user per month and per day, but you no longer actually need the rest of the detailed line-item data in your DB. Regards, John ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Greylisting code, now with mysql Backend
The mysql version of the greylisting backend has been running fine overnight, so here is the new code: http://www.bl.org/~jpk/md-greylist/ Regards, John ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Greylisting code with SQLite Backend
Hi, all, I just converted my greylisting implementation to a SQLite backend. I created a web page with the code and basic install instructions: http://www.bl.org/~jpk/md-greylist/ My code is a derivation of work that was done by others in this mailing list... the most significant contribution here is the SQLite backend. It would be mostly trivial to go from this to a mysql or other DBD supported backend. Regards, John ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Greylisting code with SQLite Backend
Bummer... I hadn't noticed it before, but I had that in my maillog file, too. It turns out that the perl DBD libraries don't expose the API method to set the wait time for locks to expire, so if a lock is encountered an error is immediately returned. There are a couple of bugs logged against the DBD Sqlite module at CPAN to this effect. Potential solutions include using external file locking or switching to another database backend. I made the minor changes to get the thing to work under mysql, and I just restarted my mimedefang. I'll monitor its progress overnight, and if it looks good in the morning, I'll post the code changes. Thanks for finding this! It's a real bummer... there's even a patch on CPAN to fix the wait time issue in the DBD module, but it's not yet in the distribution. Best Regards, John Kirkland On Thu, 24 Jun 2004, Rob Ade wrote: Hi John, Thanks for the code. I am having some trouble with database locking. Have you experienced this? I am running RH 8.0 and Mimedefang 2.43 and SpamAssassin 2.63. I am also use DBI-1.42 and DBD-SQLite-0.31. This is the error message I am getting: Jun 24 21:20:36 mail mimedefang-multiplexor[29758]: Slave 0 stderr: DBD::SQLite::st execute failed: database is locked at /etc/mail/mimedefang-filter-greylist line 247. DBD::SQLite::st execute failed: database is locked at /etc/mail/mimedefang-filter-greylist line 246. Any help would be greatly appreciated and thanks for your time! Rob -Original Message- From: John Kirkland [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 11:41 AM To: [EMAIL PROTECTED] Subject: [Mimedefang] Greylisting code with SQLite Backend Hi, all, I just converted my greylisting implementation to a SQLite backend. I created a web page with the code and basic install instructions: http://www.bl.org/~jpk/md-greylist/ My code is a derivation of work that was done by others in this mailing list... the most significant contribution here is the SQLite backend. It would be mostly trivial to go from this to a mysql or other DBD supported backend. Regards, John ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang -- ___ MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang End of MIMEDefang Digest, Vol 9, Issue 52 * ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
