On 2/8/2021 11:45 AM, Eugene Podshivalov wrote:
Thanks for the explanation, Wietse.
Probably the issue is just with the logging levels.
My current configuration already has
smtpd_client_restrictions=reject_unknown_client_hostname
and the log file is flooded with message like this
connect from unknown[ x.x.x.x]
NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25
Client host rejected: cannot find your hostname
That's a 450 temporary reject, so if it's a (semi-)legit mail server
it will likely try again and again. Bots tend to not come back.
Try changing unknown_client_reject_code=550 to signal a permanent
reject.
Also note that reject_unknown_client_hostname is a very strict test
and is known to reject some legit mail from slightly misconfigured
hosts, sometimes even major providers will fail this test. I'm not
telling you to not use this setting, but be aware that it will
eventually reject something you want.
It's safer to use reject_unknown_reverse_client_hostname.
which makes it hard to analyse.
I fail to see how that makes analysis any harder. If your logs are
for more than a trivial amount of mail use "grep" to find the
interesting bits, and "less" to view. The "interesting bits" will
vary depending on what you're investigating.
Or use a log summary tool such as pflogsumm or one of the others
listed at http://www.postfix.org/addon.html#logfile
Make sure you don't have debug logs turned on, with a -D flag in
master.cf, or debug_peer_list, or [smtp|smtpd]_tls_loglevel greater
than 1 in main.cf.
For comparison, the postscreen_*_action params let you `enforce`
reject a delivery attempt and log it, or just 'drop' the connection
silently.
postscreen's drop action _does_not_ eliminate logging. The
connect/drop/disconnect is always logged. Drop does eliminate
logging of the sender and recipient, which is often useful.
I respectfully suggest you don't waste your valuable time trying to
eliminate logging. Postfix logs what is necessary in order to trace
where mail came from and what happened to it.
If you want to get rid of the logging (not recommended) use a log
filter such as rsyslogd or block the client IP in your firewall, or
use fail2ban to automatically block clients that make too many errors.
-- Noel Jones
