dovecot - Jun 2020 - handling spam from gmail.

Am 11.06.2020 um 19:15 schrieb Ralph Seichter:
> Generating backscatter is definitely not a good move, and it is even
> prone to punish yourself. Better to reject the offending message with
> a 5xx status code and some explanatory text or the URL.
> 
> The various tests required to come to a decision about accepting or
> rejecting the message can be executed in a milter. Milter-regex, for
> example, is lightweight but still powerful enough to perform tests on
> combinations of various headers and the body content. Beyond that, a
> custom milter is always an option.
...and the body content...

There exists one problem: at this stage of mail reception you have no 
body content nor header information on which a milter may perform deeper 
analysis, only envelope data. The SMTP specs itself allow failure codes 
after any command, even a 5xx after the DATA command. Hoever, many MTAs 
still ignore error response codes after DATA and take the mail as sent, 
so that most mail servers will perform any error indication before DATA, 
at latest after RCPT TO. So the server has to accept mail first before 
it can scan its header and/or body, and would send out DSNs on rejection 
at this stage, probably causing backscatter as well.

I don't understand why this problem of ignoring data response codes even 
exists. It would be so much more practible to reject spam immediately 
after the body was scanned, i.e. after the DATA command, than to send 
out these DSNs.

Or does this issue no longer exist these days?

/andreas

* Andreas Born:
> There exists one problem: at this stage of mail reception you have no
> body content nor header information on which a milter may perform
> deeper analysis, only envelope data.
I am not sure what you mean by "this stage of mail reception", or what
software you are using that may be limited in such a particular manner,
but generally speaking you are wrong.

For example: Postfix supports both before-queue filters and after-queue
filters. Milter-regex[1] supports both multi-header and body checks. The
milter protocol itself allows for both header and body manipulation.

[1] http://www.benzedrine.ch/milter-regex.html

-Ralph

Am 12.06.2020 um 02:03 schrieb Ralph Seichter:
> * Andreas Born:
> 
>> There exists one problem: at this stage of mail reception you have no
>> body content nor header information on which a milter may perform
>> deeper analysis, only envelope data.
> 
> I am not sure what you mean by "this stage of mail reception", or
what
I meant the different stages when receiving mails over SMTP:
(very short and incomplete,  I know):

1. MTA is connecting via SMTP, TLS, etc.
2. Identification (EHLO), Authentication, Protocol Extensions etc.
3. MTA send envelope information (MAIL TO, RCPT TO)
4. MTA sends message header and body (DATA, .)
5. Connection close (QUIT) or repeat from 3. for another mail
6. enqueuing mail(s)
7. Local Delivery

I was referring to what you wrote with:

 >>> "Better to reject the offending message with a 5xx status
code [...]"

You surely refer to the 5xx status codes from SMTP, and to reject the 
mail while receiving it via SMTP, instead of sending a DSN later on? So 
the sender knows that the mail was not accepted, and that it MUST NOT 
try to resend the mail again (as with 4xx status codes).

You further write:

 > 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)

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.


/andreas