2

This is driving me nuts… Linux Debian + postfix… /etc/postfix/main.cf has the following lines:

smtpd_recipient_restrictions =
    check_recipient_access hash:/etc/postfix/access,
    reject_invalid_hostname,
    reject_non_fqdn_recipient,
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unauth_pipelining,
    reject_unknown_recipient_domain,
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client sbl-xbl.spamhaus.org,
    check_policy_service unix:private/policyd-spf,
    check_policy_service inet:127.0.0.1:10023,
    permit_auth_destination,
    reject

These days postfix is rejecting incoming messages from one single IP:

 info@domain.ext
   SMTP error from remote mail server after RCPT TO:<info@domain.ext>:
   host mail.server.ext [123.123.123.123]: 554 5.7.1 Service unavailable; Client host [234.234.234.234] blocked using cbl.abuseat.org; Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=234.234.234.234

Well… http://cbl.abuseat.org/lookup.cgi?ip=234.234.234.234 reports no blacklisting of 234.234.234.234 (obviously the IP 234.234.234.234 is not the real one).

Dozen emails have been blocked so far for the same reason, but each time I manually query the RBL, the IP is reported as clean.

Is postfix caching queries to RBLs? What am I missing?

Thanks in advance for your time.

Gabriele
  • 341
  • 1
  • 4
  • 14

1 Answers1

3

From the top layer perspective, Postfix relies on libc resolver to do DNS lookup (including RBL), so the the behaviour would depends on the library. For example, postfix will alwasy do lookup via NS server defined in /etc/resolv.conf.

If the NS server has caching mechanism, then postfix will get the cache result too. This is also happen if your provider has "DNS hijacking" (the diverted DNS packet into their NS server). In this event, you will also hit their cache (if they enable it).

To check what's the output of DNS lookup, you can use dig command. For example check if IP address 216.154.195.36 was listed in cbl.abuseat.org.

$  dig  36.195.154.216.cbl.abuseat.org

; <<>> DiG 9.10.1-P1 <<>> 36.195.154.216.cbl.abuseat.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48609
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

If the return is NXDOMAIN, the IP address wasn't listed.


From the bottom layer perspective, each smtpd process has cached its own DNSBL lookup results. Those results are not shared with other Postfix processes. Each smtpd process will be reused until max_use or max_idle reached. When smtpd process dies, the RBL cache will lost too. When new smtpd process was create by master daemon, it will pickup new configuration on main.cf (including max_idle and max_use. So actually no need to restart postfix.

masegaloeh
  • 18,236
  • 10
  • 57
  • 106
  • 1
    Thanks a lot, that makes sense; I have now flushed the server DNS cache to see if the issue is solved. As far as max_use and max_idle are concerned, I have already tried to restart postfix to no avail (I guess those values are reset upon restart, aren't they?). – Gabriele May 19 '15 at 08:23
  • Umm.. What do you mean by *restart postfix to no avail*? – masegaloeh May 19 '15 at 08:34
  • % service postfix restart … messages were still being blocked by some RBL check… – Gabriele May 19 '15 at 08:39
  • See updated answer, especially to test if your DNS resolver still cache the result – masegaloeh May 19 '15 at 09:03