[sniffer] Test - ignore
Sorry for all these tests -- but a new copy of Declude Interceptor seems to want to completely lose messages from lists. Rob # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] test -6:35 please ignre
Please ignore this test.# This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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] Test
Pong John T eServices For You Seek, and ye shall find! -Original Message- From: sniffer@sortmonster.com [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, May 15, 2006 10:12 PM To: sniffer@sortmonster.com Subject: Test Hello sniffer, Just testing. -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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 E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Test
pong... Pete McNeil wrote: Hello sniffer, Just testing. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Test
Message received... Sharon Portage College |-+-- | | Pete McNeil| | | [EMAIL PROTECTED]| | | search.com| | | Sent by: | | | [EMAIL PROTECTED]| | | r.com | | | | | | | | | 05/15/2006 11:12 PM| | | Please respond to | | | sniffer| |-+-- --| | | | To: sniffer@sortmonster.com | | cc: | | Subject: Test | --| Hello sniffer, Just testing. -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. 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 E-mail scanned for viruses by Declude Virus] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Test
Apologies, but need to test. Robert
RE: [sniffer] Test
Ping? Pong. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert MathiasSent: Thursday, August 04, 2005 3:59 PMTo: sniffer@SortMonster.comSubject: [sniffer] Test Apologies, but need to test. Robert
RE: [sniffer] test sender
Title: Message Well, an indirect way to do this is to use the (undocumented?) Declude directive: rsp set off TESTNAME as the first bit of text in your test message. That won't actually trigger sniffer, but it will for the purpose of making your JunkMail think that the test has been triggered. Andrew 8) -Original Message-From: Bonno Bloksma [mailto:[EMAIL PROTECTED] Sent: Friday, December 10, 2004 1:26 PMTo: [EMAIL PROTECTED]Subject: [sniffer] test sender Hi, Is there a test sender where I can have the program send us a test mail that should fail a specific sniffer test? I know I can test sniffer itself agains a single good and bad file, but I want to test the chain. The Declude site has something like that where it is sending the EICAR teststringin the various ways a virus might reach the mailserver. That way the full setup of the mailserver with the scanner can be tested. I would like something where I can send myself a msg which should fail with an exitcode for TRAVEL or for PORN etc. That way I can test for sure whether my "improvements" haven't broken something in stead of waiting till my users complain (certain) spam has increased. It's the small typos that can get to ya in a big way. ;-) Groetjes, Bonno Bloksma Back up my hard drive? How do I put it in reverse? _
Re[2]: [sniffer] Test ordering/precedence
On Friday, December 3, 2004, 8:53:26 AM, Joe wrote: JW OK, I'm confused. First I admit I don't spend much time on Sniffer or JW Declude settings, and I haven't learned the programs very well. JW I used the default Sniffer config files. If I changed as indicated below JW will it catch more SPAM? No. It won't catch more spam. If you are happy with your current configuration then there is no need to change. On some systems it is possible to get a better spam capture rates and lower false positives by fine tuning in this way. On most systems this is not necessary. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Test ordering/precedence
Hello Sniffer Folks, During a previous discussion in late September, it was generally agreed that it was time to re-order the priority of the experimental and generalized rule groups. I am going to begin that work today. The new ordering will be: 63: Experimental Received [IP] 62: Obfuscation 61: Experimental Abstract 60: General The concept of this priority is to give more specific rules a higher priority over less specific rules. So, for example, a spam text pattern or URI in the General group will have priority over an IP rule. By the end of the day these rule groups will have been renumbered. While this will have some subtle effects over time as the rulebase system learns some new structures, the most important short term effects will be seen by systems that give individual weights to each rule group. Please begin making the appropriate changes in your weighting schemes if you use them. Systems that do not use weighting schemes will not need to take any action. Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Test ordering/precedence
On Thursday, December 2, 2004, 4:15:43 PM, Jim wrote: JM Pete, JM We have rules setup in declude based upon sniffer return codes 60 and 62 to JM mark all messages with those tests as spam, however we do not have any 61 or JM 62 return codes setup. Can you briefly explain what each of these groups JM includes and a false positive rate for each. The false positive rates for all of these rule groups have fallen dramatically over the past 8 months and at this point they are all comparable. Different systems see different rates, but all rates are low. Group 63 - Experimental Received [IP] - contains rules that match Receive headers by IP. These are now largely generated by robots which monitor inbound spamtrap and usertrap data and then test those sources. This group used to provide the second largest rate of false positives. The rate now is roughly the same as any other group. Group 62 - Obfuscation - contains rules built to detect obfuscation techniques. Internally this group breaks down into a number of sub-groups which detect unnecessary URL encoding, HEX encoding, and HTML obfuscation patterns. Group 61 - Experimental Abstract - contains rules that are designed to recognize data patterns and structures found in spam. For example errors in headers combined with message structures, misspellings, unusual uses for table and HTML structures or message segments, and other abstract patterns that result from the use of scripting engines to generate polymorphic spam. Note: Group 60 was Gray-Hosting many months ago. That group was retired and then reused. Now it is being renumbered again. Group 60 - General (Ungrouped) - contains many of the same kinds of rules found in other groups, but particularly those which cannot be accurately categorized there. For example, fake diploma spam. These rules are largely text segments, domains, URI/URL segments, and structures (much like those found in group 61). Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re:[sniffer] Test ordering/precedence
Where can i find examples of using exit codes to assign different weights depending on groupes, when using sniffer with declude/imail ? TIA - Original Message - From: Pete McNeil [EMAIL PROTECTED] To: Jim Matuska [EMAIL PROTECTED] Sent: Thursday, December 02, 2004 9:59 PM Subject: Re[2]: [sniffer] Test ordering/precedence On Thursday, December 2, 2004, 4:15:43 PM, Jim wrote: JM Pete, JM We have rules setup in declude based upon sniffer return codes 60 and 62 to JM mark all messages with those tests as spam, however we do not have any 61 or JM 62 return codes setup. Can you briefly explain what each of these groups JM includes and a false positive rate for each. The false positive rates for all of these rule groups have fallen dramatically over the past 8 months and at this point they are all comparable. Different systems see different rates, but all rates are low. Group 63 - Experimental Received [IP] - contains rules that match Receive headers by IP. These are now largely generated by robots which monitor inbound spamtrap and usertrap data and then test those sources. This group used to provide the second largest rate of false positives. The rate now is roughly the same as any other group. Group 62 - Obfuscation - contains rules built to detect obfuscation techniques. Internally this group breaks down into a number of sub-groups which detect unnecessary URL encoding, HEX encoding, and HTML obfuscation patterns. Group 61 - Experimental Abstract - contains rules that are designed to recognize data patterns and structures found in spam. For example errors in headers combined with message structures, misspellings, unusual uses for table and HTML structures or message segments, and other abstract patterns that result from the use of scripting engines to generate polymorphic spam. Note: Group 60 was Gray-Hosting many months ago. That group was retired and then reused. Now it is being renumbered again. Group 60 - General (Ungrouped) - contains many of the same kinds of rules found in other groups, but particularly those which cannot be accurately categorized there. For example, fake diploma spam. These rules are largely text segments, domains, URI/URL segments, and structures (much like those found in group 61). Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Test ordering/precedence
On Saturday, September 18, 2004, 11:22:02 PM, Matt wrote: M Thanks Pete, but let me just stress the largest issue that I see and I M think you already are aware of it. The new IP classification is the M most likely to produce false positives and it's result code of 60 places M precedence of that over General, Experimental and Obfuscation hits. M There is a large difference in accuracy on my system between IP rules M and the other three tests. I hinted at this when you first made the M change from that category being Gray (which I didn't score) to IP but M got no response :) I guess I didn't get the hint. Sorry. M I score IP at 4 but the other three are all scored at a 6. The false M positives with things like General tend to drop significantly over time M as you report false positives, and I believe it to be over 98% accurate M on my system while the IP hits have a much higher false positive rate M based on open relay mail servers and message bounces to forged addresses M that correspond to your spamtraps (I get a lot of IP hits on the bounce M messages that we block, many of these from legitimate servers). I would M have desired the IP hits to have been added as a result code of 64 M instead of replacing the result code of 60 for this reason. This makes sense. I didn't think about that at the time because I was trying to minimize the change. Simply splitting IP rules into a then-unused group 60 was a very easy change to make. M I'm sure that you can run some stats to figure out how often IP hits M might override General, Experimental and Obfuscation hits, and get a M better idea as to the potential impact of having a generally higher M scoring test hit. I know it would have an effect on weighted systems, M though I'm not sure how large that effect might be. As things stand on M my system, IP is the #3 test and I fear that it is stealing hits from M more accurate tests, especially the #2 test, Experimental which happens I'm guessing you mean Experimental Abstract. M to be very good at tagging zombies and hitting new sources of spam that M aren't as widely blacklisted due to the types of rules that are M present. Here are some recent numbers from my system: M SNIFFER-EXPERIMENTAL...23.32% M SNIFFER-IP...9.70% M SNIFFER-OBFUSCATION...2.02% M SNIFFER-GENERAL.1.64% I must be tired, but I don't understand these numbers in this context. What are the percentages? M So now might not be the time for this due to the potential of having to M modify configs, but please minimally consider it at the next opportunity M where a change such as the Gray to IP rules are done. I've actually been thinking very strongly of reorganizing the rule group IDs recently. Especially in light of the new changes we've made with robots et al. The accuracy of the Experimental IP group has gone up considerably - and most of the false positives you've discussed should be eliminated over time (bounces especially). All that said, I think the first step to reordering the groups might be to change the sequence of the 4 highest numbers as follows: 63: Experimental Received [IP] 62: Obfuscation 61: Experimental Abstract 60: General This order is based on a least to most specific order. It turns out that the majority of General rules are simply specific patterns that don't fit existing rule groups; Experimental Abstract tend to be either abstracted patterns from specific or general patterns - or automatically generated URI candidates; Obfuscation are patterns that detect obfuscation techniques that are not specific to any particular kind of spam, and since Received [IP] rules only identify a source they are the most generalized (whether manually or automatically generated). According to a recent spam test quality analysis the accuracy and coverage for these groups in this order follows like this: 63: Experimental Received [IP]SA = 0.81 Coverage = 7.63% 62: Obfuscation SA = 1.00 Coverage = 2.58% 61: Experimental Abstract SA = 0.92 Coverage = 25.82% 60: General SA = 0.81 Coverage = 1.82% How would you feel about this order? _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: Re[2]: [sniffer] Test ordering/precedence
-Original Message- From: Pete McNeil [mailto:[EMAIL PROTECTED] I've actually been thinking very strongly of reorganizing the rule group IDs recently. Especially in light of the new changes we've made with robots et al. The accuracy of the Experimental IP group has gone up considerably - and most of the false positives you've discussed should be eliminated over time (bounces especially). All that said, I think the first step to reordering the groups might be to change the sequence of the 4 highest numbers as follows: 63: Experimental Received [IP] 62: Obfuscation 61: Experimental Abstract 60: General This order is based on a least to most specific order. It turns out that the majority of General rules are simply specific patterns that don't fit existing rule groups; Experimental Abstract tend to be either abstracted patterns from specific or general patterns - or automatically generated URI candidates; Obfuscation are patterns that detect obfuscation techniques that are not specific to any particular kind of spam, and since Received [IP] rules only identify a source they are the most generalized (whether manually or automatically generated). According to a recent spam test quality analysis the accuracy and coverage for these groups in this order follows like this: 63: Experimental Received [IP]SA = 0.81 Coverage = 7.63% 62: Obfuscation SA = 1.00 Coverage = 2.58% 61: Experimental Abstract SA = 0.92 Coverage = 25.82% 60: General SA = 0.81 Coverage = 1.82% How would you feel about this order? ++ I'm not Matt, but I very much like this idea. Please let us know when you plan to make this change so we can adjust our tests accordingly. Thanks! Bill --- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Test ordering/precedence
Pete, Given some of the recent changes in the result codes for Sniffer, I thought I would inquire about the precedence of the result codes and how these can affect systems. On my system I have weighted the result codes differently and overall, I would consider the following order to be suggestive of the order of reliability from the most reliable to the least reliable. Note that this is not scientific, but instead based on doing review and tests that hit less often could appear higher in terms of stated reliability though I have considered this in making the list: 1. SNIFFER-INK(56) SNIFFER-CASINO(59) SNIFFER-INSURANCE(48) SNIFFER-MEDIA(50) SNIFFER-GETRICH(57) SNIFFER-DEBT(58) SNIFFER-PHARMACY(52) 2. SNIFFER-AVSOFT(49) SNIFFER-PHISHING(53) 3. SNIFFER-TRAVEL(47) SNIFFER-PORN(54) 4. SNIFFER-SPAMWARE(51) SNIFFER-OBFUSCATION(61) SNIFFER-MALWARE(55) 5. SNIFFER-EXPERIMENTAL(62) 6. SNIFFER-GENERAL(63) 7. SNIFFER-IP(60) I'm not sure exactly how Sniffer orders the precedence of the result code, but I would like to recommend that you give some consideration to reviewing such things in light of recent changes and also maybe consider allowing us to customize the precedence as a part of our rulebase. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [sniffer] Test ordering/precedence
Matt Matt Matt. Then everyone would have to make sure they made the relevant changes on their systems. As we have seen on the Declude Junkmail list, there will always be those who set up their systems and then forget about them. Making a change like that would cause problems. John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Saturday, September 18, 2004 5:28 PM To: [EMAIL PROTECTED] Subject: [sniffer] Test ordering/precedence Pete, Given some of the recent changes in the result codes for Sniffer, I thought I would inquire about the precedence of the result codes and how these can affect systems. On my system I have weighted the result codes differently and overall, I would consider the following order to be suggestive of the order of reliability from the most reliable to the least reliable. Note that this is not scientific, but instead based on doing review and tests that hit less often could appear higher in terms of stated reliability though I have considered this in making the list: 1. SNIFFER-INK(56) SNIFFER-CASINO(59) SNIFFER-INSURANCE(48) SNIFFER-MEDIA(50) SNIFFER-GETRICH(57) SNIFFER-DEBT(58) SNIFFER-PHARMACY(52) 2. SNIFFER-AVSOFT(49) SNIFFER-PHISHING(53) 3. SNIFFER-TRAVEL(47) SNIFFER-PORN(54) 4. SNIFFER-SPAMWARE(51) SNIFFER-OBFUSCATION(61) SNIFFER-MALWARE(55) 5. SNIFFER-EXPERIMENTAL(62) 6. SNIFFER-GENERAL(63) 7. SNIFFER-IP(60) I'm not sure exactly how Sniffer orders the precedence of the result code, but I would like to recommend that you give some consideration to reviewing such things in light of recent changes and also maybe consider allowing us to customize the precedence as a part of our rulebase. Thanks, Matt -- =MailPure custom filters for Declude JunkMail Pro.http://www.mailpure.com/software/=
Re: [sniffer] Test ordering/precedence
John, If you read this more carefully, I was not suggesting that action be taken that would affect everyone's system in such a way that it would require modifications. The 60 result code was recently changed from Gray rules to IP rules, and that change may or may not suggest a modification to the standard way that Sniffer operates (considering that the environment will only return one result code). Sniffer may or may not follow the numerical ordering of the result codes at present, but then again, it might. Regardless, it wouldn't be a bad idea to review the precedence as a part of ongoing due diligence. I also recommended one potential solution for customization by controlling the precedence from within the rule base and I would also imagine that the new config file could also be used to control this. So if a change was made, I'm sure it wouldn't be done unless it was measurable and would be to everyone's benefit, and it if Pete felt the need, it could be done in such a way so that only those that would want to change it would need to take action. I try to make it a practice to consider the needs of others before I give suggestions or ask for new capabilities, and I did do that in this case. I don't doubt that others have slightly different ordering in terms of what they feel is more and less accurate, and of course results can vary widely across systems. Pete is especially sensitive to these needs and has done a wonderful job of customizing rule bases without placing the burden on his customers to do so. Matt John Tolmachoff (Lists) wrote: Matt Matt Matt. Then everyone would have to make sure they made the relevant changes on their systems. As we have seen on the Declude Junkmail list, there will always be those who set up their systems and then forget about them. Making a change like that would cause problems. John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Saturday, September 18, 2004 5:28 PM To: [EMAIL PROTECTED] Subject: [sniffer] Test ordering/precedence Pete, Given some of the recent changes in the result codes for Sniffer, I thought I would inquire about the precedence of the result codes and how these can affect systems. On my system I have weighted the result codes differently and overall, I would consider the following order to be suggestive of the order of reliability from the most reliable to the least reliable. Note that this is not scientific, but instead based on doing review and tests that hit less often could appear higher in terms of stated reliability though I have considered this in making the list: 1. SNIFFER-INK(56) SNIFFER-CASINO(59) SNIFFER-INSURANCE(48) SNIFFER-MEDIA(50) SNIFFER-GETRICH(57) SNIFFER-DEBT(58) SNIFFER-PHARMACY(52) 2. SNIFFER-AVSOFT(49) SNIFFER-PHISHING(53) 3. SNIFFER-TRAVEL(47) SNIFFER-PORN(54) 4. SNIFFER-SPAMWARE(51) SNIFFER-OBFUSCATION(61) SNIFFER-MALWARE(55) 5. SNIFFER-EXPERIMENTAL(62) 6. SNIFFER-GENERAL(63) 7. SNIFFER-IP(60) I'm not sure exactly how Sniffer orders the precedence of the result code, but I would like to recommend that you give some consideration to reviewing such things in light of recent changes and also maybe consider allowing us to customize the precedence as a part of our rulebase. Thanks, Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re[2]: [sniffer] Test ordering/precedence
On Saturday, September 18, 2004, 9:07:55 PM, Matt wrote: M John, M If you read this more carefully, I was not suggesting that M action betaken that would affect everyone's system in such a way M that it wouldrequire modifications. The 60 result code was M recently changed fromGray rules to IP rules, and that change may or M may not suggest amodification to the standard way that Sniffer M operates (consideringthat the environment will only return one M result code). Sniffer may ormay not follow the numerical ordering M of the result codes at present,but then again, it might. M Regardless, it wouldn't be a bad idea toreview the precedence as a M part of ongoing due diligence. I alsorecommended one potential I agree it's not a bad idea to review these things from time to time, and in fact we do quite frequently - though not publicly. I also agree that making any sweeping changes would probably be a mistake at this time. Well guys, here is how it goes. When more than one rule matches, the one with the lowest symbol # wins. If there is more than one match within that symbol then the one that is earliest in the message wins. This is why we code white rules to symbol 0, or symbol 1 in some cases; and also why we generally reserve the lower numbered symbols for any specific user requests. As much as possible we've ordered the rule groups so that the least specific rules are found in the higher numbers and the more specific rules are in the lower numbers. We even have some rules (work in progress) that are above band in the 65-255 range which have special meanings and functions. These will become more important later as these features are further developed. There are a lot of schemes out there that can be used, and in fact we can use an entirely different scheme for each user if we wish - though that might be a lot of work (so we might have to charge extra for the consulting time to develop and maintain such a thing). The scheme that we have is a little bit out of date*, but it still seems to work for most folks, so we'll probably keep it around for a while. We've had a number of alternate schemes suggested, some that might even be practical to implement - but none that wouldn't cause quite a bit of upheaval if we suddenly decided to rework everything for our current users. In fact, there are only a hand full of people who ever even mention it. Since your list shows 60, 63, 62, and 61 all at the bottom of your list I'm guessing that the current voting scheme is probably in line with your priorities at this point. That is, more specific rules (by symbol #) seem to line up roughly with your estimate of accuracy. Hope this helps, _M * Little out of date: Spammers almost always reuse URI and numbered links on multiple campaigns these days. This wasn't the case so much when we began. One result of this shift is that it is now common to find Snake-Oil spam matching a porn rule vice versa. In fact, the actual kind of spam probably matches the rule group less than 31.6% of the time (and of course 94% of statistics are made up on the spot - which means, 1/3 is a guess on my part from looking at spam all day). We've kept the scheme, however, because there are many rules that we create which are not based on URI and these tend to remain accurate to the type of spam. Also, since we generate and review our rules largely through a manual process - it helps to know what kind of spam we were looking at when we created the rule. That is, we are less likely to err while looking at a porn/adult spam than we are when looking at a travel spam - so differences in our accuracy are likely to develop along the groups we've selected - even if the type of spam captured by the rule migrates over time. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Test ordering/precedence
Thanks Pete, but let me just stress the largest issue that I see and I think you already are aware of it. The new IP classification is the most likely to produce false positives and it's result code of 60 places precedence of that over General, Experimental and Obfuscation hits. There is a large difference in accuracy on my system between IP rules and the other three tests. I hinted at this when you first made the change from that category being Gray (which I didn't score) to IP but got no response :) I score IP at 4 but the other three are all scored at a 6. The false positives with things like General tend to drop significantly over time as you report false positives, and I believe it to be over 98% accurate on my system while the IP hits have a much higher false positive rate based on open relay mail servers and message bounces to forged addresses that correspond to your spamtraps (I get a lot of IP hits on the bounce messages that we block, many of these from legitimate servers). I would have desired the IP hits to have been added as a result code of 64 instead of replacing the result code of 60 for this reason. I'm sure that you can run some stats to figure out how often IP hits might override General, Experimental and Obfuscation hits, and get a better idea as to the potential impact of having a generally higher scoring test hit. I know it would have an effect on weighted systems, though I'm not sure how large that effect might be. As things stand on my system, IP is the #3 test and I fear that it is stealing hits from more accurate tests, especially the #2 test, Experimental which happens to be very good at tagging zombies and hitting new sources of spam that aren't as widely blacklisted due to the types of rules that are present. Here are some recent numbers from my system: SNIFFER-EXPERIMENTAL...23.32% SNIFFER-IP...9.70% SNIFFER-OBFUSCATION...2.02% SNIFFER-GENERAL.1.64% So now might not be the time for this due to the potential of having to modify configs, but please minimally consider it at the next opportunity where a change such as the Gray to IP rules are done. Thanks, Matt Pete McNeil wrote: On Saturday, September 18, 2004, 9:07:55 PM, Matt wrote: M John, M If you read this more carefully, I was not suggesting that M action betaken that would affect everyone's system in such a way M that it wouldrequire modifications. The 60 result code was M recently changed fromGray rules to IP rules, and that change may or M may not suggest amodification to the standard way that Sniffer M operates (consideringthat the environment will only return one M result code). Sniffer may ormay not follow the numerical ordering M of the result codes at present,but then again, it might. M Regardless, it wouldn't be a bad idea toreview the precedence as a M part of ongoing due diligence. I alsorecommended one potential I agree it's not a bad idea to review these things from time to time, and in fact we do quite frequently - though not publicly. I also agree that making any sweeping changes would probably be a mistake at this time. Well guys, here is how it goes. When more than one rule matches, the one with the lowest symbol # wins. If there is more than one match within that symbol then the one that is earliest in the message wins. This is why we code white rules to symbol 0, or symbol 1 in some cases; and also why we generally reserve the lower numbered symbols for any specific user requests. As much as possible we've ordered the rule groups so that the least specific rules are found in the higher numbers and the more specific rules are in the lower numbers. We even have some rules (work in progress) that are above band in the 65-255 range which have special meanings and functions. These will become more important later as these features are further developed. There are a lot of schemes out there that can be used, and in fact we can use an entirely different scheme for each user if we wish - though that might be a lot of work (so we might have to charge extra for the consulting time to develop and maintain such a thing). The scheme that we have is a little bit out of date*, but it still seems to work for most folks, so we'll probably keep it around for a while. We've had a number of alternate schemes suggested, some that might even be practical to implement - but none that wouldn't cause quite a bit of upheaval if we suddenly decided to rework everything for our current users. In fact, there are only a hand full of people who ever even mention it. Since your list shows 60, 63, 62, and 61 all at the bottom of your list I'm guessing that the current voting scheme is probably in line with your priorities at this point. That is, more specific rules (by symbol #) seem to line up roughly with your estimate of accuracy. Hope this helps, _M * Little out of date: Spammers almost always reuse URI and
RE: [sniffer] test
Every rulebase is potentially a different size composition, plus sizes typically change with each update. I'm glad to hear all the positive reports on this. :-) _M At 11:43 AM 5/4/2004, you wrote: This process is also working well for me so far. File sizes, however, are closer to 2Mbyte than to 1: 12:24:17 (78.89 KB/s) - `sniffer2.new.gz' saved [1983539/1983539] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, April 30, 2004 8:48 PM To: [EMAIL PROTECTED] Subject: Re: [sniffer] test mod_gzip is now configured on our web server to handle .snf files. This means that if your download mechanism is capable of accepting gzip encoding then you can get your .snf file from the web server for less than 1Mbyte typically. This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] test
At 02:49 PM 5/4/2004, Vivek Khera wrote: On May 4, 2004, at 3:42 PM, Pete McNeil wrote: Every rulebase is potentially a different size composition, plus sizes typically change with each update. I'm glad to hear all the positive reports on this. :-) Forgive me... What is the URL for the zipped version of the file... :( Thanks, Russ --- [This E-mail scanned for viruses by Declude Virus] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] test
At 04:17 PM 5/4/2004, you wrote: At 02:49 PM 5/4/2004, Vivek Khera wrote: On May 4, 2004, at 3:42 PM, Pete McNeil wrote: Every rulebase is potentially a different size composition, plus sizes typically change with each update. I'm glad to hear all the positive reports on this. :-) Forgive me... What is the URL for the zipped version of the file... :( Actually - the URL is the same. The file will be compressed with gzip if your browser (or wget, etc...) notifies the server that it can accept that type of compression. This requires a little bit of extra scripting and that you download gzip. This hasn't made it to the archive yet but I think the following message snippet will help you get started: This can be done with wget, for example, but setting this up appears to be technically complex - so I'm going to leave it at that for now. (Requires the --header switch and piping the output through gzip) It is not so complex: In the wget command change -O sniffer.new to -O sniffer.new.gz and add the switch --header=Accept-Encoding:gzip And in the next line put the command gzip -d -f sniffer.new.gz That looks about right. Of course you will also need to download gzip to make this work if you don't already have it. http://www.gzip.org/ _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] test
This may have been aswered before but what do we do with the emails coming in and getting by the filter with .zip files that look like a virus...I have Declude 1.79 installeddo I have to go as far as to exclude all .zip files? Richard Farris Ethixs Online 1.270.247. Office 1.800.548.3877 Tech Support - Original Message - From: Pete McNeil [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 3:49 PM Subject: Re: [sniffer] test At 04:17 PM 5/4/2004, you wrote: At 02:49 PM 5/4/2004, Vivek Khera wrote: On May 4, 2004, at 3:42 PM, Pete McNeil wrote: Every rulebase is potentially a different size composition, plus sizes typically change with each update. I'm glad to hear all the positive reports on this. :-) Forgive me... What is the URL for the zipped version of the file... :( Actually - the URL is the same. The file will be compressed with gzip if your browser (or wget, etc...) notifies the server that it can accept that type of compression. This requires a little bit of extra scripting and that you download gzip. This hasn't made it to the archive yet but I think the following message snippet will help you get started: This can be done with wget, for example, but setting this up appears to be technically complex - so I'm going to leave it at that for now. (Requires the --header switch and piping the output through gzip) It is not so complex: In the wget command change -O sniffer.new to -O sniffer.new.gz and add the switch --header=Accept-Encoding:gzip And in the next line put the command gzip -d -f sniffer.new.gz That looks about right. Of course you will also need to download gzip to make this work if you don't already have it. http://www.gzip.org/ _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] test
We have done everything the mailing has been saying, and we have 1.79, and we catch about 3 viruses per day, but we know that our customers are still receiving 30 to 40 of these per day or more. Is there anything that can be done in our configuration that is sent to us every night to rid us of this problem? Eddie Arrants Cape Lookout Internet Services -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Tuesday, May 04, 2004 8:46 PM To: Richard Farris; [EMAIL PROTECTED] Subject: Re: [sniffer] test This may have been aswered before but what do we do with the emails coming in and getting by the filter with .zip files that look like a virus...I have Declude 1.79 installeddo I have to go as far as to exclude all .zip files? Not quite. You need to ban all encrypted .ZIP files (since no AV program can always detect viruses in encrypted .ZIP files). With v1.79, you can add a line BANEXT EZIP to your virus.cfg file to do that. Then, all known viruses will be blocked. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] test
This can be done with wget, for example, but setting this up appears to be technically complex - so I'm going to leave it at that for now. (Requires the --header switch and piping the output through gzip) It is not so complex: In the wget command change -O sniffer.new to -O sniffer.new.gz and add the switch --header=Accept-Encoding:gzip And in the next line put the command gzip -d -f sniffer.new.gz Roger This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] test
At 07:13 AM 5/1/2004, you wrote: This can be done with wget, for example, but setting this up appears to be technically complex - so I'm going to leave it at that for now. (Requires the --header switch and piping the output through gzip) It is not so complex: In the wget command change -O sniffer.new to -O sniffer.new.gz and add the switch --header=Accept-Encoding:gzip And in the next line put the command gzip -d -f sniffer.new.gz That looks about right. Of course you will also need to download gzip to make this work if you don't already have it. http://www.gzip.org/ _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] test
Appears to work beautifully. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Saturday, May 01, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: [sniffer] test At 07:13 AM 5/1/2004, you wrote: This can be done with wget, for example, but setting this up appears to be technically complex - so I'm going to leave it at that for now. (Requires the --header switch and piping the output through gzip) It is not so complex: In the wget command change -O sniffer.new to -O sniffer.new.gz and add the switch --header=Accept-Encoding:gzip And in the next line put the command gzip -d -f sniffer.new.gz That looks about right. Of course you will also need to download gzip to make this work if you don't already have it. http://www.gzip.org/ _M --- [This E-mail scanned for viruses by Declude Virus] This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Test
Didn't happen this time, nevermind! Frederic TaraseviciusInternet Information Services, Inc.http://www.i-is.com/810-794-4400mailto:[EMAIL PROTECTED] - Original Message - From: Fred To: [EMAIL PROTECTED] Sent: Monday, March 29, 2004 1:42 PM Subject: [sniffer] Test I'm seeing header corruption today on this group, just a test message.. Frederic TaraseviciusInternet Information Services, Inc.http://www.i-is.com/810-794-4400mailto:[EMAIL PROTECTED]
Re: [sniffer] Test
:-) At 04:31 PM 3/29/2004, you wrote: Didn't happen this time, nevermind! Frederic Tarasevicius Internet Information Services, Inc. http://www.i-is.com/ 810-794-4400 mailto:[EMAIL PROTECTED] - Original Message - From: Fred To: [EMAIL PROTECTED] Sent: Monday, March 29, 2004 1:42 PM Subject: [sniffer] Test I'm seeing header corruption today on this group, just a test message.. Frederic Tarasevicius Internet Information Services, Inc. http://www.i-is.com/ 810-794-4400 mailto:[EMAIL PROTECTED]
