handling spam from gmail.
Andreas Born
dovecot at abotech.de
Fri Jun 12 08:59:18 EEST 2020
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
More information about the dovecot
mailing list