First thing first, this isn't necessary a Dovecot related thread and using a challenge-response system like the one suggested by the initiator ("click here if you're not yet another bloody SEO guru") is plain wrong for several reasons, having said that:
On 12-06-2020 11:56, Andreas Born wrote:
Am 12.06.2020 um 02:03 schrieb Ralph Seichter:
- Andreas Born: [...] For example: Postfix supports both before-queue filters and after-queue filters. Milter-regex[1] supports both multi-header and body checks.
Of course, and there is nothing wrong with it. It just runs into the issue I tried to describe: incomplete SMTP implementations from MTAs.
Pre-queue filtering happens, before the mail was accepted to be queued. So a before-queue milter can trigger an 5xx status code to reject the mail. This code can be sent in response to steps 2, 3 or 4. According to the smtp specs. But for many years it was code of practice to send error/rejection codes latest after the RCPT TO command, and at this time the milter, independent of what software you use, has no information about email header or content. Rejecting a mail AFTER the DATA command (when the content becomes available) was discouraged because of incorrect behaving MTAs. (e.g. generating backscatter, or even treating the mail as successfully sent)
$ telnet server 25 Trying x.x.x.x... Connected to server Escape character is '^]'. 220-server ESMTP Postfix <=== Postscreen trap here ;) 220 server ESMTP Postfix HELO client.domain.com 250 server MAIL FROM:<> 250 2.1.0 Ok RCPT TO:<victim@domain.com> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> From: Me To: You Subject: Test
SA GTube string here . 550 5.7.1 Blocked, see you later. QUIT 221 2.0.0 Bye Connection closed by foreign host.
In this case the rejection comes after DATA, a content filter should be able to return either 4xx or 5xx *after* swallowing the entire email.
Maybe, and I really hope so, this problem no longer exists. I will immediately reconfigure my mail system, if rejecting mails after DATA will be safe and reliable nowadays.
Rejecting or deferring after DATA is perfectly fine these days. If the sending MTA, acting as a client in the SMTP conversation, doesn't behave properly to 5xx after DATA, it's not the recipient's MTA problem, the sender is broken and there's nothing the receiving MTA can do about it. Make it their problem, not yours.
-- Adi Pircalabu