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
