Thread Info
  • State Not Answered
  • Replies 6 replies
  • Subscribers 0 subscribers
  • Views 5202 views
  • Users 0 members are here
Options
Suggested

[9.065][ANSWERED] SMTP Failed To Expand ACL String on DNS ptr failure

Billybob
Hi, I have a few emails that are getting temporarily rejected due to ACL string error. Here are a few log snippets...
/var/log/smtp/2013/02/smtp-2013-02-10.log.gz:2013:02:10-06:15:54 gatekeeper exim-in[4648]: 2013-02-10 06:15:54 H=([36.73.64.11]) [36.73.64.11]:18546 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=36.73.64.11" gave DEFER:


gatekeeper exim-in[24914]: 2013-02-13 03:11:53 H=([180.245.209.110]) [180.245.209.110]:15930 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=180.245.209.110" gave DEFER:


gatekeeper exim-in[20166]: 2013-02-14 10:16:33 H=(mta27.agedpr.com) [192.69.94.222]:37556 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.222" gave DEFER:

and DNS query......... 
gatekeeper:/var/log # dig ptr 222.94.69.192.in-addr.arpa



; <>> DiG 9.6-ESV-R7-P4 <>> ptr 222.94.69.192.in-addr.arpa

;; global options: +cmd

;; Got answer:

;; ->>HEADER

and DNS log... 
2013:02:18-21:10:40 gatekeeper named[4207]: error (unexpected RCODE SERVFAIL) resolving '222.94.69.192.in-addr.arpa/PTR/IN': 199.19.111.7#53

2013:02:18-21:10:40 gatekeeper named[4207]: error (unexpected RCODE SERVFAIL) resolving '222.94.69.192.in-addr.arpa/PTR/IN': 204.124.182.253#53

Regards
Bill
Parents
  • 0
    Hi, i got your point. What i don't see is that "this can become a huge problem...". What else can happen besides the log getting filled?

    As i understand it, a servfail indicates a temporary failure at the dns server, a situation which the provider wants to resolve as soon as possible. Said that i don't see a bug here, nor why the behaviour of the UTM should be changed in this case.

    Regards,
    bulirich
Reply
  • 0
    Hi, i got your point. What i don't see is that "this can become a huge problem...". What else can happen besides the log getting filled?

    As i understand it, a servfail indicates a temporary failure at the dns server, a situation which the provider wants to resolve as soon as possible. Said that i don't see a bug here, nor why the behaviour of the UTM should be changed in this case.

    Regards,
    bulirich
Children
  • 0 in reply to bulirich_01
    Hi, I think the mail mentioned in my logs is probably spam. From what I remember in older versions, RDNS failure in all situations (PTR problem or non matching PTR etc) would immediately give a deny. If this was a legitimate email, there is no way for the admin to know the situation unless he looks at the logs. I am assuming here but I don't believe that the sender is getting any notifications of email not getting through.

    If my hunch is correct, then that is extra logging, communication, mail queue, and DNS queries that a UTM can do without.

    I think the RDNS feature should go back to the way it was and get a deny immediately. That is all my point is in all this. I don't see any reason to play around for the authoritative DNS to come back online. That is the sender's problem not the receiver's.

    Regards
    Bill