/dev/rob0:
> Still watching logs, this one just passed by. Probably unrelated to
> the changes in 20130517, but I was curious about it:
>
> May 19 13:24:20 harrier postfix/postscreen[3533]: CONNECT from
> [188.42.15.19]:48706 to [207.223.116.211]:25
> May 19 13:24:26 harrier postfix/postscreen[3533]: NOQUEUE: reject: RCPT from
> [188.42.15.19]:48706: 450 4.3.2 Service currently unavailable;
> from=<bou...@consumer-news123.com>, to=<mun...@example.net>, proto=ESMTP,
> helo=<mail18.consumer-news123.com>
> May 19 13:24:26 harrier postfix/postscreen[3533]: PASS NEW
> [188.42.15.19]:48706
> May 19 13:24:26 harrier postfix/postscreen[3533]: DISCONNECT
> [188.42.15.19]:48706
postscreen does not find the client IP address in the permanent
postscreen_access_list, does not find client the IP address in the
temporary postscreen_cache_map, logs the "all tests passed" status,
updates the temporary postscreen_cache_map with the expiration time
for each test, and forgets the test results.
> All is well and good for a non-whitelisted host, but apparently it
> was too quick in coming back to the secondary MX IP address ...
>
> May 19 13:24:26 harrier postfix/postscreen[3533]: CONNECT from
> [188.42.15.9]:33610 to [207.223.116.214]:25
> May 19 13:24:26 harrier postfix/postscreen[3533]: WHITELIST VETO
> [188.42.15.9]:33610
>
> ... all in the same second, but according to syslog, sequentially
> after having earned whitelist status.
postscreen logs "CONNECT from", does not find the client IP address
in the permanent postscreen_access_list, and does not find the
client IP address in the temporary postscreen_cache_map. Therefore
this is handled as a non-whitelisted client that connects to the
"wrong" IP address.
Why wasn't the client IP address found in the temporary
postscreen_cache_map? Maybe silent corruption of the cache database.
Wietse
