You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2008/03/26 10:32:38 UTC
Re: SORBS_DUL
James Gray writes:
> On Wed, 26 Mar 2008 12:09:47 pm D Hill wrote:
> > Now your confusing the subject. The previous response you made was from:
> >
> > From: James Gray <ja...@dot.com.au>
> >
> > Now you are using:
> >
> > From: James Gray <ja...@gray.net.au>
> >
> > BOTH of those domains point to an MX that has a CNAME to:
> >
> > smtp.mas.viperplatform.net.au
>
> So I use one mail client and occasionally forget to set the correct profile to
> send as.. sorry.
>
> No. None of the domains have any references to smtp.mas... as an MX record.
> They all point to mail.mas... and they all have a default TTL of 38400 for
> the zone.
>
> Besides, this still doesn't change my original point that SORBS have a habit
> of listing addresses (justifiably or not) then attempt to extract money to
> remove the listing. That's just extortion, not a good RBL.
It's worth noting that SpamAssassin has *never* used the SORBS sublist
that requires this payment. We do not endorse that "pay-to-remove"
concept.
Also, folks -- regardless of how RFC-anal his DNS records are, that
doesn't change the fact that SORBS DUL is listing his IP space
incorrectly. This is *definitely* a false positive for SORBS. So please
stop rattling on about that end of things.
Anyway -- the SORBS DUL sublist is still in SpamAssassin due to its
success at hitting spam with few false positives. Compare their accuracy
ratings against the nearest analogue, RCVD_IN_PBL:
http://ruleqa.spamassassin.org/20080322-r639965-n/RCVD_IN_SORBS_DUL/detail
http://ruleqa.spamassassin.org/20080322-r639965-n/RCVD_IN_PBL/detail
SPAM% HAM%
36.2977 488419 of 1345591 messages 0.1094 87 of 79523 messages
0.997 0.91 0.00 RCVD_IN_SORBS_DUL
66.7720 898478 of 1345591 messages 0.1823 145 of 79523 messages
0.997 0.87 0.00 RCVD_IN_PBL
that's a 99.7% accuracy rating, and generally hitting on the low-scoring
spam too, which is the most valuable. Having said that, it has a very
low score; in set3 it provides only 0.91 points. That's the GA
compensating for its false positives.
Nowadays it's mostly subsumed into PBL:
overlap spam: 91% of RCVD_IN_SORBS_DUL hits also hit RCVD_IN_PBL;
49% of RCVD_IN_PBL hits also hit RCVD_IN_SORBS_DUL
so it's likely that the PBL would compensate entirely for the loss
of SORBS DUL, if we were to remove it. But we don't know.
If you like, open a bug on our bugzilla suggesting that for the next
rescoring run (for 3.3.0), we disable SORBS_DUL and see if accuracy
survives ok, and we will try that out.
--j.
Re: SORBS_DUL
Posted by mouss <mo...@netoyen.net>.
James Gray wrote:
> [snip]
> According to SORBS:
>
> Netblock: 202.147.75.0/26 (202.147.75.0-202.147.75.63)
> Record Created: Thu May 11 02:23:32 2006 GMT
> Record Updated: Thu May 11 02:23:32 2006 GMT
> Additional Information: [MU] Dynamic/Generic IP/rDNS address, use
> your ISPs mail server or get rDNS set to indicate static assignment.
>
> The entire 202.147.74.0/23 block has *NEVER* been part of a dynamic
> range and was purchased as part of our /19 back in 1999 (or maybe
> 2000...before my time with this company anyway) when that address
> range was first made available by APNIC. Some of the other class-C's
> in our /19 have been used for a long-since-sold ISP business, but not
> the 202.147.74.0/23 block.
>
> There's only a few externally exposed MTA's in that range (although
> our mail cluster is quite large). The ones really biting us on the
> arse are:
> 202.147.74.51 (also listed on DUHL, but on a 202.147.74.0/26)
> 202.147.75.20
> 202.147.75.21
The last two don't resolve from here. make sure you have a PTR and try
delisting them individually first. use a large TTL in these PTRs. once
all your problems solved, you can switch back to whatever TTL you want.
the .51 seems ok to me, but if you can, do increase the TTLs in:
ns1.viperplatform.net.au. 436 IN A 202.147.74.80
ns2.viperplatform.net.au. 436 IN A 202.147.74.81
small TTLs resemble fast flux and may look suspicious. (besides, a small
TTL for NS records is unusual).
The idea is to maximize chances that the sorbs robot delists these IPs.
>
> Do your own queries and whois lookups...but these address blocks are
> INCORRECTLY LISTED BY SORBS and they refuse (yes, I've heard from
> them) to remove them. Apparently because our inbound and outbound
> MTA's don't use the same addresses! I have no idea what crack-monkey
> at SORBS wrote that, but that was the response we got in relation to
> our request to remove our IP's.
There may be some misunderstanding between you and them (or between you
and their robot?). I understand that this is annoying, but I think
you'll get better results by staying calm and doing some efforts until
your issues are solved.
PS. If you ever post on a sorbs mailing list, don't use the words you
used here ;-p
>
> I hope that clears it up :)
>
> Cheers,
>
> James
>
RE: SORBS_DUL
Posted by "James E. Pratt" <jp...@norwich.edu>.
>
> Do your own queries and whois lookups...but these address blocks are
> INCORRECTLY LISTED BY SORBS and they refuse (yes, I've heard from
them)
> to remove them. Apparently because our inbound and outbound MTA's
> don't
> use the same addresses! I have no idea what crack-monkey at SORBS
> wrote
> that, but that was the response we got in relation to our request to
> remove our IP's.
>
> I hope that clears it up :)
>
> Cheers,
>
> James
Sigh... Can we clear this up for _real_??
... Regardless of whether or not SORBS listings are "accurate" or not,
or should or should not be included in SA, apparently some people cannot
read, or are overly confused...
----------------------
Straight from the SORBS website:
If you are listed in the Spam Database read the Spam Database FAQ, then
and only then you have 2 options.
Pay the fine, and get delisted.
Argue that you shouldn't have to pay.
Paying the fine will get you delisted very quickly (usually within 48
hours)... However, when donating to the Royal Childrens Hospital and
sending in the receipt ensure you send in the receipt number (the actual
receipt is not needed, only the number - this is usually prefixed 'IR').
Due to privacy laws and the fact SORBS is not part of or connected with
the charity. Payment confirmations can only be verified when a receipt
number is given along withe the payee's name.
Arguing with a SORBS administrator about how you are not the person
responsible, or how you just got the address (or any other excuse) will
result in a 'boiler plate' reply. It will be blunt and usually
impersonal, this may appear rude, but is it not meant to be, it is just
meant to be efficient.
Note: There are a few good reasons why you may get delisted without
paying the fine. These will be dealt with by an admin personally.
------------------
So James - Like it says above, you really have two options. Quit
complaining here and pay the AU Hospital and send sorbs the
invoice/receipt, or perhaps if you approached the situation without
downright rudeness (yes, you sound like a rude person to have to deal
with based on your posts.. Sorry!), the admin would deal with you
"personally", but frankly, if anyone there reads this list-serv, well..
all I can say is "good luck with that".. :\
~Ciao
jp
Re: SORBS_DUL
Posted by James Gray <ja...@gray.net.au>.
mouss wrote:
> Justin Mason wrote:
>> James Gray writes:
>>
>>> On Wed, 26 Mar 2008 12:09:47 pm D Hill wrote:
>>>
>>>> Now your confusing the subject. The previous response you made was
>>>> from:
>>>>
>>>> From: James Gray <ja...@dot.com.au>
>>>>
>>>> Now you are using:
>>>>
>>>> From: James Gray <ja...@gray.net.au>
>>>>
>>>> BOTH of those domains point to an MX that has a CNAME to:
>>>>
>>>> smtp.mas.viperplatform.net.au
>>>>
>>> So I use one mail client and occasionally forget to set the correct
>>> profile to send as.. sorry.
>>>
>>> No. None of the domains have any references to smtp.mas... as an MX
>>> record. They all point to mail.mas... and they all have a default
>>> TTL of 38400 for the zone.
>>>
>>> Besides, this still doesn't change my original point that SORBS have
>>> a habit of listing addresses (justifiably or not) then attempt to
>>> extract money to remove the listing. That's just extortion, not a
>>> good RBL.
>>>
>>
>> It's worth noting that SpamAssassin has *never* used the SORBS sublist
>> that requires this payment. We do not endorse that "pay-to-remove"
>> concept.
>>
>> Also, folks -- regardless of how RFC-anal his DNS records are, that
>> doesn't change the fact that SORBS DUL is listing his IP space
>> incorrectly. This is *definitely* a false positive for SORBS. So please
>> stop rattling on about that end of things.
>>
>
> How do you know that sorbs is listing his IP space incorrectly? he
> didn't show what IP space he was talking about.
According to SORBS:
Netblock: 202.147.75.0/26 (202.147.75.0-202.147.75.63)
Record Created: Thu May 11 02:23:32 2006 GMT
Record Updated: Thu May 11 02:23:32 2006 GMT
Additional Information: [MU] Dynamic/Generic IP/rDNS address, use your
ISPs mail server or get rDNS set to indicate static assignment.
The entire 202.147.74.0/23 block has *NEVER* been part of a dynamic
range and was purchased as part of our /19 back in 1999 (or maybe
2000...before my time with this company anyway) when that address range
was first made available by APNIC. Some of the other class-C's in our
/19 have been used for a long-since-sold ISP business, but not the
202.147.74.0/23 block.
There's only a few externally exposed MTA's in that range (although our
mail cluster is quite large). The ones really biting us on the arse are:
202.147.74.51 (also listed on DUHL, but on a 202.147.74.0/26)
202.147.75.20
202.147.75.21
Do your own queries and whois lookups...but these address blocks are
INCORRECTLY LISTED BY SORBS and they refuse (yes, I've heard from them)
to remove them. Apparently because our inbound and outbound MTA's don't
use the same addresses! I have no idea what crack-monkey at SORBS wrote
that, but that was the response we got in relation to our request to
remove our IP's.
I hope that clears it up :)
Cheers,
James
Re: SORBS_DUL
Posted by mouss <mo...@netoyen.net>.
Justin Mason wrote:
> James Gray writes:
>
>> On Wed, 26 Mar 2008 12:09:47 pm D Hill wrote:
>>
>>> Now your confusing the subject. The previous response you made was from:
>>>
>>> From: James Gray <ja...@dot.com.au>
>>>
>>> Now you are using:
>>>
>>> From: James Gray <ja...@gray.net.au>
>>>
>>> BOTH of those domains point to an MX that has a CNAME to:
>>>
>>> smtp.mas.viperplatform.net.au
>>>
>> So I use one mail client and occasionally forget to set the correct profile to
>> send as.. sorry.
>>
>> No. None of the domains have any references to smtp.mas... as an MX record.
>> They all point to mail.mas... and they all have a default TTL of 38400 for
>> the zone.
>>
>> Besides, this still doesn't change my original point that SORBS have a habit
>> of listing addresses (justifiably or not) then attempt to extract money to
>> remove the listing. That's just extortion, not a good RBL.
>>
>
> It's worth noting that SpamAssassin has *never* used the SORBS sublist
> that requires this payment. We do not endorse that "pay-to-remove"
> concept.
>
> Also, folks -- regardless of how RFC-anal his DNS records are, that
> doesn't change the fact that SORBS DUL is listing his IP space
> incorrectly. This is *definitely* a false positive for SORBS. So please
> stop rattling on about that end of things.
>
How do you know that sorbs is listing his IP space incorrectly? he
didn't show what IP space he was talking about.
>
> Anyway -- the SORBS DUL sublist is still in SpamAssassin due to its
> success at hitting spam with few false positives. Compare their accuracy
> ratings against the nearest analogue, RCVD_IN_PBL:
>
> http://ruleqa.spamassassin.org/20080322-r639965-n/RCVD_IN_SORBS_DUL/detail
> http://ruleqa.spamassassin.org/20080322-r639965-n/RCVD_IN_PBL/detail
>
> SPAM% HAM%
> 36.2977 488419 of 1345591 messages 0.1094 87 of 79523 messages
> 0.997 0.91 0.00 RCVD_IN_SORBS_DUL
> 66.7720 898478 of 1345591 messages 0.1823 145 of 79523 messages
> 0.997 0.87 0.00 RCVD_IN_PBL
>
> that's a 99.7% accuracy rating, and generally hitting on the low-scoring
> spam too, which is the most valuable. Having said that, it has a very
> low score; in set3 it provides only 0.91 points. That's the GA
> compensating for its false positives.
>
> Nowadays it's mostly subsumed into PBL:
>
> overlap spam: 91% of RCVD_IN_SORBS_DUL hits also hit RCVD_IN_PBL;
> 49% of RCVD_IN_PBL hits also hit RCVD_IN_SORBS_DUL
>
> so it's likely that the PBL would compensate entirely for the loss
> of SORBS DUL, if we were to remove it. But we don't know.
>
> If you like, open a bug on our bugzilla suggesting that for the next
> rescoring run (for 3.3.0), we disable SORBS_DUL and see if accuracy
> survives ok, and we will try that out.
>
> --j.
>