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

Hi,
i managed to check this with v9.003 and v8.306 and found the same behaviour: the UTM rejects the mails temporarily.
If these emails were legitimate, i'm sure the provider would fix his DNS. Though I could not build a suitable setup yet I'm pretty sure that a properly configured mailserver would give up after a while and send a notification to the sender.
You're right, it's extra logging, communication and DNS queries for the UTM, but no mailqueue (mails are rejected before even queued). Even a heavy loaded system should handle this without problems.

For now there won't be any changes concerning this issue.
Thanks anyway for your input!

Regards,
bulirich

Though I could not build a suitable setup yet I'm pretty sure that a properly configured mailserver would give up after a while and send a notification to the sender.

gatekeeper:/var/log # grep -c "failed to expand" smtp.log
140

/var/log/smtp/2013/02/smtp-2013-02-21.log.gz:2013:02:21-19:21:40 gatekeeper exim-in[15948]: 2013-02-21 19:21:40 H=(mta16.agedpr.com) [192.69.94.211]:33787 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:
/var/log/smtp/2013/02/smtp-2013-02-21.log.gz:2013:02:21-19:22:45 gatekeeper exim-in[15963]: 2013-02-21 19:22:45 H=(mta16.agedpr.com) [192.69.94.211]:37330 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:

SNIP............

/var/log/smtp.log:2013:02:28-08:50:15 gatekeeper exim-in[21735]: 2013-02-28 08:50:15 H=(mta16.agedpr.com) [192.69.94.211]:33475 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:
/var/log/smtp.log:2013:02:28-08:52:55 gatekeeper exim-in[21770]: 2013-02-28 08:52:55 H=(mta16.agedpr.com) [192.69.94.211]:36294 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:
/var/log/smtp.log:2013:02:28-08:54:07 gatekeeper exim-in[21790]: 2013-02-28 08:54:07 H=(mta16.agedpr.com) [192.69.94.211]:54721 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:

The same mails are in my original post from the 14th but I don't have any logging since I rebuilt my box. I have been temporarily rejecting the same mail since the 21st of Feb on my rebuilt system and still waiting for someone to fix the PTR on the authoritative DNS to this day[8-)] and this is on my home system with

SMTP Proxy is active, 39 emails processed, 33 emails blocked

You're right, it's extra logging, communication and DNS queries for the UTM, but no mailqueue (mails are rejected before even queued). Even a heavy loaded system should handle this without problems.

You think so.... obviously you haven't followed threads like http://www.astaro.org/gateway-products/hardware-installation-up2date-licensing/45221-9-0044-33-spikes-high-cpu-memory.html which surely don't need additional load from bogus emails.
And by the way if the behavior was the same in earilier versions, that doesn't make it right. In any case, I am just beta testing and stating my opinion and if you think this doesn't need fixing, then the final decision is yours. 

Regards
Bill

Though I could not build a suitable setup yet I'm pretty sure that a properly configured mailserver would give up after a while and send a notification to the sender.

gatekeeper:/var/log # grep -c "failed to expand" smtp.log
140

/var/log/smtp/2013/02/smtp-2013-02-21.log.gz:2013:02:21-19:21:40 gatekeeper exim-in[15948]: 2013-02-21 19:21:40 H=(mta16.agedpr.com) [192.69.94.211]:33787 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:
/var/log/smtp/2013/02/smtp-2013-02-21.log.gz:2013:02:21-19:22:45 gatekeeper exim-in[15963]: 2013-02-21 19:22:45 H=(mta16.agedpr.com) [192.69.94.211]:37330 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:

SNIP............

/var/log/smtp.log:2013:02:28-08:50:15 gatekeeper exim-in[21735]: 2013-02-28 08:50:15 H=(mta16.agedpr.com) [192.69.94.211]:33475 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:
/var/log/smtp.log:2013:02:28-08:52:55 gatekeeper exim-in[21770]: 2013-02-28 08:52:55 H=(mta16.agedpr.com) [192.69.94.211]:36294 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:
/var/log/smtp.log:2013:02:28-08:54:07 gatekeeper exim-in[21790]: 2013-02-28 08:54:07 H=(mta16.agedpr.com) [192.69.94.211]:54721 F= temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=192.69.94.211" gave DEFER:

The same mails are in my original post from the 14th but I don't have any logging since I rebuilt my box. I have been temporarily rejecting the same mail since the 21st of Feb on my rebuilt system and still waiting for someone to fix the PTR on the authoritative DNS to this day[8-)] and this is on my home system with

SMTP Proxy is active, 39 emails processed, 33 emails blocked

You're right, it's extra logging, communication and DNS queries for the UTM, but no mailqueue (mails are rejected before even queued). Even a heavy loaded system should handle this without problems.

You think so.... obviously you haven't followed threads like http://www.astaro.org/gateway-products/hardware-installation-up2date-licensing/45221-9-0044-33-spikes-high-cpu-memory.html which surely don't need additional load from bogus emails.
And by the way if the behavior was the same in earilier versions, that doesn't make it right. In any case, I am just beta testing and stating my opinion and if you think this doesn't need fixing, then the final decision is yours. 

Regards
Bill