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 in-addr.arpa 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