Hi Fred.
On 04/01/2026 10:18, Fred Morris via Postfix-users wrote:
I don't see how they can be more brain-damaged than they already are,
they're already looping:
2026-01-02T17:36:15.671360-08:00 flame postfix/smtpd[4447]: connect from
scan.cypex.ai[3.137.73.221]
2026-01-02T17:36:15.672050-08:00 flame postfix/smtpd[4447]: warning:
non-SMTP command from scan.cypex.ai[3.137.73.221]: GET / HTTP/1.1
2026-01-02T17:36:15.672419-08:00 flame postfix/smtpd[4447]: disconnect from
scan.cypex.ai[3.137.73.221] unknown=0/1 commands=0/1
2026-01-02T17:37:34.445451-08:00 flame postfix/smtpd[4447]: connect from
scan.cypex.ai[3.137.73.221]
2026-01-02T17:37:34.446043-08:00 flame postfix/smtpd[4447]: warning:
non-SMTP command from scan.cypex.ai[3.137.73.221]: GET / HTTP/1.1
2026-01-02T17:37:34.446334-08:00 flame postfix/smtpd[4447]: disconnect from
scan.cypex.ai[3.137.73.221] unknown=0/1 commands=0/1
This client is sending non-SMTP commands, so setting "smtpd_delay_reject
= no" will make no difference. i.e. It would only make a difference if
the client was sending HELO/EHLO, MAIL FROM, RCPT TO, etc.
On 04/01/2026 10:38, Wietse Venema via Postfix-users wrote:
Another idea: use a logfile watcher and block the IP address
with a temporary TCP rule.
I agree that the only way to get rid of this type of traffic is with
firewall rules, e.g. Fail2Ban?
Nick.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
