[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.
Re: [Declude.JunkMail] Fine tuning Declude
I put an alligate server in front of Declude. It kills about 95% of incoming connections. Declude Intercepter incorporates this Sent via BlackBerry by ATT -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.
RE: [Declude.JunkMail] Fine tuning Declude
I solved the load issue by putting Alligate in front of the mail server. I put it in the same server and can handle everything coming at it much better than before. Alligate gets rid of the obvious spam, about 90 %, before it hits my mail software Thank you Please note our new Address Harry Vanderzand Intown Internet 740 Erbsville Road Waterloo, On, N2J 3Z4 519-741-1222 DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying,or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: May-12-10 9:26 AM 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.
RE: [Declude.JunkMail] Fine tuning Declude
I actually paid for Alligate a couple of years ago, but then had to repurpose the hardware for a casualty before I could install it and trial it. I never got around to putting it together after that (I'm not a big company, and I don't have a huge budget). It expired, and now every year Alligate contacts me asking me if I want to renew, and I write them back asking them if I simply lost my money, and they never respond again until the following year. It's like a bad game now. I don't have a lot of confidence in them. Which is sad. I hear it's a fine product. -- Michael Cummins From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Scott Fisher Sent: Wednesday, May 12, 2010 9:54 AM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] Fine tuning Declude I put an alligate server in front of Declude. It kills about 95% of incoming connections. Declude Intercepter incorporates this Sent via BlackBerry by ATT _ From: Michael Cummins mich...@i-magery.com Date: Wed, 12 May 2010 09:25:57 -0400 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. --- 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.
RE: [Declude.JunkMail] Fine tuning Declude
Hi Michael, I guess this is best said - let it go,,,Alligate is the the way to go in front of Declude - Contact them again - they probaby will be glad to set you up with at trial even of some sort, -Nick MadRiverAccess.com|Skywaves.com Tech Support US/Canada 877-873-6482 or International +1-802-229-6574 Emergency Support 24/7: supp...@skywaves.net General and Non-Emergency support ticket: https://www.skywaves.com/content/secure/support_ticket.htm From: Michael Cummins mich...@i-magery.com Sent: Wednesday, May 12, 2010 10:25 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude I actually paid for Alligate a couple of years ago, but then had to repurpose the hardware for a casualty before I could install it and trial it. I never got around to putting it together after that (I'm not a big company, and I don't have a huge budget). It expired, and now every year Alligate contacts me asking me if I want to renew, and I write them back asking them if I simply lost my money, and they never respond again until the following year. It's like a bad game now. I don't have a lot of confidence in them. Which is sad. I hear it's a fine product. -- Michael Cummins From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Scott Fisher Sent: Wednesday, May 12, 2010 9:54 AM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] Fine tuning Declude I put an alligate server in front of Declude. It kills about 95% of incoming connections. Declude Intercepter incorporates this Sent via BlackBerry by ATT From: Michael Cummins mich...@i-magery.com Date: Wed, 12 May 2010 09:25:57 -0400 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
Re: [Declude.JunkMail] Fine tuning Declude
Hardware reqs for alligate are fairly low too Sent via BlackBerry by ATT -Original Message- From: Michael Cummins mich...@i-magery.com Date: Wed, 12 May 2010 10:17:13 To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude I actually paid for Alligate a couple of years ago, but then had to repurpose the hardware for a casualty before I could install it and trial it. I never got around to putting it together after that (I'm not a big company, and I don't have a huge budget). It expired, and now every year Alligate contacts me asking me if I want to renew, and I write them back asking them if I simply lost my money, and they never respond again until the following year. It's like a bad game now. I don't have a lot of confidence in them. Which is sad. I hear it's a fine product. -- Michael Cummins From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Scott Fisher Sent: Wednesday, May 12, 2010 9:54 AM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] Fine tuning Declude I put an alligate server in front of Declude. It kills about 95% of incoming connections. Declude Intercepter incorporates this Sent via BlackBerry by ATT _ From: Michael Cummins mich...@i-magery.com Date: Wed, 12 May 2010 09:25:57 -0400 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. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe,
Re: [Declude.JunkMail] Fine tuning Declude
Hi Michael, I may be able to help with this. You mention doing gateway filtering for Exchange servers. We also do that, but instead of accepting any address with the domain, we have accounts set up on our server and refuse connections that don't go to one of those accounts. Now your next comment is probably that you don't want the extra management of setting up accounts on both servers. Well we've handled that by using a sync process we developed to extract the list of accounts from the Exchange server, ship that up to the gateway server, and check to see what accounts need to be added or deleted. We've been using this process for a couple of years with perfect success. Since it is a batch process, it is scheduled to run every few minutes, so there could be a few minute delay when new accounts are added, but it has worked flawlessly for a couple of years. There are checks in place to make sure incomplete transfers don't result in accounts being deleted or incorrect accounts getting added to the gateway, and notifications are sent every time accounts are added or deleted. Currently it runs as a script on the destination Exchange or IMail server, and a scheduled process on a SQL database on our mail gateway server. Also, our gateway is an IMail server, but we could easily adapt it to use the account creation command line utilities I assume SmarterMail has. One other comment about the implementation. We maintain a hosts file for forwarding to the destination mail server, and use a subdomain to forward the mail for routing purposes, so the destination mail server is configured to accept mail for the subdomain. That's a simple change in Exchange to add an SMTP alias, and can be added to the default policy in Exchange so it is automatically added when an account is created. Anyway, if you have any interest, let me know. I know we wouldn't be able to survive if we were accepting email for any address in a domain, so I feel your pain. Best, Darin Cox 4C Web A division of 4C Design Technology Corp. (813) 413-4883 Tampa Bay, FL (919) 533-5000 Research Triangle, NC - Original Message - From: Michael Cummins To: declude.junkmail@declude.com Sent: Wednesday, May 12, 2010 9:25 AM 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
Re: [Declude.JunkMail] Fine tuning Declude
Sorry guys, I meant to send this directly to Michael. Got distracted with other email and phone calls, and didn't check the address before sending. My apologies. Darin. - Original Message - From: Darin Cox To: declude.junkmail@declude.com Sent: Wednesday, May 12, 2010 10:55 AM Subject: Re: [Declude.JunkMail] Fine tuning Declude Hi Michael, I may be able to help with this. You mention doing gateway filtering for Exchange servers. We also do that, but instead of accepting any address with the domain, we have accounts set up on our server and refuse connections that don't go to one of those accounts. Now your next comment is probably that you don't want the extra management of setting up accounts on both servers. Well we've handled that by using a sync process we developed to extract the list of accounts from the Exchange server, ship that up to the gateway server, and check to see what accounts need to be added or deleted. We've been using this process for a couple of years with perfect success. Since it is a batch process, it is scheduled to run every few minutes, so there could be a few minute delay when new accounts are added, but it has worked flawlessly for a couple of years. There are checks in place to make sure incomplete transfers don't result in accounts being deleted or incorrect accounts getting added to the gateway, and notifications are sent every time accounts are added or deleted. Currently it runs as a script on the destination Exchange or IMail server, and a scheduled process on a SQL database on our mail gateway server. Also, our gateway is an IMail server, but we could easily adapt it to use the account creation command line utilities I assume SmarterMail has. One other comment about the implementation. We maintain a hosts file for forwarding to the destination mail server, and use a subdomain to forward the mail for routing purposes, so the destination mail server is configured to accept mail for the subdomain. That's a simple change in Exchange to add an SMTP alias, and can be added to the default policy in Exchange so it is automatically added when an account is created. Anyway, if you have any interest, let me know. I know we wouldn't be able to survive if we were accepting email for any address in a domain, so I feel your pain. Best, Darin Cox 4C Web A division of 4C Design Technology Corp. (813) 413-4883 Tampa Bay, FL (919) 533-5000 Research Triangle, NC - Original Message - From: Michael Cummins To: declude.junkmail@declude.com Sent: Wednesday, May 12, 2010 9:25 AM 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
RE: [Declude.JunkMail] Fine tuning Declude
I wrote a batch file once on a number of the exchange servers that used VBS and LDAP to generate a list of valid exchange recipients and then FTP them to the server where a CF script parsed it clean. Michael, it sounds like you were most of the way there. Alligate does have the feature you were working towards, which was a recipient file for a given domain, the magic phrase being the rvInput folder. I don't use it, but the rough idea is that you periodically drop in a plain text file, say, per domain, in that folder and an Alligate process picks them up. Another one of the problems is that most all of my clients don't want to disable NDRs with whatever solution I come up with, which makes it fairly impossible to avoid backscatter. This lets your gateway accept only email for valid recipients and reject mail during the envelope conversation, thus you are not generating spam backscatter and you are emitting valid NDRs only (when the bad guys spoof a MAILFROM and you accept a message because your gateway can't validate the recipient yet, then later bounce the message as undeliverable, your backscatter spams the spoofed sender). Darin's earlier message describes a way to accomplish the same thing via IMail and aliases; I believe this method was pioneered by Sandy (Sanford Whiteman) back in 2004 and the thread can be picked up here: http://www.mail-archive.com/search?q=Exchange2aliasesl=declude.junkmail %40declude.com The trouble for you is that this is an even more significant implementation for your clients than your scraping of their AD. Andrew. From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: Wednesday, May 12, 2010 11:14 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude I wrote a batch file once on a number of the exchange servers that used VBS and LDAP to generate a list of valid exchange recipients and then FTP them to the server where a CF script parsed it clean. I didn't quite know what to do with them when they got there though (I was originally going to use them in Alligate, but never got that up and going) and I don't have the full granular cooperation of all the Exchange network peeps, only most of them, so it was difficult to implement a one-size-fits-all policy regardless. I'll put my thinking cap on. Another one of the problems is that most all of my clients don't want to disable NDRs with whatever solution I come up with, which makes it fairly impossible to avoid backscatter. It goes in me one way, and out another :p Very Respectfully, Michael Cummins From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Darin Cox Sent: Wednesday, May 12, 2010 10:55 AM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] Fine tuning Declude Hi Michael, I may be able to help with this. You mention doing gateway filtering for Exchange servers. We also do that, but instead of accepting any address with the domain, we have accounts set up on our server and refuse connections that don't go to one of those accounts. Now your next comment is probably that you don't want the extra management of setting up accounts on both servers. Well we've handled that by using a sync process we developed to extract the list of accounts from the Exchange server, ship that up to the gateway server, and check to see what accounts need to be added or deleted. We've been using this process for a couple of years with perfect success. Since it is a batch process, it is scheduled to run every few minutes, so there could be a few minute delay when new accounts are added, but it has worked flawlessly for a couple of years. There are checks in place to make sure incomplete transfers don't result in accounts being deleted or incorrect accounts getting added to the gateway, and notifications are sent every time accounts are added or deleted. Currently it runs as a script on the destination Exchange or IMail server, and a scheduled process on a SQL database on our mail gateway server. Also, our gateway is an IMail server, but we could easily adapt it to use the account creation command line utilities I assume SmarterMail has. One other comment about the implementation. We maintain a hosts file for forwarding to the destination mail server, and use a subdomain to forward the mail for routing purposes, so the destination mail server is configured to accept mail for the subdomain. That's a simple change in Exchange to add an SMTP alias, and can be added to the default policy in Exchange so it is automatically added when an account is created. Anyway, if you have any interest, let me know. I know we wouldn't be able to survive if we were accepting email for any address in a domain, so I feel your pain. Best, Darin Cox 4C Web A division of 4C Design Technology Corp. (813) 413-4883 Tampa Bay, FL (919) 533-5000 Research
RE: [Declude.JunkMail] Fine tuning Declude
Hi Michael: I have a Windows script that I use with a whole bunch of different Exchange customers to pull their email addresses from their servers and dump them into a small JET (.mdb = Access) Database. It does have a few input parameters where you configure the LDAP path to the mail domain (because many Exchange customers have different schemes), the LDAP user/pwd, and which alias domain names to generate. I uses that list in a SQL query that my ORF gateway uses to block invalid email address and outright terminate connections that have too many invalid email addresses. If you have any use for it, I'll be happy to let you have it. Instead of outputting database rows, you could certainly expand the script to output a flat file instead or add alias items to the IMAIL registry, etc. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: Wednesday, May 12, 2010 2:14 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude I wrote a batch file once on a number of the exchange servers that used VBS and LDAP to generate a list of valid exchange recipients and then FTP them to the server where a CF script parsed it clean. I didn't quite know what to do with them when they got there though (I was originally going to use them in Alligate, but never got that up and going) and I don't have the full granular cooperation of all the Exchange network peeps, only most of them, so it was difficult to implement a one-size-fits-all policy regardless. I'll put my thinking cap on. Another one of the problems is that most all of my clients don't want to disable NDRs with whatever solution I come up with, which makes it fairly impossible to avoid backscatter. It goes in me one way, and out another :p Very Respectfully, 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.
RE: [Declude.JunkMail] Fine tuning Declude
That sounds like it would be fun to review, regardless. I can dig up my old script and post it, too. Mine is pretty primitive: spew and parse. Does it reach out to LDAP from the internet side of things, through a properly configured firewall, I imagine? Mine was a local script that uploaded. I like your idea better, if I am reading it right. With your idea, I provide minimum requirements instead of installation steps. Very Respectfully, Michael Cummins From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Wednesday, May 12, 2010 3:07 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude Hi Michael: I have a Windows script that I use with a whole bunch of different Exchange customers to pull their email addresses from their servers and dump them into a small JET (.mdb = Access) Database. It does have a few input parameters where you configure the LDAP path to the mail domain (because many Exchange customers have different schemes), the LDAP user/pwd, and which alias domain names to generate. I uses that list in a SQL query that my ORF gateway uses to block invalid email address and outright terminate connections that have too many invalid email addresses. If you have any use for it, I'll be happy to let you have it. Instead of outputting database rows, you could certainly expand the script to output a flat file instead or add alias items to the IMAIL registry, etc. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: Wednesday, May 12, 2010 2:14 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude I wrote a batch file once on a number of the exchange servers that used VBS and LDAP to generate a list of valid exchange recipients and then FTP them to the server where a CF script parsed it clean. I didn't quite know what to do with them when they got there though (I was originally going to use them in Alligate, but never got that up and going) and I don't have the full granular cooperation of all the Exchange network peeps, only most of them, so it was difficult to implement a one-size-fits-all policy regardless. I'll put my thinking cap on. Another one of the problems is that most all of my clients don't want to disable NDRs with whatever solution I come up with, which makes it fairly impossible to avoid backscatter. It goes in me one way, and out another :p Very Respectfully, 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.
RE: [Declude.JunkMail] Fine tuning Declude
Not sure that this list supports attachments - but here it is.
Here's how I launch it every half hour:
cscript //Nologo ExtractLDAP.wsf 70.255.255.84 ou=Their
Staff,dc=TheirCompany,dc=local logon.u...@theircompany.local mypassword
domainalias1.com domainalias2.com domainalias3.com TheirCompany
I usually use the LDAP Explorer tool to make sure I can connect to their
LDAP port through their firewall, that they have set up a valid
user/password for me, etc. Then I navigate through their LDAP hierarchy to
determine the correct OU/DC/DC, CN/DC/DC, etc path to their email users.
Once that succeeds I can simply take that info and use it as the parameters
to my script.
From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael
Cummins
Sent: Wednesday, May 12, 2010 3:25 PM
To: declude.junkmail@declude.com
Subject: RE: [Declude.JunkMail] Fine tuning Declude
That sounds like it would be fun to review, regardless. I can dig up my old
script and post it, too. Mine is pretty primitive: spew and parse.
Does it reach out to LDAP from the internet side of things, through a
properly configured firewall, I imagine? Mine was a local script that
uploaded. I like your idea better, if I am reading it right. With your
idea, I provide minimum requirements instead of installation steps.
Very Respectfully,
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.?XML version=1.0 standalone=yes ?
package
job id=ExtractLDAPAdr
?job error=true debug=true ?
reference object=Scripting.FileSystemObject /
reference object=ADODB.Connection /
reference object=ADOX.Catalog /
reference object=ADODB.Recordset/
script language=JScript
![CDATA[
//
===
// Extract Email Addresses from Active Directory
//
---
//
// Author: © 2005, Andy Schmidt
// Email: a...@argos.net
// Runtime: Windows Scripting Host 5.6
//
//
//
---
//
// CHANGE HISTORY
//
// 1.0.0 05-Apr-05 (AS) Initial Development.
// 1.1.0 17-Jan-07 (AS) Generalization and SQL sanitizing
// 1.2.0 19-Feb-07 (AS) Set Page Size ADO property for large query results
// 1.3.0 15-Apr-08 (AS) Allow for CommandLine Parameters
// 1.3.1 22-Apr-08 (AS) Reliable detection of DupRec return code from JET
//Permit Origin length of 15, check for max length
//
//
===
// --
// Global Constants
// --
var nPageSize = 2000; // (LDAP)
var strMDBFileName ='ImailAdr.mdb';
var strMDBConn ='Provider=Microsoft.Jet.OLEDB.4.0;Data Source=';
var strTable = 'UserList';
var strTableCreate = CREATE TABLE [ + strTable + ] ( [Domain] CHARACTER(255)
NOT NULL, [Host] CHARACTER(255) CONSTRAINT [HostKey] NOT NULL, [User]
CHARACTER(255) NOT NULL, [Email] CHARACTER(255) NOT NULL CONSTRAINT
[PrimaryKey] PRIMARY KEY, [Current] BIT, [Origin] CHARACTER(15) NOT NULL );;
var strIndexCreate = CREATE INDEX HostKey ON [ + strTable + ] ( [Host] )
WITH DISALLOW NULL;;
// --
// Global Variables
// --
var retCode = 0;
var bListOnly = false;
var nAddresses =0;
var nInserted = 0;
var nUpdated = 0;
var nRecordsEffected = 0;
var i, tempstr, temparr;
var strDomain, strEmail;
// ==
// Prolog
// ==
// Instantiate core objects
var objShell = WScript.CreateObject(WScript.Shell);
var objCat = WScript.CreateObject(ADOX.Catalog);
var objConn = WScript.CreateObject(ADODB.Connection);
var objRS = WScript.CreateObject(ADODB.Recordset);
// Get Command Line Parameters
if ( WScript.Arguments.Unnamed.Length 6 || WScript.Arguments.Unnamed.Length
7 )
{
WScript.Echo( 'Incorrect number of command line parameters: ' +
WScript.Arguments.Unnamed.Length + '. ');
WScript.Arguments.ShowUsage();
WScript.Quit( -4 );
}
var strComputer = WScript.Arguments.Unnamed.Item(0);
var adBase =WScript.Arguments.Unnamed.Item(1);
var adUser =WScript.Arguments.Unnamed.Item(2);
var adPwd = WScript.Arguments.Unnamed.Item(3);
var strDomains = + WScript.Arguments.Unnamed.Item(4) + ;
var strOrigin = WScript.Arguments.Unnamed.Item(5);
if ( WScript.Arguments.Unnamed.Length 6 )
bListOnly =
[Declude.JunkMail] SORBS Website Down?
Hi, Does anyone have a URL that works? I haven't been able to get www.sorbs.net/lookup.shtml, or www.au.sorbs.net/lookup.shtml to come up? I remember reading something last year that they had trouble getting a hosting sponsor - but later they were acquired by GFI. Best Regards, Andy --- 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.
RE: [Declude.JunkMail] Fine tuning Declude
Hi Michael, You're working too hard. Send a message to support @ Alligate.com and put ATTN: Brian in the subject. We'll figure out something. I usually don't see the license renewal things unless it is someone I deal with regularly, which includes a lot of members of this list. Believe it or not we get a fair number of people that say they haven't used the product yet and really just don't want to pay for it. Someone has to go back and do research in old update logs to try and find evidence or lack thereof, it and it can take half a day. It probably would have been a good idea to let us know if there were going to be deployment delays because we just make a note in the database and it saves everyone a lot of frustration. In your case, it sounds like we never heard anything until after the anniversary and the renewal reminder went out. Alligate is going to help you with a lot of this, and this is exactly what it is for. Brian Milburn From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: Wednesday, May 12, 2010 12:25 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude That sounds like it would be fun to review, regardless. I can dig up my old script and post it, too. Mine is pretty primitive: spew and parse. Does it reach out to LDAP from the internet side of things, through a properly configured firewall, I imagine? Mine was a local script that uploaded. I like your idea better, if I am reading it right. With your idea, I provide minimum requirements instead of installation steps. Very Respectfully, Michael Cummins From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Wednesday, May 12, 2010 3:07 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude Hi Michael: I have a Windows script that I use with a whole bunch of different Exchange customers to pull their email addresses from their servers and dump them into a small JET (.mdb = Access) Database. It does have a few input parameters where you configure the LDAP path to the mail domain (because many Exchange customers have different schemes), the LDAP user/pwd, and which alias domain names to generate. I uses that list in a SQL query that my ORF gateway uses to block invalid email address and outright terminate connections that have too many invalid email addresses. If you have any use for it, I'll be happy to let you have it. Instead of outputting database rows, you could certainly expand the script to output a flat file instead or add alias items to the IMAIL registry, etc. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: Wednesday, May 12, 2010 2:14 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude I wrote a batch file once on a number of the exchange servers that used VBS and LDAP to generate a list of valid exchange recipients and then FTP them to the server where a CF script parsed it clean. I didn't quite know what to do with them when they got there though (I was originally going to use them in Alligate, but never got that up and going) and I don't have the full granular cooperation of all the Exchange network peeps, only most of them, so it was difficult to implement a one-size-fits-all policy regardless. I'll put my thinking cap on. Another one of the problems is that most all of my clients don't want to disable NDRs with whatever solution I come up with, which makes it fairly impossible to avoid backscatter. It goes in me one way, and out another :p Very Respectfully, 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. --- 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.
Re: [Declude.JunkMail] Fine tuning Declude
This is about 1/3 of the process to sync the servers. Then there's the processing of the file on the gateway to add/delete accounts as needed, and the minor Exchange config changes to accept mail from a subdomain. In our implementations, and due to often insufficient access/knowledge on the part of most customers, it's a two-part batch sync. I like the all-in-one process you have by connecting through the firewall, Andy, but it's been hard enough getting access to customer servers to place the extraction script. Trying to get access to LDAP through firewalls for an external process would take a lot longer to coordinate on a per-customer basis. Darin. - Original Message - From: Andy Schmidt To: declude.junkmail@declude.com Sent: Wednesday, May 12, 2010 4:05 PM Subject: RE: [Declude.JunkMail] Fine tuning Declude Not sure that this list supports attachments - but here it is. Here's how I launch it every half hour: cscript //Nologo ExtractLDAP.wsf 70.255.255.84 ou=Their Staff,dc=TheirCompany,dc=local logon.u...@theircompany.local mypassword domainalias1.com domainalias2.com domainalias3.com TheirCompany I usually use the LDAP Explorer tool to make sure I can connect to their LDAP port through their firewall, that they have set up a valid user/password for me, etc. Then I navigate through their LDAP hierarchy to determine the correct OU/DC/DC, CN/DC/DC, etc path to their email users. Once that succeeds I can simply take that info and use it as the parameters to my script. From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: Wednesday, May 12, 2010 3:25 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude That sounds like it would be fun to review, regardless. I can dig up my old script and post it, too. Mine is pretty primitive: spew and parse. Does it reach out to LDAP from the internet side of things, through a properly configured firewall, I imagine? Mine was a local script that uploaded. I like your idea better, if I am reading it right. With your idea, I provide minimum requirements instead of installation steps. Very Respectfully, 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.
RE: [Declude.JunkMail] Fine tuning Declude
Hi Darin, I have been fortunate that my customers (or their network consultants) were able to open the LDAP port and add a user without trouble. Either they were big enough to have their own IT staff, or small enough to have an external IT consultant. But I understand that this might be different for everyone else. As far as adding/deleting accounts - this script is designed to add/delete records in the live database (that is actively used by ORF) - instead of deleting and then refreshing the entire list. This way, there is no downtime. Of course, if your gateway does not support ODBC lookups (ORF supports ODBC, LDAP and AD lookups), then you're out of luck. Anyway - I'm just sharing the code in case it helps Michael. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Darin Cox Sent: Wednesday, May 12, 2010 4:32 PM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] Fine tuning Declude This is about 1/3 of the process to sync the servers. Then there's the processing of the file on the gateway to add/delete accounts as needed, and the minor Exchange config changes to accept mail from a subdomain. In our implementations, and due to often insufficient access/knowledge on the part of most customers, it's a two-part batch sync. I like the all-in-one process you have by connecting through the firewall, Andy, but it's been hard enough getting access to customer servers to place the extraction script. Trying to get access to LDAP through firewalls for an external process would take a lot longer to coordinate on a per-customer basis. Darin. - Original Message - From: Andy Schmidt mailto:andy_schm...@hm-software.com To: declude.junkmail@declude.com Sent: Wednesday, May 12, 2010 4:05 PM Subject: RE: [Declude.JunkMail] Fine tuning Declude Not sure that this list supports attachments - but here it is. Here's how I launch it every half hour: cscript //Nologo ExtractLDAP.wsf 70.255.255.84 ou=Their Staff,dc=TheirCompany,dc=local logon.u...@theircompany.local mypassword domainalias1.com domainalias2.com domainalias3.com TheirCompany I usually use the LDAP Explorer tool to make sure I can connect to their LDAP port through their firewall, that they have set up a valid user/password for me, etc. Then I navigate through their LDAP hierarchy to determine the correct OU/DC/DC, CN/DC/DC, etc path to their email users. Once that succeeds I can simply take that info and use it as the parameters to my script. From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: Wednesday, May 12, 2010 3:25 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude That sounds like it would be fun to review, regardless. I can dig up my old script and post it, too. Mine is pretty primitive: spew and parse. Does it reach out to LDAP from the internet side of things, through a properly configured firewall, I imagine? Mine was a local script that uploaded. I like your idea better, if I am reading it right. With your idea, I provide minimum requirements instead of installation steps. Very Respectfully, 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. --- 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.
RE: [Declude.JunkMail] Fine tuning Declude
It's good all around discussion, too. I imagine it's quite topical for anyone that uses Declude ; these things affect our environment. Thanks lots! I guess I'll review my Alligate history and give Brian a shout. Very Respectfully, Michael Cummins From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Wednesday, May 12, 2010 4:51 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude Hi Darin, I have been fortunate that my customers (or their network consultants) were able to open the LDAP port and add a user without trouble. Either they were big enough to have their own IT staff, or small enough to have an external IT consultant. But I understand that this might be different for everyone else. As far as adding/deleting accounts - this script is designed to add/delete records in the live database (that is actively used by ORF) - instead of deleting and then refreshing the entire list. This way, there is no downtime. Of course, if your gateway does not support ODBC lookups (ORF supports ODBC, LDAP and AD lookups), then you're out of luck. Anyway - I'm just sharing the code in case it helps Michael. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Darin Cox Sent: Wednesday, May 12, 2010 4:32 PM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] Fine tuning Declude This is about 1/3 of the process to sync the servers. Then there's the processing of the file on the gateway to add/delete accounts as needed, and the minor Exchange config changes to accept mail from a subdomain. In our implementations, and due to often insufficient access/knowledge on the part of most customers, it's a two-part batch sync. I like the all-in-one process you have by connecting through the firewall, Andy, but it's been hard enough getting access to customer servers to place the extraction script. Trying to get access to LDAP through firewalls for an external process would take a lot longer to coordinate on a per-customer basis. Darin. - Original Message - From: Andy Schmidt mailto:andy_schm...@hm-software.com To: declude.junkmail@declude.com Sent: Wednesday, May 12, 2010 4:05 PM Subject: RE: [Declude.JunkMail] Fine tuning Declude Not sure that this list supports attachments - but here it is. Here's how I launch it every half hour: cscript //Nologo ExtractLDAP.wsf 70.255.255.84 ou=Their Staff,dc=TheirCompany,dc=local logon.u...@theircompany.local mypassword domainalias1.com domainalias2.com domainalias3.com TheirCompany I usually use the LDAP Explorer tool to make sure I can connect to their LDAP port through their firewall, that they have set up a valid user/password for me, etc. Then I navigate through their LDAP hierarchy to determine the correct OU/DC/DC, CN/DC/DC, etc path to their email users. Once that succeeds I can simply take that info and use it as the parameters to my script. From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Michael Cummins Sent: Wednesday, May 12, 2010 3:25 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Fine tuning Declude That sounds like it would be fun to review, regardless. I can dig up my old script and post it, too. Mine is pretty primitive: spew and parse. Does it reach out to LDAP from the internet side of things, through a properly configured firewall, I imagine? Mine was a local script that uploaded. I like your idea better, if I am reading it right. With your idea, I provide minimum requirements instead of installation steps. Very Respectfully, 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. --- 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.
RE: [Declude.JunkMail] SORBS Website Down?
It may have been down when you looked, Andy. It's up now. Also, I like to use this 3rd party for an instant second opinion: http://downforeveryoneorjustme.com Andrew 8) From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Wednesday, May 12, 2010 1:15 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SORBS Website Down? Hi, Does anyone have a URL that works? I haven't been able to get www.sorbs.net/lookup.shtml, or www.au.sorbs.net/lookup.shtml to come up? I remember reading something last year that they had trouble getting a hosting sponsor - but later they were acquired by GFI. Best Regards, Andy --- 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.
RE: [Declude.JunkMail] SORBS Website Down?
Thanks Andrew - it was down for a long time - but now I can get it. Thanks for reassuring me. From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Colbeck, Andrew Sent: Wednesday, May 12, 2010 5:29 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] SORBS Website Down? It may have been down when you looked, Andy. It's up now. Also, I like to use this 3rd party for an instant second opinion: http://downforeveryoneorjustme.com Andrew 8) _ From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Wednesday, May 12, 2010 1:15 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SORBS Website Down? Hi, Does anyone have a URL that works? I haven't been able to get www.sorbs.net/lookup.shtml, or www.au.sorbs.net/lookup.shtml to come up? I remember reading something last year that they had trouble getting a hosting sponsor - but later they were acquired by GFI. Best Regards, Andy --- 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. --- 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.
RE: [Declude.JunkMail] SORBS Website Down?
Nah - I wasn't imaging things - they really ARE having problems, e.g., when trying to query an IP address. Software error: Open DB Handle needed at /home/dnsbl/htdocs/cgi-bin/db line 190 For help, please send mail to the webmaster (supp...@support.sorbs.net), giving this error message and the time and date of the error. From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Colbeck, Andrew Sent: Wednesday, May 12, 2010 5:29 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] SORBS Website Down? It may have been down when you looked, Andy. It's up now. Also, I like to use this 3rd party for an instant second opinion: http://downforeveryoneorjustme.com Andrew 8) _ From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Wednesday, May 12, 2010 1:15 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SORBS Website Down? Hi, Does anyone have a URL that works? I haven't been able to get www.sorbs.net/lookup.shtml, or www.au.sorbs.net/lookup.shtml to come up? I remember reading something last year that they had trouble getting a hosting sponsor - but later they were acquired by GFI. Best Regards, Andy --- 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. --- 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.
