[sniffer] Re: Beta
Pete, one of the questions I had right away when I looked at the documentation accompanying the software package was about the communication channel. The documentation clearly pointed out that ports 25 is the default and that 80 is selectable, but didn't go further. I just answered my own question by sniffing the traffic... The question was: Ok, so I can govern the port, but will my stateful firewall like it? The answer is yes and no; if my firewall is expecting SMTP application layer traffic outbound on port 25/TCP then it won't like Sniffer's GBU/synch traffic. Which means that a firewall: * That does outbound packet filtering will be fine if it lets out 25/TCP. * That does stateful inspection will be fine if it lets out 25/TCP. * That does application layer filtering of SMTP on 25/TCP will not be fine. I suspect that the same would be true of 80/TCP if Sniffer is so configured. I doubt that this is a problem for most environments, but it is an important point for environments that have application layer filtering. These environments would be able to update their Sniffer database, but not participate in GBU, nor would they be able to use the synch system to report their logs or spam samples. Presumably, the affected environment could implement a new rule or override the application inspection and drop down their security to just allowing outbound 25/TCP without applying SMTP application layer inspection. Andrew. > -Original Message- > From: Message Sniffer Community > [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil > Sent: Wednesday, October 17, 2007 5:35 AM > To: Message Sniffer Community > Subject: [sniffer] Re: Beta > > Hello John, > > Wednesday, October 17, 2007, 1:41:18 AM, you wrote: > > >> Our SYNC server software rejects connections by default. If an SNF > >> node follows the expected connection protocols and authenticates > >> properly and consistently then it will be allowed to > communicate with > >> the system. If it fails to do any of these things or looks > suspicious > >> in any way then it will be automatically black listed for > increasingly > >> extended periods and potentially null routed by our fire-walls. The > >> security mechanisms are fully automatic and constantly monitored. > > > If something goes wrong on my server, either by a mistake I > make in a > > configuration file or a bug or whatever, and my server in > connecting to the > > SYNC server should be rejected and subsequently black > listed, is there a > > notification that takes place that some one will review to > see if that > > sniffer license is otherwise valid and otherwise no known > problems are seen > > so that I will then be notified saying "hey there is a > problem contact us" > > so that the problem can be resolved? > > Yes. > > The system is completely automated and reliable. There is nothing to > be concerned about. Quite simply, nothing can go wrong, go wrong, go > wrong... go.. > > Seriously though-- > > In order to be black-listed by our system you would have to be abusing > the SNF software or using some alternative software to attempt to gain > access or deny access to the SYNC servers. Otherwise the most you > could do would be to loose contact for some time. > > That said, if any system does something to become black-listed then > you can be sure it will have our attention. > > It is basically impossible for you to cause a properly functioning SNF > node to become black-listed by altering the configuration file. It is > far more likely that your SNF node would simply fail to connect. > > Chances are that if you were making an adjustment that could cause > this you would also be watching to make sure that things were working > correctly when you finished. > > In case you did cause the system to lose it's connection with us, the > system is designed so that SNF nodes will remain reliable and > effective for extended periods even if they are unable to contact the > SYNC server. It is also designed to recover gracefully when the > problem is corrected. > > The GBUdb system is highly effective even when it does not share it's > information with the other SNF nodes. Each GBUdb node learns first > about it's local traffic. As long as your SNF rulebase file is up to > date - or even close to being up to date, your system is likely to be > very effective at filtering spam. > > If your SNF/GBUdb node becomes detached from the main system for an > extended period, it will degrade in it's performance. Once the problem > is corrected it should recover in a very short time. > > In the event we detect any IPs being black listed or a
[sniffer] Re: Beta
Thanks as always Pete for a great explination. John T > -Original Message- > From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of > Pete McNeil > Sent: Wednesday, October 17, 2007 5:35 AM > To: Message Sniffer Community > Subject: [sniffer] Re: Beta > > Hello John, > > Wednesday, October 17, 2007, 1:41:18 AM, you wrote: > > >> Our SYNC server software rejects connections by default. If an SNF > >> node follows the expected connection protocols and authenticates > >> properly and consistently then it will be allowed to communicate with > >> the system. If it fails to do any of these things or looks suspicious > >> in any way then it will be automatically black listed for increasingly > >> extended periods and potentially null routed by our fire-walls. The > >> security mechanisms are fully automatic and constantly monitored. > > > If something goes wrong on my server, either by a mistake I make in a > > configuration file or a bug or whatever, and my server in connecting to the > > SYNC server should be rejected and subsequently black listed, is there a > > notification that takes place that some one will review to see if that > > sniffer license is otherwise valid and otherwise no known problems are seen > > so that I will then be notified saying "hey there is a problem contact us" > > so that the problem can be resolved? > > Yes. > > The system is completely automated and reliable. There is nothing to > be concerned about. Quite simply, nothing can go wrong, go wrong, go > wrong... go.. > > Seriously though-- > > In order to be black-listed by our system you would have to be abusing > the SNF software or using some alternative software to attempt to gain > access or deny access to the SYNC servers. Otherwise the most you > could do would be to loose contact for some time. > > That said, if any system does something to become black-listed then > you can be sure it will have our attention. > > It is basically impossible for you to cause a properly functioning SNF > node to become black-listed by altering the configuration file. It is > far more likely that your SNF node would simply fail to connect. > > Chances are that if you were making an adjustment that could cause > this you would also be watching to make sure that things were working > correctly when you finished. > > In case you did cause the system to lose it's connection with us, the > system is designed so that SNF nodes will remain reliable and > effective for extended periods even if they are unable to contact the > SYNC server. It is also designed to recover gracefully when the > problem is corrected. > > The GBUdb system is highly effective even when it does not share it's > information with the other SNF nodes. Each GBUdb node learns first > about it's local traffic. As long as your SNF rulebase file is up to > date - or even close to being up to date, your system is likely to be > very effective at filtering spam. > > If your SNF/GBUdb node becomes detached from the main system for an > extended period, it will degrade in it's performance. Once the problem > is corrected it should recover in a very short time. > > In the event we detect any IPs being black listed or acting > suspiciously we will be watching closely so that we can analyze any > potential threats and take appropriate actions. If we can identify a > customer involved in such a case we will contact them to investigate > and correct the problem. > > Locally, your status reports indicate when the last sync event > occurred. This is one of the ways you can check the status of your > system. Consider this example from recent telemetry: > > > > > > > > > You can see when the last sync event occurred (about 11 seconds ago in > this case): > > > > We plan to encourage the development of third party tools for > monitoring and analyzing SNF system data. In addition we plan to build > monitoring and analysis services of our own to include features that > will notify system administrators when something doesn't look quite > right. > > If you (anyone) develop something nice for displaying and/or > monitoring SNF status data then please share it with the SNF > community. > > In the mean time - we have done extensive testing and monitoring > throughout the development process. High availability is (has always > been) a design requirement and we're confident SNF can deliver that. > > Hope this helps, > > _M > > -- > Pete McNeil > Chief Scientist, > Arm Research Labs, LLC. > > > ##
[sniffer] Re: Beta
Hello John, Wednesday, October 17, 2007, 1:41:18 AM, you wrote: >> Our SYNC server software rejects connections by default. If an SNF >> node follows the expected connection protocols and authenticates >> properly and consistently then it will be allowed to communicate with >> the system. If it fails to do any of these things or looks suspicious >> in any way then it will be automatically black listed for increasingly >> extended periods and potentially null routed by our fire-walls. The >> security mechanisms are fully automatic and constantly monitored. > If something goes wrong on my server, either by a mistake I make in a > configuration file or a bug or whatever, and my server in connecting to the > SYNC server should be rejected and subsequently black listed, is there a > notification that takes place that some one will review to see if that > sniffer license is otherwise valid and otherwise no known problems are seen > so that I will then be notified saying "hey there is a problem contact us" > so that the problem can be resolved? Yes. The system is completely automated and reliable. There is nothing to be concerned about. Quite simply, nothing can go wrong, go wrong, go wrong... go.. Seriously though-- In order to be black-listed by our system you would have to be abusing the SNF software or using some alternative software to attempt to gain access or deny access to the SYNC servers. Otherwise the most you could do would be to loose contact for some time. That said, if any system does something to become black-listed then you can be sure it will have our attention. It is basically impossible for you to cause a properly functioning SNF node to become black-listed by altering the configuration file. It is far more likely that your SNF node would simply fail to connect. Chances are that if you were making an adjustment that could cause this you would also be watching to make sure that things were working correctly when you finished. In case you did cause the system to lose it's connection with us, the system is designed so that SNF nodes will remain reliable and effective for extended periods even if they are unable to contact the SYNC server. It is also designed to recover gracefully when the problem is corrected. The GBUdb system is highly effective even when it does not share it's information with the other SNF nodes. Each GBUdb node learns first about it's local traffic. As long as your SNF rulebase file is up to date - or even close to being up to date, your system is likely to be very effective at filtering spam. If your SNF/GBUdb node becomes detached from the main system for an extended period, it will degrade in it's performance. Once the problem is corrected it should recover in a very short time. In the event we detect any IPs being black listed or acting suspiciously we will be watching closely so that we can analyze any potential threats and take appropriate actions. If we can identify a customer involved in such a case we will contact them to investigate and correct the problem. Locally, your status reports indicate when the last sync event occurred. This is one of the ways you can check the status of your system. Consider this example from recent telemetry: You can see when the last sync event occurred (about 11 seconds ago in this case): We plan to encourage the development of third party tools for monitoring and analyzing SNF system data. In addition we plan to build monitoring and analysis services of our own to include features that will notify system administrators when something doesn't look quite right. If you (anyone) develop something nice for displaying and/or monitoring SNF status data then please share it with the SNF community. In the mean time - we have done extensive testing and monitoring throughout the development process. High availability is (has always been) a design requirement and we're confident SNF can deliver that. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
> Our SYNC server software rejects connections by default. If an SNF > node follows the expected connection protocols and authenticates > properly and consistently then it will be allowed to communicate with > the system. If it fails to do any of these things or looks suspicious > in any way then it will be automatically black listed for increasingly > extended periods and potentially null routed by our fire-walls. The > security mechanisms are fully automatic and constantly monitored. If something goes wrong on my server, either by a mistake I make in a configuration file or a bug or whatever, and my server in connecting to the SYNC server should be rejected and subsequently black listed, is there a notification that takes place that some one will review to see if that sniffer license is otherwise valid and otherwise no known problems are seen so that I will then be notified saying "hey there is a problem contact us" so that the problem can be resolved? John T # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
You nailed it Pete, Thanks! Darrell -- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Pete McNeil wrote: Hello Darrell, Tuesday, October 16, 2007, 9:26:47 PM, you wrote: Pete, Can you cover how the communication for the GBUdb system works? Sure. (And documentation is coming along with a web site redesign, so there will be plenty of additional detail on all things new SNF arriving over the next few weeks). Who does it exchange information with and how? Does it need special ports open? I'm going to assume this question is at least in part about security issues so I will frame my response from that perspective: Every minute or so (adjusted dynamically by the system) each new SNF node contacts one of our SYNC servers. The connection is made to port 25 by default. Since most MTAs will regularly make these kinds of connections no special ports will need to be open. If your MTAs are not allowed make outbound connections to port 25 for some reason then you have the option to make the connection to port 80. Our SYNC server software rejects connections by default. If an SNF node follows the expected connection protocols and authenticates properly and consistently then it will be allowed to communicate with the system. If it fails to do any of these things or looks suspicious in any way then it will be automatically black listed for increasingly extended periods and potentially null routed by our fire-walls. The security mechanisms are fully automatic and constantly monitored. The authentication protocol used to identify properly licensed SNF nodes is described in the file AuthenticationProtocol.swf. This file is included in the beta distributions and is also visible in the page linked below. At present there is no mechanism for connections to be made into SNF nodes -- only from SNF nodes to the SYNC servers. Also, there is no mechanism that allows the SYNC server (or any of our systems) to manipulate the SNF nodes except by the protocols described in the GBUdb documentation and by reporting update availability, tuning data, etc. This link helps explain how these interactions work: http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.GBUdb The SYNC system is separate from the rulebase delivery system. All of the data transmitted and received by the SNF nodes is in plain text or base64 encoded. The format of the data is XML. With the exception of GBUdb traffic, the telemetry transmitted to us is available to you directly in the .status. reports made by the SNF engine. Status reports can be found in the same directory as your SNF log files. You can use these XML based posts to create your own real-time monitoring systems. In addition to the GBUdb functions, the telemetry eliminates the need to send in log files by providing near real-time pattern matching statistics; supports virtual spamtraps and other collaborative learning systems; and provides performance analysis, error detection / correction, and system tuning metrics. One other security note -- the virtual spamtrap system can be turned off easily if you wish. Normally the virtual spamtrap system will send us a random sampling of messages that come from the worst known IPs when those messages do not match known pattern rules. In most systems, these are messages that would normally be discarded. Samples are infrequent by design so they should not account for any appreciable bandwidth. Similarly, the GBUdb protocol is designed to share information sparsely so that no appreciable bandwidth or CPU capacity is required. Please let me know if I missed the mark on your questions. Hope this helps, _M -- # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
Hello Darrell, Tuesday, October 16, 2007, 9:26:47 PM, you wrote: > Pete, > Can you cover how the communication for the GBUdb system works? Sure. (And documentation is coming along with a web site redesign, so there will be plenty of additional detail on all things new SNF arriving over the next few weeks). > Who > does it exchange information with and how? > Does it need special ports open? I'm going to assume this question is at least in part about security issues so I will frame my response from that perspective: Every minute or so (adjusted dynamically by the system) each new SNF node contacts one of our SYNC servers. The connection is made to port 25 by default. Since most MTAs will regularly make these kinds of connections no special ports will need to be open. If your MTAs are not allowed make outbound connections to port 25 for some reason then you have the option to make the connection to port 80. Our SYNC server software rejects connections by default. If an SNF node follows the expected connection protocols and authenticates properly and consistently then it will be allowed to communicate with the system. If it fails to do any of these things or looks suspicious in any way then it will be automatically black listed for increasingly extended periods and potentially null routed by our fire-walls. The security mechanisms are fully automatic and constantly monitored. The authentication protocol used to identify properly licensed SNF nodes is described in the file AuthenticationProtocol.swf. This file is included in the beta distributions and is also visible in the page linked below. At present there is no mechanism for connections to be made into SNF nodes -- only from SNF nodes to the SYNC servers. Also, there is no mechanism that allows the SYNC server (or any of our systems) to manipulate the SNF nodes except by the protocols described in the GBUdb documentation and by reporting update availability, tuning data, etc. This link helps explain how these interactions work: http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.GBUdb The SYNC system is separate from the rulebase delivery system. All of the data transmitted and received by the SNF nodes is in plain text or base64 encoded. The format of the data is XML. With the exception of GBUdb traffic, the telemetry transmitted to us is available to you directly in the .status. reports made by the SNF engine. Status reports can be found in the same directory as your SNF log files. You can use these XML based posts to create your own real-time monitoring systems. In addition to the GBUdb functions, the telemetry eliminates the need to send in log files by providing near real-time pattern matching statistics; supports virtual spamtraps and other collaborative learning systems; and provides performance analysis, error detection / correction, and system tuning metrics. One other security note -- the virtual spamtrap system can be turned off easily if you wish. Normally the virtual spamtrap system will send us a random sampling of messages that come from the worst known IPs when those messages do not match known pattern rules. In most systems, these are messages that would normally be discarded. Samples are infrequent by design so they should not account for any appreciable bandwidth. Similarly, the GBUdb protocol is designed to share information sparsely so that no appreciable bandwidth or CPU capacity is required. Please let me know if I missed the mark on your questions. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
Pete, Can you cover how the communication for the GBUdb system works? Who does it exchange information with and how? Does it need special ports open? Darrell -- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. Pete McNeil wrote: Hello Keith, First off-- there is a lot of misunderstanding in this message. I'm sorry for any confusion. For those watching - please read my responses carefully and hopefully they will clear things up quite a bit. Tuesday, October 16, 2007, 3:36:23 PM, you wrote: Pete, I am attempting to get caught on the latest beta and just have a few questions. I noticed Sniffer is now called a different way in the Declude config files, is that correct? Yes, but not very differently. The best way to adjust your Declude (or similar) configuration files for calling the new SNF is to REM out your existing settings, make a copy, and in your new copy change the name & path of the SNF executable so that it points to the new SNFClient.exe program. You do not need to rename SNFClient.exe. It will accept the same command line parameters that the earlier version of SNF expects - so the only change you really have to make is the name/path to the SNF executable you call to scan your messages. On the last release (running persistent), we have numerous entries in the declude.cfg file labeled: SNIFFER-TRAVEL external047 "C:\IMail\Declude\Sniffer\WeightGate.exe -12 %WEIGHT% 19 C:\IMail\Declude\Sniffer\snifferlic.exe codehere" 20 However, it appears the categories are going away (posted in some previous messages) and there is a since of urgency needed in upgrading as these won't be populated any longer soon. THIS IS NOT TRUE. The rule categories are staying just like they are. Perhaps the confusion is that one rule group, the IP rules, has been deprecated. It's functionality is being replaced by the GBUdb system which will return the same result code (63) for IPs in the "Black" range. The GBUdb will also return some additional values for special cases. By default: If the IP is in the White range, return 0. If the IP is in the Caution range, return 40. If the IP is in the Truncate range, return 20. What you will want to do is: * Make the changes to your configuration so that you are calling the SNFClient instead of . * Add two additional "tests" for the 40 result code and the 20 result code. I suggest making the 40 result code a slightly lower weight than you usually give to SNF - probably something similar to what you give a fairly accurate RBL. I suggest giving the 20 result code the same weight as SNF or possibly a higher weight. The "meaning" of the 40 result code is - "We don't trust this IP. We don't know a lot about it, but what we've seen so far looks like spam." The "meaning" of the 20 result code is - "We've watched this IP for a while now and this IP sends spam so consistently that we don't even look at the content any more - we just skip the message as soon as we see the IP." I take it we run the persistent mode the same way, but have a different hook into Declude? With the new SNF instead of running persistent, you run \SNFServer.exe \snf_engine.xml. By the way - if you have a persistent instance running, you DO NOT need to stop it to run the new SNFServer.exe. You can run both together and they will leave each other alone. This way you can switch back and forth easily just by calling the correct client --- either the original SNF installation you have or the new SNFClient. Whichever one you are NOT calling will more-or-less sleep while the other works. Once you are satisfied with the results and your installation you can then tear down the old one (if you wish). Hope this helps, _M -- # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
Hello Keith, First off-- there is a lot of misunderstanding in this message. I'm sorry for any confusion. For those watching - please read my responses carefully and hopefully they will clear things up quite a bit. Tuesday, October 16, 2007, 3:36:23 PM, you wrote: > Pete, > I am attempting to get caught on the latest beta and just have a few > questions. I noticed Sniffer is now called a different way in the > Declude config files, is that correct? Yes, but not very differently. The best way to adjust your Declude (or similar) configuration files for calling the new SNF is to REM out your existing settings, make a copy, and in your new copy change the name & path of the SNF executable so that it points to the new SNFClient.exe program. You do not need to rename SNFClient.exe. It will accept the same command line parameters that the earlier version of SNF expects - so the only change you really have to make is the name/path to the SNF executable you call to scan your messages. > On the last release (running > persistent), we have numerous entries in the declude.cfg file labeled: > SNIFFER-TRAVEL external047 > "C:\IMail\Declude\Sniffer\WeightGate.exe -12 %WEIGHT% 19 > C:\IMail\Declude\Sniffer\snifferlic.exe codehere" 20 > However, it appears the categories are going away (posted in some > previous messages) and there is a since of urgency needed in upgrading > as these won't be populated any longer soon. THIS IS NOT TRUE. The rule categories are staying just like they are. Perhaps the confusion is that one rule group, the IP rules, has been deprecated. It's functionality is being replaced by the GBUdb system which will return the same result code (63) for IPs in the "Black" range. The GBUdb will also return some additional values for special cases. By default: If the IP is in the White range, return 0. If the IP is in the Caution range, return 40. If the IP is in the Truncate range, return 20. What you will want to do is: * Make the changes to your configuration so that you are calling the SNFClient instead of . * Add two additional "tests" for the 40 result code and the 20 result code. I suggest making the 40 result code a slightly lower weight than you usually give to SNF - probably something similar to what you give a fairly accurate RBL. I suggest giving the 20 result code the same weight as SNF or possibly a higher weight. The "meaning" of the 40 result code is - "We don't trust this IP. We don't know a lot about it, but what we've seen so far looks like spam." The "meaning" of the 20 result code is - "We've watched this IP for a while now and this IP sends spam so consistently that we don't even look at the content any more - we just skip the message as soon as we see the IP." > I take it we run the persistent mode the same way, but have a different > hook into Declude? With the new SNF instead of running persistent, you run \SNFServer.exe \snf_engine.xml. By the way - if you have a persistent instance running, you DO NOT need to stop it to run the new SNFServer.exe. You can run both together and they will leave each other alone. This way you can switch back and forth easily just by calling the correct client --- either the original SNF installation you have or the new SNFClient. Whichever one you are NOT calling will more-or-less sleep while the other works. Once you are satisfied with the results and your installation you can then tear down the old one (if you wish). Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
Pete, I am attempting to get caught on the latest beta and just have a few questions. I noticed Sniffer is now called a different way in the Declude config files, is that correct? On the last release (running persistent), we have numerous entries in the declude.cfg file labeled: SNIFFER-TRAVEL external047 "C:\IMail\Declude\Sniffer\WeightGate.exe -12 %WEIGHT% 19 C:\IMail\Declude\Sniffer\snifferlic.exe codehere" 20 However, it appears the categories are going away (posted in some previous messages) and there is a since of urgency needed in upgrading as these won't be populated any longer soon. I take it we run the persistent mode the same way, but have a different hook into Declude? Thanks for the aid and understanding. Keith -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, October 15, 2007 10:05 PM To: Message Sniffer Community Subject: [sniffer] Re: Beta Hello Phillip, Monday, October 15, 2007, 6:39:22 PM, you wrote: > I just tried installing the beta and it appeared to work too well as > it was sending all the mail to the spam box. I am not sure if this > was due to the bad rule that was just replaced or something I was doing wrong. The bad rule turned out not to be as bad as we suspected -- so I don't think that was the problem. Also the bad rule has been gone for a while so you're not likely to have it in your rulebase. > I am currently running in the persistent mode. I set the xml file to > point to the correct paths in the 4 places and started up the sniffer > server. I then changed the bat file that the agent calls to > run snifclient.exe file licenseID %1 is this the correct format? I > am still using an old vopmail 5 mail server. The correct way to call SNFClient.exe is either just like you call the older SNF (compatibility mode): SNFClient.exe authenticationxx scanthis.msg I'm guessing from your notes and memory SNFClient.exe authenticationxx %1 --- The other way you can call SNFClient.exe to perform a scan is simply: SNFClient.exe scantthis.msg --- If you run SNFClient.exe without any parameters it will remind you how it can be used. If you called it with: SNFClient.exe file licenseid %1 Then that would be too many parameters so you would probably get an error and possibly a nonzero result. I may simply be misinterpreting your notes - but if you did something like this in your script (batch file) then it's possible the result would be to hold every message. > At the moment I switched back to the old version of sniffer after > going through 600 emails by hand and sorting out spam and real mail > and manually placing them in the correct mailboxes, that was fun. Sorry about that. I tried to be as explicit as possible in the readme files and the help system in the program itself (running SNFClient.exe on the command line by itself should list all of the ways the client can be called.) The new SNF doesn't have a persistent and non-persistent mode like the old version. Instead, it is strictly a client/server model. Run the SNFServer.exe program as described in the read me and then leave it running. Then, with your message processing script you can call the SNFClient.exe program in place of the old SNF program without any modifications if that is easier -- -the SNFClient.exe will accept the same parameters as the old SNF program without a problem. This makes it relatively easy to switch back (as you did). If you start out running the SNFServer from the command line then it's display will help you to know when things are working correctly -- you will be able to see when messages start going through and you should quickly get an idea of what looks correct. Once you're confident in that setup then you can run the SNFServer using srvany or firedaemon or your other favorite utility that runs programs as a service. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
Hello Phillip, Monday, October 15, 2007, 6:39:22 PM, you wrote: > I just tried installing the beta and it appeared to work too well as > it was sending all the mail to the spam box. I am not sure if this > was due to the bad rule that was just replaced or something I was doing wrong. The bad rule turned out not to be as bad as we suspected -- so I don't think that was the problem. Also the bad rule has been gone for a while so you're not likely to have it in your rulebase. > I am currently running in the persistent mode. I set the xml file to > point to the correct paths in the 4 places and started up the sniffer > server. I then changed the bat file that the agent calls to > run snifclient.exe file licenseID %1 is this the correct format? I > am still using an old vopmail 5 mail server. The correct way to call SNFClient.exe is either just like you call the older SNF (compatibility mode): SNFClient.exe authenticationxx scanthis.msg I'm guessing from your notes and memory SNFClient.exe authenticationxx %1 --- The other way you can call SNFClient.exe to perform a scan is simply: SNFClient.exe scantthis.msg --- If you run SNFClient.exe without any parameters it will remind you how it can be used. If you called it with: SNFClient.exe file licenseid %1 Then that would be too many parameters so you would probably get an error and possibly a nonzero result. I may simply be misinterpreting your notes - but if you did something like this in your script (batch file) then it's possible the result would be to hold every message. > At the moment I switched back to the old version of sniffer after > going through 600 emails by hand and sorting out spam and real mail > and manually placing them in the correct mailboxes, that was fun. Sorry about that. I tried to be as explicit as possible in the readme files and the help system in the program itself (running SNFClient.exe on the command line by itself should list all of the ways the client can be called.) The new SNF doesn't have a persistent and non-persistent mode like the old version. Instead, it is strictly a client/server model. Run the SNFServer.exe program as described in the read me and then leave it running. Then, with your message processing script you can call the SNFClient.exe program in place of the old SNF program without any modifications if that is easier -- -the SNFClient.exe will accept the same parameters as the old SNF program without a problem. This makes it relatively easy to switch back (as you did). If you start out running the SNFServer from the command line then it's display will help you to know when things are working correctly -- you will be able to see when messages start going through and you should quickly get an idea of what looks correct. Once you're confident in that setup then you can run the SNFServer using srvany or firedaemon or your other favorite utility that runs programs as a service. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[sniffer] Re: Beta
I just tried installing the beta and it appeared to work too well as it was sending all the mail to the spam box. I am not sure if this was due to the bad rule that was just replaced or something I was doing wrong. I am currently running in the persistent mode. I set the xml file to point to the correct paths in the 4 places and started up the sniffer server. I then changed the bat file that the agent calls to run snifclient.exe file licenseID %1 is this the correct format? I am still using an old vopmail 5 mail server. At the moment I switched back to the old version of sniffer after going through 600 emails by hand and sorting out spam and real mail and manually placing them in the correct mailboxes, that was fun. Phil # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
