+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.