Since I'm 99% sure the idea (or stupidity thereof 
of blocking SMTP
servers without reverse DNS came up here in this discussion, I just ran a
manual queue run to clean out a queue, and saw this come up:
... Connecting to mailin-04.mx.aol.com. via esmtp...220-rly-xn05.mx.aol.com
ESMTP mail_relay_in-xn5.9; Wed, 03 Dec 2003 09:59:55
-0500
220-America Online (AOL) and its affiliated companies do not
220- authorize the use of its proprietary computers and computer
220- networks to accept, transmit, or distribute unsolicited bulk
220- e-mail sent from the internet. Effective immediately: AOL
220- may no longer accept connections from IP addresses which
220 have no reverse-DNS (PTR record) assigned.
EHLO westnet.com
I don't know if this is new -- I don't recall seeing it before, but it
doesn't say they WILL refuse, just they may. If they do start blocking --
this WILL be an operational issue.
I don't know if this is new -- I don't recall seeing it before, but it
doesn't say they WILL refuse, just they may. If they do start blocking --
this WILL be an operational issue.
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?
randy
Christopher X. Candreva writes on 12/3/2003 10:13 AM:
Since I'm 99% sure the idea (or stupidity thereof of blocking SMTP
servers without reverse DNS came up here in this discussion, I just ran a
manual queue run to clean out a queue, and saw this come up:
They have had this policy since several months now but it is still a "may" - and does give them a good excuse to take out large IP blocks that don't have proper reverse DNS assigned and emit a lot of spam.
More at http://postmaster.info.aol.com
If this is what it takes to push more people to get valid PTR records on their mailservers ...
I don't know if this is new -- I don't recall seeing it before, but it
doesn't say they WILL refuse, just they may. If they do start blocking --
this WILL be an operational issue.
Lots of mailservers (such as the one for freebsd.org) already do this.
I have not seen any large ISP other than AOL do this yet, though. However if they make it a "must" rather than a "may", I can see a whole lot of ISPs who will be quite eager to follow suit and do something on the same lines.
srs
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 ?
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.
Randy Bush writes on 12/3/2003 10:18 AM:
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?
Well - unless you have a /24, in-addr.arpa is typically under the control of your upstream provider.
And at least some few upstream providers I have seen over the past few years are ignorant of basic DNS principles, and don't know how to do proper delegation.
Their sending senior management off on junkets abroad, ostensibly to attend APNIC tutorials, seems to be a common cause. The actual admins often remain untrained. Come to think of it, quite a few such ISPs don't know to do proper BGP or proper anything else either ...
If that is not the case, and the ISP does know to do reverse DNS, they often charge you $$$ for each line they add into their bind configs. One of the providers we were looking at (we were shopping for a /24) was charging a rather high sum per line added to their bind configs.
What's more - their support was insisting that the config we sent them (just enough to let them delegate in-addr.arpa authority for the /24 to our nameservers) was "wrong". They apparently were under the impression we were going to pay them for each IP in the /24, to add rDNS.
So, especially in countries where most if not all the IP providers you get are dumber than rocks, rDNS is often dismissed as an unnecessary luxury. Especially when you have maybe one IP allocated for a colocated server, rather than a /24 or two.
srs
Christopher X. Candreva writes on 12/3/2003 10:42 AM:
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
That must be some other thread I think - one thread soon starts to look a lot like another, and I doubt if there's a single topic of this sort that hasn't been discussed to death already.
srs
> 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.
Randy Bush writes on 12/3/2003 10:18 AM:
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?
Well - unless you have a /24, in-addr.arpa is typically under the control of your upstream provider.
RFC2317.
So, especially in countries where most if not all the IP providers you get are dumber than rocks, rDNS is often dismissed as an unnecessary luxury. Especially when you have maybe one IP allocated for a colocated server, rather than a /24 or two.
Maybe more people should do what AOL says they may do, then.
Joe
Joe Abley writes on 12/3/2003 11:11 AM:
RFC2317.
that'd still involve the ISP inserting stuff in their nameservers.
when "isp admins" are substituted by "drones working out of templates / web forms" ...
ps - there's of course the rather umm... interesting content below 
http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html
Maybe more people should do what AOL says they may do, then.
I'm all in favor of it - but I'm still reluctant to dump legit mail that'll get dumped if I do this. I'll have to be pushed a lot farther before I start doing this (and with spam levels increasing the way they are ...).
Which is totally, completely wrong and causes, in both cases, servers to
leak name space (which causes cache poisoning) and, in once case,
servers to potentially be marked as lame. The man is flat out wrong.
Don't follow his advice.
-Pete
Pete Ehlke writes on 12/3/2003 11:38 AM:
How can delegating in-addr.arpa on a per-ip basis be any different or worse
than delegating it using an rfc2317 scheme?
--Adam
Daniel Senie <dts@senie.com> writes:
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.
... and it will be a zero-sum game once the spammers (or their
complicit ISPs) fix their in-addrs too.
while i applaud the notion that people will fix their dns entries,
we're long past the days where spammers could be assumed to be
clueless twits who were operating without serious technical backing.
making the presumed good guys fix their in-addrs will have the
collateral effect of getting them fixed by the spammers too. in fact,
i wouldn't be surprised if some of the spammers who subscribe to nanog
have new to-do items on their whiteboards now.
---rob
... and it will be a zero-sum game once the spammers (or their
complicit ISPs) fix their in-addrs too.
'cept the in-addr.arps space from which they are coming has to be
populated. i.e., no more connects from black holes.
randy
How can delegating in-addr.arpa on a per-ip basis be any different or worse
than delegating it using an rfc2317 scheme?
consider the label of the ns rr to delegate only 1.2.3.42
Do you mean ns.42.3.2.1.in-addr.arpa? I still don't see what's wrong with
the following, or how it leads to cache poisoning or leaky name space.
42.3.2.1.in-addr.arpa IN NS ns.42.3.2.1.in-addr.arpa.
ns.42.3.2.1.in-addr.arpa IN A 5.6.7.86
--Adam
AOL says the PTR record needs to be assigned. It doesn't specify it has to match the @domain.com in the MAIL FROM: header. Wouldn't it be enough to make sure every IP address you announce has a PTR and matching A record? Hasn't this been a requirement for MANY services for MANY years?
Matthew Crocker.vcf (31.3 KB)
I disagree. I don't think the spammers, by and large, 'own' their IP
addresses. They are using (as someone said) hijacked space, or compromised
machines.
Odds are since many of these machines aren't SUPPOSED to be sending mail in
the first place, no one is going to complain, so nothing is going to be done
about them.
AOL says the PTR record needs to be assigned. It doesn't specify it
has to match the @domain.com in the MAIL FROM: header. Wouldn't it be
enough to make sure every IP address you announce has a PTR and
matching A record? Hasn't this been a requirement for MANY services
for MANY years?
Requiring the PTR record to match the MAIL FROM: header would be horrific.
There goes any hope of virtual hosting of mail accounts, i.e. one server
with one ip handling multiple email domains.
Adi
Eight hours later, and I'm still waiting for a reply on this. Were the
original attacks by Pete Ehlke warranted, or would he care to retract his
statements?
--Adam