Re: configuration postscreen
Claus R. Wickinghoff:
> Dec 13 09:06:27 mole postfix/postscreen[1729]: PASS NEW
> [45.146.203.135]:60433
[client gets 450 from after-220 tests]
> Dec 13 09:16:27 mole postfix/postscreen[1771]: PASS OLD
> [45.146.203.135]:49121
...
> The problem is: The system starts delivering spam and in the moment it
> connects to my server for the first time, only one blacklist has it on
> the radar. But due to the cache (PASS OLD) it can now deliver as much
> spam as it likes to my server.
Obviously, postscreen cannot predict the future, that is why all
its cached results have a configurable expiration time.
postscreen_bare_newline_ttl = 30d
postscreen_dnsbl_max_ttl = ${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h
postscreen_dnsbl_min_ttl = 60s
postscreen_greet_ttl = 1d
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_ttl = 30d
You could try use some combination of more postscreen DNSBLs and a
shorter postscreen_dnsbl_max_ttl. BTW many DNSBLs specify a shorter
TTL than 1H and postscreen will use their TTL instead (but
postscreen_dnsbl_min_ttl takes precedence).
None of this would "fix" your "problem" if a client reconnects in
less time than the DNSBL TTL. That is the whole point of postscreen:
it does not HAVE to stop all spambots, just most of them. It is
perfectly OK to handle the remaining spam with content-based methods.
Wietse
Re: configuration postscreen
On Fri, Dec 13, 2019 at 11:03:49AM +0100, Claus R. Wickinghoff wrote: > Dec 13 09:16:27 mole postfix/postscreen[1771]: PASS OLD [45.146.203.135]:49121 > > Now it reconnects and with the cache entry it's calssified as "PASS OLD" > and got redirected to smtpd... > > Dec 13 09:16:27 mole postfix/smtpd[1839]: 369B040088: > client=tremble.sckenz.com[45.146.203.135] > tremble.sckenz.com[45.146.203.135] ehlo=1 mail=1 rcpt=1 data=1 quit=1 > commands=5 > > ...and delivers its spam. > > If I check some blacklists now, I got hits: > > LISTED Spamhaus ZEN45.146.203.135 was listed 60 0 > Ignore My advice would be to enable zen.spamhaus.org (or similar mainstream low FP rate RBL) on a per-message basis in smtpd(8): smtpd_client_restrictions = permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org The purpose of postscreen is to try to keep botnets from consuming all your SMTP connection slots. You should have anti-spam measures in place for the clients that get through. I would avoid unduly short postscreen cache times, that can lead to legitimate clients not getting through at all. -- Viktor.
Re: configuration postscreen
On Fri, Dec 13, 2019 at 11:03:49AM +0100, Claus R. Wickinghoff wrote: Dec 13 09:16:27 mole postfix/postscreen[1771]: PASS OLD [45.146.203.135]:49121 Now it reconnects and with the cache entry it's calssified as "PASS OLD" and got redirected to smtpd... Dec 13 09:16:27 mole postfix/smtpd[1839]: 369B040088: client=tremble.sckenz.com[45.146.203.135] tremble.sckenz.com[45.146.203.135] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 ...and delivers its spam. If I check some blacklists now, I got hits: LISTEDSpamhaus ZEN45.146.203.135 was listed 60 0 Ignore On 13.12.19 11:30, Viktor Dukhovni wrote: My advice would be to enable zen.spamhaus.org (or similar mainstream low FP rate RBL) on a per-message basis in smtpd(8): smtpd_client_restrictions = permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org The purpose of postscreen is to try to keep botnets from consuming all your SMTP connection slots. You should have anti-spam measures in place for the clients that get through. I would avoid unduly short postscreen cache times, that can lead to legitimate clients not getting through at all. I'm not sure if that would help. Apparently, both postscreen and smtpd will use the same nameserver for dnsbl lookup, and if it's cached from previous postscreen lookup, it will probably give the same result. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Christian Science Programming: "Let God Debug It!".
Re: configuration postscreen
On Fri, Dec 13, 2019 at 05:40:33PM +0100, Matus UHLAR - fantomas wrote: > >I would avoid unduly short postscreen cache times, that can lead to > >legitimate clients not getting through at all. > > I'm not sure if that would help. Apparently, both postscreen and smtpd will > use the same nameserver for dnsbl lookup, and if it's cached from previous > postscreen lookup, it will probably give the same result. The negative TTLs on SpamHaus RBL replies are not very long: zen.spamhaus.org. 10 IN SOA need.to.know.only. hostmaster.spamhaus.org. 1912132118 3600 600 432000 10 presently just 10 seconds. -- Viktor.
Re: configuration postscreen
>I would avoid unduly short postscreen cache times, that can lead to >legitimate clients not getting through at all. On Fri, Dec 13, 2019 at 05:40:33PM +0100, Matus UHLAR - fantomas wrote: I'm not sure if that would help. Apparently, both postscreen and smtpd will use the same nameserver for dnsbl lookup, and if it's cached from previous postscreen lookup, it will probably give the same result. On 13.12.19 16:19, Viktor Dukhovni wrote: The negative TTLs on SpamHaus RBL replies are not very long: zen.spamhaus.org. 10 IN SOA need.to.know.only. hostmaster.spamhaus.org. 1912132118 3600 600 432000 10 presently just 10 seconds. the time difference between postscreen blacklist check and smtpd blacklist check should be lower than 10 seconds. yes, with postscreen_dnsbl_min_ttl there's another ~50 seconds where potscreen passes the IP while smtpd would blacklist it. However, I consider postscreen's weighed black/whitelisting more safe than whitelisting/blacklisting at smtpd level maybe unless there's exactly one whitelist and one blacklist used. of course, I'm willing to learn if there's something I have missed -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Your mouse has moved. Windows NT will now restart for changes to take to take effect. [OK]
Re: configuration postscreen
Claus R. Wickinghoff: > So for me it still makes sense to combine postscreen with postgrey, as > postscreen works mainly on ip addresses (their reputation in fact) while > postgrey also takes care on sender's and recipient's e-mail addresses. By design, postscreen does not know the sender or recipient. Wietse
Re: configuration postscreen
Wietse Venema: > Claus R. Wickinghoff: > > So for me it still makes sense to combine postscreen with postgrey, as > > postscreen works mainly on ip addresses (their reputation in fact) while > > postgrey also takes care on sender's and recipient's e-mail addresses. > > By design, postscreen does not know the sender or recipient. In particular, when postscreen allows a remote SMTP client to talk to a Postfix SMTP server process, it must make that decision before the remote SMTP client has sent any commands. Wietse
Re: configuration postscreen
Hi Wietse, So for me it still makes sense to combine postscreen with postgrey, as postscreen works mainly on ip addresses (their reputation in fact) while postgrey also takes care on sender's and recipient's e-mail addresses. By design, postscreen does not know the sender or recipient. In particular, when postscreen allows a remote SMTP client to talk to a Postfix SMTP server process, it must make that decision before the remote SMTP client has sent any commands. Sure. My point was that a combination of both seem to make sense. And I brought an example to show it, similar to the situation that I asked a couple of days ago. I had another similar situation today, when the other server passed postscreen and got greylisted in the beginning and then rejected by postscreen due to blacklist entries. So the dns lifetime in the cache works, too. I'm still impressed how much spam you can get rid off just on smtp level. Groetjes Claus
