I put an alligate server in front of Declude. It kills about 95% of incoming connections. Declude Intercepter incorporates this Sent via BlackBerry by AT&T
-----Original Message----- From: "Michael Cummins" <mich...@i-magery.com> Date: Wed, 12 May 2010 09:25:57 To: <declude.junkmail@declude.com> Subject: [Declude.JunkMail] Fine tuning Declude So this past week has been fairly hellish for me, buried in the thick of Botnet Spam storms. (Quite a number of people seem to be experiencing them, at least as reported over on the [SNIFFER] list) My implementation of Declude seems to be pressed to its limits to handle the volume. 1) Dedicated SmarterMail 6.8 2) Declude, Invaluement RBLs added, running off a SimpleDNSPlus install on another local machine 3) INVURIBL with Invaluement and SpamEatingMonkey added 4) SNIFFER, integrated with Declude This is the root of my volume issues: this box is a dedicated Incoming Gateway for several dozen Exchange servers for SMBs, which means it accepts ALL mail for those domains. It's not like my other mail server that rejects bad addresses right off the bat. When the spam storms hit, it's like a hurricane. My usual Sniffer-measured rate of about 150-200k messages per day kick up as high as 850k. I don't really handle that much mail, but that's the rate when it storms. My regular SmarterMail server that dishes out POP/IMAP handles a more appropriate level of 50k messages per day. 1) If I keep WAITBETWEENTHREADS too low, DecludeProc will race up to the top of THREADS and crash when the storms hit. I currently find that 45 is the bleeding edge of sanity (for my config) with INVURIBL and SNIFFER running, but in a bad storm, even that is too low, and sometimes I have to drop it back to 60 or 65; but then it's just keeping up with things, and it's difficult to reduce the backlog that swelled during the crash. 2) If I keep WAITBETWEENTHREADS too high, like around 100, Declude is stable as a rock, but can't keep up with the mail load when times get tough. 3) When things get bad, I go into GLOBAL.CFG and comment out INVURIBL and/or the many SNIFFER tests. Does anyone have any useful advice for beefing up or streamlining this process? What hardware choices have the biggest impact on Declude? As an aside, I imagine that you could prevent a lot of Declude crashes if WAITBETWEENTRHEADS was a dynamic setting, derived from the mail rate. Yes? No? On a related note, I've been building a Declude Management interface in ColdFusion that makes excellent use of Mark Russinovich's Sysinternals suite of tools, most specifically PsList and PsKill, so I can keep a careful eye on DecludeProc on my two machines, and using the Microsoft FSO to keep an eye on file counts. Sysinternals http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx FSO http://msdn.microsoft.com/en-us/library/z9ty6h50(VS.85).aspx I really recommend those tools. FSO is really responsive when inspecting large file counts, for keeping an eye on /spool/ /proc/ and /review/. You can write a parse the results of PsList to keep an eye on the number of Threads that Declude is spawning, and even detect a crash. Oh, and I have to compliment Linda and David for their relentless and professional service. They are a fantastic and responsive team. BZ! -- Michael Cummins --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
