Hello Sniffer folks,
I'm sorry to report that another bad rule got past us today. The
rule has been removed (was in from about 1200-1500), but it may be
in some of your rulebases.
To avoid a problem with this rule you can enter a rule-panic entry
in your .cfg file for rule id: 828931
Dear Pete,
In the future, please let us know immediately when you become aware of this.
As it is, I will spend the next 3 hours picking out the fales positives from
the mailbox and forwarding them to the clients. If I could have put the
rulepanic in place an hour ago it would have saved me a
I do most humbly apologize,
It was my intention to do it immediately, however I became embroiled
in related support issues and was delayed.
I don't expect more of these, but I will make announcing their
discovery the next event after removing them from the system.
Thanks,
_M
On Tuesday,
Dear Pete,
Please excuse my previous E-mail if it seemed a bit harsh. I guess I am so
used to your great service, that on the rare occasion when this happens, I
panic.
Thanks for being there to walk me through the procedure.
Sincerely,
Michael Stein
Computer House
- Original Message
I'm not showing this from my location and the server looks ok.
I just downloaded a few rulebases, each in under 3 seconds.
Please provide a traceroute -- that should show us where the issue is
(if it is still there).
Thanks,
_M
On Tuesday, February 7, 2006, 4:39:35 PM, Chuck wrote:
CS
Agreed, my last report showed pretty slow times. All today were slower now
that I look at them. I normally see up to 1.3M with overall times around
800-900K.
John C
0K .. .. .. .. .. 36.79 KB/s
50K .. .. .. ..
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,
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
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
Don't know about the proper syntax for baregrep, but for the standard UNIX
grep for Win32, the following would give you an accurate count:
grep -c Final.*828931 c:\imail\declude\sniffer\logfile.log
Bill
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of
Final\t828931 and Final.*828931 both found 850 entries in my current log
using Baregrep.
John C
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David Sullivan
Sent: Tuesday, February 07, 2006 6:12 PM
To: sniffer@SortMonster.com
Subject: Re[2]: [sniffer]
On Tuesday, February 7, 2006, 6:15:13 PM, David wrote:
DS Sorry, wrong thread on the last post.
DS Add'l question. Pete, what is the content of the rule?
The rule info is:
Rule - 828931
NameC%+I%+A%+L%+I%+S%+V%+I%+A%+G%+R%+A
Created 2006-02-07
Source
I don't get into the sniffer logs like I should, but just noticed this. It
is 2/7/06 6:42 CST here, but my logs show 20060208004243, which would
indicate +6 hours off of Zulu, Greenwich, Coordinated Universal Time, or
whatever we are calling these days. Is that right, sniffer doesn't stamp
local
I've had an internal note that our colo provider is working on a
networking problem. That's probably what you're seeing. Apparently it
doesn't effect all paths to the 'net equally and/or it may be solved
by now.
_M
On Tuesday, February 7, 2006, 5:53:35 PM, John wrote:
JC Agreed, my last report
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
So, in my terms (simple), this rule only catches msg if the two drug names
are in that order and in all capitals, but not necessarily one immediately
following the other?
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Pete McNeil
Sent: Tuesday,
On Tuesday, February 7, 2006, 7:48:05 PM, John wrote:
JC I don't get into the sniffer logs like I should, but just noticed this. It
JC is 2/7/06 6:42 CST here, but my logs show 20060208004243, which would
JC indicate +6 hours off of Zulu, Greenwich, Coordinated Universal Time, or
JC whatever we
On Tuesday, February 7, 2006, 8:14:53 PM, David wrote:
DS Hello Pete,
DS 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
Pete,
Gotcha. Basically anything that I trapped that is over 10 KB may have
failed this (because that would be indicative of having an attachment in
base64). It is much less likely to have hit on things without
attachments, but it of course would be possible, and the bigger it was,
the
Pete,
The overflow directory disappeared when 3.x was introduced. I posted a
follow up on the Declude list about how to do this.
Matt
Pete McNeil wrote:
On Tuesday, February 7, 2006, 8:14:53 PM, David wrote:
DS Hello Pete,
DS Tuesday, February 7, 2006, 8:11:50 PM, you wrote:
DS Not
David
Drop the q/d files back into the \spool\proc directory. Declude will
reprocess them. If you put them in just the \spool, queue manager will send
them out in the next queue run, bypassing Declude.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
I just ran the grep command on my log and I got 850 hits.
Now is there a way to take the output of the grep command and use it
pull out the total weight of corresponding message from the declude log
file, or maybe the subject?
Goran Jovanovic
Omega Network Solutions
-Original
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
Thanks for the update, Pete.
I also appreciate that you expanded on how that rule went wild. I can
see that the intent was good but the unintended consequences were not so
good.
Here's how it played out on my server:
How many messages hit the FP rules: 2,042
How many messages Declude decided
Thanks for the update, Pete.I also appreciate that
you expanded on how that rule went wild. I can see that the intent was
good but the unintended consequences were not so good.Here's how it
played out on my server:How many messages hit the FP rules: 2,042How
many messages Declude decided
OK to answer my own question. Run the following commands
grep -U Final.828931 snf.log 1.txt
cut -b26-41 1.txt 2.txt
grep -U -f2.txt d:\spool\dec0207.log 3.txt
egrep -U \smd Tests failed|\smd Subject 3.txt 4.txt
notepad 4.txt
Now I have to read my 4.txt and figure out what I am going to do about
26 matches
Mail list logo
