Re[2]: [sniffer] Downloads are slow.
Somebody please tell me I'm doing something wrong here. I use this expression in Baregrep "Final\t828931" and it yields 22,055 matching lines across 3 of my 4 license's log files. Since this is set to my hold weight, I'm assuming that means I've had 22,055 holds on this rule? -- Best regards, Davidmailto:[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
[sniffer] Bad Rule - 828931
Sorry, wrong thread on the last post. Add'l question. Pete, what is the content of the rule? Tuesday, February 7, 2006, 6:05:53 PM, you wrote: DS> Somebody please tell me I'm doing something wrong here. I use this DS> expression in Baregrep "Final\t828931" and it yields 22,055 matching DS> lines across 3 of my 4 license's log files. DS> Since this is set to my hold weight, I'm assuming that means I've had DS> 22,055 holds on this rule? -- Best regards, Davidmailto:[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[2]: [sniffer] Bad Rule - 828931
Hello Matt, Tuesday, February 7, 2006, 6:27:25 PM, you wrote: M> rule number, and I don't have the tools set up or the knowledge of grep M> yet to do a piped query of Sniffer's logs to extract the spool file names. http://www.baremetalsoft.com/ is a great grep'er for windows. In BSD I always used ".*" to represent any number of characters, white space or non, but that didn't seem to work with baregrep. That's why I was trying to confirm with anyone on the list my regex of "Final\t828931" was an accurate regex to find every message that 'finaled' on that rule. I'm praying that I screwed up the expression and I don't have 22,055 messages held by that rule. M> BTW, David, it is generally better not to hold or block on one single M> test, especially one that automates such listings (despite whatever M> safeguards there might be). I know, shame on me. I guess I'm used to the days that we used to be able to hold on sniffer alone. We have some safeguards in place now and are transitioning our rule methodologies but hadn't gotten to this one yet as this always seems to hit back-burner. This is also why I'd really like to see the content of the rule to see how it made it passed our safeguards. -- Best regards, Davidmailto:[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[4]: [sniffer] Bad Rule - 828931
Hello William, Tuesday, February 7, 2006, 7:39:05 PM, you wrote: LWMU> grep -c "Final.*828931" c:\imail\declude\sniffer\logfile.log That's what I tried. Just figured out I forgot to capitalize the "F". It works. Confirmed - 22,055 I'm writing a program now to parse the sniffer log file, extract the file ID, lookup the id in sql server, determine quarantine location, extract q/d pair from quarantine and send to user. -- Best regards, Davidmailto:[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[2]: [sniffer] Bad Rule - 828931
Hello Pete, Tuesday, February 7, 2006, 7:43:52 PM, you wrote: PM> The rule would match the intended spam (and there was a lot of it, so PM> 22,055 most likely includes mostly spam. On spot check I'm seeing about 30-40% of the messages are valid. PM> Unfortunately it would also match messages containing the listed PM> capital letters in that order throughout the message. Essentially, if PM> the text is long enough then it will probably match. A greater chance PM> of FP match if the text of the message is in all caps. Also if there PM> is a badly coded base64 segment and file attachment (badly coded PM> base64 might not be decoded... raw base64 will contain many of these PM> letters in mixed case and therefore increase the probability of PM> matching them all). Not sure, can anyone think of a way to cross check this? What if I put all the released messages back through sniffer? -- Best regards, Davidmailto:[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[4]: [sniffer] Bad Rule - 828931
Hello Pete, Tuesday, February 7, 2006, 8:11:50 PM, you wrote: DS>> Not sure, can anyone think of a way to cross check this? What if I put DS>> all the released messages back through sniffer? PM> That would be good -- new rules were added to correctly capture the PM> bad stuff. I almost suggested something more complex. That said...anyone know specifics of reprocessing messages through Declude on Imail? I know that in 1.x Declude would drop some kind of marker so that q/d's copied into spool would not be reprocessed but I don't remember what it was and don't know if it works same in 3.x. Posted question on Declude JM list but no answer so far. -- Best regards, Davidmailto:[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[6]: [sniffer] Bad Rule - 828931
Hello John, Tuesday, February 7, 2006, 8:30:57 PM, you wrote: JC> Drop the q/d files back into the \spool\proc directory. Declude will JC> reprocess them. If you put them in just the \spool, queue manager will send JC> them out in the next queue run, bypassing Declude. Perfect, thanks. I just dropped the q/d from known spam into \proc and it reprocessed and HELD again. -- Best regards, Davidmailto:[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] problems!!!!
Wednesday, February 8, 2006, 11:19:52 AM, you wrote: AS> The only idea I came up with, would be to have ALL new rules go into a 6 AS> hour "proving" category (=return code) before they are moved into their AS> "final" category. AS> By using Sniffer return codes, folks could decide to "trust" the established AS> rules and decide to "cross-check" any new rules by weighing them against AS> other sources/methods. That's a pretty good idea. New rules in a category we could assign lower weight to and once the rule was proved not to be problematic, it could automatically fall into its normal category. My results: 22,055 reprocessed 1,578 spam 20,477 release I expect about 30% of the released were spam but they came clean through sniffer. -- Best regards, Davidmailto:[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[2]: [sniffer] Max Evals Error
Hello Pete, PM> It is theoretically possible for too many evaluators to be spawned, PM> but highly unlikely. Most of the time, fewer than 100 are generated. PM> It's ok for this to happen, but it is noteworthy. PM> I will look for any rules that make this more likely than usual. I have a monitor that constantly monitors all log files and this is the first alert on this error that I've seen. -- Best regards, Davidmailto:[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
[sniffer] Re: Increase in spam
We've doubled the amount of spam being HELD in the past 7 weeks and spam leakage has about doubled as well. -- Best regards, Davidmailto:[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]>
