Are PTR Records Important?

erfmuffin asks: "I work for a medium-sized regional ISP. Recently we configured our email gateway to refuse connections to IP addresses that do not resolve (ie no reverse DNS). I am amazed at how many legitimate domains use mail servers with no PTR record! At the same time, we have avoided a great deal of junk mail in one swoop. Wouldn't it be better for mankind if all mail servers refused mail from non-resolvable IPs? Should all legitimate mail servers have valid PTR records or has the world become too lazy to make email delivery, easier?"

Comments

Yes and no.

[FreeLinux]

PTR records are not necessary. They are not required for the internet to work acceptably. But, PTR records do add considerable convenience to network operation and they are a part of the DNS standard specification so, they should be used.

The fact that mail systems that require PTR records before accepting mail significantly reduces spam is reason enough that PTR records should be required. I too experience a great deal of mail problems due to a lack of PTR records but, it is worth the effort to stick to this policy. If you don't have a PTR record, you can't send me mail!

Re:Yes and no.

[Anonymous Coward]

The fact that mail systems that require PTR records before accepting mail significantly reduces spam is reason enough that PTR records should be required.

Hang on a second, I'm dizzy. Woo. That's one hell of a circular argument you've got there. I'm still trying to sort it out, but it seems like you might have actually made two full circuits of the argument in that one sentence. Wow.

The implicit assumption behind all of that, though, is that stopping some spam is more important than delivering all legitimate mail. You say so yourself: "I too experience a great deal of mail problems due to a lack of PTR records but, it is worth the effort to stick to this policy." That's completely wrongheaded. Mail should be delivered. That's what it's for. Given the choice between receiving no spam and missing the occasional important email and receiving all spam and getting all my important emails, I would choose the latter any day of the week. And so would most reasonable people, I think. The inconvenience and annoyance of hitting that "delete" key every day is nothing compared to the inconvenience and annoyance of not being able to receive email from a friend or business associate.

Re:Yes and no.

[FreeLinux]

That's completely wrongheaded. Mail should be delivered.

I gues that you are entitled to your opinion but, I feel that the action is correct. The fact is that this policy works very well for me. The mail does go through, eventually.

Here's how it works. A user tries to send a message to someone inside my company. The message fails, of course, because my mail server rejects the connection due to the lack of a PTR. After a few attempts the sender either calls their admin or the intended recipient, who then calls me. Either way, the admin and I talk. He/she says your mail server is broken. I say no, it isn't, yours is misconfigured. Try sending a message from your Yahoo account and you will find that it is delivered. He/she then says, so why can't I send any mails to your domain. I respond that it is because your DNS is misconfigured. Call your ISP and ask them to add a PTR record for your mail server and the mail will flow.

Sometimes there is question about this along the lines of; well why can I send to these other domains? I explain that some administrators are willing to accept mail from misconfigured systems because there are so many of them and it makes the administrator's life easier. I then say; Trust me, call your ISP. It only takes a couple of minutes and you will never have to deal with this problem again.

Typically, I get a thanks via email the next day. If they refuse to make the changes I point out to my user that they are receiving mail from everywhere else just fine and they can even send to this broken domain. Thus, our mail system is working correctly and the problem is at the far end. Done.

No it wouldnt be better

[mnmn]

I host maybe 7 domains, an email server, and several other things from my dynamic-ip DSL connection. Have been maintaining it for over a year with reasonable uptimes. I cant have PTR records or reverse resolution to my domain... but I dont send spam.

Many cottage-industry websites will be closed and not everyone can afford professional hosting services that use Jboss, postgresql, php4, ldap etc. Least fan sites that can make no money, and homepages.

Re:No it wouldnt be better

[Zeriel]

Doesn't your ISP have PTR records anyway, though? Even if it resolves to something like modem212-yourstate-yrcty.adelphia.com like my cable modem does, it's still a valid PTR record.

If your ISP doesn't do this, might I suggest shopping around for a new one?

I was under the impression the original question referred to completely nonexistent PTR records (that resolve to NXDOMAIN or similar).

Re:No it wouldnt be better

[Harik]

People choose their ISP's for various reasons: price, quality of service, convenience. What kind of drangles they use on their gimlets should not be one of them.

Quite right! Who cares about standard things like DNS when you can just use WINS! Send packets to the broadcast address and hope the right machine responds.

Hell, people who want their ISP to support PPP or IPv4 are just being bitchy. Nobody needs more then IPX over SLIP anyway.

--Dan

Discussion on spam, reverse DNS, etc.

[knightwolf]

You can find a small discussion of the topic on the Missouri Linux Users group - See this for a sample and just look for the "More spam" subject messages.

There are a LOT of places though that don't set these records, and filtering out these sites will drop a LOT of emails that actually might be valid.

The answer is "no"

[Anonymous Coward]

Wouldn't it be better for mankind if all mail servers refused mail from non-resolvable IPs?

No. Why? Let's look at this philosophically.

The purpose of email is to facilitate communication. That's it. One person sends an email to another with the intention that the message be received and read. The sender implicitly assumes that the message will, in fact, be received by the recipient, because the email system is based around that assumption. If the system works correctly, your mail will be delivered.

Any failure to deliver mail is a failure of the system. Period. The system exists to put mail in mailboxes, not to selectively put mail in mailboxes.

Now, spam. Spam is a problem, sure. It's not nearly as big a problem as a few people seem to think it is, but it's a problem. But the correct solution to the problem of nuisance mail is not to break the implied contract between the sender and the mail system as a whole. "Your mail will be delivered to its recipient." That's the implied contract. (I'm speaking metaphorically. There's no actual contract here, of course.) Anything that bolts on an "except" or "unless" to that implied contract is a bug, not a feature.

Now, in my opinion the correct way to deal with spam is to filter it on the receiving end. All mail should be delivered, but the recipient's automation may choose to flag some messages based on their content or their envelope or whatever. Some carriers don't like this idea because it requires them to deal with mail that people don't generally want to read, but choosing not to deal with certain pieces of mail is far worse.

That's the abstract argument. Here's the concrete one. If I send a piece of mail, I generally have no control whatsoever over, or even knowledge of, the bits and pieces that make up the delivery chain. My message leaves my computer and goes to an upstream server which then delivers it to another server, which then delivers it to the recipient. If that delivery process should fail because of the way the machines in the middle are configured, then that's going to be a problem for me. A very serious problem, over which I have absolutely no control.

Look at it this way. Let's say the postal service institutes a new regulation that no letters will be delivered if they're picked up by a mail carrier in brown shoes. Okay? Only white-shoe-wearing mail carriers are authorized to pick up mail. The mailman who serves my neighborhood forgets to wear his white shoes tomorrow when he picks up my outgoing mail. He gets to the post office and is told, summarily, that none of the letters in his bag will be accepted for processing because he's wearing the wrong color shoes.

How would I feel under those circumstances? Annoyed. Really annoyed. And so would all the other people on my block.

People who manage email servers really need to adopt the mailman's philosophy: we don't care what the mail is. We deliver it. No matter what, if it's got adequate postage on it (which doesn't apply to email), we deliver it. Neither rain, nor sleet, nor dark of night... and so on.

Re:The answer is "no"

[Deagol]

The purpose of email is to facilitate communication. That's it.

The same was once thought of having open relays, too. See how we changed out behavior with those?

DUCK! QUICKLY

[wowbagger]

You have suggested limiting Mr. 31337's ability to send any email he wants from his ub3rb0x3n without doing any real setup, like getting a proper reverse lookup established.

FOR THE LOVE OF $DEITY MAN, DUCK AND COVER!

You are about to be flamed by all the "How DARE you limit me! I have the $deity-given right to send email from ANYTHING, and YOU are wanting to RESTRICT IT! YOU BASTARD FACIST COMMIE!" types.

Personally, I would want my mail server configured to do something like this:

Get Host's name as given in EHLO.
Look that name up.
if (IP address from DNS != IP address talking to me)
Bugger off spammer
endif
reverse look up IP address talking to me
if (name from DNS != name from EHLO)
Look up name from DNS
if (ip address from lookup != IP address talking to me)
Bugger off spammer
endif
endif
Accept mail.


(It is assumed the "bugger off spammer" state is a terminal state).

This way, even if your box's reverse lookup is foo.bar.baz.adsl.example.com rather than mybox.example.com, so long as foo.bar.baz.adsl.example.com resolves to your IP address you wouldn't be rejected.

Yes, it has

[linuxwrangler]

...has the world become too lazy to make email delivery, easier?

I don't know of any specific RFC that requires reverse DNS for SMTP but the RFCs do require that the HELO/EHLO be 1) fully qualified and 2) resolvable.

I strongly recommend enforcing that rule even though you will be amazed at the number of mailservers that are not configured properly to follow this basic requirement of RFC2821.

Naturally it's not a bad idea to then look up the EHLO domain and make sure it resolves back to the connecting IP. Something like 25% of the mail I reject is rejected for greeting me with my own IP or hostname.

I agree in theory.

[Deagol]

This topic has sparked much heated debate in the postfix mailing list. Two camps exist. The first is the stop-spam-at-all-costs group, and then there's the you-evil-bastard-that's-not-mandated-by-rfc crowd.

Both have valid points.

I once tried this restriction with my employer's email server (we host a handful of university domains). It was a complete failure. Not because it didn't stop spam (I was finding several thousand spams per day rejected -- a 75% reduction of mail let through!), but because there were so damned many legit domains that didn't play by these common sense rules which you seek to enforce.

The overheard of me fielding complaints from my users was just too much. You'd think that the bloody sender would get the clue that it was a problem at his end (due to the bounce messages provided by postfix), but that just wasn't the case.

So I turned off the rules. I did come up with a compromize (I use postfix, btw). For major domains that should know better, and are in fact configured correctly (aol, hotmail, msn, etc.), I add a line like "earthlink.com reject_unknown_client" in my file pointed to by the check_sender_access line in my main.cf file.

Also, when I receive a piece of spam that gets through, I add the forged From: domain to that list if the connecting client was "unknown". I then add the "reject_unknown_client" restriction to the offending class-C in my check_client_access file in main.cf.

This method catches quite a few (maybe 50%). I use a few free RBLs to catch maybe 45% more spams. That other 5% gets through, but I haven't had a single complaint from my users since beginning this practice. So we're all smiles here now.

If and when I ever run my own email domains (business and personal), I will use all the rules postfix can enforce.

Re:PTRs should not be required

[Harik]

I personally run a mail server on my computer, and don't gateway mail it sends. That's the way email was designed to work, and still the way it works best. I think that's pretty legitimate. I get an immediate response when mail delivery fails, can set how long I want resends to be done, and don't have to remember to change my gateway when I move from home to college and back. I have no reason to run out and buy a domain -- I don't have any reason to present a domain to the world.

With all due respect, you're an idiot.

Requiring a reverse DNS record isn't forcing you to go out and buy a domain, just to bitch at your ISP to give you a valid reverse DNS. It can be in your domain, or in theirs, it just has to exist.

--Dan

Here's an even BETTER idea!

[Ashurbanipal]

Why not just refuse all messages that come from IP addresses that include the number 68?

I have analyzed the vast body of spam (for Bayes purposes) that has come through my mailservers over the last year or so, and I find that a lot of spam is sourced from IP addresses that include this number.

Sometimes it's x.x.68.x, sometimes it's x.n68.x.x, but that evil little 68 just keeps popping up!

According to my numbers, a greater amount of spam comes from IPs containing 68 or 24 than comes from domains with inconsistent PTRs.

So, using your own logic, I should just ban all IPs with 68 in them, and tell people with legitimate Email needs that they will have to find a new ISP.

To paraphrase a previous poster, "The fact that discarding mail from addresses containing the number 68 significantly reduces spam is reason enough that everyone should do so. I too will have to stop using a bunch of numbers I own but, it is worth the effort to stick to this policy. If you have a 68 in your IP, you can't send me mail!"

Note to moderators: Irony is not the same thing as flamebait...