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

the whole blocking w/o IN PTR
records had come up,

Interestingly, there was a time when access to FTP servers
was considered important and many FTP servers blocked access
if the IN PTR records did not match the IN A records.

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.

Sometimes SMTP relaying is good. If your ISP has good reason
to not configure matching IN PTR records for your mail server
then ask them to relay all your outgoing SMTP. The end result
is the same; you won't be able to set up a working SMTP server
without your ISP's cooperation.

Then there was the comment on how reverse DNS was
meaningless, and did you still run identd ?

It's not the reverse DNS itself that is meaningful. It is the
fact that the SMTP server operator with proper IN PTR records
probably has the cooperation of their ISP.

Proper configuration of is a "good idea" TM.
However, it isn't the right way for large mail server operators
to go. Instead, they should start exchanging their SMTP sessions
on a port other than 25, i.e. NIMTP (New Improved MTP). The NIMTP
servers would not accept incoming connections from unknown servers.
In order to join the club, you would have to certify that you will
only send mail from known senders or relay mail from organizations
which will make the same certification. In this way, we create an
overlay mail transport network in which the members have some sort
of one-to-one mail peering relationship that allows them to enforce
an AUP on each other as well as maintain good contact info.

Peering relationships work for BGP (lots of rules) and they worked
for USENET (not many rules). Why can't the same principles be applied
to email or IM services?

--Michael Dillon

The system exactly like you describe already exists. It�s based on the standard
X.400 protocol and is available across the world. Or in some parts, used to
be. If that approach would be highly successful, why would it not prosper
instead of SMTP today?


This is a broken model. People that are buying high level services should
expect those to be delivered correctly, but those who are buying bit
transport should not be required to obtain additional services to become
fully functional. It is nice to fantasize that the ISP is in control, but
time has shown that people will do what it takes to make their service work.
If that means pushing the service provider into further irrelevance, they
will. Rather than trying to break service for the antonymous network by
requiring consent from the cabal, the service providers need to be making it
easier and cheaper to get the desired results from their service.


I'm sorry, I couldn't find your proposal for solving the problem in that
paragraph. Could you tell us what your solution is.