[sniffer] OT Mdaemon Ldap (Ldaemon is Slow question)
I hate to put this to the sniffer list since it is way OT, however people on this list seem to have good insight. I've been having an issue with Ldaemons Ldap server being incredibly slow to respond to Ldap querys from clients such as Netscape, Outlook, and outlook express. Simply queries usually take about 10 seconds to complete (even with only 500 accounts), I have submitted a support request to Altn and posted to their forum but they have no idea why Ldap queries are slow for me. I have even purged and reloaded the Ldaemon Database to no avail. Has anyone running Mdaemon and Ldaemon run into this before. Sorry for the OT message. Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] <>
RE: Re[4]: [sniffer]
Well, I think you will likely find that most organizations do use Mdaemon's built-in SA implementation. I have it under fairly high load and have no problems with it. No tool is perfect, so I use mutlipe tools. SA gives me a lot of flexibility in writing my own custom rules, WhiteLists, BlackLists, etc. as well as using SURBL and URIBL lookups. It is also nice that it "Learns" key terminology for our Organization. If Mdaemon hadn't of created the plugin hook to have Sniffer run inline, I probably wouldn't have run Sniffer as a content filter rule due to the overhead. SA and Sniffer are both great products, and having the ability for them to work in conjunction with each other seems a natural progression. Just my two cents worth... :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, November 10, 2005 12:36 PM To: Peer-to-Peer (Support) Subject: Re[4]: [sniffer] On Thursday, November 10, 2005, 11:45:48 AM, Peer-to-Peer wrote: PtPS> _M, PtPS> <<_M said>> will create a "default" installation that emits PtPS> headers and puts a .cf file in place for SA to interpret them. PtPS> Not sure if this is relevant to your thought process, but we feel PtPS> that SA PtPS> (SpamAssassin) does more harm than good. Under moderate loads it PtPS> bogs-down MDaemon so we always have SA disabled. Sniffer is by PtPS> far superior in every category, (accuracy, speed, dependability PtPS> etc...) so there's no need to use SpamAssassin. PtPS> My point: Keep in mind that some of us use sniffer independently PtPS> (not tied to SA). We're using sniffers .cfg plug-in for MD ver 8. PtPS> I assume you will, and I probably misunderstood your post, but PtPS> just wanted to mention this out-loud. Thanks for this! I think it's the first time I've heard it said out loud from anyone involved with MDaemon. As a result I'm operating under the assumption that folks who install SNF on MDaemon _most likely_ have SA running and so that would be the simplest default installation. Is that true (do you think) or is it now more likely that SA would be disabled? In any case, the installer is intended for someone who just wants to push the button and have it work. In that context, what is the best "default install"? All that said, once the installation is complete, a technically savvy person could reconfigure SNF to and MDaemon to work in any way they prefer. We're definitely not going to do anything to make that more difficult. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[4]: [sniffer]
_M, <<_M said>> Is that true (do you think) or is it now more likely that SA would be disabled? I have no basis, but doubt that more than 5% of MDaemon configurations have SA disabled. I'm certain Sniffer would far benefit in the overall picture if you could create an installation that ties-in together with SA. The benefit of SA in MDaemon is the fact that it's their default Spam-Filter and unfortunately MD has built their bells and whistles around it. For a normal company it's almost mandatory to use. I'm not anti-SA; I think its a fine service, we've just figured out that it's extra baggage on our servers which serves no specific use for our needs (just ties-up system resources). Arvel @ Alt-N is clearly missing the boat... Paul R -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Thursday, November 10, 2005 12:36 PM To: Peer-to-Peer (Support) Subject: Re[4]: [sniffer] On Thursday, November 10, 2005, 11:45:48 AM, Peer-to-Peer wrote: PtPS> _M, PtPS> <<_M said>> will create a "default" installation that emits headers and puts PtPS> a .cf file in place for SA to interpret them. PtPS> Not sure if this is relevant to your thought process, but we feel that SA PtPS> (SpamAssassin) does more harm than good. Under moderate loads it bogs-down PtPS> MDaemon so we always have SA disabled. Sniffer is by far superior in every PtPS> category, (accuracy, speed, dependability etc...) so there's no need to use PtPS> SpamAssassin. PtPS> My point: Keep in mind that some of us use sniffer independently (not tied PtPS> to SA). We're using sniffers .cfg plug-in for MD ver 8. PtPS> I assume you will, and I probably misunderstood your post, but just wanted PtPS> to mention this out-loud. Thanks for this! I think it's the first time I've heard it said out loud from anyone involved with MDaemon. As a result I'm operating under the assumption that folks who install SNF on MDaemon _most likely_ have SA running and so that would be the simplest default installation. Is that true (do you think) or is it now more likely that SA would be disabled? In any case, the installer is intended for someone who just wants to push the button and have it work. In that context, what is the best "default install"? All that said, once the installation is complete, a technically savvy person could reconfigure SNF to and MDaemon to work in any way they prefer. We're definitely not going to do anything to make that more difficult. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[4]: [sniffer]
Hi Pete, Here is my setup. I still have SpamAssassin running, for two reasons. 1. It allows my users to submit False Positives, False Negatives, and Whitelisted address'. By using the built-in email address' that Mdaemon provides for those. I then setup rules in the Mdaemon Content Filter to then forward those to the appropriate SortMonster address'. 2. It can block obvious spam in the SMTP session before it even comes in. I also have Spam Assassin setup to use the Message Sniffer Results. As far as my updating of the Rule Base. I setup a Content Filter Rule to scan incoming mail for the Update Notification. Listed Below. [Rule007] RuleName=Update Message Sniffer Rules Enable=Yes ThisRuleCondition=All ProcessQueue=BOTH Condition01=SUBJECT|contains|AND|vXXX.snf Update| Action01=run a program|"-1,0,1","cmd.exe /C C:\MDaemon\MessageSniffer\snfupd.cmd" Action02=stop processing| The snfupd.cmd is setup pretty much like the example you include with the plugin I setup two Content Filter rules to forward the False Positive and False Negatives to Sort Monster. Listed Below [Rule001] RuleName=Forward Ham Learn to Message Sniffer Enable=Yes ThisRuleCondition=All ProcessQueue=BOTH Condition01=TO|contains|AND|[EMAIL PROTECTED]| Action01=remove header|"Subject","" Action02=add header|"Subject","False Positive Report - license vXXX" Action03=remove header|"From","" Action04=add header|"From","[EMAIL PROTECTED]" Action05=copy to|"[EMAIL PROTECTED]" Action06=stop processing| [Rule002] RuleName=Forward Spam Learn to Message Sniffer Enable=Yes ThisRuleCondition=All ProcessQueue=BOTH Condition01=TO|contains|AND|[EMAIL PROTECTED]| Action01=remove header|"From","" Action02=add header|"From","[EMAIL PROTECTED]" Action03=copy to|"[EMAIL PROTECTED]" Action04=stop processing| HTH, Daniel > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil > Sent: Thursday, November 10, 2005 12:36 PM > To: Peer-to-Peer (Support) > Subject: Re[4]: [sniffer] > > On Thursday, November 10, 2005, 11:45:48 AM, Peer-to-Peer wrote: > > PtPS> _M, > > PtPS> <<_M said>> will create a "default" installation that > emits headers and puts > PtPS> a .cf file in place for SA to interpret them. > > PtPS> Not sure if this is relevant to your thought process, > but we feel that SA > PtPS> (SpamAssassin) does more harm than good. Under > moderate loads it bogs-down > PtPS> MDaemon so we always have SA disabled. Sniffer is by > far superior in every > PtPS> category, (accuracy, speed, dependability etc...) so > there's no need to use > PtPS> SpamAssassin. > > PtPS> My point: Keep in mind that some of us use sniffer > independently (not tied > PtPS> to SA). We're using sniffers .cfg plug-in for MD ver 8. > PtPS> I assume you will, and I probably misunderstood your > post, but just wanted > PtPS> to mention this out-loud. > > Thanks for this! I think it's the first time I've heard it said out > loud from anyone involved with MDaemon. As a result I'm operating > under the assumption that folks who install SNF on MDaemon _most > likely_ have SA running and so that would be the simplest default > installation. > > Is that true (do you think) or is it now more likely that SA would be > disabled? > > In any case, the installer is intended for someone who just wants to > push the button and have it work. In that context, what is the best > "default install"? > > All that said, once the installation is complete, a technically savvy > person could reconfigure SNF to and MDaemon to work in any way they > prefer. We're definitely not going to do anything to make that more > difficult. > > Thanks, > > _M > > > > This E-Mail came from the Message Sniffer mailing list. For > information and (un)subscription instructions go to > http://www.sortmonster.com/MessageSniffer/Help/Help.html > This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[4]: [sniffer]
We are running Sniffer with the Mdaemon plug-in and SA and it seems to work great for us, much better than our previous Imail/Declude sniffer combination. Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, November 10, 2005 9:36 AM To: Peer-to-Peer (Support) Subject: Re[4]: [sniffer] On Thursday, November 10, 2005, 11:45:48 AM, Peer-to-Peer wrote: PtPS> _M, PtPS> <<_M said>> will create a "default" installation that emits headers and puts PtPS> a .cf file in place for SA to interpret them. PtPS> Not sure if this is relevant to your thought process, but we feel that SA PtPS> (SpamAssassin) does more harm than good. Under moderate loads it bogs-down PtPS> MDaemon so we always have SA disabled. Sniffer is by far superior in every PtPS> category, (accuracy, speed, dependability etc...) so there's no need to use PtPS> SpamAssassin. PtPS> My point: Keep in mind that some of us use sniffer independently (not tied PtPS> to SA). We're using sniffers .cfg plug-in for MD ver 8. PtPS> I assume you will, and I probably misunderstood your post, but just wanted PtPS> to mention this out-loud. Thanks for this! I think it's the first time I've heard it said out loud from anyone involved with MDaemon. As a result I'm operating under the assumption that folks who install SNF on MDaemon _most likely_ have SA running and so that would be the simplest default installation. Is that true (do you think) or is it now more likely that SA would be disabled? In any case, the installer is intended for someone who just wants to push the button and have it work. In that context, what is the best "default install"? All that said, once the installation is complete, a technically savvy person could reconfigure SNF to and MDaemon to work in any way they prefer. We're definitely not going to do anything to make that more difficult. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[4]: [sniffer]
On Thursday, November 10, 2005, 11:45:48 AM, Peer-to-Peer wrote: PtPS> _M, PtPS> <<_M said>> will create a "default" installation that emits headers and puts PtPS> a .cf file in place for SA to interpret them. PtPS> Not sure if this is relevant to your thought process, but we feel that SA PtPS> (SpamAssassin) does more harm than good. Under moderate loads it bogs-down PtPS> MDaemon so we always have SA disabled. Sniffer is by far superior in every PtPS> category, (accuracy, speed, dependability etc...) so there's no need to use PtPS> SpamAssassin. PtPS> My point: Keep in mind that some of us use sniffer independently (not tied PtPS> to SA). We're using sniffers .cfg plug-in for MD ver 8. PtPS> I assume you will, and I probably misunderstood your post, but just wanted PtPS> to mention this out-loud. Thanks for this! I think it's the first time I've heard it said out loud from anyone involved with MDaemon. As a result I'm operating under the assumption that folks who install SNF on MDaemon _most likely_ have SA running and so that would be the simplest default installation. Is that true (do you think) or is it now more likely that SA would be disabled? In any case, the installer is intended for someone who just wants to push the button and have it work. In that context, what is the best "default install"? All that said, once the installation is complete, a technically savvy person could reconfigure SNF to and MDaemon to work in any way they prefer. We're definitely not going to do anything to make that more difficult. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer]
_M, <<_M said>> will create a "default" installation that emits headers and puts a .cf file in place for SA to interpret them. Not sure if this is relevant to your thought process, but we feel that SA (SpamAssassin) does more harm than good. Under moderate loads it bogs-down MDaemon so we always have SA disabled. Sniffer is by far superior in every category, (accuracy, speed, dependability etc...) so there's no need to use SpamAssassin. My point: Keep in mind that some of us use sniffer independently (not tied to SA). We're using sniffers .cfg plug-in for MD ver 8. I assume you will, and I probably misunderstood your post, but just wanted to mention this out-loud. Thanks, Paul R -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Thursday, November 10, 2005 10:43 AM To: Daniel Bayerdorffer Subject: Re[2]: [sniffer] On Thursday, November 10, 2005, 9:40:42 AM, Daniel wrote: DB> Hi Pete, DB> Thanks for the info. I actually already have the current version running. DB> I'm very happy with it's performance. I just did not have a clear DB> understanding on those issues. DB> On another note, when you have the new version install, will it overwrite my DB> current settings? And will it also install scripts for updating the rule DB> base, and sending logs? Because I already have that setup now. In theory the installer will know if there is a previous version and will not adjust any of the config data. It's a bit of a complicated problem because there are so many way to configure the software.. so the installation process can be complex. I'd like to know how you have your updates set up - perhaps I can use that as a model for the installer. The basic idea is that the installer will create a "default" installation that emits headers and puts a .cf file in place for SA to interpret them. After that, the technically minded can manually adjust the installation. If the installer finds an installation in place then it will likely update the .DLL and leave everything else alone. Comments about these concepts are welcome, of course. The goal is to make a plug-and-play installation possible while leaving the more sophisticated options open to the technically minded. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer]
On Thursday, November 10, 2005, 9:40:42 AM, Daniel wrote: DB> Hi Pete, DB> Thanks for the info. I actually already have the current version running. DB> I'm very happy with it's performance. I just did not have a clear DB> understanding on those issues. DB> On another note, when you have the new version install, will it overwrite my DB> current settings? And will it also install scripts for updating the rule DB> base, and sending logs? Because I already have that setup now. In theory the installer will know if there is a previous version and will not adjust any of the config data. It's a bit of a complicated problem because there are so many way to configure the software.. so the installation process can be complex. I'd like to know how you have your updates set up - perhaps I can use that as a model for the installer. The basic idea is that the installer will create a "default" installation that emits headers and puts a .cf file in place for SA to interpret them. After that, the technically minded can manually adjust the installation. If the installer finds an installation in place then it will likely update the .DLL and leave everything else alone. Comments about these concepts are welcome, of course. The goal is to make a plug-and-play installation possible while leaving the more sophisticated options open to the technically minded. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer]
Hi Pete, Thanks for the info. I actually already have the current version running. I'm very happy with it's performance. I just did not have a clear understanding on those issues. On another note, when you have the new version install, will it overwrite my current settings? And will it also install scripts for updating the rule base, and sending logs? Because I already have that setup now. Thanks, Daniel > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil > Sent: Thursday, November 10, 2005 9:33 AM > To: Daniel Bayerdorffer > Subject: Re: [sniffer] > > On Thursday, November 10, 2005, 8:07:18 AM, Daniel wrote: > > DB> Hello, > > DB> Can anyone tell me if the Mdaemon Plug-in runs in > persistent mode? Also are > DB> there any plans to bring the plug-in to Version 1 status? > > The MDaemon plugin has no need for persistent mode because it is > loaded and kept in memory by MDaemon itself. As a result, the > performance is always optimal because the rulebase is only ever loaded > when a new file is present. > > Persistent mode is a mechanism developed to enhance the performance of > peer-server implementations (using the command line utility). > > The current plugin code is actually at 1.0 status, however we haven't > released an official 1.0 distribution because we are working on a few > refinements and an installer. The existing 0.53 download should be > considered production ready code -- only external things like the > installer are missing. > > When we do release a 1.x version, it will include an Install Shield > installer and a few new features - primarily to provide some advanced > configuration options. The core of the program will not change > however. > > This work is currently on hold for back-end improvements on the > rulebase and rulebase development tools. > > Hope this helps, > > _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer]
On Thursday, November 10, 2005, 8:07:18 AM, Daniel wrote: DB> Hello, DB> Can anyone tell me if the Mdaemon Plug-in runs in persistent mode? Also are DB> there any plans to bring the plug-in to Version 1 status? The MDaemon plugin has no need for persistent mode because it is loaded and kept in memory by MDaemon itself. As a result, the performance is always optimal because the rulebase is only ever loaded when a new file is present. Persistent mode is a mechanism developed to enhance the performance of peer-server implementations (using the command line utility). The current plugin code is actually at 1.0 status, however we haven't released an official 1.0 distribution because we are working on a few refinements and an installer. The existing 0.53 download should be considered production ready code -- only external things like the installer are missing. When we do release a 1.x version, it will include an Install Shield installer and a few new features - primarily to provide some advanced configuration options. The core of the program will not change however. This work is currently on hold for back-end improvements on the rulebase and rulebase development tools. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer]
Hello, Can anyone tell me if the Mdaemon Plug-in runs in persistent mode? Also are there any plans to bring the plug-in to Version 1 status? Thanks, Daniel -- Daniel Bayerdorffer [EMAIL PROTECTED] Numberall Stamp & Tool Co., Inc. PO Box 187 Sangerville, ME 04479 USA TEL 207-876-3541 FAX 207-876-3566 www.numberall.com This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
