sendmail cannot resolve PTR record

A week ago I installed 64-bit FreeBSD 10.2, Mate (the gnome2 fork) and Evolution 3.16.5, among other things, in a VMware Workstation virtual machine (Win7). I find that sendmail gives an error message "Relaying temporarily denied. Cannot resolve PTR record for ..."

I can send mail to myself. My domain is a subdomain; I can send email messages to others on the primary domain. However, I can't send anything beyond that.

I've never seen this error since I started using FreeBSD back in the 5.4 days, and I've no idea how to correct it. Any suggestions would be most appreciated!
 
drill(1) and dig(1) are tools for DNS lookup. An example would be drill -x 8.8.8.8. Sendmail is sensitive to DNS issues so if things like that are failing then DNS needs to be looked at.
 
Thank you. dig seems not to be installed, but drill is. I'll try a couple of outside addresses.

Additional data: I have a couple of older FreeBSD VMs (9 era/Gnome2) that were perfectly functional when last used. They now not able to send or receive email. Weird. The web/email hosting company claims that nothing has changed over the last week or so, but tech support often is the last to know. Also, I had installed Thunderbird some days ago, but never configured it. I set it up quickly, and it seems to work fine. I don't know what MTA Thunderbird uses.
 
On 9.x and earlier, ISC's dig(1) was part of the base system along with BIND. On 10.x and later, NLnet labs Unbound suite and drill(1) are included instead.

This certainly does look to be some changes to DNS resolution somewhere in the network that are causing issues.
 
% drill 66.237.94.160
Error: error sending query: Could not send or receive, because of network error​

This is an address to a colleague at NIH, so it should be good.
 
prosecco:/etc % more resolv.conf
Code:
# Generated by resolvconf
search wavecable.com
nameserver 192.168.0.1

Wavecable is my ISP; the other is my local router. I wondered if this was an issue with reverse lookups, but it always has worked in the past.
 
drill -x @8.8.8.8 66.237.94.160 for a query to Google fails. It works for a reverse DNS lookup of my home router IP address. I think the issue with with the ISP.
 
% drill 66.237.94.160
Error: error sending query: Could not send or receive, because of network error​
This is an address to a colleague at NIH, so it should be good.

So this address is not your home address so it's not your ISP responsibility. I also see this fail using the command mentioned above to a public DNS server.

Does a reverse DNS lookup of your home IP address work? That will at least rule out local issues with your ISP's DNS.
 
drill -x <homeaddress> gives the same error as above. Using the IP address for my website/email host works.
 
Please don't just disappear - tell us what the solution was so that others with similar issues may benefit.
 
Not mention people who just read stuff here in order to learn. :)
 
There is no solution yet, but scottro pointed out something to me in an email message off the forum here that I have to pursue. It is late, and I'm heading to bed, but I'll follow up. Heaven knows that FreeBSD documentation often is scarce, and these and other fora are the only places where one learns things.

Stay tuned!
 
OK -- I'll expand before turning in. I installed the bind utilities, and found with dig (and scottro's help) that I could locate the IP address of my mail server. That IP address could not identify the name of my mail server, but rather the domain that hosts mine. It seems not to be my ISP, but the company that hosts my subdomain. My wife holds the main domain so it is no big deal, but we have to get the pointers pointing in the right direction.

I'll call them in the morning, and let you know here what happens.

Damn these things are frustrating.
 
To clarify, for those following along trying to get a better handle on DNS. We'll say the good doctor's mail server is called mail.example.com with an address of 1.2.3.4 and his wife's domain is examplewife.com.
Code:
dig +short mail.example.com
1.2.3.4
dig -x 1.2.3.4
something.examplewife.com

So, he needs a PTR (also called rDNS and reverse DNS) to point 1.2.3.4 to mail.example.com.

Also, note that it's best to have a PTR record only pointing to one host. While people sometimes do have it pointing at multiple hosts for various reasons, it can be problematic as the response to a lookup might be host1, host2, or both of 'em. :)

(There's a good chance everything at something.examplewife.com will work without that reverse DNS pointing at it, though ideally, find something without a PTR record in your allowed range of IP's and give that IP to the server.)
 
scottro has it exactly right. I contacted Westhost, which we use for web and email services, to update the PTR record to point to my email server instead of my wife's. I'll post when things work as they should. FWIW, Westhost has been very good for us, and this is the first glitch we have had in about 10 years.
 
The answer from Westhost:

After looking at your request to up date the DNS so that the IP 1.2.3.4 resolves back to example.com. We can not do that currently because the primary domain on the account is examplewife.com. You would need to either change the primary domain of the account, or you would need to have a separate account for example.com with a dedicated IP. Please let us know if you have any other questions or concerns.
Needless to say, I am very unimpressed.

Is anyone aware of a hosting company that uses FreeBSD as a local VM for their clients?
 
I don't know if anyone still is following this thread, but it gets curiouser and curiouser. I have a bunch of older FreeBSD VMs that I checked for email delivery, and they didn't work. I went back to check that one of my old FreeBSD VMs was set up properly. It turns out that I had it set to work offline. Makes sense, since I was transferring the various email files to the new VM.

When I switched it to work online, it sent the email message to my gmail address just fine. So there is something different in the new sendmail configuration. This one may not be Westhost's fault.
 
Back
Top