This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Rejected: RDNS/HELO (RDNS missing)

Over the past few weeks (it may have been happening for longer) I am getting mail being rejected from email addresses that used to work just fine.
I have been forced to add exceptions in the in the SMTP proxy in order to receive the previously rejected mail messages.
Given the amount of SPAM that hits the SMTP proxy, going though the list line by line checking for valid emails is not viable.

No settings on my firewall have been changed in a very long time. What's going on here?


This thread was automatically locked due to age.
  • I think I have fixed this myself.
    It would appear that Astaro had a conniption with the DNS forwarder that was set.
    When I removed it and then added it back everything started to work again.

    Basically the firewall  just lost the plot and therefore lost the ability to resolve IP addresses; hence my problems. 
    This is more than a little disconcerting....
  • I have been having a similar problem over the last week. 
    Some have been for Gmail.com and the strange thing is one Gmail email will be delivered and the one will fail.

    I have not tried changing the DNS Forwarder settings yet.

    It been about a year ago when a DNS security patch was applied the IPS started identifying every DNS response as a port scan. I had to create an exception for the DNS fowarder. I don't know if that could be related in any way.

    Astaro Security Gateway Software 7.404
  • Lyvewyre has been around for a long time, so he probably doesn't need these suggestions for DNS configuration:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/p/53408/193983#193983

    Please let us know if you've discovered a glitch in 7.404 or in a pattern update or ???

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I determined the cause of the problem was a bad DNS server in our list of forwarders.

    We had 4.4.2.1 as a forwarder and it was not responding. I removed that and entered only the ISP's DNS forwarder and it appears to be working fine now. 

    I am going to give it 24 hours and see if it is still rejecting legitimate RDNS entries.
  • Lyvewyre, For future visitors here, is there something you see in the DNS or SMTP logfile that would help to identify the problem?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • It appears the the DNS server may still be the source of the problem. After the change almost immediately the messages started being rejected again.

    There are timeouts in the DNS proxy log but they do not correlate to the RDNS failures.
    Here's a sample of the DNS Proxy Log with timeout errors:
    2009:08:20-15:17:38 fw2 named[3365]: too many timeouts resolving '82.253.40.208.in-addr.arpa/PTR' (in '253.40.208.in-addr.arpa'?): disabling EDNS
    2009:08:20-16:04:27 fw2 named[3365]: too many timeouts resolving '144.234.216.209.in-addr.arpa/PTR' (in '234.216.209.in-addr.arpa'?): disabling EDNS


    In the SMTP Proxy log there is an example of a perfectly legitimate email being rejected:

    H=(chvpkmox2.chevron.com) [146.23.4.128]:14634 F= rejected RCPT : No RDNS entry for 146.23.4.128
    2009:08:20-16:29:12 fw2 exim[9286]: 2009-08-20 16:29:12 SMTP connection from (chvpkmox2.chevron.com) [146.23.4.128]:14634 closed by DROP in ACL

    I did some tests using Support=>Tools>DNS Lookup plugging in the IP and it failed one time and succeeded the next. I am waiting for the datacenter staff to provide me with another local DNS server to test with.

    If I do the same test from home it works reliably.

    I will keep you posted on the results if anyone has any other suggestions let me know.
  • It was the DNS Forwarding server. I used two new DNS lookup servers and no longer have the issue. 

    Resolved!