[sniffer] Message sniffer in FreeBSD Postfix
Hi, Is there anyone else who would like to see Message Sniffer incorporated into Amavis-new? This would be a great addition to my IMGate - Postfix mail gateway. Currently I use message sniffer on my Imail box but would like to offload that server and do the sniffing before the mail hits Imail. Thanks, Jacques Brouwers 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!!!!
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]]
On Behalf Of David
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]
[mailto:[EMAIL
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 information and (un)subscription instructions go to
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? Goran Jovanovic Omega Network
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: [sniffer] Message sniffer in FreeBSD Postfix
Is there anyone else who would like to see Message Sniffer incorporated into Amavis-new? This would be a great addition to my IMGate - Postfix mail gateway. Currently I use message sniffer on my Imail box but would like to offload that server and do the sniffing before the mail hits Imail. This is already available by using Sniffer with Spamassassin. Craig 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] Message sniffer in FreeBSD Postfix
Does not require spamassassin or amavis. You can do it just with postfix. DustyC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Deal Sent: Wednesday, February 08, 2006 10:41 AM To: sniffer@SortMonster.com Subject: RE: [sniffer] Message sniffer in FreeBSD Postfix Is there anyone else who would like to see Message Sniffer incorporated into Amavis-new? This would be a great addition to my IMGate - Postfix mail gateway. Currently I use message sniffer on my Imail box but would like to offload that server and do the sniffing before the mail hits Imail. This is already available by using Sniffer with Spamassassin. Craig 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: [sniffer] Message sniffer in FreeBSD Postfix
Does not require spamassassin or amavis. You can do it just with postfix. DustyC True, but he wanted it to work with amavisd-new. Less risk of a false positive if its part of a weighted system. Craig 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] Message sniffer in FreeBSD Postfix
Correct, the weighted system that amavis uses would be better in my situation. Having said that I am going to try DustyC's method put the spam in the users junk folder (still using the weighted system). Do you have the problem of the user's junk mail using up their mail box quota? Jacques -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Deal Sent: Wednesday, February 08, 2006 9:49 AM To: sniffer@SortMonster.com Subject: RE: [sniffer] Message sniffer in FreeBSD Postfix Does not require spamassassin or amavis. You can do it just with postfix. DustyC True, but he wanted it to work with amavisd-new. Less risk of a false positive if its part of a weighted system. Craig 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[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: [sniffer] Message sniffer in FreeBSD Postfix
It was actually simple. And I have the update process automated too. We did have a little issue where we had to run sniffer under bash shell on our FreeBSD box but that was resolved quickly. I am running one box with sniffer on it. All the external gateways send their inbound mail to this box before it hits the Imail server. DustyC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Support Sent: Wednesday, February 08, 2006 10:56 AM To: sniffer@SortMonster.com Subject: Re: [sniffer] Message sniffer in FreeBSD Postfix Hi Dusty: Was it much problems setting up sniffer on your postfix box? This sounds like the way for us to go as well. Thanks Phil NetEase Operations Manager wrote: I am using sniffer on a postfix box. I let sniffer tag it there and then on the Imail box I am filtering anything with that tag into a users suspect spam box. That offloads the spam handling to the user and the techs do not have to deal with it. False positives do not bother me much because I can simply tell the user to check their web mail and move it to their inbox if they want. The Imail server deletes anything in the suspect spam that is 7 days old so it maintains its own cleaning cycle too. DustyC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacques Brouwers Sent: Wednesday, February 08, 2006 9:33 AM To: sniffer@sortmonster.com Subject: [sniffer] Message sniffer in FreeBSD Postfix Hi, Is there anyone else who would like to see Message Sniffer incorporated into Amavis-new? This would be a great addition to my IMGate - Postfix mail gateway. Currently I use message sniffer on my Imail box but would like to offload that server and do the sniffing before the mail hits Imail. Thanks, Jacques Brouwers 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 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
[sniffer] question on xhdr files
I am using a smtp proxy called Ewall with Message Sniffer. I just checked inside the Ewall folders and found one named TEMP where I found tens of thousands of files with the .xhdr extension. What are these? Are they needed? Why are they in the ewall directory and not the message sniffer directory? Can I simply erase them? Could their 'cleanup' be done by the message sniffer in a new version? David Payer 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] question on xhdr files
On Wednesday, February 8, 2006, 12:54:56 PM, David wrote: DP I am using a smtp proxy called Ewall with Message Sniffer. DP I just checked inside the Ewall folders and found one named TEMP where I DP found tens of thousands of files with the .xhdr extension. DP What are these? Are they needed? Why are they in the ewall directory and not DP the message sniffer directory? Can I simply erase them? Could their DP 'cleanup' be done by the message sniffer in a new version? The .xhdr files are created by SNF and can be turned off in SNF's .cfg file. They contain text that could be added to the headers of the message to help debug false positives and/or to trigger other filtering systems. (For example, in many postfix installations, a very simple script scans the message with SNF and then adds the .xhdr information to the message. Filtering then occurs later when the result codes in the .xhdr information are detected.) Normally these would be created in SNFs working directory, I'm not sure why they would be anywhere else. You can safely delete any .xhdr files that are left over. 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[2]: [sniffer] question on xhdr files
On Wednesday, February 8, 2006, 1:32:05 PM, David wrote: The .xhdr files are created by SNF and can be turned off in SNF's .cfg file. They contain text that could be added to the headers of the message to help debug false positives and/or to trigger other filtering systems. DP Well I see this in the config file: DP DP # XHeader File Output - When set to On the engine will create a new file DP with DP # each message scanned with the name scanfilename.xhdr that contains DP x-header DP # information that should be added to the message. DP XHeaderData: X-MessageSniffer-Rules DP XHeaderFinal: X-MessageSniffer-Result DP DP I don't see the specific line to turn this off. Do I simply comment out the DP XHeaderData and XHeaderFinal lines? If I do that will it still insert the DP information in the header? I'm sorry that's misleading. Yes, comment out the two lines: # XHeaderData: X-MessageSniffer-Rules # XHeaderFinal: X-MessageSniffer-Result That should prevent SNF from creating the .xhdr files. According to what I see, the headers created in your messages are actually generated by the script, so the .xhdr info generated by SNF is largely redundant. Best, _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] Message sniffer in FreeBSD Postfix
I am not running Declude. I am just using the filters in Imail to push it in their junk mail. Depends on ones requirements. We were spending 6-8 man hours per day dealing with spam. Now we just let the users decide. Dusty -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landry, William (MED US) Sent: Wednesday, February 08, 2006 1:02 PM To: sniffer@SortMonster.com Subject: RE: [sniffer] Message sniffer in FreeBSD Postfix Yep, but for someone not running IMail/Declude, the integration with spamassassin and amavisd-new works great. Bill 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] Message sniffer in FreeBSD Postfix
Jacques, I am pretty sure that you would also need to install SpamAssassin in order to get Sniffer to work. I do not believe that there is any way to plug Sniffer into Amavis-new directly, nor would you necessarily want it to. William Van Hefner Network Administrator Vantek Communications, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacques Brouwers Sent: Wednesday, February 08, 2006 7:33 AM To: sniffer@sortmonster.com Subject: [sniffer] Message sniffer in FreeBSD Postfix Hi, Is there anyone else who would like to see Message Sniffer incorporated into Amavis-new? This would be a great addition to my IMGate - Postfix mail gateway. Currently I use message sniffer on my Imail box but would like to offload that server and do the sniffing before the mail hits Imail. Thanks, Jacques Brouwers 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] 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
