North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonymity" when domain exists, whois not updated yet)

  • From: Steven Champeon
  • Date: Thu Jan 13 00:12:28 2005

on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote:
> On Wed, 12 Jan 2005 23:19:47 -0500, [email protected]
> <[email protected]> wrote:
> > On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said:
> > > In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide.
> > 
> > Yes, but he asked for a rDNS solution specifically...
> 
> I think Steve was referring to some things that can be implemented
> right away, like "if you operate a mailserver, please make sure that
> it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com,
> try to give it unique and non generic rDNS, preferably with a hostname
> that starts off with smtp-out, mail, mta etc)"

Yep. And it helps if the rDNS is "right-anchored", (uses "subdomains"
to distinguish between various assignment types and technologies) a la

 1-2-3-4.dialup.dyn.example.net
               ^^^^^^^^^^^^^^^^
 4-3-2-1.dsl.static.example.net
            ^^^^^^^^^^^^^^^^^^^
as opposed to 

 dyn-dialup-1-2-3-4.example.net
 static-dsl-4-3-2-1.example.net

as the former is easier to block using even the simplest of antispam
heuristics. I'd love to see a convention, or even a standard, arise for
rDNS naming of legit mail servers. But I'll happily settle for decent
and consistent rDNS naming of everything else ;)

> Basically a call to operators to adopt a consistent forward and
> reverse DNS naming pattern for their mailservers, static IP netblocks,
> dynamic IP netblocks etc.

...and to ISPs to facilitate the process by supporting their users who
want to run mail servers, and helping the rest of us use such techniques
to quarantine the spew from zombies and less conscientious mail admins.

I'm always willing to be educated on why it is impossible for any given
ISP to maintain an in-addr.arpa zone with PTRs for their customers who
wish to be treated like real admins, as opposed to casual consumer-grade
users with dynamically assigned addresses.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us!   http://hesketh.com/about/careers/account_manager.html    join us!