on naming conventions (was: Re: Repeated Blacklisting / IP reputation)

Tue Sep 15 21:40:30 UTC 2009

on Tue, Sep 08, 2009 at 09:57:58AM -0500, Tom Pipes wrote:
> [...] We have done our best to ensure these blocks conform to RFC
> standards, including the proper use of reverse DNS pointers.

Sorry to jump in so late, been catching up from vacation. I'm checking
out the PTRs for the /18 you mention, and I see that you've used a few
different naming conventions, some of which are friendly to those who
block on dot-separated substrings, some of which are confusing, and some
of which are custom to specific clients. If I could speak on behalf of
the tens of thousands of mail admins out there for a minute, I'd ask
that instead of (e.g.)

  69.197.115.62: 69-197-115-62-dynamic.t6b.com

you instead use a dot to separate the 'dynamic' from the generated
IP-based hostname part, a la

  69.197.115.62: 69-197-115-62.dynamic.t6b.com

This allows admins of most FOSS MTAs to simply deny traffic from all
of those hosts on the grounds that they are dynamically assigned, for
example in sendmail's access.db:

Connect:dynamic.t6b.com ERROR:5.7.1:"550 Go away, dynamic user."

If you choose not to, it doesn't bother me; I've got a rather extensive
set of regular expressions that can handle those naming conventions, but
the rest of the mail admins may find it more friendly were you to do so.

Additionally, it may also be useful to indicate what sort of access is
being provided, so for dialups you might want to do

  69.197.115.62: 69-197-115-62.dialup.dynamic.t6b.com

(Note: not 'dynamic.dialup.t6b.com', most people care more about whether
a host is dynamic at least in the context of antispam operations).

I also note that the vast majority of the /18 simply lacks PTRs at all;
you also mix statics and dynamics (though on different /24s, eg
69.197.106, 69.197.107, 69.197.108 seem static where 69.197.110,
69.197.111, and 69.197.115 do not, with more statics seen in 69.197.117
and 69.197.118 ff.) and don't seem to SWIP the statics or indicate in
whois which are dynamic pools. All of these are likely to result in
unfunny errors by DNSBL operators if they decide that you're serious and
the whole /18 is dynamic based on a preponderance of hosts in some /24s
with dynamic-appearing names AND a lack of evidence otherwise in the
whois record.

Of course, if you follow MAAWG's port 25 blocking BCP, it's moot as
far as the dynamics go.

Ultimately, you'd want to make sure any static customer intending to
provide mail services have their own custom PTR(s) for those hosts,
in their domains (not yours). 

HTH,
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/