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
of short
TTL's. As I have stated, the TTL's were dropped recently and restored
back recently but the SORBS listing was made in 2006 - long before I
started with this company and long before the recent co-lo move.
Why? Can you remove them from the SORBS_DUL? No, then it's not really
relevant
James Gray wrote:
[snip]
I didn't ASK FOR HELP! I asked what people's thoughts were on keeping
a list like SORBS_DUL in the base/default spamassassin rules. I'm
quite capable of fixing the mess I inherited.
As long as
- it doesn't cause FPs
- it helps catch spam
- it is free for use
James Gray wrote:
Sorbs sux, don't use it. Last time we had this problem they wanted
money (and not an insignificant amount either) to remove a listing
from their systems. They arbitrarily add addresses to a database the
IP's owner can't control, then demand money to remove the listing;
it? Unfortunately, being
on SORBS_DUL doesn't impact us directly, and despite the claims that
removal is free, th reality is proving to be quite different.
Regardless, what matters from a spamassassin perspective is the
accuracy of the list. That's the primary criteria that will get a list
kicked
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
James E. Pratt writes:
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
of that :-/ Embarrassing isn't it? Unfortunately,
being on SORBS_DUL doesn't impact us directly, and despite the claims
that removal is free, th reality is proving to be quite different.
Regardless, what matters from a spamassassin perspective is the
accuracy of the list. That's the primary criteria
On Wed, 26 Mar 2008 03:31:34 am mouss wrote:
while you are at it, fix your DNS. your domain has been succesfully
submitted to rfci (boguxms):
http://www.rfc-ignorant.org/tools/lookup.php?domain=gray.net.au
On 26.03.08 11:30, James Gray wrote:
Yes - that's one of my personal domains,
both our external mail IP's listed in SORBS_DUL despite the
fact the /24 they belong to, and the /24's on either side have NEVER
been part of a dynamic pool.
what are those IPs and their DNS records?
Why? Can you remove them from the SORBS_DUL? No, then it's not really
relevant
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.
;
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
Why? Can you remove them from the SORBS_DUL? No, then it's not
really
relevant then is it ;)
I was trying to help you find the real problem. If you don't want
help,
stop
bitching.
I have seen more requests here to stop using some blacklists because
of
the
requestor was unable
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 [EMAIL PROTECTED]
Now you are using:
From: James Gray [EMAIL PROTECTED]
BOTH of those
many e-mail addresses and switch and
change between them at will.
The SORBS_DUL seems to arbitrarily gobble up blocks that have never been
part of dynamic ranges, and never been parked either, then they refuse
to de-list them. That is the situation I am faced with currently. See
my most recent
for purchased a /19 address block directly from APNIC
before anyone else had it (IOW, we were the first users of that block).
We now have both our external mail IP's listed in SORBS_DUL despite the
fact the /24 they belong to, and the /24's on either side have NEVER
been part of a dynamic pool. SORBS
listed in SORBS_DUL despite the
fact the /24 they belong to, and the /24's on either side have NEVER
been part of a dynamic pool.
what are those IPs and their DNS records?
SORBS refuse to delist them as our MX
records are different to these outgoing mail servers! FFS - we run
managed
for Ips and netblocks to be in the DUL database and
I thought it said it was because of published info by the ISP as well as
reverse lookup records. Over the years of my use of SORBS_DUL, I've
seen maybe a dozen or so .coms that had their static ISP assigned
address in SURBS_DUL because of their PTR
, the
company I work for purchased a /19 address block directly from APNIC
before anyone else had it (IOW, we were the first users of that block).
We now have both our external mail IP's listed in SORBS_DUL despite
the fact the /24 they belong to, and the /24's on either side have
NEVER been part
listed in SORBS_DUL despite the
fact the /24 they belong to, and the /24's on either side have NEVER
been part of a dynamic pool.
what are those IPs and their DNS records?
Why? Can you remove them from the SORBS_DUL? No, then it's not really
relevant then is it ;)
SORBS refuse to delist them
in it, good luck getting off it! Case at hand, the
company I work for purchased a /19 address block directly from APNIC
before anyone else had it (IOW, we were the first users of that block).
We now have both our external mail IP's listed in SORBS_DUL despite
the fact the /24 they belong
in it, good luck getting off it! Case at hand, the
company I work for purchased a /19 address block directly from APNIC
before anyone else had it (IOW, we were the first users of that block).
We now have both our external mail IP's listed in SORBS_DUL despite
the fact the /24 they belong
in SORBS_DUL despite
the fact the /24 they belong to, and the /24's on either side have
NEVER been part of a dynamic pool. SORBS refuse to delist them as our
MX records are different to these outgoing mail servers! FFS - we run
managed services for a number of ISP's why the hell would we *want
users of that block).
We now have both our external mail IP's listed in SORBS_DUL despite
the fact the /24 they belong to, and the /24's on either side have
NEVER been part of a dynamic pool. SORBS refuse to delist them as our
MX records are different to these outgoing mail servers! FFS - we run
On Wed, 26 Mar 2008 11:51:32 am D Hill wrote:
Actually, closer inspection shows your:
ns2.viperplatform.net.au
is still reporting back:
smtp.mas.viperplatform.net.au
You're assuming gray.net.au and the viperplatform.net.au domains are the
same...they're not. If you query MY DNS
had it (IOW, we were the first users of that block).
We now have both our external mail IP's listed in SORBS_DUL despite
the fact the /24 they belong to, and the /24's on either side have
NEVER been part of a dynamic pool. SORBS refuse to delist them as our
MX records are different
incorrectly listed in it, good luck getting off it! Case at hand, the
company I work for purchased a /19 address block directly from APNIC
before anyone else had it (IOW, we were the first users of that block).
We now have both our external mail IP's listed in SORBS_DUL despite
the fact the /24
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 [EMAIL PROTECTED]
Now you are using:
From: James Gray [EMAIL PROTECTED]
BOTH of those domains point to an MX that has a CNAME to:
listed in SORBS_DUL despite
the fact the /24 they belong to, and the /24's on either side have
NEVER been part of a dynamic pool. SORBS refuse to delist them as our
MX records are different to these outgoing mail servers! FFS - we run
managed services for a number of ISP's why the hell
Rick Macdougall wrote:
Daryl C. W. O'Shea wrote:
[EMAIL PROTECTED] wrote:
Received: from host-212-158-194-14.bulldogdsl.com (HELO
phoenix.example.com) (212.158.194.14)
by secure.example.name with (DHE-RSA-AES256-SHA encrypted) SMTP; 1
Jul 2005 10:00:52 +0100
What SMTP service
Sorry for the slight delay, replies inline:
At 01:39 07-07-05, Daryl C. W. O'Shea - [EMAIL PROTECTED] wrote:
Received: from host-212-158-194-14.bulldogdsl.com (HELO
phoenix.example.com) (212.158.194.14)
by secure.example.name with (DHE-RSA-AES256-SHA encrypted) SMTP;
1 Jul 2005 10:00:52
[EMAIL PROTECTED] wrote:
Sorry for the slight delay, replies inline:
At 01:39 07-07-05, Daryl C. W. O'Shea - [EMAIL PROTECTED] wrote:
Received: from host-212-158-194-14.bulldogdsl.com (HELO
phoenix.example.com) (212.158.194.14)
by secure.example.name with (DHE-RSA-AES256-SHA encrypted)
[EMAIL PROTECTED] wrote:
Received: from host-212-158-194-14.bulldogdsl.com (HELO
phoenix.example.com) (212.158.194.14)
by secure.example.name with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Jul
2005 10:00:52 +0100
What SMTP service generates this header?
phoenix.example.com is a machine
Daryl C. W. O'Shea wrote:
[EMAIL PROTECTED] wrote:
Received: from host-212-158-194-14.bulldogdsl.com (HELO
phoenix.example.com) (212.158.194.14)
by secure.example.name with (DHE-RSA-AES256-SHA encrypted) SMTP; 1
Jul 2005 10:00:52 +0100
What SMTP service generates this header?
Hi
[EMAIL PROTECTED] wrote:
Hi,
I just sent myself two test-mails from my home machine, and realised
that they were both triggering the RCVD_IN_NJABL_DUL and
RCVD_IN_SORBS_DUL tests, and scoring alarmingly high, but brought down
again due to the Bayes tests:
-- Complete Mail
Hi,
I just sent myself two test-mails from my home machine, and realised
that they were both triggering the RCVD_IN_NJABL_DUL and
RCVD_IN_SORBS_DUL tests, and scoring alarmingly high, but brought
down again due to the Bayes tests:
-- Complete Mail
Return-Path: [EMAIL
36 matches
Mail list logo
