Am 12.06.2020 um 04:43 schrieb Ralph Seichter:
- Andreas Born:
I meant the different stages when receiving mails over SMTP [...]
I am well aware of the technical details of SMTP. Your comment is unclear to me because the OP did not make any limitations on when he wants to counter spam, so why would we artificially limit ourselves in this discussion?
THe OP wanted to send an additional mail back to possible unwanted senders. That's even worse than a DSN in my opinion. You suggested to reject mail directly during the smtp process.
Full ack!
I just talked about problems that existed in the past, that caused additional problems when trying to reject a mail after the SMTP DATA command. So my response was not about any limitation denoted by the OP, but about your suggestion that a prequeue-milter can even scan mail header and body as well before "hard rejecting" the mail.
This had some conflicts in earlier times, but it turnes out, that this problem is out-dated and no more existent.
SMTP allows rejecting messages even after the whole body has been received (end of DATA phase in SMTP, EOM phase in the milter protocol).
Yes. And it always has been. But i knew that this was not always respected by MTAs, even by some large email providers I had contact to.
for many years it was code of practice to send error/rejection codes latest after the RCPT TO command [...]
Can you name examples?
postfix.org itself had some information in its postconf section. There ist still an information about smtpd_relay_reject, that some clients mis-behave on error codes before RCTP TO (the other way around), and in the past there (somewhere) has been an info about issues sending them after DATA, too, because of mis-behaving clients. That was discussed in many postfix-setup-tutorials also. Reject on RCPT TO.
But okay, many years ago. I thought few thing don't change, some others do. But i never heard that this issue was ever solved.
So my fault. Friends? ;-)
I have never used a milter so restricted, nor have I seen one being used.
Might be. But default configurations and most old tutorials have no smtpd_data_restrictions set up. And smtpd_data_end_restrictions did not even exist last time I changed my config. :)
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)
Again I am stumped by what you write. SMTP rejection does not generate backscatter.
Indeed; not, when Client (MTA) and Server (MX) behave correctly. But some MTAs did not. Maybe they do NOW, so everything is fine.
Mis-Behaving MTAs did generate DSNs on rejections after DATA, they sent it (under special circumstances like forwarding mails or multiple recipients) to their forged envelope-sender, so this is backscatter in my opinion. But they should not, because the mail was immediately rejected.
Other mail-providers did not respect these recjections as permanent as they should do, because they didn't really evaluate error responses after DATA, the treated it as underlying transmission Problem, therefore trying to resend...
And other providers did never generate an info to the user, that their mail did not arrive. A legal problem, when the recipient was a corporation and the mail a false positive etc..
Frankly, I see no use in discussing broken MTAs or milters, real or imagined. Using milter-regex and other milters with Postfix works fine as I described it. What you wrote therefore makes little sense to me.
I agree, there is really no use in discussing broken Software; at least as long, as the resulting problems do not restrict/limit your configuration possibilities or otherwise causing additional Spam, e.g.
It was not about broken Milters, not at all. It was about broken MTAs. And about correctly working MX-Server like postfix, which had to be configured in such a way, that different problems were circumvented. Like broken MTAs generating spam because of your MX Server behaving correctly by sending 5xx after DATA. You can do anything right, and at the same time a bad client can make things bad.
These problems really existed in the past, and I apologize if i'm completed out-of-date regarding these issues.
/ Andreas