It's Pete McNeil's (from Message Sniffer). It's available on their website. It allows you to pass an incoming weight to the program and based on that, conditionally execute another program.
We use it with Declude to only run invURIBL when the message is within a certain weight range. That way we're not causing extra load for messages we know are good or bad, only the messages in the middle range that we're not sure of yet. I don't know if something like this can be used with MXGuard, but you might want to check out the Message Sniffer site and with MXGuard to see if it can be used to reduce CPU load for certain tests. Darin. ----- Original Message ----- From: Martin Schaible To: [email protected] Sent: Tuesday, March 13, 2007 12:19 PM Subject: AW: [IMail Forum] Mail-Server on heavy load Hi Darin, We're using mxGuard to check the several DNSLBL. All other tests are not in use. What is "WeightApp"? Mit freundlichen Grüssen ----------------------------------------------------------------------------------- Merlin Consulting | Martin Schaible Bahnhofstrasse 27 | CH-8702 Zollikon | Switzerland Tel.: +41 44 391 30 00 | Fax: +41 44 391 32 49 Mail: [EMAIL PROTECTED] | www.merlinconsulting.ch Support: support.merlinconsulting.ch GPS: N47 20.235 E8 34.226 ----------------------------------------------------------------------------------- News - Unsere Produkte: .:. Ipswitch Premium Partner .:. mxGuard/InvURIBL/MessageSniffer Antispam Lösung für IMail .:. Brainware Columbus Software Management .:. NOD32 Antivirus System .:. NewAtlanta BlueDragon .:. Kiwi Syslog Monitor .:. Paessler Network Monitoring .:. SmarterTools ----------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Darin Cox Gesendet: Dienstag, 13. März 2007 18:41 An: [email protected] Betreff: Re: [IMail Forum] Mail-Server on heavy load invURIBL can use a lot of CPU. Does MXGuard have a weighting scenario? If so, can you use Pete McNeil's WeightGate app with it? Doing so could save you from running invURIBL on messages you already know are going to be held/blocked/etc. Also, you might try running Sniffer in persistent mode. That could potentially save you a few cycles. Darin. ----- Original Message ----- From: Martin Schaible To: [email protected] Sent: Tuesday, March 13, 2007 11:16 AM Subject: AW: [IMail Forum] Mail-Server on heavy load Hi, Thanks for tips. We have Antivirus standard (Bitdefender), mxGuard with INVURI and MessageSniffer. I cleaned up rules.ima for old an unused rules. The file is now below 100k, before it was 160K. I heard, that a big rules.ima could be one reason for big cpu loads. I think, i see the result already, but it's 5pm here and the people are leaving their offices now, which reduces the load anyway. i will check if we have dead DNSBL and/or redundant DSNBL. I see the problem to trash all the incoming crap before it arrives the mail server. But my maybe naive question is: A mail server should be capable to handle all incoming mails by itself? I'm not talking about trillions messages per day, only 10000, which is not really a lot, i think. Or is this a problem related to IMail? Mit freundlichen Grüssen ----------------------------------------------------------------------------------- Merlin Consulting | Martin Schaible Bahnhofstrasse 27 | CH-8702 Zollikon | Switzerland Tel.: +41 44 391 30 00 | Fax: +41 44 391 32 49 Mail: [EMAIL PROTECTED] | www.merlinconsulting.ch Support: support.merlinconsulting.ch GPS: N47 20.235 E8 34.226 ----------------------------------------------------------------------------------- News - Unsere Produkte: .:. Ipswitch Premium Partner .:. mxGuard/InvURIBL/MessageSniffer Antispam Lösung für IMail .:. Brainware Columbus Software Management .:. NOD32 Antivirus System .:. NewAtlanta BlueDragon .:. Kiwi Syslog Monitor .:. Paessler Network Monitoring .:. SmarterTools ----------------------------------------------------------------------------------- ---------------------------------------------------------------------------- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Darin Cox Gesendet: Dienstag, 13. März 2007 17:27 An: [email protected] Betreff: Re: [IMail Forum] Mail-Server on heavy load Hi Martin, You should be well within the limits of a single server. What else do you have running in terms of spam and virus filtering? I would check for dead blacklists, which can delay mail processing and lead to overload, as well as check your average message processing time in the logs. Anything over two seconds per message with all spam and virus filtering would indicate a problem in your filtering configuration. Darin. ----- Original Message ----- From: Martin Schaible To: [email protected] Sent: Tuesday, March 13, 2007 9:25 AM Subject: [IMail Forum] Mail-Server on heavy load Hi, We have a Compaq DL-360 (2 x 1,33 Ghz, 2 GB RAM) which worked pretty good with about 120 Domains. 2 Weeks ago we added 99 Domains and since then, the server is in under heavy load. The Queue Manager needs more CPU power, more than expected. We have about 10000 Mails "local deliver" per day and 3500 "Remote Deliver per day. I'm in trouble to accept that 200 Domains are to much for this server. Any idea to fix this? Any finetuning which i can apply? Mit freundlichen Grüssen ----------------------------------------------------------------------------------- Merlin Consulting | Martin Schaible Bahnhofstrasse 27 | CH-8702 Zollikon | Switzerland Tel.: +41 44 391 30 00 | Fax: +41 44 391 32 49 Mail: [EMAIL PROTECTED] | www.merlinconsulting.ch Support: support.merlinconsulting.ch GPS: N47 20.235 E8 34.226 ----------------------------------------------------------------------------------- News - Unsere Produkte: .:. Ipswitch Premium Partner .:. mxGuard/InvURIBL/MessageSniffer Antispam Lösung für IMail .:. Brainware Columbus Software Management .:. NOD32 Antivirus System .:. NewAtlanta BlueDragon .:. Kiwi Syslog Monitor .:. Paessler Network Monitoring .:. SmarterTools -----------------------------------------------------------------------------------
