Eugene Podshivalov:
> Is it by chance possible that tcp wrappers will be supported in future at
> least as an optionally compiled feature?
If you must, you can run "/usr/sbin/sendmail -bs" as user "postfix"
under TCP Wrappers from inetd.
I prefer to spend my limited development cycles on things that
benefit more people.
Wietse
> ??, 8 ????. 2021 ?. ? 23:00, Eugene Podshivalov <yauge...@gmail.com>:
>
> > Thanks, Noel! Your comments are helpful indeed.
> >
> > ??, 8 ????. 2021 ?. ? 22:37, Noel Jones <njo...@megan.vbhcs.org>:
> >
> >>
> >> 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
> >>
> >
