best practices for PTR naming and whois (was, sadly, Re: ArrogantRBL list maintainers)
Michael_OReirdan at Cable.Comcast.com
Thu Dec 10 10:19:33 CST 2009
MAAWG has published an approach that it recommends is taken to share
information as to nature of IP space. This may be of interest here.
It can be found here: http://www.maawg.org/about/publishedDocuments
On 12/10/09 11:11 AM, "Michael Thomas" <mike at mtcc.com> wrote:
> 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
> (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
> dynamic space (assuming that's The Problem!), would operators do that? Or is
> this another case where the energy barrier is too high?
More information about the NANOG