handling spam from gmail.

[Andreas Born]

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