Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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/
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
In message 4b211da6.9000...@mtcc.com, Michael Thomas writes: 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 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 12/10/2009 08:38 AM, Mark Andrews wrote: In message4b211da6.9000...@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
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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... 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. $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 ; * RP jabley.hopcount.ca. . * HINFO Nothing Unallocated * TXT unallocated, should source no traffic Joe
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
on Thu, Dec 10, 2009 at 09:27:44AM -0800, Michael Thomas wrote: On 12/10/2009 09:06 AM, Joe Abley wrote: 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. Well, it seems to be a question that folks at MAAWG are currently trying to answer; I know of at least one effort to coordinate standard means of publishing your dynamics between various MAAWG members, so it seems to be a question that does need to be answered. I'd agree that it's not the only question - see my post on why we consider generic statics suspect. I think in the end, we'll see anyone without a custom, clear, legible, name indicating that a host should be sending mail simply having their mail refused. ... 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. Yeah, for example, it took Road Runner something on the order of 18 months to move all of their residential account PTRs under 'res.rr.com', and their business class under 'biz.rr.com'. They're a bit of a special case, as they're more of a franchise than a single entity, but still. They came to realize that doing so was useful and good, so they did it. And kudos to them for doing so. Making certain that you're solving the right problem should be the first concern, since it's so expensive. All I'm saying, and feel free to do with this what you will, is that there is a demand for means for assigning reputation to IPs based partly on their PTR records; antispam appliance vendors, reputation service providers, carrier class cable and telco companies and ISPs, are all exploring or actively using PTR naming classification as one of those means. You can either recognize this and make your networks more transparent to such enquries, or not. Whois is not the only answer; without a way to quickly associate a PTR with a whois record that happens to say dynamic residential or static business (to use the most broad of available classifications) in real time by DNS lookup or other means, your detailed whois records are useless in direct, practical terms, to postmasters and spam filtering software and others. Spamhaus PBL is one answer, mapping IPs based on ISP-provided information or Spamhaus researcher-discovered information, into zones to be used for rejecting mail. SORBS DUL works in similar way, and makes assumptions on the basis of rDNS scans at the /24 level (among other mechanisms). Enemieslist uses whatever information we can to classify PTR naming; whois, Web sites, price lists and a la carte menus (do they charge extra for static IPs?, do they even provide static IPs?, etc.) and then bases that classification on the name of the remote host at connect time - so we don't have the same falls in a suspicious /24 problem seen so often with SORBS and now MAPS DUL, but just because a customer /can/ ask for and pay for and receive a custom PTR for their mail server doesn't mean they always do - just that over time, they will have to or face poor deliverability, hassles, and the like. But the bottom line is that failure to provide transparency via PTRs is a problem, particularly for deliverability, whether directly (your mail server is named rrcs-12-34-56-78.se.biz.rr.com, which is static but generic, so would be scored suspicious via Enemieslist) or indirectly (your mail server is in a block of generic PTRs that may be static or dynamically assigned based on vague rDNS, so it ended up in a SORBS DUL listing) or (your mail server is in a block with no custom rDNS that the whois record doesn't indicate is static, so ended up in a PBL listing due to lack of cooperation from the ISP), and so on and so on. Of course it makes it easier for me, and Spamhaus, and SORBS, and Trend, if the networking community helps us make these determinations and pass along the proper and appropriate classifications, so that our users and licensees can use our data to make fine-grained policy decisions. Also true is that doing this stuff right can be difficult, or expensive, but I think the point to take away here is that it's already being done, and you can either help, or be an obstacle to progress. Asking whether this is the right question isn't terribly helpful /now/, given that debates have raged here and on mailop and in other forums for years. I prefer to look at the available data (spamtraps, filters, mail flow analyses, etc.) and do something /now/ that is helpful to people wishing to ameliorate abuse /now/. And for the moment, as for the past six years, associating classifications with PTRs based on their naming is a very effective strategy, and one which we're going to continue to use. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w:
