You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Randy Ramsdell <rr...@activedg.com> on 2010/06/24 18:07:36 UTC
Nonsense spam
Anyone receiving these? It is either a borked spam script or they are
probing. They come in with different headers and different body each
time so I am not sure how to mark or block them. Any suggestions would
be appreciated.
http://pastebin.com/kQJ0SPti
Re: Nonsense spam
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Thu, Jun 24, 2010 at 03:59:24PM -0400, Michael Scheidell wrote:
> > that is why, as Ned said, you have to only use it on the LAST
> > UNTRUSTED ip. (or first received header).
On 25.06.10 13:27, Henrik K wrote:
> What you are referring to is the EXTERNAL border (MX-border). Trusted may
> not be the same on some configurations (big ISP server in trusted_networks for
> whitelisting purposes etc).
correct. Mail may be delivered from listed dialups etc to trusted servers of
big ISPs and you should not blacklist them in such cases.
> Just wanted to clarify that for list archives. It's too common to refer to
> trusted path like it's the only thing SA has.
Once it was the only one. Now we have internal_networks for this usage and
trusted networks has a different one.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Re: Nonsense spam
Posted by Henrik K <he...@hege.li>.
On Thu, Jun 24, 2010 at 03:59:24PM -0400, Michael Scheidell wrote:
>
> that is why, as Ned said, you have to only use it on the LAST
> UNTRUSTED ip. (or first received header).
What you are referring to is the EXTERNAL border (MX-border). Trusted may
not be the same on some configurations (big ISP server in trusted_networks for
whitelisting purposes etc).
Just wanted to clarify that for list archives. It's too common to refer to
trusted path like it's the only thing SA has.
Re: Nonsense spam
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2010-06-25 at 10:59 -0400, Randy Ramsdell wrote:
> > The current scores are actually:
> > RCVD_IN_PBL 0 3.558 0 3.335
Latest 3.3.x scores.
> I show these current scores which are much lower than what you have. It
> this because of the spamassassin version we use or maybe I did not use
> sa-update properly. It is odd that the scores increased by this margin.
> What changed about the PBL that would necessitate this?
>
> RCVD_IN_PBL 0 0.509 0 0.905
3.2.x scores.
There is no short or simple answer to your question. The difference is
not about a sudden change in PBL. But a lot of contributing factors.
First of all, IIRC, the PBL accuracy and most importantly the FP rate
dropped since the initial 3.2.0 re-scoring. Also it got better coverage
since then. Remember we're talking about a period of 3 years here.
Plus, spam changed. And other rules. All these facts and variations
taken together, some salt and a re-score run...
Results in a different score, reflecting a current-ish ability to detect
spam, yet avoid FPs. And yes, an individuals rule score *is* affected by
the score of other rules and their overlap.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Nonsense spam
Posted by Randy Ramsdell <rr...@activedg.com>.
RW wrote:
> On Thu, 24 Jun 2010 15:59:24 -0400
> Michael Scheidell <sc...@secnap.net> wrote:
>
>
>> On 6/24/10 3:51 PM, Ned Slider wrote:
>>
>>> The danger comes when people use the PBL incorrectly and deep parse
>>> all headers which *will* lead to copious FPs.
>>>
>>> Either way, I'd have no hesitation blocking outright on PBL or
>>> scoring very highly in SA.
>>>
>>>
>
> The current scores are actually:
>
> RCVD_IN_PBL 0 3.558 0 3.335
>
>
>
I show these current scores which are much lower than what you have. It
this because of the spamassassin version we use or maybe I did not use
sa-update properly. It is odd that the scores increased by this margin.
What changed about the PBL that would necessitate this?
RCVD_IN_PBL 0 0.509 0 0.905
Re: Nonsense spam
Posted by RW <rw...@googlemail.com>.
On Thu, 24 Jun 2010 15:59:24 -0400
Michael Scheidell <sc...@secnap.net> wrote:
> On 6/24/10 3:51 PM, Ned Slider wrote:
> > The danger comes when people use the PBL incorrectly and deep parse
> > all headers which *will* lead to copious FPs.
> >
> > Either way, I'd have no hesitation blocking outright on PBL or
> > scoring very highly in SA.
> >
The current scores are actually:
RCVD_IN_PBL 0 3.558 0 3.335
> since the PBL also lists 'dialups'. and if a dialup user connects to
> their legitimate smtp host for their provider and sends an email,
> their dialup ip will still be in the received headers.
>
> that is why, as Ned said, you have to only use it on the LAST
> UNTRUSTED ip. (or first received header). or on your MTA.
> NOTE; if you use it in your MTA, and you are using a caching DNS
> server, then you are not making any redundant outbound DNS queries,
> one for the MTA, one for SA.
SA does a zen lookup for all the untrusted relays. Zen encodes SBL,PBL
and XBL into one look-up. All the SBL results are used, but the PBL and
XBL results are used on the last-external IP.
One score that I do find odd is:
RCVD_IN_SBL 0 2.596 0 0.141
I suspect that if SBL were split into separate, mutually exclusive,
deep and last-external checks, the deep check wouldn't get pushed
down so much in the bayes+net scoreset.
Re: Nonsense spam
Posted by Michael Scheidell <sc...@secnap.net>.
On 6/24/10 3:51 PM, Ned Slider wrote:
> The danger comes when people use the PBL incorrectly and deep parse
> all headers which *will* lead to copious FPs.
>
> Either way, I'd have no hesitation blocking outright on PBL or scoring
> very highly in SA.
>
since the PBL also lists 'dialups'. and if a dialup user connects to
their legitimate smtp host for their provider and sends an email, their
dialup ip will still be in the received headers.
that is why, as Ned said, you have to only use it on the LAST UNTRUSTED
ip. (or first received header). or on your MTA.
NOTE; if you use it in your MTA, and you are using a caching DNS server,
then you are not making any redundant outbound DNS queries, one for the
MTA, one for SA.
SA will use the cached result.
and, in the case of DHA's, that one ip will probally hit your server
25,000 more times today :-)
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________
Re: Nonsense spam
Posted by Yet Another Ninja <sa...@alexb.ch>.
On 2010-06-24 21:51, Ned Slider wrote:
> Michael Scheidell wrote:
>> On 6/24/10 1:18 PM, Randy Ramsdell wrote:
>>> Yet spamassassin scores it with a .9. I have been reluctant to
>>> block and
>>> this is compounded by spamassassin scoring it low as if it weren't as
>>> accurate as you state.
>>>
>>>
>> again, look at the circumstances. the SA scoring might be crippled
>> due to the issue of a lack of these ip's in spam corpus since most
>> people use that as a hard mta rbl.
>>
>> (chime in, anyone who uses it)
>>
>>
>
> I use PBL to block at the MTA level. I agree the FP rate is near
> non-existent. So long as you're *only* scanning the --lastexternal IP in
> SA then I'd personally score the rule well above the spam threshold level.
>
> Interesting what Michael says about the reason for a low score in SA. I
> don't know enough about the weighting of the scoring system, but it
> sounds like a reasonable argument to me to explain the low scoring. If
> you're not convinced, grep your own inbox for hits against PBL for FPs.
> The danger comes when people use the PBL incorrectly and deep parse all
> headers which *will* lead to copious FPs.
>
> Either way, I'd have no hesitation blocking outright on PBL or scoring
> very highly in SA.
<me too>
Re: Nonsense spam
Posted by Ned Slider <ne...@unixmail.co.uk>.
Michael Scheidell wrote:
> On 6/24/10 1:18 PM, Randy Ramsdell wrote:
>> Yet spamassassin scores it with a .9. I have been reluctant to
>> block and
>> this is compounded by spamassassin scoring it low as if it weren't as
>> accurate as you state.
>>
>>
> again, look at the circumstances. the SA scoring might be crippled due
> to the issue of a lack of these ip's in spam corpus since most people
> use that as a hard mta rbl.
>
> (chime in, anyone who uses it)
>
>
I use PBL to block at the MTA level. I agree the FP rate is near
non-existent. So long as you're *only* scanning the --lastexternal IP in
SA then I'd personally score the rule well above the spam threshold level.
Interesting what Michael says about the reason for a low score in SA. I
don't know enough about the weighting of the scoring system, but it
sounds like a reasonable argument to me to explain the low scoring. If
you're not convinced, grep your own inbox for hits against PBL for FPs.
The danger comes when people use the PBL incorrectly and deep parse all
headers which *will* lead to copious FPs.
Either way, I'd have no hesitation blocking outright on PBL or scoring
very highly in SA.
Re: Nonsense spam
Posted by Michael Scheidell <sc...@secnap.net>.
On 6/24/10 1:18 PM, Randy Ramsdell wrote:
>
> Yet spamassassin scores it with a .9. I have been reluctant to block and
> this is compounded by spamassassin scoring it low as if it weren't as
> accurate as you state.
>
>
again, look at the circumstances. the SA scoring might be crippled due
to the issue of a lack of these ip's in spam corpus since most people
use that as a hard mta rbl.
(chime in, anyone who uses it)
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________
Re: Nonsense spam
Posted by Randy Ramsdell <rr...@activedg.com>.
Michael Scheidell wrote:
> On 6/24/10 12:07 PM, Randy Ramsdell wrote:
>> Anyone receiving these? It is either a borked spam script or they are
>> probing. They come in with different headers and different body each
>> time so I am not sure how to mark or block them. Any suggestions would
>> be appreciated.
>>
>> http://pastebin.com/kQJ0SPti
>>
> at least for THIS one, RCVD_IN_PBL
>
> if you are using this BL, you might just want to block it at the MTA
> level and not even scan it.
>
> (I suspect the spam/vs ham scoring on that rule is so low because the
> people submitting spam corpus probally block it at the MTA level and
> never see it.
> My understanding of PBL is that its at least 99.999% free of FP's)
>
Yet spamassassin scores it with a .9. I have been reluctant to block and
this is compounded by spamassassin scoring it low as if it weren't as
accurate as you state.
Re: Nonsense spam
Posted by Michael Scheidell <sc...@secnap.net>.
On 6/24/10 12:07 PM, Randy Ramsdell wrote:
> Anyone receiving these? It is either a borked spam script or they are
> probing. They come in with different headers and different body each
> time so I am not sure how to mark or block them. Any suggestions would
> be appreciated.
>
> http://pastebin.com/kQJ0SPti
>
at least for THIS one, RCVD_IN_PBL
if you are using this BL, you might just want to block it at the MTA
level and not even scan it.
(I suspect the spam/vs ham scoring on that rule is so low because the
people submitting spam corpus probally block it at the MTA level and
never see it.
My understanding of PBL is that its at least 99.999% free of FP's)
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________