[sniffer]Re[2]: [sniffer]FP suggestions
Hello Darin, Wednesday, June 7, 2006, 7:31:29 AM, you wrote: > > > The one issue with this I have is > > > > 1) Forward full original source to Sniffer with license code. > > If we could do it without the license code, it would be much > easier to automate on our end. I already have a process in place > to copy and reroute false positives by rewriting the Q file. I'm > hesitant to alter the message itself to add the license code. If we > could authenticate the FP report via some other means it would help > greatly. How about connecting IP instead? At the moment that is how it's done: a combination of email address and source IP are matched with the license ID. The reason we ask for the license ID is because folks submitting false positives occasionally forget that we authenticate on their registered email address and use some other address. -- The rule is that if the system can't match the email address it should/may drop the message rather than evaluating it. We get a lot of spam and attempts to game the system at our false@ address... so when it's heavy we do drop messages that can't be properly identified. However, in an effort to provide the best service possible, if the license ID is present and we have the time we will look to see if it could be a legit FP submission by researching the source and domain - and if we think it is likely to be legitimate we will process the FP and respond with an additional code reminding the submitter that they must use their registered email address or an authorized alias. _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[2]: [sniffer]FP suggestions
Hello Scott, Wednesday, June 7, 2006, 10:08:58 AM, you wrote: > > > For me the pain of false positives submissions is the research > that happens when I get a "no rule found" return. > > > > I then need to find the queue-id of the original message and then > find the appropriate Sniffer log and pull out the log lines from > there and then submit it. Almost always in these cases, a rule is removed. > > > > If this process could be improved that would really be a time saver. This depends on the email system you are using. On some systems (MDaemon, and postfix, for example) X- headers from SNF can be emitted into the message. When we see these we can identify the rules directly without asking for the extra research. It would be nice if Declude would offer a mechanism to pick up the optional .xhdr file SNF can generate and include it in the X headers that it already adds to the message. I know this begs the question, why not have SNF add the headers for SmarterMail and IMail platforms, and the reason is that it would require writing an additional copy of the message to disk. Since these systems tend to be io bound already (Declude/IMail anyhow) the performance penalty would be prohibitive. If Declude picks up .xhdr from SNF directly then it can be included in the ONE rewrite Declude makes anyway. I've asked them about this and other improved integration opportunities for a while now (many months), and I get favorable responses, but no action so far. I guess we will see :-) _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[2]: [sniffer]FP suggestions
Hello Darin, Wednesday, June 7, 2006, 5:14:02 PM, you wrote: > > > Oh, I assumed the rule had been removed. Are you saying there was > a rule in place, but the FP processing somehow failed to find it? > If so, I'd say that is a major failing on the part of the FP processing. > > > > There's no way that we can find time to go through the Sniffer > logs after this bounces back with "no rule found". This would have > to be automated to have any chance of occurring, but again I would > say the FP processing needs to be corrected to identify the rule the > message failed since the complete message, headers and body, are included in > the report. Unfortunately, by the time the message gets to us it is sometimes just different enough that the original pattern cannot be found. There are some folks who consistently have success, and some who occasionally have problems, and a few who always have a problem. The best solution is to include the headers during the scan since they will travel with the message. The next best is to automate matching the log entries with the message so they can be included with the submission (some do this to prevent the "second trip"). _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]>
Re: [sniffer]Re[2]: [sniffer]FP suggestions
Hi Pete, Can I interpret this as email address and matching source IP are sufficient if the correct email address is used to submit? If not, do you have any suggestions on how you would like to see us inserting the license ID in the D file? Darin. - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Message Sniffer Community" Sent: Wednesday, June 07, 2006 8:25 AM Subject: [sniffer]Re[2]: [sniffer]FP suggestions Hello Darin, Wednesday, June 7, 2006, 7:31:29 AM, you wrote: > > > The one issue with this I have is > > > > 1) Forward full original source to Sniffer with license code. > > If we could do it without the license code, it would be much > easier to automate on our end. I already have a process in place > to copy and reroute false positives by rewriting the Q file. I'm > hesitant to alter the message itself to add the license code. If we > could authenticate the FP report via some other means it would help > greatly. How about connecting IP instead? At the moment that is how it's done: a combination of email address and source IP are matched with the license ID. The reason we ask for the license ID is because folks submitting false positives occasionally forget that we authenticate on their registered email address and use some other address. -- The rule is that if the system can't match the email address it should/may drop the message rather than evaluating it. We get a lot of spam and attempts to game the system at our false@ address... so when it's heavy we do drop messages that can't be properly identified. However, in an effort to provide the best service possible, if the license ID is present and we have the time we will look to see if it could be a legit FP submission by researching the source and domain - and if we think it is likely to be legitimate we will process the FP and respond with an additional code reminding the submitter that they must use their registered email address or an authorized alias. _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]>
Re: [sniffer]Re[2]: [sniffer]FP suggestions
Pete, An X-Header would be very, very nice to have. I understand the issues related to waiting to see if something comes through, and because of that, I would maybe suggest moving on your own. Sniffer doesn't need to be run on every single message in a Declude system. Through weight based skipping, many administrators (especially the ones that could make the most use of this) could skip processing Sniffer once a certain weight is reached, and in turn that would save enough load that it should easily make up for needing to re-write the message to the disk with the modified headers. On external tests that allow for weight skipping on my system, I was skipping around 50% of messages before lightening the load with pre-scanning. Sniffer could do weight skipping with Declude by accepting the %WEIGHT% variable in the command line. SNIFFER-IP external 063 "C:\IMail\Declude\Sniffer\customer-code.exe license-code WH=26 WL=-5 CW=%WEIGHT%" 5 0 ...etc. The WH setting says don't run if equal to or greater than, the WL says don't run if equal to or less than, and the CW passes in the weight from Declude at the time of calling Sniffer. It still launches Sniffer, but it could be stopped immediately before any heavy lifting is done. The best solution of course would be for Declude to allow for weight-based skipping in the config without calling the executable, but I started asking about that back in the Scott days and I am not holding out hope for that happening soon considering. The most realistic option would seem to then have Sniffer do the heavy lifting of rewriting itself, and save some CPU and disk I/O by improving efficiencies with something as simple as weight-based skipping. I'm pretty sure the net result would be less CPU and disk I/O overall if both were done. Another alternative may be to create a separate executable (with weight-based skipping) that would only deal with adding headers from the text file that Sniffer drops in the directory. There would be less benefit overall to keeping this all in one app, but it would target the primary need. This could easily be written by one of us in _vbscript_ as a proof of concept. I have considered doing this before, but it isn't at the top of my priorities. BTW, you could maybe even encode links in the headers for FP reporting through a Web interface, completely removing the forwarding mechanism from the mix, though you wouldn't have the opportunity to see the messages which may not be good as a whole. Matt Pete McNeil wrote: Hello Scott, Wednesday, June 7, 2006, 10:08:58 AM, you wrote: For me the pain of false positives submissions is the research that happens when I get a "no rule found" return. I then need to find the queue-id of the original message and then find the appropriate Sniffer log and pull out the log lines from there and then submit it. Almost always in these cases, a rule is removed. If this process could be improved that would really be a time saver. This depends on the email system you are using. On some systems (MDaemon, and postfix, for example) X- headers from SNF can be emitted into the message. When we see these we can identify the rules directly without asking for the extra research. It would be nice if Declude would offer a mechanism to pick up the optional .xhdr file SNF can generate and include it in the X headers that it already adds to the message. I know this begs the question, why not have SNF add the headers for SmarterMail and IMail platforms, and the reason is that it would require writing an additional copy of the message to disk. Since these systems tend to be io bound already (Declude/IMail anyhow) the performance penalty would be prohibitive. If Declude picks up .xhdr from SNF directly then it can be included in the ONE rewrite Declude makes anyway. I've asked them about this and other improved integration opportunities for a while now (many months), and I get favorable responses, but no action so far. I guess we will see :-) _M
Re: [sniffer]Re[2]: [sniffer]FP suggestions
>Unfortunately, by the time the message gets to us it is sometimes just >different enough that the original pattern cannot be found. There are >some folks who consistently have success, and some who occasionally >have problems, and a few who always have a problem. Different in what way? Is the mail client encoding differently in the forwarding process? If so, do you know what clients are altering the messages and how? If there's one that's better for this, we could always use it for forwarding since we currently send it to ourselves first, then forward. If we rewrite the Q file and queue directly from IMail, encoding shouldn't change, correct? If that avoids this issue, we could do that instead. >The best solution is to include the headers during the scan since they >will travel with the message. What do you mean? The XHDR? We would love that for more several reasons, but Declude is not the same company anymore. >The next best is to automate matching >the log entries with the message so they can be included with the >submission (some do this to prevent the "second trip"). Yeah, we'd have to automate it. I can't imagine taking the time to manually match for each occurrence of "no rule found". Another item for the automation list. # 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[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Hello Darin, Wednesday, June 7, 2006, 8:44:26 AM, you wrote: > Hi Pete, > Can I interpret this as email address and matching source IP are sufficient > if the correct email address is used to submit? Yes. > If not, do you have any suggestions on how you would like to see us > inserting the license ID in the D file? To clarify, nothing should be inserted in the D file. The original message should be attached as an RFC 822 attachment is as close to the original form as possible. The license id, if included at all, should be in the subject line of the submission message. Remember also, we WILL be responding to the submission message so that we can record a dialogue with you about the false positive in question. Hope this helps, Thanks, _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[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Hello Matt, Wednesday, June 7, 2006, 3:37:36 PM, you wrote: > > Pete, > > An X-Header would be very, very nice to have. I understand the > issues related to waiting to see if something comes through, and > because of that, I would maybe suggest moving on your own. I've got it on the list to have a message rewriting option... it's just not as high as some others. I hadn't thought about the weight gating utility - though that seems like something that would be useful in general for external tests... "weightgate -5 %WEIGHT% 20 " 5 0 is executed if %WEIGHT% is in the range [-5,20] and the exit code of is returned. That seems like a pretty simple utility to knock out - perhaps I will ;-) Also, on the FP reporting links idea, that would break the process - it's important for us to see the message for many reasons, and it's important for the FP resolution process to be interactive. _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[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Hello Darin, Wednesday, June 7, 2006, 7:26:48 PM, you wrote: >>Unfortunately, by the time the message gets to us it is sometimes just >>different enough that the original pattern cannot be found. There are >>some folks who consistently have success, and some who occasionally >>have problems, and a few who always have a problem. > Different in what way? Is the mail client encoding differently in the > forwarding process? If so, do you know what clients are altering the > messages and how? If there's one that's better for this, we could always > use it for forwarding since we currently send it to ourselves first, then > forward. It is unclear - we receive FPs that have traveled through all sorts of clients, quarantine systems, changed hands various numbers of times, or not (to all of those)... Right now I don't want to make that research project a high priority. > If we rewrite the Q file and queue directly from IMail, encoding shouldn't > change, correct? If that avoids this issue, we could do that instead. That's true it wouldn't change, but submitting the message directly would not be correct - the dialogue is with you, and in any case, additional trips through the mail server also modify parts of the header and sometimes parts of the message (tag lines, disclaimers, etc)... >>The best solution is to include the headers during the scan since they >>will travel with the message. > What do you mean? The XHDR? We would love that for more several reasons, > but Declude is not the same company anymore. At some point perhaps they will include the SNF engine in DLL form and all of these issues will become simpler. For now there's no definitive answer on that possibility so we will have to find other solutions. I don't like the idea of rewriting the message file more often than absolutely necessary, but that is a feature that is on the todo list and so it may make it into the next heavy update (work in progress). >>The next best is to automate matching >>the log entries with the message so they can be included with the >>submission (some do this to prevent the "second trip"). > Yeah, we'd have to automate it. I can't imagine taking the time to manually > match for each occurrence of "no rule found". Another item for the > automation list. _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]>
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Pete, Since the %WEIGHT% variable is added by Declude, it might make sense to have a qualifier instead of making the values space delimited. Errors in Declude could cause values to not be inserted, and not everyone will want to skip at a low weight. I haven't seen any bugs with %WEIGHT% since shortly after it was introduced, but you never know. I have seen some issues with other Declude inserted variables though. One other thing that I came across with the way that Declude calls external apps...you can't delimit the data with things like quotes. There is no mechanism for escaping a functional quote from a quote that should appear in the data that you pass to it...so don't use quotes as delimiters :) Matt Pete McNeil wrote: Hello Matt, Wednesday, June 7, 2006, 3:37:36 PM, you wrote: Pete, An X-Header would be very, very nice to have. I understand the issues related to waiting to see if something comes through, and because of that, I would maybe suggest moving on your own. I've got it on the list to have a message rewriting option... it's just not as high as some others. I hadn't thought about the weight gating utility - though that seems like something that would be useful in general for external tests... "weightgate -5 %WEIGHT% 20 " 5 0 is executed if %WEIGHT% is in the range [-5,20] and the exit code of is returned. That seems like a pretty simple utility to knock out - perhaps I will ;-) Also, on the FP reporting links idea, that would break the process - it's important for us to see the message for many reasons, and it's important for the FP resolution process to be interactive. _M
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Right... quotes are no good. That came to light in the context of passing long file names (with spaces); the 8.3 format would be preferred. I've designed my folder structure such that none of the folders had spaces in them; that just happened to be the way it turned out and I'm glad I stuck with it. Andrew. From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Wednesday, June 07, 2006 1:22 PMTo: Message Sniffer CommunitySubject: Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions Pete,Since the %WEIGHT% variable is added by Declude, it might make sense to have a qualifier instead of making the values space delimited. Errors in Declude could cause values to not be inserted, and not everyone will want to skip at a low weight. I haven't seen any bugs with %WEIGHT% since shortly after it was introduced, but you never know. I have seen some issues with other Declude inserted variables though.One other thing that I came across with the way that Declude calls external apps...you can't delimit the data with things like quotes. There is no mechanism for escaping a functional quote from a quote that should appear in the data that you pass to it...so don't use quotes as delimiters :)MattPete McNeil wrote: Hello Matt, Wednesday, June 7, 2006, 3:37:36 PM, you wrote: Pete, An X-Header would be very, very nice to have. I understand the issues related to waiting to see if something comes through, and because of that, I would maybe suggest moving on your own. I've got it on the list to have a message rewriting option... it's just not as high as some others. I hadn't thought about the weight gating utility - though that seems like something that would be useful in general for external tests... "weightgate -5 %WEIGHT% 20 " 5 0 is executed if %WEIGHT% is in the range [-5,20] and the exit code of is returned. That seems like a pretty simple utility to knock out - perhaps I will ;-) Also, on the FP reporting links idea, that would break the process - it's important for us to see the message for many reasons, and it's important for the FP resolution process to be interactive. _M
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
>> Can I interpret this as email address and matching source IP are sufficient >> if the correct email address is used to submit? >Yes. Ok, so the answer to my original suggestion is yes. Great. > If not, do you have any suggestions on how you would like to see us > inserting the license ID in the D file? >To clarify, nothing should be inserted in the D file. The original >message should be attached as an RFC 822 attachment is as close to the >original form as possible. Uh, but the D file contains mime segments corresponding to attachments. >The license id, if included at all, should be in the subject line of >the submission message. Good. Subject line is easier and more reliable to parse out. Not that it's needed per the original question. Darin. # 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]>
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
That would be great if you could add message rewriting. With the complete lack of response by Declude to support emails and the support list, they're going to lost most of us as customers as soon as someone comes out with am IMail/SmarterMail compatible product that has weighting and the array of tests and scriptable filters we've come to rely on. Darin. - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Message Sniffer Community" Sent: Wednesday, June 07, 2006 4:09 PM Subject: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions Hello Matt, Wednesday, June 7, 2006, 3:37:36 PM, you wrote: > > Pete, > > An X-Header would be very, very nice to have. I understand the > issues related to waiting to see if something comes through, and > because of that, I would maybe suggest moving on your own. I've got it on the list to have a message rewriting option... it's just not as high as some others. I hadn't thought about the weight gating utility - though that seems like something that would be useful in general for external tests... "weightgate -5 %WEIGHT% 20 " 5 0 is executed if %WEIGHT% is in the range [-5,20] and the exit code of is returned. That seems like a pretty simple utility to knock out - perhaps I will ;-) Also, on the FP reporting links idea, that would break the process - it's important for us to see the message for many reasons, and it's important for the FP resolution process to be interactive. _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]>
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
>It is unclear - we receive FPs that have traveled through all sorts of >clients, quarantine systems, changed hands various numbers of times, >or not (to all of those)... Right now I don't want to make that >research project a high priority. Understood. >That's true it wouldn't change, but submitting the message directly >would not be correct - the dialogue is with you, and in any case, >additional trips through the mail server also modify parts of the >header and sometimes parts of the message (tag lines, disclaimers, >etc)... Hmmm... with attaching the original message, I guess it still makes more sense to deliver to us first for now. Just looking for an alternative that gets you the message as close as possible to the original form as possible. Maybe we'll write a script to copy and forward the D*.SMD file as an attachment to you for FPs at some point in the future. # 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[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Hello Matt, Wednesday, June 7, 2006, 4:22:05 PM, you wrote: > > Pete, > > Since the %WEIGHT% variable is added by Declude, it might make > sense to have a qualifier instead of making the values space > delimited. I don't want to mix delimiters... everything so far is using spaces, so it makes sense to continue that way IMO. > Errors in Declude could cause values to not be inserted, > and not everyone will want to skip at a low weight. I haven't seen > any bugs with %WEIGHT% since shortly after it was introduced, but > you never know. I have seen some issues with other Declude inserted > variables though. Well, errors are always a possibility, but in this case it _should_ be reasonably safe. For example, if this is used to gate SNF, then a missing %WEIGHT% would result in trying to launch a program with the same name as the authentication string, and it is highly unlikely that would be found, so the result would be the "program not found" error code. That's not perfect because it's a nonzero result, but it is safe in that it is not likely to launch another program. > One other thing that I came across with the way that Declude calls > external apps...you can't delimit the data with things like quotes. > There is no mechanism for escaping a functional quote from a quote > that should appear in the data that you pass to it...so don't use > quotes as delimiters :) Not a problem... I just whipped together a utility called WeightGate.exe that can be downloaded here (for now): http://www.messagesniffer.com/Tools/WeightGate.exe Suppose you wanted to use it in Declude to skip running SNF if your weight was already ridiculously low (perhaps white listed) or already so high that you want to save the extra cycles. Then you might do something like this: SNF external nonzero "c:\tool\WeightGate.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 (hopefully that didn't wrap, and if it did you will know what I meant ;-) To test this concept out you might first create a copy of WeightGate.exe callled ShowMe.exe (case matters!) and then do something like this: SNF external nonzero "c:\tool\ShowMe.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 The result of that would be the creation of a file c:\ShowMe.log that contained all of the parameters ShowMe.exe was called with -- that way you wouldn't have to guess if it was correct. ShowMe.exe ALWAYS returns zero, so this _should_ be safe ;-) If you run WeightGate on the command line without parameters it will tell you all about itself and it's alter ego ShowMe.exe. That description goes like this (I may fix the typo(s) later): WeightGate.exe (C) 2006 ARM Research Labs, LLC. This program is distributed AS-IS, with no warranty of any kind. You are welcome to use this program on your own systems or those that you directly support. Please do not redistribute this program except as noted above, however feel free to recommend this program to others if you wish and direct them to our web site where they can download it for themselves. Thanks! www.armresearch.com. This program is most commonly used to control the activation of external test programs from within Declude (www.declude.com) based on the weigth that has been calculated thus far for a given message. As an added feature, if you rename this program to ShowMe.exe then it will emit all of the command line arguments as it sees them to a file called c:\ShowMe.log so that you can use it as a debugging aid. If you are seeing this message, you have used this program incorrectly. The correct invocation for this program is: WeightGate , ,... Where: = a number representing the lowest weight to run . = a number representing the actual weight to evaluate. = a number representing the highest weight to run . = the program to be activated if is in range. , = arguments for . If is in the range [,] then WeightGate will run and pass all of , ,... to it. Then WeightGate will collect the exit code of and return it as WeightGate's exit code. If WeightGate gets the wrong number of parameters it will display this message and return FAIL_SAFE (zero) as it's exit code. If is not in range (less than or greater than ) then WeightGate will NOT launch and will return FAIL_SAFE (zero) as it's exit code. As a deubgging aid, I was called with the following arguments: arg[0] = WeightGate -- 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[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Hello Darin, Wednesday, June 7, 2006, 5:05:28 PM, you wrote: > Uh, but the D file contains mime segments corresponding to attachments. That's ok. SNF looks inside those, and w/ the FP scanning software inside the rfc822 atachment also. It's not perfect, but the majority of the time it does pick out the rules that match and having the original helps us put those into context. >>The license id, if included at all, should be in the subject line of >>the submission message. > Good. Subject line is easier and more reliable to parse out. Not that it's > needed per the original question. :-) -- 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]>
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Pete, I think that you just broke Scott's record with his two hour feature request with your own a two hour program :) Anyone remember those days??? Thanks, Matt Pete McNeil wrote: Hello Matt, Wednesday, June 7, 2006, 4:22:05 PM, you wrote: Pete, Since the %WEIGHT% variable is added by Declude, it might make sense to have a qualifier instead of making the values space delimited. I don't want to mix delimiters... everything so far is using spaces, so it makes sense to continue that way IMO. Errors in Declude could cause values to not be inserted, and not everyone will want to skip at a low weight. I haven't seen any bugs with %WEIGHT% since shortly after it was introduced, but you never know. I have seen some issues with other Declude inserted variables though. Well, errors are always a possibility, but in this case it _should_ be reasonably safe. For example, if this is used to gate SNF, then a missing %WEIGHT% would result in trying to launch a program with the same name as the authentication string, and it is highly unlikely that would be found, so the result would be the "program not found" error code. That's not perfect because it's a nonzero result, but it is safe in that it is not likely to launch another program. One other thing that I came across with the way that Declude calls external apps...you can't delimit the data with things like quotes. There is no mechanism for escaping a functional quote from a quote that should appear in the data that you pass to it...so don't use quotes as delimiters :) Not a problem... I just whipped together a utility called WeightGate.exe that can be downloaded here (for now): http://www.messagesniffer.com/Tools/WeightGate.exe Suppose you wanted to use it in Declude to skip running SNF if your weight was already ridiculously low (perhaps white listed) or already so high that you want to save the extra cycles. Then you might do something like this: SNF external nonzero "c:\tool\WeightGate.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 (hopefully that didn't wrap, and if it did you will know what I meant ;-) To test this concept out you might first create a copy of WeightGate.exe callled ShowMe.exe (case matters!) and then do something like this: SNF external nonzero "c:\tool\ShowMe.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 The result of that would be the creation of a file c:\ShowMe.log that contained all of the parameters ShowMe.exe was called with -- that way you wouldn't have to guess if it was correct. ShowMe.exe ALWAYS returns zero, so this _should_ be safe ;-) If you run WeightGate on the command line without parameters it will tell you all about itself and it's alter ego ShowMe.exe. That description goes like this (I may fix the typo(s) later): WeightGate.exe (C) 2006 ARM Research Labs, LLC. This program is distributed AS-IS, with no warranty of any kind. You are welcome to use this program on your own systems or those that you directly support. Please do not redistribute this program except as noted above, however feel free to recommend this program to others if you wish and direct them to our web site where they can download it for themselves. Thanks! www.armresearch.com. This program is most commonly used to control the activation of external test programs from within Declude (www.declude.com) based on the weigth that has been calculated thus far for a given message. As an added feature, if you rename this program to ShowMe.exe then it will emit all of the command line arguments as it sees them to a file called c:\ShowMe.log so that you can use it as a debugging aid. If you are seeing this message, you have used this program incorrectly. The correct invocation for this program is: WeightGate , ,... Where: = a number representing the lowest weight to run . = a number representing the actual weight to evaluate. = a number representing the highest weight to run . = the program to be activated if is in range. , = arguments for . If is in the range [,] then WeightGate will run and pass all of , ,... to it. Then WeightGate will collect the exit code of and return it as WeightGate's exit code. If WeightGate gets the wrong number of parameters it will display this message and return FAIL_SAFE (zero) as it's exit code. If is not in range (less than or greater than ) then WeightGate will NOT launch and will return FAIL_SAFE (zero) as it's exit code. As a deubgging aid, I was called with the following arguments: arg[0] = WeightGate
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
(sniff) Aw, cut it out, Matt. You're making me all weepy. p.s. Pete, that's pretty darned amazing! From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Wednesday, June 07, 2006 3:58 PMTo: Message Sniffer CommunitySubject: Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions Pete,I think that you just broke Scott's record with his two hour feature request with your own a two hour program :)Anyone remember those days???Thanks,MattPete McNeil wrote: Hello Matt, Wednesday, June 7, 2006, 4:22:05 PM, you wrote: Pete, Since the %WEIGHT% variable is added by Declude, it might make sense to have a qualifier instead of making the values space delimited. I don't want to mix delimiters... everything so far is using spaces, so it makes sense to continue that way IMO. Errors in Declude could cause values to not be inserted, and not everyone will want to skip at a low weight. I haven't seen any bugs with %WEIGHT% since shortly after it was introduced, but you never know. I have seen some issues with other Declude inserted variables though. Well, errors are always a possibility, but in this case it _should_ be reasonably safe. For example, if this is used to gate SNF, then a missing %WEIGHT% would result in trying to launch a program with the same name as the authentication string, and it is highly unlikely that would be found, so the result would be the "program not found" error code. That's not perfect because it's a nonzero result, but it is safe in that it is not likely to launch another program. One other thing that I came across with the way that Declude calls external apps...you can't delimit the data with things like quotes. There is no mechanism for escaping a functional quote from a quote that should appear in the data that you pass to it...so don't use quotes as delimiters :) Not a problem... I just whipped together a utility called WeightGate.exe that can be downloaded here (for now): http://www.messagesniffer.com/Tools/WeightGate.exe Suppose you wanted to use it in Declude to skip running SNF if your weight was already ridiculously low (perhaps white listed) or already so high that you want to save the extra cycles. Then you might do something like this: SNF external nonzero "c:\tool\WeightGate.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 (hopefully that didn't wrap, and if it did you will know what I meant ;-) To test this concept out you might first create a copy of WeightGate.exe callled ShowMe.exe (case matters!) and then do something like this: SNF external nonzero "c:\tool\ShowMe.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 The result of that would be the creation of a file c:\ShowMe.log that contained all of the parameters ShowMe.exe was called with -- that way you wouldn't have to guess if it was correct. ShowMe.exe ALWAYS returns zero, so this _should_ be safe ;-) If you run WeightGate on the command line without parameters it will tell you all about itself and it's alter ego ShowMe.exe. That description goes like this (I may fix the typo(s) later): WeightGate.exe (C) 2006 ARM Research Labs, LLC. This program is distributed AS-IS, with no warranty of any kind. You are welcome to use this program on your own systems or those that you directly support. Please do not redistribute this program except as noted above, however feel free to recommend this program to others if you wish and direct them to our web site where they can download it for themselves. Thanks! www.armresearch.com. This program is most commonly used to control the activation of external test programs from within Declude (www.declude.com) based on the weigth that has been calculated thus far for a given message. As an added feature, if you rename this program to ShowMe.exe then it will emit all of the command line arguments as it sees them to a file called c:\ShowMe.log so that you can use it as a debugging aid. If you are seeing this message, you have used this program incorrectly. The correct invocation for this program is: WeightGate , ,... Where: = a number representing the lowest weight to run . = a number representing the actual weight to evaluate. = a number representing the highest weight to run . = the program to be activated if is in range. , = arguments for . If is in the range [,] then WeightGate will run and pass all of , ,... to it. Then WeightGate will collect the exit code of and return it as WeightGate's exit code. If WeightGate gets the wrong number of parameters it will display this message and return FAIL_SAFE (zero) as it's exit code. If is not in range (less than or greater than ) then WeightGate will NOT launch and will return FAIL_SAFE (zero) as it's exit code. As a deubgging aid, I was called with the following arguments: arg[0] = WeightGate
Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Awesome. Great job, Pete. Darin. - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Message Sniffer Community" Sent: Wednesday, June 07, 2006 6:49 PM Subject: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions Hello Matt, Wednesday, June 7, 2006, 4:22:05 PM, you wrote: > > Pete, > > Since the %WEIGHT% variable is added by Declude, it might make > sense to have a qualifier instead of making the values space > delimited. I don't want to mix delimiters... everything so far is using spaces, so it makes sense to continue that way IMO. > Errors in Declude could cause values to not be inserted, > and not everyone will want to skip at a low weight. I haven't seen > any bugs with %WEIGHT% since shortly after it was introduced, but > you never know. I have seen some issues with other Declude inserted variables though. Well, errors are always a possibility, but in this case it _should_ be reasonably safe. For example, if this is used to gate SNF, then a missing %WEIGHT% would result in trying to launch a program with the same name as the authentication string, and it is highly unlikely that would be found, so the result would be the "program not found" error code. That's not perfect because it's a nonzero result, but it is safe in that it is not likely to launch another program. > One other thing that I came across with the way that Declude calls > external apps...you can't delimit the data with things like quotes. > There is no mechanism for escaping a functional quote from a quote > that should appear in the data that you pass to it...so don't use > quotes as delimiters :) Not a problem... I just whipped together a utility called WeightGate.exe that can be downloaded here (for now): http://www.messagesniffer.com/Tools/WeightGate.exe Suppose you wanted to use it in Declude to skip running SNF if your weight was already ridiculously low (perhaps white listed) or already so high that you want to save the extra cycles. Then you might do something like this: SNF external nonzero "c:\tool\WeightGate.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 (hopefully that didn't wrap, and if it did you will know what I meant ;-) To test this concept out you might first create a copy of WeightGate.exe callled ShowMe.exe (case matters!) and then do something like this: SNF external nonzero "c:\tool\ShowMe.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 The result of that would be the creation of a file c:\ShowMe.log that contained all of the parameters ShowMe.exe was called with -- that way you wouldn't have to guess if it was correct. ShowMe.exe ALWAYS returns zero, so this _should_ be safe ;-) If you run WeightGate on the command line without parameters it will tell you all about itself and it's alter ego ShowMe.exe. That description goes like this (I may fix the typo(s) later): WeightGate.exe (C) 2006 ARM Research Labs, LLC. This program is distributed AS-IS, with no warranty of any kind. You are welcome to use this program on your own systems or those that you directly support. Please do not redistribute this program except as noted above, however feel free to recommend this program to others if you wish and direct them to our web site where they can download it for themselves. Thanks! www.armresearch.com. This program is most commonly used to control the activation of external test programs from within Declude (www.declude.com) based on the weigth that has been calculated thus far for a given message. As an added feature, if you rename this program to ShowMe.exe then it will emit all of the command line arguments as it sees them to a file called c:\ShowMe.log so that you can use it as a debugging aid. If you are seeing this message, you have used this program incorrectly. The correct invocation for this program is: WeightGate , ,... Where: = a number representing the lowest weight to run . = a number representing the actual weight to evaluate. = a number representing the highest weight to run . = the program to be activated if is in range. , = arguments for . If is in the range [,] then WeightGate will run and pass all of , ,... to it. Then WeightGate will collect the exit code of and return it as WeightGate's exit code. If WeightGate gets the wrong number of parameters it will display this message and return FAIL_SAFE (zero) as it's exit code. If is not in range (less than or greater than ) then WeightGate will NOT launch and will return FAIL_SAFE (zero) as it's exit code. As a deubgging aid, I was called with the following arguments: arg[0] = WeightGate -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed
[sniffer]AW: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Yes I can remember those days. At this time it was fascinating to contribute the own time and brain with the goal to improve the filters. Now the only communiaction from Declude I receive is from Declude Sales "... be advised that your Declude Service Agreement will expire on ..." Has anyone received back any answer regarding the no-action issue? I'm going to prepare a very angry mail send back to declude sales and stating that I will not more pay any further SA if they don't publish at least a statement that they have noticed there is a possible bug and what they intend to do. The message will go CC to the public list with an invitation to other customers to do the same thing. "Service agreement" is build by two words. I have to pay and they agree to offer service for this payment. I have payd but there is no service. Markus Von: Message Sniffer Community [mailto:[EMAIL PROTECTED] Im Auftrag von MattGesendet: Donnerstag, 8. Juni 2006 00:58An: Message Sniffer CommunityBetreff: Re: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions Pete,I think that you just broke Scott's record with his two hour feature request with your own a two hour program :)Anyone remember those days???Thanks,MattPete McNeil wrote: Hello Matt, Wednesday, June 7, 2006, 4:22:05 PM, you wrote: Pete, Since the %WEIGHT% variable is added by Declude, it might make sense to have a qualifier instead of making the values space delimited. I don't want to mix delimiters... everything so far is using spaces, so it makes sense to continue that way IMO. Errors in Declude could cause values to not be inserted, and not everyone will want to skip at a low weight. I haven't seen any bugs with %WEIGHT% since shortly after it was introduced, but you never know. I have seen some issues with other Declude inserted variables though. Well, errors are always a possibility, but in this case it _should_ be reasonably safe. For example, if this is used to gate SNF, then a missing %WEIGHT% would result in trying to launch a program with the same name as the authentication string, and it is highly unlikely that would be found, so the result would be the "program not found" error code. That's not perfect because it's a nonzero result, but it is safe in that it is not likely to launch another program. One other thing that I came across with the way that Declude calls external apps...you can't delimit the data with things like quotes. There is no mechanism for escaping a functional quote from a quote that should appear in the data that you pass to it...so don't use quotes as delimiters :) Not a problem... I just whipped together a utility called WeightGate.exe that can be downloaded here (for now): http://www.messagesniffer.com/Tools/WeightGate.exe Suppose you wanted to use it in Declude to skip running SNF if your weight was already ridiculously low (perhaps white listed) or already so high that you want to save the extra cycles. Then you might do something like this: SNF external nonzero "c:\tool\WeightGate.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 (hopefully that didn't wrap, and if it did you will know what I meant ;-) To test this concept out you might first create a copy of WeightGate.exe callled ShowMe.exe (case matters!) and then do something like this: SNF external nonzero "c:\tool\ShowMe.exe -50 %WEIGHT% 30 c:\SNF\sniffer.exe authenticationxx" 10 0 The result of that would be the creation of a file c:\ShowMe.log that contained all of the parameters ShowMe.exe was called with -- that way you wouldn't have to guess if it was correct. ShowMe.exe ALWAYS returns zero, so this _should_ be safe ;-) If you run WeightGate on the command line without parameters it will tell you all about itself and it's alter ego ShowMe.exe. That description goes like this (I may fix the typo(s) later): WeightGate.exe (C) 2006 ARM Research Labs, LLC. This program is distributed AS-IS, with no warranty of any kind. You are welcome to use this program on your own systems or those that you directly support. Please do not redistribute this program except as noted above, however feel free to recommend this program to others if you wish and direct them to our web site where they can download it for themselves. Thanks! www.armresearch.com. This program is most commonly used to control the activation of external test programs from within Declude (www.declude.com) based on the weigth that has been calculated thus far for a given message. As an added feature, if you rename this program to ShowMe.exe then it will emit all of the command line arguments as it sees them to a file called c:\ShowMe.log so that you can use it as a debugging aid. If you are seeing this message, you have used this program incorrectly. The correct i
[sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]Re[2]: [sniffer]FP suggestions
Hello Andrew, Wednesday, June 7, 2006, 6:59:52 PM, you wrote: > > > (sniff) Aw, cut it out, Matt. > > > > You're making me all weepy. > > > > p.s. Pete, that's pretty darned amazing! Well,... I was interrupted by kids, crazy house contractors, nosey neighbors, phones, IM, and, well... all of that... So, let's see if it works as advertised (in the real world) before we get too excited ;-) Please do let me know right away so I can fix it if it's broke. Thanks! _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]>
