[120076] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Arrogant RBL list maintainers

daemon@ATHENA.MIT.EDU (Sven Olaf Kamphuis)
Wed Dec 9 10:19:47 2009

Date: Wed, 9 Dec 2009 15:18:47 +0000 (GMT)
From: Sven Olaf Kamphuis <sven@cyberbunker.com>
To: nanog@nanog.org
Cc: sales@cb3rob.net, dul@mail-abuse.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

Hi NANOG readers,

We've noticed that Trend Micro "mail-abuse.com" just "assumes" ips are
dynamic by default, adds them to their stupid list, and then expects US to
update -their- database -for them- for free to get them off their stupid
list again. (as ofcourse our customers bug us when their email doesn't
arrive on the other side, hell they even tell the customers to bug -us- ;)

because they just assume that working, rfc compliant, reverse dns that
just-so-happens to be automatically generated would indicate dynamic ip
space.. (or actually because they think using customer-pressure is a good
way to get isps to maintain their product (their database) for them for
free).

we've basically told them to go to hell and we advise everyone who uses
their RBL lists to remove their RBLs from their configs, as what we have
here is a mismanaged list.

as ofcourse we neither intend to change our perfectly fine
"aXXX-XXX-XXX-XXX.cb3rob.net." reverse dns scheme, nor maintain their
database for free for them..

they've probably done the same with other isps that use simular schemes.

just to let everyone know...


---------- Forwarded message ----------
Date: Wed, 9 Dec 2009 12:07:50 GMT
From: Adelaide Santos via RT <dul@mail-abuse.org>
To: sven@cb3rob.net
Cc: sales@cb3rob.net
Subject: [MAPS #322153] Re: WWW remove for 84.22.XX.XX

Hello,

Thank you for this information.  The DUL list is simply a listing of IP blocks which use dynamic IP
assignment, and are prohibited (usually by AUP/TOS) from running servers.  Many ISP's voluntarily
participate in the DUL by providing us with their blocks of dynamically-assigned IP's.  ISPs benefit
from participating in the DUL because the amount of spam and abusive IP traffic originating from
their IP space is reduced, which also reduces the amount of abuse complaints received.  We benefit
because of increased communications and cooperation with the ISPs makes our lists that much
more accurate.  Everyone benefits because the DUL helps stop spam.

See also "Addition due to ISP Participation":
http://mail-abuse.com/support/nominats_dul.html

Currently, you are using a generic naming convention that does not show any indication of being
static. If this space is indeed static, then all rDNS must reference to static in the rDNS.

Here is an example of a generic naming convention:
84.22.XX.0 (a84-22-XX-0.cb3rob.net)
84.22.XX.1 (a84-22-XX-1.cb3rob.net)
<...>

Here is what you can do:
84.22.XX.0 (a84-22-XX-0.fixed.cb3rob.net)
84.22.XX.1 (customer.cb3rob.net)
84.22.XX.2 (a84-22-XX-2.fixed.cb3rob.net)
84.22.XX.3 (mail.cb3rob.net)
84.22.XX.4 (a84-22-XX-4.fixed.cb3rob.net)
<...>

Here are the naming conventions that we uses to decide if an IP or CIDRs is static or dynamic.

Typical static rDNS terms:
bus, biz, colo, ded, fix, mta, perm, server, smtp, static, wsip.

 Typical dynamic rDNS terms:
adsl, cable, dhcp, dialup, dsl, dyn, home, isdn, modem, pool, ppp, or res.

Trend Micro supports the Messaging Anti-Abuse Working Group (MAAWG) Best Practices for
Dynamic Address Sharing. Please review the Best Practices document (available at
http://www.maawg.org/about/publishedDocuments/MAAWG_Dynamic_Space_2008-06.pdf).

We need to see these changes before we can proceed with the removal. If changing the rDNS is not
possible, we suggest that you add a statement in the WHOIS information stating that this space is
statically assigned.

Thank you,
Adelaide Santos
DUL Investigator
Trend Micro Email Reputation Services
http://www.mail-abuse.com/





[sven@cb3rob.net - 2009-12-08 13:23:03 +0000]:

> hi "dul".
>
> none of our ips are "dynamic", as we simply don't do access networks,
> as those are lame and don't make money.
>
> this includes:
>
> 84.22.96.0/19
> 205.189.71.0/24
> 205.189.72.0/23
> 91.209.12.0/24
>
> all of which originate from AS34109 and none of which are "dynamic"
>
> furthermore, i really don't see why -we- should spend time and effort on a
> problem thats initiated on -your- end by your action of
>
> 1: incorrectly adding our ips to your list, thereby obviously causing
> problems for our customers
>
> 2: getting our customers to get us to bug you about it instead of just
> solving it with our customers directly, and therefore not forcing
> us to wasting our time with it.
>
> we generally do not interfere in 'third party' problems, and this clearly
> qualifies as one (together with dmca crap, arrogant irc networks, etc) you
> name it, we don't go and sit in the middle, just solve it with the
> customers!).
>
> as the problem is as follows: you put ips on some list therefore our
> customer cannot mail, exactly WHY should we spend manhours (and therefore
> money) to fix a problem YOU created...
>
> as i'm damn sure we never put any of our ips on some "dynamic pool" list.
>
> it's probably just your software thinking "oh automatically generated
> reverse dns" (which in our case takes the form of
> a84-22-xx-xx.cb3rob.net. as it's RFC complient and we cannot be fucked to
> make up host names for each and every one of our many 10000 of ips in our
> many isp companies worldwide, and doesn't imply "dynamic" lameness AT ALL.
>
> thats just your software being all buggy and shit.
>
> (why oh why does half the world expect isps to solve things for them for
> free... when they are not even our customer.. ;)


-- 

Sven Olaf Kamphuis
CB3ROB Ltd. & Co. KG DataServices

Phone: +31/87-8747479
Skype: CB3ROB
MSN:   sven@cb3rob.net
C.V.:  http://www.linkedin.com/in/cb3rob

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


home help back first fref pref prev next nref lref last post