Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Wrong behavior from DNSBL apews.org?

259 views
Skip to first unread message

sancho

unread,
Jan 23, 2010, 11:26:46 AM1/23/10
to
Hi,

I don't know why, but at apews.org there seem to be some very
aggresive rules to be active. This is definetly doing more harm then
good...

The problem is, that the mailsystems from our customer (83.236.152.228
and 83.236.152.229) are listed in their database, as we are part of
the class b net 83.236.0.0/16. But as one can see on the ripe
database, the customers range is from 83.236.152.224 to
83.236.152.239. I think we are not responsible for a whole provider,
nor should apews.org block an hole ISP net.

Apews.org does not provide manual delisting or an email contact.
Great!

Any idea how to get rid of this?

Regards
Mathias Tauber

--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.

MrD

unread,
Jan 24, 2010, 12:23:05 PM1/24/10
to
sancho wrote:
> Hi,
>
> I don't know why, but at apews.org there seem to be some very
> aggresive rules to be active. This is definetly doing more harm then
> good...

Ho-hum. Repetitive whingeing about BACKSCATTERER is banned;
similarly-repetitive whingeing about APEWS is OK.

It's a strange world.


>
> The problem is, that the mailsystems from our customer
> (83.236.152.228 and 83.236.152.229) are listed in their

(APEWS')

> database, as we are part of the class b net 83.236.0.0/16.

Who is "we"? Are you QSC AG? If so, you are responsible for the entire
block, not just "part" of it. The RIPE listing says that 83.236.152.229
is allocated to a customer of QSC AG. If you are some middleman (neither
QSC nor the customer), then you don't seem to be involved in this matter
at all.

> But as one can see on the ripe database, the customers range is from
> 83.236.152.224 to 83.236.152.239. I think we are not responsible for
> a whole provider,

Which "whole provider"? Who is "we"?

> nor should apews.org block an hole ISP net.

It has always been so. The "EW" in "APEWS" stands for "Early Warning" -
APEWS lists address-space it thinks is likely to emit spam. It lists
containing blocks if smaller blocks persist in spamming. Whether it
"should" behave like that or not is a pointless debate - that's what it
does, and it's unlikely to change.


>
> Apews.org does not provide manual delisting or an email contact.

If you are QSC AG, then the APEWS listing told you all you need to know.
If you are not, then someone from QSC AG needs to deal with this. Either
way, you don't need a manual delisting facility, nor an email contact.


>
> Any idea how to get rid of this?

Take another look at the APEWS listing - it tells you what has to be done.

--
MrD.
http://ipquery.org

1urk3r

unread,
Jan 24, 2010, 8:37:39 PM1/24/10
to
On Jan 23, 10:26 am, sancho <tau...@hdpnet.de> wrote:
> Hi,
>
> I don't know why, but at apews.org there seem to be some very
> aggresive rules to be active. This is definetly doing more harm then
> good...
>
> The problem is, that the mailsystems from our customer (83.236.152.228
> and 83.236.152.229) are listed in their database, as we are part of
> the class b net 83.236.0.0/16. But as one can see on the ripe
> database, the customers range is from 83.236.152.224 to
> 83.236.152.239. I think we are not responsible for a whole provider,
> nor should apews.org block an hole ISP net.
>
> Apews.org does not provide manual delisting or an email contact.
> Great!
>
> Any idea how to get rid of this?
>

because it is sometimes claimed that APEWS is a manifestation of the
phenomenon known as "DNSBL theatre," all readers of this newsgroup
would be interested in seeing evidence of an actual instance of email
rejected based on a listing in APEWS. if you have such evidence, would
you please post a copy here?

if you feel it necessary to preserve personal privacy, you can of
course elide any references to the individual sender and receiver, but
please do not remove references to the receiving system, if such a
thing exists.


adam

--

0 new messages