You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ron McKeating <R....@lboro.ac.uk> on 2004/08/04 10:38:34 UTC

Confused over Sorbs

Hi all,

I just got a complaint from a user because of a false positive that was
filtered into their spam folder. A very small part of the score came
from the rule

0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS
        *      [81.136.151.191 listed in dnsbl.sorbs.net]

Looking at the headers (see below) I do not understand why this rule
comes into effect. The sender sent the email validly through her ISP
(yahoo.com). I thought if you did that then that rule did not kick in.
Am I missing something here?

Ron

Return-path: <he...@ocis.co.uk>
Delivery-date: Tue, 03 Aug 2004 12:30:22 +0100
Received: from [158.125.1.193] (helo=bill.lut.ac.uk)
        by dougal.lut.ac.uk with esmtp (Exim 4.30)
        id 1BrxUs-0007lc-Bh
        for ccrah@support-staff-mailin.lut.ac.uk; Tue, 03 Aug 2004
12:30:22 +0100
Received: from smtp810.mail.ukl.yahoo.com ([217.12.12.200])
        by bill.lut.ac.uk with smtp (Exim 4.41)
        id 1BrxUl-0002je-GP
        for R.A.Haskins@lboro.ac.uk; Tue, 03 Aug 2004 12:30:22 +0100
Received: from unknown (HELO HELEN01)
(jamesd.murphy@ocis.co.uk@81.136.151.191 with poptime)
  by smtp810.mail.ukl.yahoo.com with SMTP; 3 Aug 2004 11:29:44 -0000
Message-ID: <01...@HELEN01>
Reply-To: "Helen Fairhead" <he...@ocis.co.uk>
From: "Helen Fairhead" <he...@ocis.co.uk>
To: "Bob Haskins" <R....@lboro.ac.uk>


-- 
Ron McKeating
Senior IT Services Specialist
Internet Services and Software Solutions
Loughborough University
01509 222329


Re: Confused over Sorbs

Posted by Jeff Chan <je...@surbl.org>.
On Wednesday, August 4, 2004, 1:38:34 AM, Ron McKeating wrote:
> Hi all,

> I just got a complaint from a user because of a false positive that was
> filtered into their spam folder. A very small part of the score came
> from the rule

> 0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS
>         *      [81.136.151.191 listed in dnsbl.sorbs.net]

> Looking at the headers (see below) I do not understand why this rule
> comes into effect. The sender sent the email validly through her ISP
> (yahoo.com). I thought if you did that then that rule did not kick in.
> Am I missing something here?

> Ron

> Return-path: <he...@ocis.co.uk>
> Delivery-date: Tue, 03 Aug 2004 12:30:22 +0100
> Received: from [158.125.1.193] (helo=bill.lut.ac.uk)
>         by dougal.lut.ac.uk with esmtp (Exim 4.30)
>         id 1BrxUs-0007lc-Bh
>         for ccrah@support-staff-mailin.lut.ac.uk; Tue, 03 Aug 2004
> 12:30:22 +0100
> Received: from smtp810.mail.ukl.yahoo.com ([217.12.12.200])
>         by bill.lut.ac.uk with smtp (Exim 4.41)
>         id 1BrxUl-0002je-GP
>         for R.A.Haskins@lboro.ac.uk; Tue, 03 Aug 2004 12:30:22 +0100
> Received: from unknown (HELO HELEN01)
> (jamesd.murphy@ocis.co.uk@81.136.151.191 with poptime)
                            ^^^^^^^^^^^^^^    !!!!!!!!!!!!!!!
>   by smtp810.mail.ukl.yahoo.com with SMTP; 3 Aug 2004 11:29:44 -0000
> Message-ID: <01...@HELEN01>
> Reply-To: "Helen Fairhead" <he...@ocis.co.uk>
> From: "Helen Fairhead" <he...@ocis.co.uk>
> To: "Bob Haskins" <R....@lboro.ac.uk>

Her sending IP 81.136.151.191 *is* listed in SORBS, so the
detection code may be working correctly.

Assuming BT provides outbound mail servers, she should probably
relay through btopenworld.com servers instead of sending directly
to yahoo's mail servers.

That said, I'm not really familiar with how SpamAssassin's RBL
code parses headers, etc. so I can't tell if this behavior
is proper or not.  But she should still use BT's outbound mail
servers.

Jeff C.
-- 
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/


Re: Confused over Sorbs

Posted by John Andersen <js...@pen.homeip.net>.
On Wednesday 04 August 2004 12:38 am, Ron McKeating wrote:
> Hi all,
>
> I just got a complaint from a user because of a false positive that was
> filtered into their spam folder. A very small part of the score came
> from the rule
>
> 0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS
>         *      [81.136.151.191 listed in dnsbl.sorbs.net]
>
> Looking at the headers (see below) I do not understand why this rule
> comes into effect. The sender sent the email validly through her ISP
> (yahoo.com). I thought if you did that then that rule did not kick in.
> Am I missing something here?
>
> Ron
>
> Return-path: <he...@ocis.co.uk>
> Delivery-date: Tue, 03 Aug 2004 12:30:22 +0100
> Received: from [158.125.1.193] (helo=bill.lut.ac.uk)
>         by dougal.lut.ac.uk with esmtp (Exim 4.30)
>         id 1BrxUs-0007lc-Bh
>         for ccrah@support-staff-mailin.lut.ac.uk; Tue, 03 Aug 2004
> 12:30:22 +0100
> Received: from smtp810.mail.ukl.yahoo.com ([217.12.12.200])
>         by bill.lut.ac.uk with smtp (Exim 4.41)
>         id 1BrxUl-0002je-GP
>         for R.A.Haskins@lboro.ac.uk; Tue, 03 Aug 2004 12:30:22 +0100
> Received: from unknown (HELO HELEN01)
> (jamesd.murphy@ocis.co.uk@81.136.151.191 with poptime)

The rule says the SENDER was in SORBS, not the relays.  
The IP was reported to SORBS as a source of spam at one time
or another (could be a dialup?).  


-- 
_____________________________________
John Andersen

Re: Confused over Sorbs

Posted by Matt Kettler <mk...@comcast.net>.
At 09:38 AM 8/4/2004 +0100, Ron McKeating wrote:
>I just got a complaint from a user because of a false positive that was
>filtered into their spam folder. A very small part of the score came
>from the rule
>
>0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS
>         *      [81.136.151.191 listed in dnsbl.sorbs.net]
>
>Looking at the headers (see below) I do not understand why this rule
>comes into effect. The sender sent the email validly through her ISP
>(yahoo.com). I thought if you did that then that rule did not kick in.
>Am I missing something here?

This is actually a byproduct of how SORBS works, and how SA handles RBLS.

However, it's very much intentional that the rule only scores 0.1 points. 
It's because of the exact case you ran into here, and it's to prevent it 
from causing a false positive for this specific case.

In short, it's a non-issue that SA's already designed to handle. In 
detail.. read on.

The deal is that SORBS is an aggregate list of many RBLs. Some of those 
RBLs are "standard" RBLs that get checked against every IP address in the 
headers. One of those RBLs is a "dialup" listing, which only gets checked 
against the relays.

In order to be more efficient, all of these RBLs are checked as a single 
query per IP, and SA interprets the answers it gets to decide if a 
particular RBL within SORBS hit.

However, that means there has to be a "root" rule that generates the DNS 
query that all of the sub-tests use. Since some of the RBLS in sorbs are 
non-dailup, the root rule has to be checked against every IP in the 
message, and the difference gets split-up in the sub-tests. Since the root 
rule fires off when *any* of the SORBS RBLS match, it will always fire off 
on dialup email, regardless of wether or not it was properly relayed, 
because the root rule is always checked on all IPs.  The SA-devs *know* 
about the issue here, which is why the score of the root rule is forced 
low. If it was set to 3.0 or something, we'd have a real problem.

Now, if that email had NOT been relayed properly, it would have also 
matched the RCVD_IN_DYNABLOCK test (renamed into SORBS_DUL in 3.0), which 
is where the real score would be applied. That rule would have scored 2.5 
points, but that rule is configured for "notfirsthop" to not trigger on 
legitamate dialup email.

Basicaly, all of the following are sub-tests of the RCVD_IN_SORBS test, and 
the original rule itself is more-or-less a placeholder:

score RCVD_IN_SORBS_BLOCK 0
score RCVD_IN_SORBS_HTTP 0 1.101 0 1.101
score RCVD_IN_SORBS_MISC 0 1.101 0 0.687
score RCVD_IN_SORBS_SMTP 0 1.522 0 2.700
score RCVD_IN_SORBS_SOCKS 0 1.101 0 1.204
score RCVD_IN_SORBS_WEB 0 2.800 0 0
score RCVD_IN_SORBS_ZOMBIE 0 2.596 0 2.599
score RCVD_IN_DYNABLOCK 0 2.546 0 2.599