RE: [sniffer] problems!!!!
Harry,
(please don't post your entire license code to a public
list.)
regarding the reliability of sniffer we should know that
errors sometimes can happen, even at sniffer-side after they've worked for years
now very relaible. I don't expect that such errors will happen now more
often.
What you can do is trying to configure your declude
spamfilter in order to hold only if multiple or at least more then one test
failed. For doing this the first step is to set the maximum weight of each test
(at least slightly) below your hold weight.
I've configured different weights for different sniffer
exit codes depending how reliable they seem to me but as a maximum weight for
sniffer I've set 95% of the mark-subjectline-weight and around 63% of the
hold-weight. So the problematic sniffer-rule from yesterday was not a real
problem on our server. There was some single messages who has had a final weight
above the the hold weight because we use combinations of the most
reliabletests. From several thousand processed messages only around 20
messages has had a false-positive combination caused by sniffer-rule82893 and
another spam test.
Thanks to Andrew and Goran for their info's and scripts.
Saved a lot of time here.
Pete: Any info if and if yes when you can adapt MDLP for
the declude v3 logfile? I realy miss this data. Once accustomized
tothehourly results of MDLP e sometimes feel now like a blind
chicken :-)
Markus
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harry
VanderzandSent: Wednesday, February 08, 2006 4:02 PMTo:
sniffer@SortMonster.comSubject: [sniffer]
problems
With the recent issues at sniffer it has caused
tremendous problems with the entire client base here.
Sniffer has been so reliable for so lond and al of a
sudden recently I cannot rely on it any more
What is going on with sniffer
Will these issues get resolved or is it going to be more
unstable than what we have come to rely on?
I need my spam trap software to work without spend hours
everyday and without getting a large group of my customers questioning
the reliability of what I am doing.
Hope there will be some indication of
improvement.
The following is my sniffer code
SNIFFERexternal nonzero
"D:\IMail\Declude\sniffer\sniffer.exex" 10 0
Should I be doing something different?
This
has worked very well for a year now.
Harry Vanderzand inTown Internet Computer Services 519-741-1222
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck,
AndrewSent: Tuesday, February 07, 2006 9:42 PMTo:
sniffer@SortMonster.comSubject: RE: Re[4]: [sniffer] Bad Rule -
828931
Goran, this is pretty much what I did to
get to re-queuing:gawk "$0 ~
/Final\t828931/ {print substr($3,2,16)}" gxamq2kt.log.20060207*
msgids.txtThe file msgids.txt will now contain just the
GUID part of the D[guid].SMD from column 3 in the tab delimited Message
Sniffer log files.I then used a batch file I had previously created
called qm.cmd (for queue and move). Note that the folders I specify
are for Declude 1.x, which has an overflow folder. I use the overflow
folder so that Declude will re-analyze the message:Rem this is the qm.cmd file listingmove
d:\imail\spool\spam\d%1.smd u:\imail\spool\ nulmove
d:\imail\spool\spam\q%1.smd u:\imail\spool\overflow\ nulI
then issued from the command line:for /F %i in (msgids.txt) do
@qm.cmd %iThat takes of re-queuing all the held messages. I am
using a move instead of a copy because I want Declude to be able to move a
message it deems spam to the spam folder. If I used a copy, it would
fail to do the move because the file is already in the spam folder, and
Declude would then pass control back to Imail, which would then deliver the
spam inbound.After my queue went back to normal, I then set to work
on my dec0207.log file to determine if the entirety of the message was spam
or ham based on whether it was held or not (which is the simple scenario I
have).I hope that helps,Andrew 8)
p.s. Another re-posting in HTML so as to
preserve the line breaks. Sorry for the duplication,
folks.
-Original
Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Goran Jovanovic Sent: Tuesday, February 07, 2006 5:39
PM To: sniffer@SortMonster.com Subject: RE: Re[4]: [sniffer]
Bad Rule - 828931 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
Message- From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
RE: [sniffer] problems!!!!
thank you
Sorry for the licence goof. Just finished 4 hours
going through spam
Harry Vanderzand inTown Internet Computer Services 519-741-1222
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Markus
GuflerSent: Wednesday, February 08, 2006 10:48 AMTo:
sniffer@SortMonster.comSubject: RE: [sniffer]
problems
Harry,
(please don't post your entire license code to a public
list.)
regarding the reliability of sniffer we should know that
errors sometimes can happen, even at sniffer-side after they've worked for
years now very relaible. I don't expect that such errors will happen now more
often.
What you can do is trying to configure your declude
spamfilter in order to hold only if multiple or at least more then one test
failed. For doing this the first step is to set the maximum weight of each
test (at least slightly) below your hold weight.
I've configured different weights for different sniffer
exit codes depending how reliable they seem to me but as a maximum weight for
sniffer I've set 95% of the mark-subjectline-weight and around 63% of the
hold-weight. So the problematic sniffer-rule from yesterday was not a real
problem on our server. There was some single messages who has had a final
weight above the the hold weight because we use combinations of the most
reliabletests. From several thousand processed messages only around 20
messages has had a false-positive combination caused by sniffer-rule82893 and
another spam test.
Thanks to Andrew and Goran for their info's and scripts.
Saved a lot of time here.
Pete: Any info if and if yes when you can adapt MDLP for
the declude v3 logfile? I realy miss this data. Once accustomized
tothehourly results of MDLP e sometimes feel now like a blind
chicken :-)
Markus
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harry
VanderzandSent: Wednesday, February 08, 2006 4:02
PMTo: sniffer@SortMonster.comSubject: [sniffer]
problems
With the recent issues at sniffer it has caused
tremendous problems with the entire client base here.
Sniffer has been so reliable for so lond and al of a
sudden recently I cannot rely on it any more
What is going on with sniffer
Will these issues get resolved or is it going to be
more unstable than what we have come to rely on?
I need my spam trap software to work without spend
hours everyday and without getting a large group of my customers
questioning the reliability of what I am doing.
Hope there will be some indication of
improvement.
The following is my sniffer code
SNIFFERexternal
nonzero "D:\IMail\Declude\sniffer\sniffer.exex" 10 0
Should I be doing something different?
This has worked very well for a year now.
Harry Vanderzand inTown Internet Computer Services 519-741-1222
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck,
AndrewSent: Tuesday, February 07, 2006 9:42 PMTo:
sniffer@SortMonster.comSubject: RE: Re[4]: [sniffer] Bad Rule -
828931
Goran, this is pretty much what I did to
get to re-queuing:gawk "$0 ~
/Final\t828931/ {print substr($3,2,16)}" gxamq2kt.log.20060207*
msgids.txtThe file msgids.txt will now contain just the
GUID part of the D[guid].SMD from column 3 in the tab delimited Message
Sniffer log files.I then used a batch file I had previously
created called qm.cmd (for queue and move). Note that the folders I
specify are for Declude 1.x, which has an overflow folder. I use the
overflow folder so that Declude will re-analyze the message:Rem this is the qm.cmd file listingmove
d:\imail\spool\spam\d%1.smd u:\imail\spool\ nulmove
d:\imail\spool\spam\q%1.smd u:\imail\spool\overflow\
nulI then issued from the command line:for /F
%i in (msgids.txt) do @qm.cmd %iThat takes of re-queuing all the
held messages. I am using a move instead of a copy because I want
Declude to be able to move a message it deems spam to the spam
folder. If I used a copy, it would fail to do the move because the
file is already in the spam folder, and Declude would then pass control
back to Imail, which would then deliver the spam inbound.After my
queue went back to normal, I then set to work on my dec0207.log file to
determine if the entirety of the message was spam or ham based on whether
it was held or not (which is the simple scenario I have).I hope
that helps,Andrew 8)
p.s. Another re-posting in HTML so as to
preserve the line breaks. Sorry for the duplication,
folks.
-Original
Message- From: [EMAIL PROTECTED]
Re: [sniffer] problems!!!!
I have an idea. These problems seem to stem
mostly from changes in the methods of handling rulebase updates.
We were lucky enough not to be affected with the
latest rule issue, but the previous one made for a very long day
andsomedisgruntled customers.
Would it be feasible to announce in advance when
such changes are to be implemented? With advance notice of a date and time
for the switch we could choose to freeze our rulebases just before that for a
day to make sure the kinks were worked out before updating. A few spam
messages that slip through are better than a slough of false positives that
require review and are delayed in reaching the customer.
Thoughts?
Darin.
- Original Message -
From: Harry Vanderzand
To: sniffer@SortMonster.com
Sent: Wednesday, February 08, 2006 10:02 AM
Subject: [sniffer] problems
With the recent issues at sniffer it has caused tremendous
problems with the entire client base here.
Sniffer has been so reliable for so lond and al of a sudden
recently I cannot rely on it any more
What is going on with sniffer
Will these issues get resolved or is it going to be more
unstable than what we have come to rely on?
I need my spam trap software to work without spend hours
everyday and without getting a large group of my customers questioning the
reliability of what I am doing.
Hope there will be some indication of
improvement.
The following is my sniffer code
SNIFFERexternal nonzero
"D:\IMail\Declude\sniffer\umzqbs4l.exe dky4t444qqpk69j6" 10 0
Should
I be doing something different?
This
has worked very well for a year now.
Harry Vanderzand inTown Internet Computer Services 519-741-1222
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck,
AndrewSent: Tuesday, February 07, 2006 9:42 PMTo:
sniffer@SortMonster.comSubject: RE: Re[4]: [sniffer] Bad Rule -
828931
Goran, this is pretty much what I did to get
to re-queuing:gawk "$0 ~ /Final\t828931/
{print substr($3,2,16)}" gxamq2kt.log.20060207*
msgids.txtThe file msgids.txt will now contain just the
GUID part of the D[guid].SMD from column 3 in the tab delimited Message
Sniffer log files.I then used a batch file I had previously created
called qm.cmd (for queue and move). Note that the folders I specify are
for Declude 1.x, which has an overflow folder. I use the overflow folder
so that Declude will re-analyze the message:Rem this is the qm.cmd file listingmove
d:\imail\spool\spam\d%1.smd u:\imail\spool\ nulmove
d:\imail\spool\spam\q%1.smd u:\imail\spool\overflow\ nulI
then issued from the command line:for /F %i in (msgids.txt) do @qm.cmd
%iThat takes of re-queuing all the held messages. I am using a
move instead of a copy because I want Declude to be able to move a message it
deems spam to the spam folder. If I used a copy, it would fail to do the
move because the file is already in the spam folder, and Declude would then
pass control back to Imail, which would then deliver the spam
inbound.After my queue went back to normal, I then set to work on my
dec0207.log file to determine if the entirety of the message was spam or ham
based on whether it was held or not (which is the simple scenario I
have).I hope that helps,Andrew 8)
p.s. Another re-posting in HTML so as to
preserve the line breaks. Sorry for the duplication,
folks.
-Original
Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Goran Jovanovic Sent: Tuesday, February 07, 2006 5:39 PM
To: sniffer@SortMonster.com Subject: RE: Re[4]: [sniffer] Bad Rule -
828931 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
Message- From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of David Sullivan Sent: Tuesday, February 07, 2006
7:47 PM To: Landry, William (MED US) Subject: 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,
David
mailto:[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 This E-Mail came from the Message Sniffer mailing
list. For informat
RE: [sniffer] problems!!!!
If I understand right you mean that if "experimental" rules
are introduced you want to know about and so temporaly disable ruelbase updates
on you server.
As I know Sniffer has a much smarter way for doing this.
They introduce experimental rules in a separate category (sniffer-exp) and look
how they will work. In fact I can see that this category is the least reliable.
So I've set a relative low weight for this exit code.
If a experimental rule showed to be reliable they move them
in the appropriate category (rich, fraud,...)
I'm not sure about this but I think it's so and so it
shouldn't be necessary to do something like manualy block
updates.
Markus
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darin
CoxSent: Wednesday, February 08, 2006 4:59 PMTo:
sniffer@SortMonster.comSubject: Re: [sniffer]
problems
I have an idea. These problems seem to stem
mostly from changes in the methods of handling rulebase updates.
We were lucky enough not to be affected with the
latest rule issue, but the previous one made for a very long day
andsomedisgruntled customers.
Would it be feasible to announce in advance when
such changes are to be implemented? With advance notice of a date and
time for the switch we could choose to freeze our rulebases just before that
for a day to make sure the kinks were worked out before updating. A few
spam messages that slip through are better than a slough of false positives
that require review and are delayed in reaching the customer.
Thoughts?
Darin.
- Original Message -
From: Harry Vanderzand
To: sniffer@SortMonster.com
Sent: Wednesday, February 08, 2006 10:02 AM
Subject: [sniffer] problems
With the recent issues at sniffer it has caused
tremendous problems with the entire client base here.
Sniffer has been so reliable for so lond and al of a
sudden recently I cannot rely on it any more
What is going on with sniffer
Will these issues get resolved or is it going to be more
unstable than what we have come to rely on?
I need my spam trap software to work without spend hours
everyday and without getting a large group of my customers questioning
the reliability of what I am doing.
Hope there will be some indication of
improvement.
The following is my sniffer code
SNIFFERexternal nonzero
"D:\IMail\Declude\sniffer\umzqbs4l.exe dky4t444qqpk69j6" 10 0
Should I be doing something different?
This
has worked very well for a year now.
Harry Vanderzand inTown Internet Computer Services 519-741-1222
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck,
AndrewSent: Tuesday, February 07, 2006 9:42 PMTo:
sniffer@SortMonster.comSubject: RE: Re[4]: [sniffer] Bad Rule -
828931
Goran, this is pretty much what I did to
get to re-queuing:gawk "$0 ~
/Final\t828931/ {print substr($3,2,16)}" gxamq2kt.log.20060207*
msgids.txtThe file msgids.txt will now contain just the
GUID part of the D[guid].SMD from column 3 in the tab delimited Message
Sniffer log files.I then used a batch file I had previously created
called qm.cmd (for queue and move). Note that the folders I specify
are for Declude 1.x, which has an overflow folder. I use the overflow
folder so that Declude will re-analyze the message:Rem this is the qm.cmd file listingmove
d:\imail\spool\spam\d%1.smd u:\imail\spool\ nulmove
d:\imail\spool\spam\q%1.smd u:\imail\spool\overflow\ nulI
then issued from the command line:for /F %i in (msgids.txt) do
@qm.cmd %iThat takes of re-queuing all the held messages. I am
using a move instead of a copy because I want Declude to be able to move a
message it deems spam to the spam folder. If I used a copy, it would
fail to do the move because the file is already in the spam folder, and
Declude would then pass control back to Imail, which would then deliver the
spam inbound.After my queue went back to normal, I then set to work
on my dec0207.log file to determine if the entirety of the message was spam
or ham based on whether it was held or not (which is the simple scenario I
have).I hope that helps,Andrew 8)
p.s. Another re-posting in HTML so as to
preserve the line breaks. Sorry for the duplication,
folks.
-Original
Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Goran Jovanovic Sent: Tuesday, February 07, 2006 5:39
PM To: sniffer@SortMonster.com Subject: RE: Re[4]: [sniffer]
Bad Rule - 828931 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?
Re[2]: [sniffer] problems!!!!
On Wednesday, February 8, 2006, 10:59:09 AM, Darin wrote: DC I have an idea. These problems seem to stem mostly from changes DC in the methods of handling rulebase updates. snip/ DC Would it be feasible to announce in advance when such changes DC are to be implemented? With advance notice of a date and time DC for the switch we could choose to freeze our rulebases just before DC that for a day to make sure the kinks were worked out before DC updating. A few spam messages that slip through are better than DC a slough of false positives that require review and are delayed in reaching the customer. That's a good idea, and we do, in fact, follow that procedure. Whenever we make any large scale changes we always announce them here on this list,... we usually also put them on our web site. There is an error in your comment however... the previous event (with the rule-bots) was completely unforeseeable. There was no way to announce that known good software would suddenly fail so spectacularly when no changes within our control were made. Thankfully, that kind of event is extremely unlikely also. It is unfortunate that these two events would happen so closely together. _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] problems!!!!
There was no error in my comment. I completely understand that some issues will not be foreseeable... I did say mostly, not entirely. The switch to the automated bots caused a rash of false positives in our system. I'm not pointing fingers, but instead want to make sure I have the ability to decide what risks to take on my end. While mistakes are always possible... we are human after all... the more controls we have available to minimize possible impact, the better. What I would be looking for is an announcement of a specific date/time for a cutover so we could freeze just before that, and unfreeze once it was clear that no glut of false positives would result. Darin. - Original Message - From: Pete McNeil [EMAIL PROTECTED] To: Darin Cox sniffer@SortMonster.com Sent: Wednesday, February 08, 2006 11:13 AM Subject: Re[2]: [sniffer] problems On Wednesday, February 8, 2006, 10:59:09 AM, Darin wrote: DC I have an idea. These problems seem to stem mostly from changes DC in the methods of handling rulebase updates. snip/ DC Would it be feasible to announce in advance when such changes DC are to be implemented? With advance notice of a date and time DC for the switch we could choose to freeze our rulebases just before DC that for a day to make sure the kinks were worked out before DC updating. A few spam messages that slip through are better than DC a slough of false positives that require review and are delayed in reaching the customer. That's a good idea, and we do, in fact, follow that procedure. Whenever we make any large scale changes we always announce them here on this list,... we usually also put them on our web site. There is an error in your comment however... the previous event (with the rule-bots) was completely unforeseeable. There was no way to announce that known good software would suddenly fail so spectacularly when no changes within our control were made. Thankfully, that kind of event is extremely unlikely also. It is unfortunate that these two events would happen so closely together. _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: Re[2]: [sniffer] problems!!!!
What is the correct Sniffer string in Declude Global.cfg file. SNIFFER external nonzero d:\imail\declude\sniffer\sniffer.exe code12 0 of SNIFFER external nonzero d:\imail\declude\sniffer\sniffer.exe code10 0 Thanks Filippo
Re[2]: [sniffer] problems!!!!
On Wednesday, February 8, 2006, 11:06:07 AM, Markus wrote: MG If a experimental rule showed to be reliable they move them in MG the appropriate category (rich, fraud,...) MG MG MG MG I'm not sure about this but I think it's so and so it shouldn't MG be necessary to do something like manualy block updates. This is not how it works. Experimental rule groups contain abstract rules that may not classify a particular type of message. Indeed, even rules that are coded to more specific groups will likely match messages that are outside of those categories because the blackhats frequently re-use domains and other features in many different campaigns. For example, the current chatty drugs, chatty loans, and chatty watches campaigns all tend to share the same domains in their links. Along the lines of delaying implementation of new rules, we can configure rulebases and rule groups within them to only accept rules with a specific minimum age in days. We might have to charge for this kind of custom modification, and it would by it's nature increase spam leakage. _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] problems!!!!
On Wednesday, February 8, 2006, 11:19:52 AM, Andy wrote: AS Pete, 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. This is not something we could do without a lot of work. _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[4]: [sniffer] problems!!!!
On Wednesday, February 8, 2006, 11:26:46 AM, Darin wrote: DC There was no error in my comment. I completely understand that some issues DC will not be foreseeable... I did say mostly, not entirely. The switch to DC the automated bots caused a rash of false positives in our system. snip/ Actually, there is the error I was talking about -- (I'm not pointing fingers either, just trying to set the record straight.) The automated bots had been online and part of the system for several years when the error occurred. There was no cut-over to announce. DC What I would be looking for is an announcement of a specific date/time for a DC cutover so we could freeze just before that, and unfreeze once it was clear DC that no glut of false positives would result. I completely agree, and that is our policy. Before we turn on anything important, we will announce it, as we have in the past. Even if for no other reason than we want you to know we've done something cool... but certainly so that we can have everyone aware and watching out for any un-expected results (good or bad). _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[4]: [sniffer] problems!!!!
Perhaps I used the wrong terminology about what changed, since I do not know what your system architecture is, but I remember you mentioning a significant change at the time. Immediately afterwards we saw a rash of false positives. That is what I would like to have controls in place to avoid. Darin. - Original Message - From: Pete McNeil [EMAIL PROTECTED] To: Darin Cox sniffer@SortMonster.com Sent: Wednesday, February 08, 2006 11:46 AM Subject: Re[4]: [sniffer] problems On Wednesday, February 8, 2006, 11:26:46 AM, Darin wrote: DC There was no error in my comment. I completely understand that some issues DC will not be foreseeable... I did say mostly, not entirely. The switch to DC the automated bots caused a rash of false positives in our system. snip/ Actually, there is the error I was talking about -- (I'm not pointing fingers either, just trying to set the record straight.) The automated bots had been online and part of the system for several years when the error occurred. There was no cut-over to announce. DC What I would be looking for is an announcement of a specific date/time for a DC cutover so we could freeze just before that, and unfreeze once it was clear DC that no glut of false positives would result. I completely agree, and that is our policy. Before we turn on anything important, we will announce it, as we have in the past. Even if for no other reason than we want you to know we've done something cool... but certainly so that we can have everyone aware and watching out for any un-expected results (good or bad). _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[6]: [sniffer] problems!!!!
On Wednesday, February 8, 2006, 12:34:44 PM, Darin wrote: DC Perhaps I used the wrong terminology about what changed, since I do not know DC what your system architecture is, but I remember you mentioning a DC significant change at the time. Immediately afterwards we saw a rash of DC false positives. That is what I would like to have controls in place to DC avoid. I see. We did make a number of changes to optimize the rulebase and improve delivery. These changes were announced and are unrelated to the problem we had with the 'bots. The changes are still in place, in fact, and working well. Thanks, _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] 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
[sniffer] Problems downloading Windows tools / starter scripts
I am having problems downloading the starter scripts to automate updates for the rule base file detailed at http://www.sortmonster.com/MessageSniffer/Help/AutomatingUpdatesHelp.htm l. There are two sources to get the zip, both of which I am having issues: http://www.sortmonster.net/Sniffer/Updates/WindowsTools.zip (prompted for basic authentication - I'm not aware of an account to use) ftp://ftp.sortmonster.net/Sniffer/Updates/WindowsTools.zip (anonymous access denied) Is there another link, or are there temporary issues? Thanks, Steve 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 downloading Windows tools / starter scripts
On Friday, September 17, 2004, 12:42:26 PM, Steve wrote: SF I am having problems downloading the starter scripts to automate updates Responded off list. _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
