Hello Wietse, Friday, October 19, 2018, 11:15:49 AM, you wrote:
> Phil Biggs: >> Oct 18 14:58:56 postfix/postscreen[1592]: CONNECT from [203.38.21.10]:35490 >> to [192.168.11.19]:25 >> Oct 18 14:59:02 postfix/postscreen[1592]: NOQUEUE: reject: RCPT from >> [203.38.21.10]:35490: 450 4.3.2 Service currently unavailable; >> from=<myISPemailAddr>, to=<myPrivateEmailAddr>, proto=ESMTP, >> helo=<nsstlmta10p.bpe.bigpond.com> >> Oct 18 14:59:02 postfix/postscreen[1592]: PASS OLD [203.38.21.10]:35490 >> Oct 18 14:59:02 postfix/postscreen[1592]: DISCONNECT [203.38.21.10]:35490 > The log shows a 6-second delay, meaning that the test for "pregreet" > was expired, or that no record was found in the postscreen > cache. > "Service currently unavailable" followed by "PASS" means that you > have one of: > postscreen_bare_newline_enable = yes > postscreen_non_smtp_command_enable = yes > postscreen_pipelining_enable = yes > and some of the timestamps for these tests were too old, or that > no record was found in the postscreen cache. Until now, these tests > are not useful for blocking spambots; they always result in "Service > currently unavailable" if the test has expired which can be annoying. > I suggest that you turn these tests off. > After the "PASS" result, the timestamps for the expired tests will > be set to 'now', and those tests will be skipped until the timestamps > expire, or until the postscreen cache is deleted. > Is it possible that the reboot or 'postfix start' removes the > postscreen cache, as in: "rm -f $data_directory/*' or even 'rm -rf > $data_directory'? > Wietse Yes, all three were present: postscreen_bare_newline_enable = yes postscreen_non_smtp_command_enable = yes postscreen_pipelining_enable = yes I have removed those. I don't see any evidence of the postscreen cache being removed at any stage. There were 230-odd entries in there when I ran the postmap -s, shortly after the reboot. Thanks Wietse, Phil
