Get APLawrence.com by RSS(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Home > Unix Articles > More on PTR records
Printer Friendly Version
More on PTR Records
Quite some time ago I wrote up Basic DNS: PTR records and why you care. I realized today that it is far too geeky: I sent someone experiencing a PTR issue to read that and he came back still thinking that either his Mac or Verizon were to blame.
Why does he think that? Well, I suspect mostly because he got bad support from Verizon AND Apple. His problem was that email he sent to someone with a Comcast address got bounced back with a message like this:
Comcast requires that all mail servers must have a PTR record with a valid Reverse DNS entry. Currently your mail server does not fill that requirement.
Whose mail server does not fill that requirement? His Mac Mail.app is set to use "outgoing.verizon.net" as its outgoing server. His machine NEVER TALKED TO COMCAST. It's not supposed to: it's supposed to talk to "outgoing.verizon.net". It's THAT machine or some other machine of Verizon's that will talk to Comcast. So if Comcast is complaining, it's something at Verizon they are complaining about, and nothing to do with whether or not he's using a Mac or a PC!
It's beyond amazing that no one at Apple or Verizon was able to help him with this and that they each kept bouncing him back to the other.
Specifically, Comcast rejected "206.46.173.5". I just checked and that's NOT "outgoing.verizon.net" but it is in Verizon's block, and it doesn't have a PTR record so Comcast is right to complain. Verizon needs to assign a PTR to that address and that wll be the end of his problem.
Nothing to do with OS X or anything else. Just Verizon itself.
If this page was useful to you, please click to help others find it:
Your +1's can help friends, contacts, and others on the web find the best stuff when they search.
Inexpensive and informative Apple related e-books:
Podcasting on the Mac
iPhoto '09: Visual QuickStart Guide
Permissions in Tiger (Leopard version also available)
Making Music with GarageBand '06
Screen Sharing in Snow Leopard
More Articles by Anthony Lawrence - Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Thu Apr 24 17:11:13 2008: JonR
Thanks for this, Tony. I'd never even heard of PTR records before (your original post was before I subscribed to your blog, I think). This may, unfortunately, come in handy, for my ISP is ATT/Yahoo! and they, er, make their share of mistakes. (Couldn't find the "understatement" HTML tags to use there.)
Could you state, or restate, the best way to get a situation like this corrected when it occurs?
Thu Apr 24 17:28:53 2008: TonyLawrence
There are two ways to solve it: have your ISP make a PTR record for your mailserver, or have your mailserver relay through something that does have a PTR record.
In this case, this guy was doing the latter, but Verizon screwed up their own DNS and didn't have the PTR.
Fri Apr 25 11:30:53 2008: badanov
http://www.freefirezone.org
A lot of ISPs mail admins look for mail coming from servers which have no reverse DNS entry or PTR as part of their anti spam operation, and I am always getting them to drop that requirement for my server since I don't have a full DNS setup.
Fri Apr 25 14:09:45 2008: BigDumbDinosaur
http://bcstechnology.net
Lack of a valid PTR record is almost always a sign of a spam source. My mail server will block any foreign system that doesn't have a PTR record. If the server admin can't be bothered to handle the DNS details he/she probably isn't sufficiently motivated to police the system's usage and try to keep out the spammers. Either that, or the server has been intentionally set up to be an open relay.
Tue Oct 21 08:41:15 2008: Gary
The PTR explanation has enlightened my doubts.
But how to add PTR to the mail server?
Tue Oct 21 09:47:38 2008: TonyLawrence
You don't add it to your server. Your ISP has to do it. See http://aplawrence.com/Blog/B961.html
Sat Nov 21 15:14:18 2009: Donna
Hi
Maybe you can help with this .... I am so confused.
I have a website ... who I host with and who I go thru for domain name are different companies.
Comcast stopped letting my emails go thru yesterday ... because of no ptr record with a valid reverse entry.
Who is responsible for this .... hosting company .... or ... where I get my domain name from?
My hosting company says .... where I got domain name
My domain name people says ..... where I got hosting
Nobody wants to step up to the plate and help with this problem .... each blame the other.
Can you help explain this to me .... as to who is responsible to fix this
Maybe ....its something I am supposed to be doing???
Thank you in advance
Sat Nov 21 15:28:46 2009: TonyLawrence
It depends upon how you are sending the mail.
I'm assuming you are talking about your home computer sending mail?
What do you have your "Outgoing SMTP server" set to?
If it's Comcast's SMPT server, it's their problem.
If you have it set to your website's mail server, then the responsible party is whoever owns the IP address you are using. That would usually be the hosting company, It would NEVER be where you got the domain from - whoever told you that is an idiot. In NO case is this anything you can do: a PTR record is NOT something you can add to your DNS.
See http://aplawrence.com/Blog/B961.html for more on that.
Sat Nov 21 15:32:34 2009: TonyLawrence
If you have it set to your website's mail server, then the responsible party is whoever owns the IP address you are using.
In case that's not clear, I mean your web site's IP, not your home IP.
Sat Nov 21 15:35:00 2009: TonyLawrence
Wait - I assumed you were using Comcast at home.
If you are using YOUR HOME ISP's mail server, it's their problem, whoever they are.
Sat Nov 21 16:11:06 2009: Donna
Hi
Thank you for the quick response!
I am not talking about my home computer email .... I am talking about my website email
which has nothing to do with my home computer ... or .... my
home email address
Thanks
Donna
Sat Nov 21 16:22:23 2009: TonyLawrence
OK then. It's whoever is responsible for the net-block your ISP uses.
Usually, that would be your hosting company, but it's possible that they get IP's from someone else.
You want to know who is responsible for the reverse ip lookup. Again, if they don't understand, demand to speak to someone more intelligent and refer them to http://aplawrence.com/Blog/B961.html - that's what you need.
Sat Nov 21 16:36:33 2009: Donna
Hi
Again .... Thank you for the quick response!
You have been very helpful.
Thank You
Sun Nov 22 17:34:09 2009: BigDumbDinosaur
http://bcstechnology.net
If it's Comcast's SMPT (sic) server, it's their problem.
Something to note for all you Comcast subscribers. They will not allow traffic on port 25 to pass through their system to a third party mailserver, obviously a gesture intended to thwart mail zombies running on Windows XP home edition machines. If you are relaying your mail through a third party server you must do so on an alternate (non-privileged) port.
Several of my clients who have Comcast at home relay their outbound mail through their company servers for legal reasons. All my clients' servers run Sendmail, so once I had worked out a methodology for providing secure relay access, it was trivial to set it up on other servers. The trick is to have Sendmail listen on a dynamic port (that is, any port from 49152 upward) to accept authorized relay traffic. This arrangement doesn't affect Sendmail's ability to listen on port 25 for the usual inbound SMTP traffic from other mailservers. See the DaemonPortOptions keyword in sendmail.cf for more info.
Needless to say, if you set up such an arrangement, you must enable client authentication to avoid having the Internet monkeys attempt to relay through your server. You may use AUTH-LOGIN or more complex schemes, such as CRAM-MD5, to verify that the connecting mail client (meaning Thunderbird, Outhouse Distress...er...Outlook Express, etc.) is authorized to relay. AUTH-LOGIN generally works well enough but is not truly secure due to the use of base64 encoding of the username and password sent by the client to the server (reversing base64 is trivial to implement). For improved security, consider adding STARTTLS to the mix in your sendmail.cf config file. If you are using some other MTA, such as Postfix, read up on the documentation to find the equivalent functions.
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar