On Tue, Apr 26, 2022 at 11:54:21PM +0900, Byung-Hee HWANG wrote:
> > There is obviously a point where the server won't be capable of
> > handling the load, always. But what are the odds with "just" a
> > brute-force on passwords/accounts?
> > Our outbound/internal mail gateway handles the traffic for +2K
> > every-day users +28K occasional users. Millions emails per month. It
> > handles also emails sent by applications. One of these app had a
> > problem last October and tried to send +2M emails per day, for many
> > days: the app authenticated on the mail server (sasl/dovecot) tried to
> > send the mail, got bounced because recipient was non-valid, got
> > disconnected, re-connected and tried again with next recipient, etc.
> > Nobody noticed, no user complained, no performance impact at all. We
> > only find out because of the postfix log volume increase.
> > It's a virtual machine with 4 vcpu and 10GB RAM (most ram is used by
> > antispam), it can handle way more: it runs postfix multi, does
> > antispam/av filtering and dkim singing for outbound, handles mailing
> > lists peaks of +60K messages, etc.
>
> Wow amazing story! Your email volume/traffic is a thousand times bigger than
> mine!
Not surprising, when over a decade ago I set the Postfix servers for the
Google IPO, each individual server (spinning rust not SSD) was capable
of sustaining ~200 msgs/sec, which would be ~17M msgs/day if there were
enough messages.
In the meantime the corporate mail servers were handling 2M messages/day
for ~80k users, for redundancy 4 nodes 2 each at 2 sites, any one would
have handled all the load. The main limiting factor was the CPU cost
of content inspection, "normal" mail processing easily scaled to
~300/sec, but dropped to ~30/sec with content inspection.
With SSD storage and modern CPUs, the peak performance of a Postfix
server would be a few times higher.
--
Viktor.
