handling spam from gmail.

[Michael Peddemors]

+1, and while you SHOULD try to block before DATA when you can, to 
reduce loads on servers, and not tie up the SMTP connections any longer 
than you need, for rules bases on content, it is perfectly well to send 
a 5XX after data, and while there may be still some 'broken' MTA's and 
clients that don't properly wait for the response code after DATA, that 
isn't your problem..

The only complexity comes from when multiple recipients have different 
policies for acceptance based on DATA content.  Which is why many 
systems still do content filtering AFTER acceptance.

There ARE ways to address it in-stream, and there ARE now methods to 
return a variable acceptance after DATA, and there are resource 
intensive DATA handlers that are best used out of band (eg, after 
acceptance) but in general, the more you can stop inband, the better it 
is and less potential back scatter.

But yeah.. this thread doesn't really belong on the dovecot list, so 
'nuff said ;)

On 2020-06-11 7:43 p.m., Adi Pircalabu wrote:
> 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.



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.