On Dec 9, 2009, at 12:11 PM, Mike Lieman wrote:

Is there an RFC detailing that specific text strings must be used for static v. dynamic addresses?

Well there is this draft Document, FWIW, http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Which contains suggestions.. -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C Please send all spam to my main address, root@localhost

On Wed, 9 Dec 2009, Mike Lieman wrote:

Is there an RFC detailing that specific text strings must be used for static v. dynamic addresses?

There's this expired draft http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt But really, the rdns should just clearly indicate the use of the IPs if you're going to do generic/script generated rDNS. a84-22-96-117.cb3rob.net doesn't tell me anything except that this IP is part of a large block of generic rDNS. Something like a84-22-96-117.static.cb3rob.net at least indicates that the IPs are static, while a84-22-96-117.dynamic.cb3rob.net clearly indicates the space is dynamic. Doing this takes much of the guesswork out of it when others on the net need to decide "should we accept mail from this IP?" Keeping the indicator as close as possible to the domain helps out for things that do simple string matching. i.e. with a84-22-96-117.dynamic.cb3rob.net, it's a safe bet I don't want mail from *.dynamic.cb3rob.net. That's easier to block (with a single rule) than dynamic.a84-22-96-117.cb3rob.net. Still, if you're serious about getting mail from that IP delivered, its far better to have the PTR = the domain or system name than some generic string roughly equivalent to all the neighboring IP PTRs. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

One could argue that you are *not* complying by using a generic PTR for a mail server. Some would say that a serious mail server should have proper DNS records, others will say that you should accept mail from any IP no matter what.

No, we do have it correct .. they wanted us to fix all the *other* ones (that can't even send mail because they're firewalled from doing so) .. $ dig -t mx csuohio.edu [..] ;; ANSWER SECTION: csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu. [..] ;; ADDITIONAL SECTION: antispam5.csuohio.edu. 10800 IN A 137.148.19.13 antispam4.csuohio.edu. 10800 IN A 137.148.18.13 antispam3.csuohio.edu. 10800 IN A 137.148.18.21 antispam2.csuohio.edu. 10800 IN A 137.148.19.12 (and) 13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu. 13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu. 21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu. 12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu. Cheers, Michael Holstein Cleveland State University

To be clear: because the legitimate mailserver with a proper non-generic reverse was in a block with other generic reverses, they blacklisted you? That's egregiously harsh. SORBS was blocking a customer for a generic reverse entry, I gave them a legit looking reverse (that fwds properly too), solved, if a bit irritating. To require the whole BLOCK be totally legit is too much. /kc On Wed, Dec 09, 2009 at 02:48:28PM -0500, Michael Holstein's said:

No, we do have it correct .. they wanted us to fix all the *other* ones (that can't even send mail because they're firewalled from doing so) ..

$ dig -t mx csuohio.edu [..] ;; ANSWER SECTION: csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu. csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu.

Michael Holstein Cleveland State University

-- Ken Chase - ken@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.

To be clear: because the legitimate mailserver with a proper non-generic reverse was in a block with other generic reverses, they blacklisted you?

Their initial email said : [snip] Trend Micro Notification: 137.148.0.0/16 added to DUL [snip] and then went on to say : [snip] To work with us, please generate the following three lists: 1) TOTAL ALLOCATED SPACE – in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip] Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly. After some arguing back-and-forth .. they (Trend) said : [snip] Also we don't see the IP address as static as we see the generic naming convention of *csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static. [snip] Seriously .. we're a college campus, not a colo. Org-Abuse roles is defined (and valid) and real people read the RFC2142 required addresses. What more do these people want? (Note: they did eventually say "okay, we see the MXs as static so those aren't listed" .. but not without some discussion). Cheers, Michael Holstein Cleveland State University

1) TOTAL ALLOCATED SPACE – in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip]

Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly.

Is your network setup so chaotic that you don't know what address chunks are allocated by DHCP or PPP? They're not asking you to aggregate your printers, they're just asking which ranges are dynamic, since mail directly from dynamic ranges is about 99.999% bot spam. If you really don't know what's dynamic, I can't say I blame them for assuming the worst. R's, John

on Thu, Dec 10, 2009 at 10:48:05AM -0500, Michael Holstein wrote:

Like many places, we run seperate internal and external DNS .. when a user requests a static IP, they can opt to make it "external", but few do, since we point out that when they do that, they loose the anonymity of the "generic" rDNS.

An internal DNS entry might look like : lastname-modelnumber.router.building.csuohio.edu While the external entry might look like : csu-137-148-19-3.csuohio.edu

At least at one point in 2003, you also used, eg finance137-148-212-227.dhcp.csuohio.edu [137.148.212.227] which kindly pointed out that the IP was dynamically assigned (or at least suggested it, I know DHCP can push statics, too). I have the pattern for the csu-n-n-n-n.csuohio.edu naming convention above marked as 'static/lan' - should I have this down as 'natproxy/unknown' instead? Or 'static/unknown'? Or 'static/wan'? I'm a bit confused by what it means to have an "internal" static public IP, I guess. Or are you saying that they have the option of making their chosen internal name also visible via external DNS lookups, with all IPs being public just not all visible via custom names to the outside? -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/

Michael: I've seen their form, too. I think you're reading too much into their policies/requests. Does it matter if they label your non e-mail server IPs as dynamic space, and therefore put it on their DUL? Frank -----Original Message----- From: Michael Holstein [mailto:michael.holstein@csuohio.edu] Sent: Wednesday, December 09, 2009 3:18 PM To: Ken Chase Cc: nanog@nanog.org Subject: Re: Arrogant RBL list maintainers

To be clear: because the legitimate mailserver with a proper non-generic reverse was in a block with other generic reverses, they blacklisted you?

Their initial email said : [snip] Trend Micro Notification: 137.148.0.0/16 added to DUL [snip] and then went on to say : [snip] To work with us, please generate the following three lists: 1) TOTAL ALLOCATED SPACE - in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip] Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly. After some arguing back-and-forth .. they (Trend) said : [snip] Also we don't see the IP address as static as we see the generic naming convention of *csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static. [snip] Seriously .. we're a college campus, not a colo. Org-Abuse roles is defined (and valid) and real people read the RFC2142 required addresses. What more do these people want? (Note: they did eventually say "okay, we see the MXs as static so those aren't listed" .. but not without some discussion). Cheers, Michael Holstein Cleveland State University

On Thu, 10 Dec 2009, Chris Edwards wrote:

On Wed, 9 Dec 2009, Michael Holstein wrote:

| Their initial email said : | | [snip] | Trend Micro Notification: 137.148.0.0/16 added to DUL | [snip]

Oh dear. I can see why many sites that once used MAPS now don't :-(

It isn't just idiocy like this thread. They never expire entries from the RBL, even when IP address space changes hands. The most stupid thing is that they will not accept bug reports from their customers, insisting that they come from the sender (not recipient). WTF?! Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

Ronald Cotoni wrote:

Very true. At my old place of employment a DUHL listed an ip since before my previous company existed. For some reason, when we obtained it, they still listed it. Sounds like a bug in the DUHL bot to me. Also the standard makes a lot of sense. You may be on Trend Micros DUHL by following the rules on SORBS DUHL and vica versa. Makes life a pain.

If you set non generic rDNS or generic following their suggestions you'd be removed from the SORBS DUHL pretty much automagically (a request initiates the rescan) - there is manual stuff on my behalf but nothing for a requestor to worry about. The only reason you wouldn't be is if you had a listing and too short a TTL for the robot to accept the delisting request... A reply would result in a human (usually me) processing netblocks of /24 or greater (greater as in number of IPs) providing the TTLs were not shorter than 1 hour. That is well documented in many places. Seems according to their rules if you follow the SORBS DUHL rules you'll also be delisted from them. To add my $0.02 I agree with many of the replies... If you have one generic pattern for a /16 you either: Don't care to setup DNS. Don't know how to setup DNS. Don't care what's in the netblock. Don't have the competency to run a network/mailserver/dnsserver/<insert what ever>. In all the cases above I would not want your mail as it is 99.999% likely to be abusive in nature (spam, viruses etc.) Oh and many know I don't care if you are Peer1, Level 3 or Joe Blows Backyard VISP in outback Australia, you're all the same to me, you should all have competent people on staff, the only thing that changes between you is the number of *your* customers, and the amount you charge. Similar issues apply when looking at *.edu's vs *.com's, *.au's, and *.mt's. Just because you come from a certain country or certain type of establishment, doesn't make you different, it's only the number of people you service, you should still have competent staff. If you don't have enough staff that's not my problem (nor the rest of the world's) though it usually results in our problem when abuse starts flowing. I know most here are the admins and staff, so sorry if it sounds like I'm having a go at you guys, but really most on this list are the competent admins, a minority being people learning (nothing wrong with that!) but unfortunately there are some who are not and they don't care that they are not. I know that makes me an arrogant w***er, or another one of those "Arrogant RBL list maintainers" but think about it, and think about the following... Would you like to be prioritised down the queue because someone else was supposedly more important? ..... What happens to the poor mum and dad VISP in Somalia that never gets delisted because Telstra is logging 100's of tickets every day because their super size and constant rotating listings? ..... What happens if Telstra have a single IP blocked and Sprint come along and request delisting for a spamming customer's netspace they once hosted? Should we (RBL Maintainers, SORBS or anyone else) push the largest ISP in Australia out of the way for the bigger USA based Sprint? If not should we push the mum and dad operation out of the way for Telstra? ..... The obvious answer is if you have signed SLAs then you should adhere to those SLAs as a minimum and give better service if time allows... Hands up those who have an SLA (free or not) with an RBL maintainer... I don't expect to see any hands... ..... my answer to the question above is a very obvious take every issue in order, and if you get a super high priority issue, deal with it if necessary, but size of the ISP (or size of the admin's d***) is _not_ the prioritising factor. Note: Names chosen and mentioned above have no baring on any current abuse level or any logged issue, they are for example only. I don't want answers to the questions, I know some will post to the list or me regardless... it's stuff for *you* to think about when dealing with organisations such as RBLs.. especially when they are volunteer run. A little example about "arrogance" when it comes to ISPs... I know at least one member of this list (an ISP) has posted to every address in GFI in the last few days that they could think of (including the CEOs email) because their spamming netblocks have not been delisted. They have previously stated they would not deal with SORBS, so what changed, well as they found out in an email, nothing, they still need to log a support ticket, and their out of band request just pushed them down the queue. Sad thing based on their ticket ID, had they waited another 2 hours they would have been answered, now they have 112 manual processing tickets before theirs. I'm sure they'll guess who they are, I'd advise them to be patient or they might push themselves down further. ... and then of course there are some RBL Maintainers (and RBLs) that are arrogant, maybe it comes with the territory... Lastly.... No I don't take tickets to here, or my personal email addresses. Those that have already mailed me, following my last post to NANOG, you've been ignored as per my previous post. If you have a problem with a robot response, read the response! Most of the time it will tell you to respond to it for a human review! We will always answer you, however how soon depends on how busy we are. Messaging everyone/anyone in GFI *will* delay any ticket you may have, because the time it wastes will result in your ticket being placed at the back of the queue *without review*. If there is a problem with the support system in itself feel free to message me, but as I indicated before I have various sensors to tell me there is an issue mostly before you'd even notice (examples: the robot occasionally locks up so tickets to the DUHL will not get any auto reply of any kind after a few hours... the sensor for this triggers after 20 hours so, mailing me after 6 hours will speed things up however,,, support website down? I'll be paged within 5 minutes, which means unless it crashed just before you tried to access it, I'll likely already be logging in by the time you have started your email client.) Michelle

Niels Bakker wrote:

* matthew@sorbs.net (Michelle Sullivan) [Wed 16 Dec 2009, 17:41 CET]: [..]

...

..... The obvious answer is if you have signed SLAs then you should adhere to those SLAs as a minimum and give better service if time allows... Hands up those who have an SLA (free or not) with an RBL maintainer... I don't expect to see any hands...

How much would you charge a company for it to get taken off immediately after it hits your list?

Nothing. I don't believe in such a practice because it would be fraught with the danger of being accused of pandering to spammers, extortion and blackmail. Its bad enough requiring a donation to charity for expedited delisting of just the spam DB entries. As for an SLA the only type I would consider (hypothetically) is a "we will provide a phone/pager number for you to call" or "we will answer your ticket by email within x hours" type SLA. In either case there would be a clause the states clearly that the SLA does not provide any sort of guaranteed delisting. Michelle PS: Have been asked to take this off list by someone who didn't identify themselves as a list manager, but they did it politely and I respect that, so all future replies from me to this thread will be offlist. Please feel free to reply to me *offlist*. Thanks.

All of the DNSBLs I know are about outbound mail hosts, not inbound ones. What are your sending hosts called?

Outbound goes through the same 4 boxes. We used to split it up (2 at MX10, 2 at MX20 .. reversed for outbound) but for capital (licensing/hardware) reasons we decided to do in/out through the same system. This is just "first touch" on the way in and "last touch" on the way out. We also have spfv1 records defined (albeit a rather permissive "ptr ~all") .. but as I mentioned, the firewall disallows smtp to anywhere but appropriate hosts. We do still allow smtps and submission to accommodate folks that travel, as we haven't (yet) had a problem with bots using either of those services. My beef with Trend was that they were in essence telling us to re-do DNS on our /16 because they didn't like the way we did it .. despite the mail part (the one that matters) being technically correct by most everyone else's standards. Personally, I think this is just so they can have a "big list" when they sell it (.. our DNSBL has $x million more entries than $competitor..). Cheers, Michael Holstein Cleveland State University

On Wed, 9 Dec 2009, Frank Bulk wrote:

Two sides of an SP's coin: I want to maximize my e-mail servers' deliverability, so I make sure those have appropriately named PTRs and make sure that outbound messages aren't spammy; I also want to restrict

The point he was trying to make is that there is no standard for what those "appropriately named PTRs" should look like. He has forward/reverse that is perfectly ok according to standard (forward/reverse matches) and if he had a automatic dictionary for naming those IPs instead of putting the IPs there, things would be different. If people want to make standards on how to put information into DNS for RBL use, they should take it to the IETF and make a standard out of it, not just ad-hoc create something of their own and expect everybody else to conform. If there is an "industry standard" (which the replies here seem to indicate), that should be written down and standardized by the people who actually make money out of it, in this case Trend Micro. This would remove the problem of having to maintain tens or hundred points of contacts for "what is dynamic dialup space" which is the problem right now as there are a lot of RBLs to deal with. Creating a standard on what to put in WHOIS/DNS for dynamic/static/infrastructure would make a lot of sense, seems nobody is doing it though. -- Mikael Abrahamsson email: swmike@swm.pp.se

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? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

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"

thing is that it's illegal to maintain a database with "personal details" which ip addresses according to various german courts are (don't ask.. mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not persons, but the germans seem to mainain a different view on this, despite us isps being the owners of the internet and not the german government ;). therefore we are not even -allowed- to cooperate with trend micro *grin* sometimes laws really come in handy you know ;) -- 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. On Thu, 10 Dec 2009, Raymond Dijkxhoorn wrote:

Hi!

...

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.

Who cares!?

This is something between the ISP using them and YOU. If people want to make use of ANY datasource thats their own thing. They are not forced to use it at all.

There is no EU law or anything involved here.

There are blacklists that block .CN, so what, up to you to use it it not.

Same with iptables, you can also filter anything you like there, yourselve. No EU law telling anything about that.

Stick to the point, solve your issue with the party receiving your mails. they dediced to use the list, and most likely were not forced to do so.

If you want to mail with them, fix your reverses. If not, no problem either. But stop whining :)

Byem, Raymond.

X-CONTACT-FILTER-MATCH: "nanog"

thing is that it's illegal to maintain a database with "personal details" which ip addresses according to various german courts are (don't ask..

I've actually looked at some of the German decisions, and I didn't see anything that would be a problem for DNSBLs But if you're getting legal advice from the same wizard who told you to do this:

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.

I can understand why your impressions of the law would be so mistaken. R's, John

-----Original Message----- From: Michelle Sullivan [mailto:matthew@sorbs.net] Sent: Wednesday, December 16, 2009 6:09 PM To: nanog@nanog.org Subject: Re: Arrogant RBL list maintainers

Please reply to the list, not me and the list!

...

thing is that it's illegal to maintain a database with "personal

Sven Olaf Kamphuis wrote: details"

...

which ip addresses according to various german courts are (don't ask.. mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not persons, but the germans seem to mainain a different view on this, despite us isps being the owners of the internet and not the german government ;).

therefore we are not even -allowed- to cooperate with trend micro *grin*

sometimes laws really come in handy you know ;)

Based on what you say there, then the RIPE whois database cannot contain the information either because it to would be maintaining a database of "personal details"... As you probably know RIPE is located in the Netherlands and following Dutch law and not German law (however they are very similar). Publishing persons (done by RIPE in the whois database) is something that could be changed in

the future (if I look to the current law in the Netherlands and SIDN did change the policy about whois information).

Love to hear the legal battle on that one! <grin>

Michelle

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.

Please don't be ridiculous. Of course DNSBL's are authorized to do this. There is no compulsory use; if I choose to USE a DNSBL, I am electing to allow them to assist me in making decisions about who I receive mail from. If you receive a request for information about your address space from a DNSBL operator, there is no compulsory requirement for you to respond. If you choose to provide it, you authorize the DNSBL to share that information. If you do not, the DNSBL may take whatever action it considers appropriate. Do you believe that some further "authorization" is required? If so, please explain... because there are businesses whose business models revolve around providing much more detailed information about IP address usage. Your next obvious reply will probably be that some EU privacy law somehow considers this to be "personally identifiable information" of some sort; however, that is simply ridiculous. One bit of information about whether the address is a dynamic or static allocation is not PII, it's a bit of information that describes the network operator's intended use of the address. The only way it could be construed as PII is to note that it might be an address assigned to a person. However, you can assign both static and dynamic addresses to a person. Since the person in question could be anyone, interchangeably, it is obviously not PII. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On 12/10/2009 07:54 AM, Steven Champeon wrote:

In a nutshell, if you're not clearly indicating mail sources as mail sources, don't expect great deliverability. If you're running a Web hosting shop and don't have rate-limited outbound smarthosts, expect all your clients' mail to be suspected of being phishing scams. If you run a corporate network that allows unsecured outbound port 25 via NAT, you lose. If you run a university network (or part of one) without clearly distinguishing between server infrastructure and student-use end nodes, you really might want to rethink that. And if you're a consumer ISP that allows both static and dynamic assignments or serves both residential and commercial under the same useless generic naming convention, you are Making It Harder for the rest of us, which is an automatic upgrade path to reflexive blocking of all traffic. Oh, and if it's out of your control or what you consider your responsibility, SWIP it and label it clearly so we can figure out what it is and decide whether we want it as part of our view of the Internet. Keep your whois up to date and indicate if nothing else whether a given block is static or dynamically assigned, residential or corporate.

I'd say that Mikael Abrahamsson's sentiment (or at least the way I read it) would be a better start: take a step back and ask what the problem is. Naming conventions blah, blah, blah all started from the _lack_ of a standard and trying to educe knowledge from chaos. In other words, a bunch of hacks. Which doesn't work especially well, especially when every RBL has its own hack. If IETF can do something here, which seems plausible, it would be to actually define the problem and _then_ write a protocol to fit the needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming conventions (ick), probably it does not. But if it were standardized, it would at least be predictable which the current situation manifestly is not. To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high? Mike

on Thu, Dec 10, 2009 at 08:11:18AM -0800, Michael Thomas wrote:

I'd say that Mikael Abrahamsson's sentiment (or at least the way I read it) would be a better start: take a step back and ask what the problem is.

Well, as I see it, the problem is a widespread and systemic failure to prevent massive abuses from being perpetrated by unauthorized software in the control of entities other than the administrators of those networks and servers in question, resulting in a near-total breakdown of trust in any given unknown host's reputation, resulting in desparate attempts to gain insight into which hosts might be trusted and which not, using what means may be available (naming, whois, DNSBLs, etc.)

Naming conventions blah, blah, blah all started from the _lack_ of a standard and trying to educe knowledge from chaos. In other words, a bunch of hacks. Which doesn't work especially well, especially when every RBL has its own hack.

Well, I'd like to think my approach (name-based, rather than IP-based) works fairly well, going as it does in the names you give your IPs and whatever other public information may be available, but I understand your frustration with the various approaches used by IP-based DULs; I can also understand the lack of patience on the side of the DUL operators. The situation is a mess.

If IETF can do something here, which seems plausible, it would be to actually define the problem and _then_ write a protocol to fit the needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming conventions (ick), probably it does not. But if it were standardized, it would at least be predictable which the current situation manifestly is not.

Like it or not, naming conventions are useful and powerful and widespread. Would you rather have to deal with inbound mail from 134.25.177.41-get-allinone-adsl-and-free-webhosting-for-only-r189.saol.com or 196-200-118.isnigeria or one-of-hosts-our-net.dn.cv.ua [194.146.136.24] or dressless-debate.volia.net [77.123.181.13] or dont-blame-admin-its-a-dsl-pool-251-41.wobline.de or cable-66-103-40-69.clarenville.dyn.personainc.net [66.103.40.69] or 200.72.157.254: pcdibujante2.eiser.local ?

To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high?

It's not just dynamics, either. Static generic IPs also emit spam and abuse. Finding all the dynamics on the Net would only stop from half to maybe two thirds of the traffic we see, for example. http://enemieslist.com/news/archives/2009/07/why_we_suspect.html Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/

On 12/10/2009 08:38 AM, Mark Andrews wrote:

In message<4B211DA6.9000203@mtcc.com>, Michael Thomas writes: To Crocker's point though: if IETF came up with a way to publish your network's

...

dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high?

Mike

The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records.

Sigh. What is the "this" to which you refer? The problem space here is what's important. And I think it's worth considering that port 25 isn't the only abuse vector anymore. Mike

On 12/10/2009 09:06 AM, Joe Abley wrote:

On 2009-12-10, at 16:42, Michael Thomas wrote:

...

On 12/10/2009 08:38 AM, Mark Andrews wrote:

...

The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records.

Sigh. What is the "this" to which you refer?

I think Mark means "the question of whether a particular address is statically-assigned or dynamically-assigned", but...

Which assumes that that's the question that actually needs to be answered.

...

The problem space here is what's important. And I think it's worth considering that port 25 isn't the only abuse vector anymore.

... I agree that there's no clear limit to the kind of questions we could come up with that we could answer in such a way. Maybe we don't need to boil the ocean, though.

Sure, but positing the deployment of any infrastructure comes at a huge cost. Making certain that you're solving the right problem should be the first concern, since it's so expensive.

$ORIGIN 90.212.90.in-addr.arpa. @ SOA ... @ NS ... ; 13 PTR calamari.hopcount.ca. 13 HINFO Apple-Mac-Mini "Mac OS X Server" 13 RP jabley.hopcount.ca. . 13 TXT "dynamic"

See, that makes the assumption that that is the right question. Is it really though? Dynamic vs static is a placeholder for "authorized for this role or not", right? And not a very good one when you start to consider the larger world of protocols. I don't think it's "boiling the ocean" to ask the question of what the producers and consumers of that information are actually looking for. Mike

; * RP jabley.hopcount.ca. . * HINFO Nothing "Unallocated" * TXT "unallocated, should source no traffic"

Joe

Mikael Abrahamsson wrote:

On Wed, 9 Dec 2009, Frank Bulk wrote:

...

Two sides of an SP's coin: I want to maximize my e-mail servers' deliverability, so I make sure those have appropriately named PTRs and make sure that outbound messages aren't spammy; I also want to restrict

The point he was trying to make is that there is no standard for what those "appropriately named PTRs" should look like. He has forward/reverse that is perfectly ok according to standard (forward/reverse matches) and if he had a automatic dictionary for naming those IPs instead of putting the IPs there, things would be different.

If people want to make standards on how to put information into DNS for RBL use, they should take it to the IETF and make a standard out of it, not just ad-hoc

I did.. a number of people went out of their way to bury it. One of who would do anything to bury anything SORBS does (I think we all know who that was.)

create something of their own and expect everybody else to conform. If there is an "industry standard" (which the replies here seem to indicate), that should be written down and standardized by the people who actually make money out of it, in this case Trend Micro. This would remove the problem of having to maintain tens or hundred points of contacts for "what is dynamic dialup space" which is the problem right now as there are a lot of RBLs to deal with.

Creating a standard on what to put in WHOIS/DNS for dynamic/static/infrastructure would make a lot of sense, seems nobody is doing it though.

100% with you!!!! ...and if people used "static" and "dynamic" keywords in DNS as I suggested in my previously mentioned draft, there would be *NO NEED* for DUL/DUHL/PBL lists at all because people could create a very simple set of patterns to match and therefore the RBLs would be unneccessary.. (and it would save me about 10 hours a day, every day of the week, every week of the year!) Currently I have a few 100 patterns and I know another on this list has more like the region of 10k patterns to do what in reality one should be able to do in 2 (10 at the most!). At 10k patterns it becomes a lot cheaper to use DUL/DUHL/DYNABLOCK to block dynamics, does anyone wonder why people do? Regards, Michelle

...and if people used "static" and "dynamic" keywords in DNS as I suggested in my previously mentioned draft,

What are the words for "static" and "dynamic" in Lower Sorbian?

dynamic: dynamika static: statik

One wonders how this will be handled when the flood of non-Latin domains starts. Are these RBL maintainers really going to figure out how many different ways there are to say the (English/Latin) equivalent of "static" in Chinese, Cyrillic, Swahili, etc. Cheers, Michael Holstein Cleveland State University

Security by obscurity, in this day and age? :) On Wed, Dec 16, 2009 at 11:42 AM, James Hess <mysidia@gmail.com> wrote:

As is common for many domains. Spammers coming in  by  scanning  large ranges of IPs,  have no pointer to report  the  mailserver they discovered  is  @example.com  inbound  (or outbound) mail.

Since the RDNS domain is different, and in fact generic,  which  helps avoid  assisting the spammer  in identifying the IP as an  inbound mail server.

-- Suresh Ramasubramanian (ops.lists@gmail.com)

Wouldn't SPF ( RFC 4408) tell people more about where the real mailservers are than some half-baked idea of trying to enforce what hostnames should look like? What's the word for 'mail server' in Lower Sorbian, and does your algorithm properly detect it in a hostname? See the problem here? On Wed, Dec 16, 2009 at 6:49 AM, Adam Armstrong <lists@memetic.org> wrote:

On 16/12/2009 06:12, James Hess wrote:

...

On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong<lists@memetic.org> wrote:

...

personally, i'd recommend not being a dick and setting valid *meaningful* reverse dns for things relaying mail.

Many sites don't use names that will necessarily be meaningful to an outsider. Sometimes the non-meaningful name is the actual hostname and the _only_ name that machine is known by, even if the name appears "generic" or contains an IP. Host naming is a matter of local network policy, and the RFCs that pertain to hostnames specify syntax requirements only.

Some sites might want to avoid certain "meaningful" RDNS entries since spammers, hackers, and other abusive users that scan IP ranges can utilize the RDNS to facilitate their activities. All reverse DNS information is in the hands of the enemy.

For example, when spammers' IP scanning efforts find that an IP address reverses to "mail.example.com" the spammer will know to try @example.com e-mail addresses for their dictionary-based brute-force spamming.

On the other hand, if the MTA's IP reverses to something like a152.x.example.net.

As is common for many domains. Spammers coming in by scanning large ranges of IPs, have no pointer to report the mailserver they discovered is @example.com inbound (or outbound) mail.

The 1970s called and asked for its security policy back :(

I would have thought that asking for the MXes for example.com would have told them what the inbound mailserver is...

adam.

On Wed, 16 Dec 2009 07:06:55 EST, Mike Lieman said:

What's the word for 'mail server' in Lower Sorbian, and does your algorithm properly detect it in a hostname? See the problem here?

When the hostname at that IP address is exactly one incremented character different than the preceding address, and one decremented character different than the following address, and that pattern holds across a /24, they're probably not mail servers. Nobody has 256 'frzzmabs-1'..'frzzzmabs-256' servers in the same /24 for *anything* user-facing.

On Wed, Dec 16, 2009 at 5:21 AM, <Valdis.Kletnieks@vt.edu> wrote:

On Wed, 16 Dec 2009 07:06:55 EST, Mike Lieman said:

...

What's the word for 'mail server' in Lower Sorbian, and does your algorithm properly detect it in a hostname?  See the problem here?

When the hostname at that IP address is exactly one incremented character different than the preceding address, and one decremented character different than the following address, and that pattern holds across a /24, they're probably not mail servers.  Nobody has 256 'frzzmabs-1'..'frzzzmabs-256' servers in the same /24  for *anything* user-facing.

You clearly haven't set up webmail farms to handle half a billion accounts before. ^_^; We name our (many thousands of) webmail front end boxes as webXYYZZ.mail.$site.yahoo.com, so for cluster 3, farm 57, you end up with a string of hosts all in a row like web35701.mail.mud.yahoo.com web35702.mail.mud.yahoo.com web35703.mail.mud.yahoo.com web35704.mail.mud.yahoo.com web35705.mail.mud.yahoo.com web35706.mail.mud.yahoo.com web35707.mail.mud.yahoo.com web35708.mail.mud.yahoo.com ...etc... Take a look at the reverse DNS for the entire 66.163.178.0/23 subnet; you'll find that when you're doing things at large scale, you can't really get away from having sequentially numbered reverse DNS entries all in a row, exactly as you seem to think "Nobody has". :/ Matt

On Wed, 16 Dec 2009 09:21:42 PST, Matthew Petach said:

You clearly haven't set up webmail farms to handle half a billion accounts before. ^_^;

Yes, but we all already know who those 800 pound gorillas are. If you're doing automagic handling of this sort of DNS data, and not using a regexp to prevent auto-blocking any of the 800 pound gorillas... :)

On Wed, Dec 16, 2009 at 12:12:22AM -0600, James Hess wrote:

Many sites don't use names that will necessarily be meaningful to an outsider.

Then they should expect issues with mail acceptance by outsiders.

Some sites might want to avoid certain "meaningful" RDNS entries since spammers, hackers, and other abusive users that scan IP ranges can utilize the RDNS to facilitate their activities.

This is nonsense. RDNS/DNS naming choices are a trivial obstacle to spammers et.al. who went over this speed bump at 70 MPH years ago and have been accelerating ever since. This kind of security-by-obscurity tactic is far more likely to draw their attention than evade it, as any site using it has in effect run up a large flag with "we don't understand security basics" written on it and thus made itself an attractive target. ---Rsk