On Fri, Jan 28, 2022 at 09:41:40AM +0100, Matus UHLAR - fantomas wrote:
> the delay is not a problem for remote servers, they can wait a few minutes
> without problems (rfc 5321 section 4.5.3.2.6. explains that the DATA timeout
> should be 10 minutes)
Sure, but there's no Internet police, and a bunch of legitimate senders
may time out sooner. Or the filter might under load take more than 10
minutes. Scanning concurrent messages via milters can't be deferred
till later, the CPU load is driven by the number of concurrent SMTP
connections.
> since the antispam/antiviru filter needs to process the mail before it's
> delivered, the delay should be no different than with after-queue content
> filter.
This is wrong. With post-queue filtering, messages are queued and
scanned in an orderly manner subject to the configured destination
concurrency limit on the content filter transport. If there's a burst
of inbound traffic, the CPU cost be spread out over however long it
takes to scan all the queued mail at a reasonable concurrency.
Post-queue filtering degrades better in the face of transient load
spikes.
--
Viktor.
