Steffen Nurpmeso wrote in <20210609165007.rc_ih%stef...@sdaoden.eu>: ... ||> Jun 9 01:38:06 postfix/smtpd[17007]: B713116056: client=unknown[45.13\ ||> 7\ ||> .22.84] | ... ||> status=sent (delivered to mailbox) || ||Postfix delivers an email message with message-id ||<20210608163805.e242f6fe5d7ac...@sdaoden.eu> to mailbox. | |But how can it if the client is unknown, that should normally |result in NOQUEUE? ... |Ok, i see .. it is because of RCPT is someone known. But how can |i enforce .. i had reject_unverified_sender but i removed that |again. Hm. I will add reject_unknown_client_hostname to the |smtpd_client_restrictions! | |For postfix the reject_unknown_helo_hostname .. it can simply skip |sending HELO/EHLO! Hmm, i see. So anyhow connection |address/hostname, helo/ehlo address/hostname, that is all |distinct. Ok, then yes, this is solely my fault.[.]
So just to get this straight. What this spam does is that it uses a valid hostname that does not belong to the actual network connection during EHLO, so smtpd_helo_restrictions do not come into play, and it sends something to a valid recipient (me), so relay etc restrictions do not, too. I will add reject_unknown_client_hostname to smtpd_client_restrictions, which hopefully avoids this particular problem. Astounding how many individual pieces aka DNS entries come together just for such a small preamble! I have never considered HELO being simply bypassed, too! Thanks for postfix, and Ciao from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
