Slashdot Mirror
Ask Slashdot: Is Reverse DNS a Worthy Standard For Fighting Spam?
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?"
Like all things spam, marking the message as bad automatically is generally discouraged. If you simply increase the SCL value by some reasonable number, and continue to raise SCL based on other soft violations (like spamhaus, surbl, etc), you will rarely put good senders in the junk email folder, and very frequently be able to reject most spam content.
When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
In all but the most closed groups, having a system that generates lots of false positives is in most cases going to be a bad move in my opinion.
What reason would anyone have to be running an SMTP server without a PTR record?
As with most spam fighting metrics it's up to you. Mail from a server without reverse DNS that doesn't trigger any of your other flags generally shouldn't be treated as spam if you care about false positives, if it's borderline then maybe the lack of reverse DNS will be enough to justify tagging it as spam. The decision of how heavily to weight the lack of reverse DNS is yours, personally I don't give it much weight but it does add a little to the score. Some people go hardcore and reject anything that doesn't have come from a machine with reverse DNS, they accept the significant false positive rate usually for idealogical reasons (while I like a properly configured system I'm not going to bite my nose off to spite my face).
If your email server does not have rDNS records then it's very likely half your mail is not getting delivered. aol.com, gmail, hotmail, etc all require rDNS.
Blocking on invalid rDNS, invalid or missing A records and not following proper smtp protocol is helpful on a email gateway. However, if you are a relay for clients you'll have problems.
It is possible to configure your mailer to require all sorts of things, like rDNS. If you configure all of them you will get almost no spam, but you'll also not get 50% of your legitimate e-mail. Perhaps that's ok with you, you're willing to only talk to the "clueful".
Most people though want to get mail. The old Internet axiom "Be conservative with what you send, be liberal with what you accept" applies. WIth spam fighting this generally means use every mechanism at your disposal (including rDNS existence, or matching with forward DNS); but use it only to affect the score of a message. That way the guy who doesn't have rDNS right, but does everything else right will still get through.
In an organization operating a mailserver without a PTR record for their SMTP, the users should be having so much difficulty sending outbound mail that they know something is wrong. I know this from experience, having set up an SMTP without reverse DNS, and then observing that half my test messages bounced back.
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.
"I opened my eyes, and everything went dark again"
Being fed up with postfix and exim, I recently wrote a simple e-mail server using python. I followed the RFC standard as well as I could, but to my surprise, I noticed there are numerous special undocumented tricks one needs to know to get mail through to the recipient in a reliable way (whitelists, blacklists, reverse dns, etc). I am wondering if anybody here knows if there is a place on the net where such tricks are documented.
PS: IANAS (I am not a spammer, honestly)
If Pandora's box is destined to be opened, *I* want to be the one to open it.
For short term outages, sending servers will queue messages and try again later. You can avoid long term outages like this one by having redundant Internet connections from different providers.
Uhh...not to nitpick, but that is what backup MX servers are for. When your primary server is not available, mail is delivered to one of the others. If your e-mail is that critical then you need to have a store-and-forward server somewhere else, just in case your link goes down.
There are lots of services that provide this, if you don't want to do it yourself. But setting up a simple store-and-forward server isn't all that complicated and doesn't need a full Exchange deployment.
Learning HOW to think is more important than learning WHAT to think.
The requirement for reverse dns is in hindsight a part of the "security theater" where various claims are made, and remedies suggested against perceived ills. The suggestion for reverse DNS comes solidly from the era of TCP wrappers, another supposed saviour of ill maintained systems from outside evils.
In reality, there is no actual increase of security from checking if some address has reverse dns as for ages most of the dial up and broadband lines all have reverse dns. Also, as reverse dns zones are by and large often unmaintained, esp. when it comes to removing entries, you neither can rely on the data returned, nor assign any significance to what is returned.
Magnificent. Seriously, giving back retarded English is a stoke of genius, and I'm not being sarcastic. Real admins will chuckle, jerks and asshats will flame you (and now you know to add them to your deny), and machines aren't reading it anyways, you had them at 553.
I think there's a recipe out there to automate dropping the connections after a set number of tries and rejects. For my denies, I just ignore the connection and let them timeout. This seems to trigger a lot of spammers to stop wasting time connecting since it hangs them a lot longer than an error response, and maybe sometimes looks like my server is hosed, so they write me off as gone.
Rreally, I love it. Haiku would be overkill. Maybe you should have used 'form' instead to complete the effect.
deleting the extra space after periods so i can stay relevant, yeah.
I think you're missing the point. Configuring DNS means that someone with clue set out to create a mail server and intends for it to be such rather than just slapping something together without any clue. Whether or not that mail server is sending anything desirable is not related.
this is my sig
If email is important to your organization then the cost of a correctly configured mail server is insignificant.
Seriously, your email server can be anywhere in the world. There's no reason that you have to go through a specific ISP. Even if they're blocking port 25, you can get a different ISP to accept mail from you on a different port. Even Google offers that option.
The question "Is Reverse DNS a Worthy Standard For Fighting Spam?" is incorrect. Spam is not the reason; using it as a measure of clue is. Servers that emit spam and and clue level can be related, though. If someone is clueful enough to set up a mail server properly they're going to make sure it has reverse DNS. A mail server run by a less than clueful individual (or set-and-forget with no admin) is more likely to be a problem source either now or in the future than the ones that are cluefully configured and actively maintained.
Of course you are going to have spammers that are clueful mail admins and will set up their servers properly. That's why you can't pigeonhole reverse DNS as some kind of spam fighting method alone. But it can always be used as a measure of cluefulness.
this is my sig
Real men would scan the IPv6 space too.... :)
-Charlie
That's not how the reverse DNS check works. When your SMTP server connects to another computer, it announces itself with a HELO. That HELO should resolve to that server's IP address. The reverse DNS of that IP address should be the same DNS name given in the HELO. This has nothing to do with using a different outgoing vs. incoming server or anything in your SPF records.
I work for an ISP and we require rDNS records for all incoming mail. You will filter out a TON of spam email with that simple rule. It's much easier on the CPU load to filter on a simple reverse DNS check than to run spam assassin on that message. There are the occasional (not as many as you'd think) misconfigured servers that don't have rDNS. In those rare cases we contact the other end and let them know they're incorrectly setup, and usually add a temporary allow until they get the issue fixed.
I highly recommend requiring rDNS for incoming mail. 99.9% of legit mail servers will have those records, and only about 30% of spam servers will. We process over a million email messages a day with this method, it works.
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...
Filtering based on lack of rDNS is an old technique that actually did a good job of detecting spam without an excess of false positives for about a week in the late '90s. It has for some reason become enshrined as policy by a great many people now. These days it is occasionally a better indicator of NOTspam since the spammers all make sure they have rDNS set up and have done so since that week or so in the '90s.
Consider, if someone in a striped shirt wrote your business a bad check a decade ago, would you maintain a policy of not doing business with people who wear striped shirts?
I didn't read every comment, but the general theme seems to be that it's not absolutely required to have a reverse DNS entry. While this is true per the RFC - it's incredibly bad in practice. Google MX check, run the checker and if you don't have reverse DNS it'll point it out. Also people that say not one mail has bounced because of this must simply be wrong. Many blacklists will auto-add you if they notice you don't have reverse dns, then many companies will pick that up. Last time i had to move my companies mail server, the reverse was inadvertently not setup properly - not only did this cause problems fairly quickly it was slow to fix because while you'll be added to blacklists instantly, getting back off them is a manual process - you have to find every one you are on and then the companies that have picked up this info then have to get the new info - and some don't do this in a timely manner.
Running a real mail server for a real company without a correct functioning PTR record would be something that should get you fired.
The reasoning is simple, anyone running a real mail server will easily be able to set it up, if you don't have the PTR it likely means you are a spammer or you are running a server at home. Not that there's anything wrong with running your own SMTP server, but that's basically how botnets send spam...so there's a heavy correlation to that and spam.
They can write you a personal letter about how your job at Foocorp is stressing you out and not only leaving you with less energy at the end of the day, but that the stupid meeting Johnson scheduled for Monday morning has you discouraged and feeling down all weekend, and that this is why you can't get it up, so you might want to at least stop taking everything so seriously, and most importantly, quit worrying about things that are beyond your control and you'll find your sex life has improved. But what they do is send you a misspelling-filled ad for Viagra.
"Believe me!" -- Donald Trump
However, reverse dns is a completely different beast. Whoever has the ipv4 subnet controls the rdns for that subnet. If an isp is nice, they can delegate smaller subnets of their larger block to individuals, but this is rare.
This should help clarify
Right. If you verify that the domain name matches, you'll block a whole lot of email from anything that's on a shared host, since the rDNS will be for the hosting provider's domain. On the other hand, just checking for a record is pointless. My home broadband has a rDNS record.
It takes five minutes to configure the HELO and DNS records to be the same if you know what you're doing. It works, just not the way you wish it works. HELO = DNS or you don't get to send me email.
This violates the RFC. The only check you can do is for the correct HELO syntax.
The argument to HELO is supposed to be an FDQN (although an IP-address literal is also valid, but a bare IP address is not). It does not have to resolve, nor does any PTR record have to return that same FQDN.
Luckily, you're not doing much harm. I ran my mail servers for over a year checking (logged only) for both whether the HELO resolved at all, and if it matched the PTR lookup from the connecting IP. Since I reject for bad HELO syntax, it turns out that the other checks on the HELO argument would reject less than 1% of remaining connections. Greylisting deals with everything that would have been rejected by HELO argument checks, plus a lot more, so that's what I stick with.
I didn't really speak to that. I just wanted to correct the commenter that claimed that all one need do is sign up to a virtual host to somehow magically hijack someone else's reverse DNS zone. It wouldn't be that simple. One would either need to trick the authority responsible for delegating the zone or hack a server in the chain of authority.
The reason many mail servers require matching forward and reverse DNS is because it provides a level of assurance that your ISP is aware of and approves of your providing an outside service to the Internet -- in this case a mail server. It's not a guarantee that spam won't come from your server, but gives your server an added level of credibility.
My approach, using Exim4, is not to reject messages outright based on single issues, such as not having a proper reverse DNS entry, but to reject based on combinations of them. This is a great way to limit false positives.
For instance, an incoming message may also have a bad HELO, a bad sender domain, be blacklisted locally or by a DNSBL service, or not have a working callout so that the existence of the sender's account can't be verified. There are more issues like these to look for. My systems count the number of these transgressions per message and reject when a certain value is reached, say three, while dumping messages that score one or two end in the recipient's spambox folder. With Exim, this kind of solution is surprisingly easy to construct using ACL statements with user-defined variables that include arithmetic statements. The last checks that are performed involve Clamd and SpamAssassin, because they are so resource-intensive.
I should also mention that my systems also perform a number of checks up front for obvious spam that is rejected immediately, e.g. if the sender address domain is gmail.com, but the sender HELO name is not part of the google.com domain.
You do realize the ISP owns the f'ing address. That means *THEY* control what PTRs are assigned. They are the only ones that can change them.