AOL rejecting mail from IP's w/o reverse DNS ?

Wed Dec 3 15:58:53 UTC 2003

At 10:42 AM 12/3/2003, Christopher X. Candreva wrote:

>On Wed, 3 Dec 2003, Randy Bush wrote:
>
> > you're right.  it will be.  people will have to clean up their
> > in-addr.arpa.  or am i missing some reason they can't, other
> > than laziness?
>
>See, this is the war I didn't want to start again. Unless I'm thinking of a
>discussion on a different list -- I was sure in the whole Verizon "spam
>measures hurting other servers" thread, the whole blocking w/o IN PTR
>records had come up, with people saying they were on hosting where they
>couldn't change PTR records, and the clients who couldn't get mail from
>small offices with Exchange servers on DSL lines where the ISP hadn't
>configured reverse DNS . Then there was the comment on how reverse DNS was
>meaningless, and did you still run identd ?

The issue I think AOL was getting at was not whether PTR records matched 
the A record for the host. That is indeed a can of worms, and there are 
reasons why that isn't a good idea, primarily because many people don't 
have access to the PTR records for smaller blocks or single addresses.

However, there are a great many hosts spewing email (spam, in most cases 
seen at our servers) that have no INADDR set up at all. It would indeed be 
helpful if there were reasonable PTR records everywhere, even if the PTR 
information didn't match the A record information. The PTR information 
could at least provide some clues as to the ISP involved, etc.

>Maybe I'm thinking of the wrong list.
>
>If AOL does it, in a way the question is moot. At least those of us who DO
>know how to configure DNS can get some clients from the ones who don't.

Many will turn on a flag to specify "some PTR must exist" if AOL or some 
other large provider does it and is able to stick with it.

Yes, there'll be some work for DNS-clued consultants if that happens.

The impact on the 'net will not be all that significant, though. A few 
providers will certainly be impacted, namely those who've not bothered to 
implement (or only partially implement) INADDR.