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:<vic...@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
