Ask Slashdot: Is Reverse DNS a Worthy Standard For Fighting Spam? 301
drmartin66 makes it to the front page with this question: "Last weekend I installed a new spam filter server for a client, and enabled connection rejection if the sending server did not have a Reverse DNS record. Since then, I have had a number of emails rejected from regulator bodies that do not have a Reverse DNS record, and are refusing to have one created for their email server. What is your opinion of Reverse DNS records? Are they (or should they be) a standard, and required? Or are they useless for spam fighting?"
No (Score:4, Interesting)
You know....I hate spam. It made usenet useless for years, it continues to degrade the usefulness of email, spamers steal resources and are underhanded dickwads.
All that said, some of the anti-spam people are ridiculous zealots who don't care who gets caught in the crossfire.
I have a server in colo. Its my mail server, but it also does a number of other things. Until recently, it ran a tor node. Why? Because i had sooo much more allocated bandwidth than I was using on a monthly basis that it cost me nothing extra to run. Ran it for at least 6 years on the same node.
Its now shut off, why? Because some idiots at Spamhaus decided that running a tor server was suspect. Never mind that it was disallowed from exiting on port 25, which is publically posted info in its service descriptor....no... Of course, I think they are also fooled by the fact that several windows users have shell accounts and use it as a web proxy.... so somehow my box also was infected with a Windows trojan according to these geniuses.
We got it cleared up, but still are not able to donate excess bandwidth allowance to the tor network.... which is bad enough, but this isn't the first time I have had my server blacklisted for no good reason at all. I don't even remember what BS it was last time, just that it was... BS.
Now will this kill me? No.... I have reverse DNS setup and have for years but...come on.... seriously? Bouncing mail sucks, especially when you suddenly start doing it to whole domains.
If it were just me, my opinion is that anyone using one of these RBLs has a misconfigured mail server, I wouldn't have "fixed it".... but I host other peoeple's email domains, so the black ball tactics worked.
Re:Better Question... (Score:5, Interesting)
I hate to say it but you have way too high of an expectation of ISP's
I have a static address on a business account via a major ISP. I have a Domain name and have DNS. My DNS resolves to www.mycompany.com but the ISP has the PTR set to 111.222.333.444.static.ISPDOMAIN.COM
They will not change it no matter what I ask and E-mail from my domain through my e-mail server is rejected because the PTR does not match the A record. It has gotten so bad that I had to pay for a mail relay host to push my mail through. To me, this is a risk because they (The relay) could intercept, monitor, or filter the private e-mail between me and my customers which would directly effect my business.
So, personally I say it is a bad idea!
You have to do this (Score:2, Interesting)
Its right, its not fair; but its needed. Legitimate sites should have no problems setting up reverse records or getting their provider to do if for them.
Anyone who is not in a position get PTR records in place for their mail server is not actually in a position to be running a mail server anyway. Sorry that is just the way it is. PTR records are nice to have for any number of mail delivery troubleshooting and validation issues outside of SPAM.
As a mail admin I'd kinda consider them a requirement anyway. Its not easy to work transmission problems when I can't figure out who the admin of the other server is and how to get in touch with them.
I know its not within the standards, but I say no PTR record no, mail accepted.
Re:Absolutely required. (Score:2, Interesting)
uh. negative.
i'm not sure what you are describing, but the way it work is this:
incoming connection says ehlo "my name is fleaflicker.bigbonus.tld"
my postfix server would note that the connection is coming from 10.10.205.71
It does a check for the ptr record of 10.10.205.71
IF YOU REREAD THE SUMMARY, he's just looking for a ptr record, ANY ptr record. You'd be surprised how many have no record at all. This is what we're looking for, and dropping.
When you do get a ptr record, who cares if it doesn't MATCH, 99% of them don't match.
dropping connection attempts because they don't match is stupid.
what you can do, is besides dropping attempts with null ptr records is to check those that do have a ptr for words like "pool", "dsl", "loop", "static", "dhcp", "dynamic" etc etc etc, and decide what you want to do based on those terms...