On 01.10.19 08:50, Ramon F Herrera wrote:
This is the 3rd. time that I attempt this post. First, I assumed
that the mailing list was down. However, other messages are being
distributed properly.
My current guess is that maybe a vigilant SA rule is considering
my post suspicious?
On 10/1/20
On 10/1/2019 10:53 AM, Matus UHLAR - fantomas wrote:
On 01.10.19 08:50, Ramon F Herrera wrote:
This is the 3rd. time that I attempt this post. First, I assumed that
the mailing list was down. However, other messages are being
distributed properly.
My current guess is that maybe a vigilant S
On 01.10.19 08:50, Ramon F Herrera wrote:
This is the 3rd. time that I attempt this post. First, I assumed that
the mailing list was down. However, other messages are being
distributed properly.
My current guess is that maybe a vigilant SA rule is considering my
post suspicious?
maybe just
On 21.04.15 18:49, Quanah Gibson-Mount wrote:
I just wanted to give a thank you to everyone who responded to this
thread. I clearly misunderstood what DCC does, and it now has little
value to me as a scoring item.
Am 22.04.2015 um 12:47 schrieb Matus UHLAR - fantomas:
I recommend you putting
Am 22.04.2015 um 12:47 schrieb Matus UHLAR - fantomas:
On 21.04.15 18:49, Quanah Gibson-Mount wrote:
I just wanted to give a thank you to everyone who responded to this
thread. I clearly misunderstood what DCC does, and it now has little
value to me as a scoring item.
I recommend you putting
On 21.04.15 18:49, Quanah Gibson-Mount wrote:
I just wanted to give a thank you to everyone who responded to this
thread. I clearly misunderstood what DCC does, and it now has little
value to me as a scoring item.
I recommend you putting mass senders to whitelist. It's perfect scoring item
for
Hi Quanah,
On 22/04/15 02:52, [*] Quanah Gibson-Mount wrote:
--On Tuesday, April 14, 2015 11:05 PM +0100 Steve Freegard
wrote:
Just because *you* can't find any sense in it; others might be able to.
For example:
meta __FSL_ANY_BULK ((DCC_CHECK || RAZOR2_CHECK ||
PYZOR_CHECK) && !
--On Tuesday, April 14, 2015 11:05 PM +0100 Steve Freegard
wrote:
On 14/04/15 19:45, Reindl Harald wrote:
Am 14.04.2015 um 20:26 schrieb Kevin A. McGrail:
On 4/14/2015 2:16 PM, Reindl Harald wrote:
DCC isn't designed to tell you if a message is spam/not-spam. It's a
*BULK* indicator. e.
I just wanted to give a thank you to everyone who responded to this thread.
I clearly misunderstood what DCC does, and it now has little value to me as
a scoring item.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
Zimbra :: the leader in open source m
On 04/17/2015 01:17 PM, RW wrote:
On Thu, 16 Apr 2015 15:06:42 -0700 (PDT)
John Hardin wrote:
On Thu, 16 Apr 2015, RW wrote:
I don't see why it's not auto generated - perhaps with a cap of 1.5.
How long are signatures kept in the DCC database? Masscheck uses a
corpus that covers a couple of
On Thu, 16 Apr 2015 15:06:42 -0700 (PDT)
John Hardin wrote:
> On Thu, 16 Apr 2015, RW wrote:
>
> > I don't see why it's not auto generated - perhaps with a cap of 1.5.
>
> How long are signatures kept in the DCC database? Masscheck uses a
> corpus that covers a couple of years. If the DCC signat
I don't see why it's not auto generated - perhaps with a cap of 1.5.
On 16.04.15 15:06, John Hardin wrote:
How long are signatures kept in the DCC database? Masscheck uses a
corpus that covers a couple of years. If the DCC signatures expire
within a month or two then that would skew the massch
On Thu, 16 Apr 2015, RW wrote:
I don't see why it's not auto generated - perhaps with a cap of 1.5.
How long are signatures kept in the DCC database? Masscheck uses a corpus
that covers a couple of years. If the DCC signatures expire within a month
or two then that would skew the masscheck r
On Thu, 16 Apr 2015 07:14:12 -0400
Kevin A. McGrail wrote:
> > Vernon, do you have a recommended score for the implementation of
> > DCC with SA? There are concerns that bulk mail from good senders
> > has been hit by DCC which is completely by design.
>
> Vernon replied off-list so I wanted t
Am 16.04.2015 um 17:45 schrieb Matus UHLAR - fantomas:
On 04/16/2015 02:15 PM, Mark Martinec wrote:
I don't agree with moving a DCC rule into a __* rule or setting
its score to a near zero. I find DCC hits useful as they are now:
contributing to the overall score, bit not so large as to make
a
On 04/16/2015 02:15 PM, Mark Martinec wrote:
I don't agree with moving a DCC rule into a __* rule or setting
its score to a near zero. I find DCC hits useful as they are now:
contributing to the overall score, bit not so large as to make
a major effect by themselves.
Am 16.04.2015 um 14:55 sch
Am 16.04.2015 um 14:55 schrieb Axb:
On 04/16/2015 02:15 PM, Mark Martinec wrote:
I don't agree with moving a DCC rule into a __* rule or setting
its score to a near zero. I find DCC hits useful as they are now:
contributing to the overall score, bit not so large as to make
a major effect by t
On 04/16/2015 02:15 PM, Mark Martinec wrote:
I don't agree with moving a DCC rule into a __* rule or setting
its score to a near zero. I find DCC hits useful as they are now:
contributing to the overall score, bit not so large as to make
a major effect by themselves.
FWIW; I totally agree with
Kevin A. McGrail wrote:
Vernon, do you have a recommended score for the implementation of
DCC with SA? There are concerns that bulk mail from good senders has
been hit by DCC which is completely by design.
Vernon replied off-list so I wanted to bring the relevant portion back
to the list:
"My
Vernon, do you have a recommended score for the implementation of
> DCC with SA? There are concerns that bulk mail from good senders has
> been hit by DCC which is completely by design.
Vernon replied off-list so I wanted to bring the relevant portion back
to the list:
"My general suggestion i
On 4/14/2015 5:43 PM, John Hardin wrote:
It's not. The 1.1 points is hardcoded:
50_scores.cf:score DCC_CHECK0 1.1 0 1.1
It's reasonable to argue that this score should be informational only,
and that it should only be scored meaningfully in metas.
It doesn't look like masscheck
Am 15.04.2015 um 10:24 schrieb Matus UHLAR - fantomas:
Am 14.04.2015 um 20:44 schrieb Dave Pooser:
Finally I would submit that if the phrase "sometimes wrong, but never
uncertain" sounds like a description of your mailing list posts, it¹s
worth putting the effort in to change that
On 14.04.1
Am 14.04.2015 um 20:44 schrieb Dave Pooser:
Finally I would submit that if the phrase "sometimes wrong, but never
uncertain" sounds like a description of your mailing list posts, it¹s
worth putting the effort in to change that
On 14.04.15 20:49, Reindl Harald wrote:
nobody is perfect, but if i
John Hardin wrote:
[...] The 1.1 points is hardcoded:
50_scores.cf:score DCC_CHECK0 1.1 0 1.1
It's reasonable to argue that this score should be informational only,
and that it should only be scored meaningfully in metas.
Steve Freegard wrote:
However - I'll readily agree with yo
On Tue, 14 Apr 2015, Kevin A. McGrail wrote:
On 4/14/2015 5:05 PM, Steve Freegard wrote:
However - I'll readily agree with you that DCC_CHECK adding score to all
bulk mail isn't that useful, however that is what the mass-checker has
decided works best with the corpus of mail available.
I a
On 4/14/2015 5:05 PM, Steve Freegard wrote:
However - I'll readily agree with you that DCC_CHECK adding score to
all bulk mail isn't that useful, however that is what the mass-checker
has decided works best with the corpus of mail available.
I am not sure DCC is masschecked, to be honest...
On 14/04/15 19:45, Reindl Harald wrote:
Am 14.04.2015 um 20:26 schrieb Kevin A. McGrail:
On 4/14/2015 2:16 PM, Reindl Harald wrote:
DCC isn't designed to tell you if a message is spam/not-spam. It's a
*BULK* indicator. e.g. have lots of people seen this message?
that is simply not true an
Am 14.04.2015 um 20:44 schrieb Dave Pooser:
Finally I would submit that if the phrase "sometimes wrong, but never
uncertain" sounds like a description of your mailing list posts, it¹s
worth putting the effort in to change that
nobody is perfect, but if i would be uncertain i just won't say an
On 4/14/2015 2:45 PM, Reindl Harald wrote:
because i can't find any sense in give bulk mail just because it is
bulk mail - indepdendent of subscribed, double-optin and what not - a
penalty
however, the real problem of all the hashing services is the way how
personalized parts get stripped and
Am 14.04.2015 um 20:26 schrieb Kevin A. McGrail:
On 4/14/2015 2:16 PM, Reindl Harald wrote:
DCC isn't designed to tell you if a message is spam/not-spam. It's a
*BULK* indicator. e.g. have lots of people seen this message?
that is simply not true and defeats the purpose
I disagree. That
>>DCC isn't designed to tell you if a message is spam/not-spam. It's a
>>*BULK* indicator. e.g. have lots of people seen this message?
>
>that is simply not true and defeats the purpose
>
>the problem are idiots reporting legit mail as spam
Well, the folks who *run* the DCC servers seem to disag
On 14 Apr 2015, at 13:59, Quanah Gibson-Mount wrote:
I've noticed that DCC_CHECK is flagging on tons of items that are
clearly not spam. The most recent hit for me today was a release
announcement from the mariadb folks. Overall, it's a trend I'm
routinely seeing where it is flagging a lot o
On 4/14/2015 2:16 PM, Reindl Harald wrote:
DCC isn't designed to tell you if a message is spam/not-spam. It's a
*BULK* indicator. e.g. have lots of people seen this message?
that is simply not true and defeats the purpose
I disagree. That description of DCC seems very accurate to me. See
Am 14.04.2015 um 19:59 schrieb Quanah Gibson-Mount:
> I've noticed that DCC_CHECK is flagging on tons of items that are
> clearly not spam. The most recent hit for me today was a release
> announcement from the mariadb folks. Overall, it's a trend I'm
> routinely seeing where it is flagging a lot
From: Quanah Gibson-Mount
Date: Tue, 14 Apr 2015 10:59:28 -0700
I've noticed that DCC_CHECK is flagging on tons of items that are clearly
not spam. The most recent hit for me today was a release announcement from
the mariadb folks. Overall, it's a trend I'm routinely seeing
Am 14.04.2015 um 20:11 schrieb Steve Freegard:
Quanah,
On 14/04/15 18:59, Quanah Gibson-Mount wrote:
I've noticed that DCC_CHECK is flagging on tons of items that are
clearly not spam. The most recent hit for me today was a release
announcement from the mariadb folks. Overall, it's a trend
Am 14.04.2015 um 19:59 schrieb Quanah Gibson-Mount:
I've noticed that DCC_CHECK is flagging on tons of items that are
clearly not spam. The most recent hit for me today was a release
announcement from the mariadb folks. Overall, it's a trend I'm
routinely seeing where it is flagging a lot of e
Quanah,
On 14/04/15 18:59, Quanah Gibson-Mount wrote:
I've noticed that DCC_CHECK is flagging on tons of items that are
clearly not spam. The most recent hit for me today was a release
announcement from the mariadb folks. Overall, it's a trend I'm
routinely seeing where it is flagging a lot o
I've noticed that DCC_CHECK is flagging on tons of items that are clearly
not spam. The most recent hit for me today was a release announcement from
the mariadb folks. Overall, it's a trend I'm routinely seeing where it is
flagging a lot of email that clearly isn't spam. Are others who use DC
On 31/07/2014 11:36, Dave Warren wrote:
There is a difference: Gmail is a very major source of wanted,
legitimate mail. Most "may 'n pa run outback country dialup ISPs" are
not.
Most mail to most clients are a "very major source of wanted mail"
Again, playing favourites is plain wrong, and i
On Thu, Jul 31, 2014 at 1:06 AM, Noel Butler wrote:
> There is no such thing as 'too big' when it comes to handling the shit storm
> of spam that gets spewed out of some organisations, and I'll treat Gmail and
> the likes the same as a ma 'n pa run outback country dialup ISP, there is
At dnswl.
On 2014-07-30 16:06, Noel Butler wrote:
Certainly have done it on employers network before (a public ISP), and
would have no problem doing it again if the need arose.
There is no such thing as 'too big' when it comes to handling the shit
storm of spam that gets spewed out of some organisations,
On Thu, 2014-07-31 at 09:06 +1000, Noel Butler wrote:
> Certainly have done it on employers network before (a public ISP), and
> would have no problem doing it again if the need arose.
> There is no such thing as 'too big' when it comes to handling the shit
> storm of spam that gets spewed out of
On Wed, 2014-07-30 at 09:12 -0400, David F. Skoll wrote:
> On Wed, 30 Jul 2014 09:34:30 +1000
> Noel Butler wrote:
>
> > This is the exact attitude as to why they wont get off their arses,
> > because people think they are too big to block. be damned if I care,
> > I have blocked yahoo and gmai
On 2014-07-30 06:12, David F. Skoll wrote:
On Wed, 30 Jul 2014 09:34:30 +1000
Noel Butler wrote:
This is the exact attitude as to why they wont get off their arses,
because people think they are too big to block. be damned if I care,
I have blocked yahoo and gmail before, and I dare say I'll h
On Wed, 30 Jul 2014 09:34:30 +1000
Noel Butler wrote:
> This is the exact attitude as to why they wont get off their arses,
> because people think they are too big to block. be damned if I care,
> I have blocked yahoo and gmail before, and I dare say I'll have to
> again sometime.
You don't hav
On 30/07/2014 04:29, David F. Skoll wrote:
originates from servers that RBLs cannot block for political or
practical resons. Think Gmail, Hotmail and Yahoo servers, for
This is the exact attitude as to why they wont get off their arses,
because people think they are too big to block. be damn
On Jul 29, 2014, at 12:29 PM, David F. Skoll wrote:
> On Tue, 29 Jul 2014 14:21:56 -0400
> Dave Pooser wrote:
>
> RBLs are a good first line of defense, but unfortunately a lot of spam
> originates from servers that RBLs cannot block for political or
> practical resons. Think Gmail, Hotmail a
>RBLs are a good first line of defense, but unfortunately a lot of spam
>originates from servers that RBLs cannot block for political or
>practical resons. Think Gmail, Hotmail and Yahoo servers, for
>example. You need something extra to have acceptable catch rates, and
>the "something extra" inv
On Tue, 29 Jul 2014 14:21:56 -0400
Dave Pooser wrote:
> We use the invaluement lists managed by Rob McEwen and have been very
> happy with them-- been using them for 3-4 years. A lot of blocking
> that doesn't overlap with Spamhaus, very few false positives, and
> those that do occur are addresse
On Wed, 12 Feb 2014 13:11:19 -0800 (PST)
John Hardin wrote:
> That only works if your hammy mail stream contains text that looks
> like the random garbage they put in to try to spoof bayes.
Indeed. Just for kicks, I ran the OP's pastebin example through our
Bayes database and it scored 99.99% l
since i do not know, how effective is it to train on snowshoe spam?
under what conditions is it good idea?
always?
under what conditions is it not a good idea?
thanks in advance...
- rh
>
> Sorry, don't understand what you mean.
>
> Kai
>
recently i put a small list of RBL rulenames we have zero'd out on the list
to ask if anyone would share their experience and comments about how
effective they are in stopping spam in their large installations.
we have them zero'd out ca
On Thu, Jan 29, 2009 at 22:17, RobertH wrote:
>
>
>
>> >
>> A general grasp of how it performs across a diverse range of
>> email can be gotten from the STATISTICS-set*.txt files
>> included in the tarball.
>> Look in the rules directory.
>>
>> The file contains the mass-check results that were us
RobertH wrote on Thu, 29 Jan 2009 14:18:56 -0800:
> we use other network tests so turning off rbl checks wouldnt be a good idea
> right?
Sorry, don't understand what you mean.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
>
> fairly easy. run one week with default settings and one week
> with "skip_rbl_checks 1". Then compare.
> In general, these rules will provide hits if you don't use
> RBLs at MTA level. If you use RBLs to reject at MTA level
> they won't hit much.
>
> Kai
>
> --
> Kai Schätzl, Berlin,
> >
> A general grasp of how it performs across a diverse range of
> email can be gotten from the STATISTICS-set*.txt files
> included in the tarball.
> Look in the rules directory.
>
> The file contains the mass-check results that were used in
> score generation. Generally the best numb
On 22.01.09 14:54, RobertH wrote:
> would those of you in the know please comment based upon your data re: the
> below rules and their effectiveness in hitting spam vrs ham and/or false
> readings in diverse or fairly diverse large scale isp and/or corporate
> installations please
RobertH wrote on Thu, 22 Jan 2009 14:54:41 -0800:
> would those of you in the know please comment based upon your data re: the
> below rules and their effectiveness in hitting spam vrs ham and/or false
> readings in diverse or fairly diverse large scale isp and/or corporate
> installa
RobertH wrote:
> would those of you in the know please comment based upon your data re: the
> below rules and their effectiveness in hitting spam vrs ham and/or false
> readings in diverse or fairly diverse large scale isp and/or corporate
> installations please
>
A general
would those of you in the know please comment based upon your data re: the
below rules and their effectiveness in hitting spam vrs ham and/or false
readings in diverse or fairly diverse large scale isp and/or corporate
installations please
RCVD_IN_BL_SPAMCOP_NET
RCVD_IN_DSBL
On Fri, 12 Dec 2008, Marcin Krol wrote:
John Hardin wrote:
On Thu, 11 Dec 2008, Karsten Br�ckelmann wrote:
> I still recommend initial training, to give Bayes a good kick-start.
Initial _manual_ training.
Define manual: manual picking out spams is plain too labor-intensive.
Manual trai
Marcin Krol wrote on Fri, 12 Dec 2008 10:37:31 +0100:
> Define manual: manual picking out spams is plain too labor-intensive. If
> we redefine "manual" to mean ham coming from authenticated mail, and
> spam coming from spamtraps, I wholeheartedly agree.
The point is that you need to have a corp
Marcin Krol wrote on Fri, 12 Dec 2008 10:43:57 +0100:
> posted spamtraps to Usenet some 6 months ago and I
> still get very little spam caught in spamtraps.
you will have to exclude them from RBL blocking, of course ;-)
I have one Usenet spamtrap that is getting a lot of spam, although it
hasn
Henrik K wrote:
sure there's other useful stuff you can do with spamtrap mails too.
Unfortunately it takes a lot of effort to create *good* spamtraps.
Yep.
It's just
too much trouble for a normal admin, I leave it to those who have time on
their hands. You can do the simple grep for "mistyp
John Hardin wrote:
On Thu, 11 Dec 2008, Karsten Br�ckelmann wrote:
I still recommend initial training, to give Bayes a good kick-start.
Initial _manual_ training.
Define manual: manual picking out spams is plain too labor-intensive. If
we redefine "manual" to mean ham coming from authentic
Karsten Bräckelmann wrote:
Well, isn't it better to use them before SA, provided your MTA does have
this feature (I recommend Exim to everyone)?
No -- unless you ultimately trust the RBL to produce a *negligible*
amount of FPs. Every single RBL does have FPs to a highly variable
degree. Instead
Matthias Leisi wrote on Thu, 11 Dec 2008 22:05:34 +0100:
> (and
> are thus likely to be quoted in reply emails)
correctly working email programs leave the signature out from quoting
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Mark Martinec schrieb:
> or construct custom rules to whitelist (=add negative score points)
> based on some other specific chraracteristic of mail to be passed.
Your own (your companys) street address, phone number, or some hopefully
unique token which you typically add in footers of outgoing e
On Thu, 2008-12-11 at 18:36 +0100, Matus UHLAR - fantomas wrote:
> > > Ned Slider wrote:
> > > > Yes, additional DNSBLs such as psbl and uceprotect can be integrated
> > > > into SA
>
> > On Thu, 2008-12-11 at 15:19 +0100, Marcin Krol wrote:
> > > Well, isn't it better to use them before SA, prov
On Thu, Dec 11, 2008 at 05:57:10PM +, Ned Slider wrote:
>
> Genuine spam traps are great for bayes training as they should contain a
> representative sample of spam your users will be seeing plus you know
> they only contain spam so you don't need to check the contents before
> feeding th
Ned Slider a écrit :
> Genuine spam traps are great for bayes training as they should contain a
> representative sample of spam your users will be seeing plus you know
> they only contain spam so you don't need to check the contents before
> feeding them to bayes to learn :)
>
you must be careful
Marcin Krol wrote:
Matus UHLAR - fantomas wrote:
- blocking at MTA by RBL or other techniques (such as graylisting)
is efficient and effective, but deprives SpamAssassin of spam samples,
so if your resources permit, it is better to let SpamAssassin deal
with all RBLs.
I don't think so. W
Karsten Bräckelmann wrote:
On Thu, 2008-12-11 at 15:19 +0100, Marcin Krol wrote:
Ned Slider wrote:
Yes, additional DNSBLs such as psbl and uceprotect can be integrated
into SA
Well, isn't it better to use them before SA, provided your MTA does have
this feature (I recommend Exim to everyone)?
> > Ned Slider wrote:
> > > Yes, additional DNSBLs such as psbl and uceprotect can be integrated
> > > into SA
> On Thu, 2008-12-11 at 15:19 +0100, Marcin Krol wrote:
> > Well, isn't it better to use them before SA, provided your MTA does have
> > this feature (I recommend Exim to everyone)?
On
On Thu, 2008-12-11 at 15:19 +0100, Marcin Krol wrote:
> Ned Slider wrote:
>
> > Yes, additional DNSBLs such as psbl and uceprotect can be integrated
> > into SA
>
> Well, isn't it better to use them before SA, provided your MTA does have
> this feature (I recommend Exim to everyone)?
No -- unle
On Thu, 2008-12-11 at 08:28 -0800, John Hardin wrote:
> On Thu, 11 Dec 2008, Karsten Bräckelmann wrote:
> >>> I still recommend initial training, to give Bayes a good kick-start.
> >>
> >> Initial _manual_ training.
> >
> > Err... Yes! :)
>
> The reason I stressed that is it sounds like the OP tu
On Thu, 11 Dec 2008, Karsten Br�ckelmann wrote:
On Thu, 2008-12-11 at 08:18 -0800, John Hardin wrote:
On Thu, 11 Dec 2008, Karsten Bräckelmann wrote:
I still recommend initial training, to give Bayes a good kick-start.
Initial _manual_ training.
Err... Yes! :)
The reason I stressed that
On Thu, 2008-12-11 at 08:18 -0800, John Hardin wrote:
> On Thu, 11 Dec 2008, Karsten Bräckelmann wrote:
>
> > I still recommend initial training, to give Bayes a good kick-start.
>
> Initial _manual_ training.
Err... Yes! :)
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,
On Thu, 2008-12-11 at 16:28 +0100, Marcin Krol wrote:
> Karsten Bräckelmann wrote:
> > Do train false negatives. It does help Bayes, if you train "FN according
> > to Bayes", that is spam that has been caught, but got a low, ham-ish
> > Bayes score.
>
> It seems that I need to brush up on specific
On Thu, 11 Dec 2008, Karsten Br�ckelmann wrote:
I still recommend initial training, to give Bayes a good kick-start.
Initial _manual_ training.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
[EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED]
key:
Karsten Bräckelmann wrote:
Do train false negatives. It does help Bayes, if you train "FN according
to Bayes", that is spam that has been caught, but got a low, ham-ish
Bayes score.
It seems that I need to brush up on specifics of SA Bayes; so far I have
used only DSPAM from among statistical
Matus UHLAR - fantomas wrote:
- blocking at MTA by RBL or other techniques (such as graylisting)
is efficient and effective, but deprives SpamAssassin of spam samples,
so if your resources permit, it is better to let SpamAssassin deal
with all RBLs.
I don't think so. We get "enough" of sp
On 11.12.08 15:47, Mark Martinec wrote:
> Quality of bayes auto-learning improves if you let all your mail
> pass through SpamAssassin:
>
> - outbound mail is often a high-quality source of ham
> for autolearning;
But when one of your users starts spamming (trojan or wtf), you have problem
and
On Thu, 2008-12-11 at 16:01 +0100, Karsten Bräckelmann wrote:
> On Thu, 2008-12-11 at 15:13 +0100, Marcin Krol wrote:
Forgot to add...
> > No, I just waited until default 200 hams and 200 spams kicked it in. As
> > I mentioned elsewhere, I get a weird effect of correct positives, but
> > relati
erhaps he misconfigured it or smth?
That's pretty much just another way of saying, what you snipped from my
post. ;) "Results and effectiveness vary, everyone's spam is
different." Yes, that means it might work much better for you. Did you
try it?
> >I also recommend t
Marcin Krol wrote:
> Karsten Bräckelmann wrote:
> >
> > Did you manually (initially) train it
> > with your collected ham and recent (not older than 3 months) spam?
>
> No, I just waited until default 200 hams and 200 spams kicked it in.
> As I mentioned elsewhere, I get a weird effect of correct
Marcin,
> >Did you manually (initially) train it
> > with your collected ham and recent (not older than 3 months) spam?
>
> No, I just waited until default 200 hams and 200 spams kicked it in. As
> I mentioned elsewhere, I get a weird effect of correct positives, but
> relatively many false negati
Marcin Krol wrote:
> Matthias Leisi wrote:
>
> > * If circumstances permit, make use of extensive whitelisting, so
> > that you can increase the score of rules (or maybe lower the
> > threshold after which you consider a message to be spam).
>
> With all due respect, that's risky... My users ofte
> Ned Slider wrote:
> >Also look at setting up Bayes and train it well. A well trained Bayes
> >setup can hit 99% plus spam (for me) and can be highly effective.
On 11.12.08 15:19, Marcin Krol wrote:
> Except I found that while it often gets positive identification right,
> it sometimes produces
Ned Slider wrote:
Yes, additional DNSBLs such as psbl and uceprotect can be integrated
into SA
Well, isn't it better to use them before SA, provided your MTA does have
this feature (I recommend Exim to everyone)?
Also look at setting up Bayes and train it well. A well trained Bayes
setup can
Karsten Bräckelmann wrote:
- SURBL and URIBL are extremely effective at identifying spam
They are enabled by default -- unless you are running local tests only.
Did you (or your distro default) disable network tests? If you
specifically had to enable these, you are likely missing more of them.
Matthias Leisi wrote:
* If circumstances permit, make use of extensive whitelisting, so that
you can increase the score of rules (or maybe lower the threshold after
which you consider a message to be spam).
With all due respect, that's risky... My users often get legit mails out
of blue or e
> * If circumstances permit, make use of extensive whitelisting, so that
> you can increase the score of rules (or maybe lower the threshold after
> which you consider a message to be spam).
When whitelisting, never whitelist just based on a plain sender or author
address (such as 'whitelist_from'
resources. I also recommend the iXhash plugin, which is another digest
test that kicks some serious butt.
Results and effectiveness vary, everyone's spam is different.
> Is anybody here willing to share other / better techniques and tips?
Watch the list. Every now and then additional rules, t
Matthias Leisi wrote:
Marcin Krol schrieb:
Is anybody here willing to share other / better techniques and tips?
No silver bullet, only blood, sweat and tears :-)
I agree.
* Create custom rules that to match your uncaught spam (and maybe share
these rules back on this list).
Yes, cust
Marcin Krol schrieb:
Is anybody here willing to share other / better techniques and tips?
No silver bullet, only blood, sweat and tears :-)
* Create custom rules that to match your uncaught spam (and maybe share
these rules back on this list).
* If circumstances permit, make use of extensi
Hello everyone,
I'm (somewhat) new to SA, and it works nicely, except now I would like
to boost its effectiveness at finding spam. I have searched the web and
frankly I'm disappointed with the results - except basic config there is
not much info there on how to finetune SA to
On Tue, 20 Mar 2007, Erik Slooff wrote:
all,
I have an interesting observation on my mail gateway (policyd for
greylisting, postfix, amavisd-new and spamassassin); after implementing
greylisting and other measures such as RBLs there aren't enough spam
messages coming through to keep bayes train
On Tue, March 20, 2007 13:23, [EMAIL PROTECTED] wrote:
> On Tue, 20 Mar 2007, Erik Slooff wrote:
>
>> I have an interesting observation on my mail gateway (policyd for
>> greylisting, postfix, amavisd-new and spamassassin); after implementing
>> greylisting and other measures such as RBLs there ar
1 - 100 of 137 matches
Mail list logo
