[120133] in North American Network Operators' Group
Re: Arrogant RBL list maintainers
daemon@ATHENA.MIT.EDU (Sven Olaf Kamphuis)
Thu Dec 10 11:47:47 2009
Date: Thu, 10 Dec 2009 16:46:50 +0000 (GMT)
From: Sven Olaf Kamphuis <sven@cyberbunker.com>
To: dcrocker@bbiw.net
In-Reply-To: <4B211728.8050302@dcrocker.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>
> On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote:
> > As previously noted in this thread, msullivan@sorbs did a fairly good
> > job of documenting this in an RFC draft. I'd say its still the primary
> > goto to point people at for how to do things the "right way".
> >
> > http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00
>
>
> The time to pursue something like this in the IETF is when there is a
> substantial industry consensus that it is the right approach and that the folks
> supporting it will actually use it.
>
> Are those of you who have participated in this thread willing to conform to the
> model specified in this draft?
no, as having PTR records in "dot seperated form" could potentially cause
confusion with normal ip addresses in case the search domain is the same.
we stick to the "must start with an alphabetic and not contain dots"
method, as in "a84-22-123-123" not as in 84.22.123.123.bla.cb3rob.com
(which actually are also the host names on the devices on those ips in
most cases (although customers are ofcourse free to change that after the
control has been given over to them in case of rented out servers).
as for the rest of it, i really don't see why we should specifically
"mark" static space as being static space as it's simply the de-facto
standard, anything else (dhcp, radius, etc) is -optional- and requires
extra protocols, so just mark dynamic ip space explicitly instead (if
anything)
It's also a thing that does not "belong" in dns but rather in whois if
anywhere at all.
RBLs are neither authorised (EU privacy laws anyone?), nor the appointed
authority to keep databases on "whats static or not". RIRs -are-, if
anyone should maintain a database on such things, i'd be the rirs
(which they have, it's called "whois", it just lacks a field that
indicates the type of assignment method used.
but i guess that would quickly end the "selling point" of such databases,
as who needs Trend Micro if either DNS or whois already contained all
required data to just make your mailservers check it in real-time.
Anyway, i wish Trend Micro all the luck with maintaining their little
database in the age of IPv6 and decaying SMTP use anyway (we nowadays
prefer methods like skype, msn, jabber for most of our communications,
SMTP has been considered end-of-life for the past 5 years or so over here
in our companies, guess why, because it hardly ever works, thanks to
companies like Trend Micro just making up their own little standards.
it's just a bit annoying for customers that happen to want to send SMTP
based (legacy) email to parties that use their RBL, that's all, but
indeed, their list will rapidly be removed by any party using it that
finds out about their "criteria" to be removed (as they seem to add
a lot of stuff by default as being dynamic, kinda the wrong way around ;)
spam is -not- what will eventually kill all support for smtp (that can be
easily solved by adding a header field with a unique password for each
contact you have approved, and bouncing everything that doesnt contain
one ;), shitty amateuristic RBL lists and graylisting (so your urgent mail
arrives 20 minutes late) is what's killing smtp support.
the only reason -we- still run it is that RIPE etc do not support other
address types in whois and mailinglists (such as nanog) still use it.
as it's neither peer to peer anymore, nor real-time (with a lot of
parties blocking port 25), nor very certain that your message actually
will be delivered anymore.
We prefer the pre-approved contact list method anyway, you may notice our
emails have this X-CONTACT-FILTER-MATCH: nanog "header" at the bottom,
added by our contact-filter software (kinda like procmail but different)
as "nanog" happens to be the "super secret password" for this list.
business cards etc all contain a unique password, as when you don't know
us and we don't know you, you have no business mailing us, same as on
skype and msn "contact lists".
methods like that could ofcourse be implemented in the protocol SMTP itself
and in all the clients so it could become a proper mail header at one point,
removing the need for all the other crap that only slows the exchange of mail
down and lessens its reliability and doesn't really stop spam anyway ;).
we don't feel that:
- dns is the proper place to distinquish between address assignment
methods
- dns should be relevant for SMTP to work anyway
- RBLs should be authorative to maintain databases of address assignment
methods (although the EU privacy laws take it a bit too far, prohibiting
companies in germany where we are from even storing IP addresses in the
first place ;)
- RBLs are an effective method to stop spam (it stops -some-.. not -all-)
- Making SMTP less reliable and less fast is a good way to go forward if
we want to keep the SMTP protocol around in the future.
- Making it impossible to use SMTP in a peer-to-peer fashion on eyeball
networks and therefore not very real-time anymore is a good idea.
furthermore, trend micro is simply on crack, thinking that they can force
us to practically work for them for free and maintain their list for them.
if they want us to update their -product- as that's what it is with our
-information- they should simply pay us for the manhours, which they
don't, so there. (not to mention that what trend micro is doing is illegal
under german law so we cannot cooperate with them on that ;)
>
> d/
>
> --
>
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
>
> X-CONTACT-FILTER-MATCH: "nanog"
>
