> On Dec 18, 2018, at 6:48 PM, Alex <mysqlstud...@gmail.com> wrote:
>
> The problem is that this is a domain with thousands of recipients, and
> mailchimp and others send mass newsletters to thousands of those
> recipients at once to our relyhosts, which first scan the emails for
> spam/viruses and only then forward on. This causes somewhat of a
> significant delay at times as the server processes all the emails.
>
> I recall reading that more recently people are configuring their mail
> systems to scan the email as it's received without queuing it, and I
> assume reject temporarily any mail that can't be processed at the time
> it's received?
So you have a CPU-limited throughput cap that is currently post-queue,
so that mail can arrive faster than it can be scanned.
Throughput = concurrency / latency, and the problem is that the
input stage has low latency, and can accept mail quickly, but
at the same concurrency, the filter stage has higher (CPU-bound)
latency, and noticeably lower throughput.
The solution is perhaps in part to throw some more CPU at the
problem, but alternatively, assuming that mailchimp et. al.
are not abusing reasonable concurrency limits, you can reduce
the impedance mismatch by increasing the input latency, by
doing the A/V scan "on-line' via a milter.
This does carry a greater risk of overall DoS (all your
SMTP servers busy competing for limited CPU), but by
reducing the throughput per concurrent connection, and
assuming no attack, a combination of some more CPU,
and pre-queue A/V scanning might do the job.
You could attempt per-client message rate limits, or
slightly lower per-client concurrency limits, but these
can backfire if set too low, by just deferring ever more
traffic if you make the pipe too narrow.
And of course, if possible, encourage your users to subscribe
to less junk mail.
--
Viktor.
