https://www.postfix.org/SMTPD_ACCESS_README.html#timing
In particular this:
"Some SMTP clients do not expect a negative reply early in the SMTP
session. When the bad news is postponed until the RCPT TO reply, the
client goes away as it is supposed to, instead of hanging around
until a timeout happens, or worse, going into an endless
connect-reject-connect loop."
What does current experience with this in the field look like? Is
anybody out there running with "smtpd_delay_reject = no" and can speak
to this? I want to make cypex.ai go away. They're coming out of Amazon's
space (for the most part I block the ability of things within Amazon to
make outbound TCP connections to my infra, but I make some allowances
for well-behaved MTAs). At least they go to the trouble to set up
reverse DNS (PTRs), I wish more people did. Since they're not following
the happy path to RCPT TO I'm not certain whether I need to turn
smtpd_delay_reject off or not, but I certainly will find out the hard way.
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
Thank you...
--
Fred Morris, internet plumber
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
