RDNS missing 8.201 -NOT A BUG

We have the same issue since upgrading to 8.201

We have the same issue since upgrading to 8.201

Can you please double check whether
[LIST=1]

• really legitimate mail is rejected and
  
• the DNS setup on your ASG is working.
  

[/LIST]

In case legitimate mail really gets rejected due to RDNS and your DNS setup on your ASG is really working, please contact your partner to open a support case for you.

Thanks,
mlenk

Hi mlenk,

I have gone thru alot of logs now on the production site and it seems I was out a little early. I have not spottet any not correct RDNS rejects yet.

However, I still think it is wrong that the RDNS check obay the dns routing rules I setup in order to resolve domain dns to the company on the site2site VPN...

The RDNS check should only check against "public" / ISP assigned DNS servers or there should be an option at least to tell the mail filter what to do in this case.

I guess this is a natural consequence of so many features in one box sharing the same subsystems.

Vels, could you show simple diagrams of how this works and how you want it to work?

PC -> DNS -> VPN -> Internal DNS ?

Cheers - Bob

Sure..

As a sysadmin I have most of a small hosting enviroment at home - including an ASG.

This ASG connect to my company with a SSL site2site VPN tunnel where some nutcse 10 years ago configured the internal domain ( .com ) to be the same as the external domain, insted of using .local or the like inside.
This basically means I have to route my dns request for the company domain to the internal DNS servers at the company.

So for the company DNS request it looks like this if I ask for a company server or the like :

home pc -> home ASG -> site2site SSL -> company ASG - company DNS server

If I ask for anything else.. :

home pc - > home ASG -> ISP DNS

Now the fun part is that I ( like many other sysadmins ) have my own mailserver at home and I realized that when someone writes me a mail from the company the PTR in my home ASG will try to resolve the RDNS for the company mailserver - which would be fine it the check was done against ISP DNS or public DNS like google DNS.
In this rare case however the domain name matches the internal company domain and the RDNS request is routet to the internal DNS server of the company which replies with the LAN IP of the server.

This will result in a failed PTR / RDNS check since the ASG is fully aware of the public IP of the mailserver and it fully aware of the hostname of the mailserver ( the public one ) - but fails because it gets the internal IP becuase of this DNS route that I really only want my home client PC's to follow.

I Hope that makes sense.. its a minor problem though.

Now the fun part is that I ( like many other sysadmins ) have my own mailserver at home and I realized that when someone writes me a mail from the company the PTR in my home ASG will try to resolve the RDNS for the company mailserver - which would be fine it the check was done against ISP DNS or public DNS like google DNS.
In this rare case however the domain name matches the internal company domain and the RDNS request is routed to the internal DNS server of the company which replies with the LAN IP of the server.

In this particular case you should properly configure your home ASG to treat the company mailserver (i.e. the IP address that is seen in the smtp.log for mails sent by your company mailserver) as a trusted upstream host by adding it to the Mail Security -> SMTP -> Relaying -> Upstream host list. This will cause the RDNS checks to be skipped for your company mailserver. Also other AntiSpam features such as greylisting will benefit from knowing the upstream hosts of your setup.

Rationale: Doing reverse DNS checks or greylisting for your known company mail server doesn't make any sense, because you know that they are administered properly, so they will never send you any junk mail. And in the unlikely case they do send you junk, you know who to beat for it... [;)]

Regards,
mlenk

I think there's a resolution using 'Request Routing'.  First, google site:astaro.org dns best practice.  You may not have a separate internal name server at home, but I think you'll see the picture.

If the proper reverse DNS entry is available in internal DNS, you could add a request route like '1.16.172.in-addr.arpa -> {Internal DNS}' (assuming your internal network is 172.16.1.0/24).

The alternative is simply to create a 'Static Entry' like 'mail.company.com -> {internal IP of mail server}' and select the 'Reverse DNS' option.

I haven't thought through this completely, so I'm not certain neither approach will make it difficult for you to send email from your home server to your office server without another tweak.

Cheers - Bob
PS Although my idea will work, mlenk's approach is the more-elegant solution, as he explains.

mlenk - ofcourse DOH! Why didn't I think of that.. I was just too focused on the company mailserver which I know has all proper configuration was ditched because of a "wrong" DNS lookup towards internal DNS because of DNS Request routing.

Balfson, it was the other way around. The Exchange server doesn't need all the fancy "anti spam" records on the inside network except ofcourse if I wanted my home ASG to get the right info which seemed a bit overkill.

It still fun though that this is an import configuration from a previous version of ASG.. I think 8.03 or around there and there was not an issue back then. But again good to know.

To cut it short, the main issue of this thread I cannot confirm. Read 5 days log today with PTR check enabled on my main ASG's at the company and found none rejected that should not be rejected.
The other part of the error I got was simply a brain fart caused by the system acting a bit different than a few versions ago and I did not think out of the box.

Besides that, management gave me an order today to disable PTR checks because too many of our partners has poor configured mail systems with incorrect hostnames and missing PTR records. I asked the Sales people to whitelist the people they often send mail to and new contacts - but they found it too difficult ( I have no idea how the user portal could be difficult at that point ). But I guess the only thing they would find easy is an outlook pugin where they can rightclick and add to whitelist in the mail filter.
So now I am looking forward to see how much junk that will actually pass the spam inspection and arrive in the inboxes ...no need to mention my point of view on this.

Thats one thing you can love by Astaro, there always seems to be a way to the goal even though its not always obvious.

I've got the same issue where a domain has multiple A records with different IP address, the SMTP service will tag the mail with Rejected: RDNS/HELO (RDNS missing).

When I NSLOOKUP the IP it resolves with the correct domain (as per the sender email domain - however it's rejected by SMTP service), however when I NSLOOKUP the domain name I get a different IP. Granted this is not a good DNS set up (which I can't control), however email that didn't bounce under ASG 8.1xx is now bouncing under ASG 8.2xx

@mleck let me know if there are any additional logs I can provide.

Hi Lemo,

thank you for reporting back your observations.

Granted this is not a good DNS set up (which I can't control), however email that didn't bounce under ASG 8.1xx is now bouncing under ASG 8.2xx

If this is true, the RDNS check feature was probably broken in ASG 8.1xx - unfortunately we didn't know about any RDNS check issue in ASG 8.1xx, so maybe it was broken only in a few special setups, so we didn't discover it. But this is wild guessing. And - as the feature now seems to work as intended - I see no benefit in investigating any more details.

As said before in an earlier post: Please check that the now bouncing mail is really legitmate mail, and not Spam. If it really is legitimate mail, you should consider to add an exception to skip the RDNS check for the few legitimate mail sending servers (source hosts/networks).

Regards,
mlenk