On 2025-01-24 16:35, Wietse Venema via Postfix-users wrote:
>
> This perceived problem is already optimized away with caching. On
> my system 93% of connections are from repeat clients.
$ journalctl -t postfix/postscreen | grep -i ']: CONNECT from' | cut -f4 -d':'
| wc -l
13973
$ journalctl -t postfix/postscreen | grep -i ']: CONNECT from' | cut -f4 -d':'
| sort -u | wc -l
5348
$ journalctl -t postfix/postscreen | grep -i ']: CONNECT from' | cut -f4 -d':'
| sort | uniq -c | sort -n | tail | cut -f1 -d'['
41 CONNECT from
42 CONNECT from
44 CONNECT from
49 CONNECT from
52 CONNECT from
55 CONNECT from
59 CONNECT from
99 CONNECT from
206 CONNECT from <- this one sends with ~hourly intervals per dst domain
(I guess)
224 CONNECT from <- seems to be sending in ~10 minutes intervals, in
"working hours" only
However I also have nft logic suppressing spambots even before they reach TCP
port.
Currently I'm setting this up to log positive RBL responses via protobuf to
redis,
which is then used to create appropriate ACL entries on BGP/BNG, so that single
detection on one node imediatelly protects entire network from incoming
connections.
> In case people forget: postscreen does not answer the question "does
> this client send spam?". Instead, it answers the question "is this
> s spambot?". For that, FCRDNS is irrelevant. Reputation is relevant
> for that question, as is behavior, but the deep protocol tests are
> too intrusive if applied to every client.
All true. The issue is "whether we need the answer for this question at all"?
Positive spambot answer tears down the session with 521/550.
The inconclusive FCrDNS returning unknown_client_reject_code, i.e. 450 by
default,
could keep the bots busy if they have the queue in the "worst" case, shielding
our
RBLs.
And if someone usess 5xx for unknown_client_reject_code for policy reasons
(undeliverable should be reported ASAP, not after several days of retries), this
seems to be clear win-win.
Actually the latter case is another "wish", to return 4xx only up to some
defined
time per domain (like 1 hour), and after that switching to 5xx to notify the
sender.
People expect mails to be delivered or bounced right away, not hanging in the
queue
for several days - and we, as a recipient, have no control over sending server
conf.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
