Your mailserver can get jammed before you have time to react, if a dedicated spambot injection is kicking off hard on a connected webserver This leaves exim etc incapable of responding usefully, if at all.
We got stuck in this situation at an ISP+MgdSvcs company a few years ago. No response from anything but shell built-ins or nearly-so primitives, and even THEY were sluggish (!). (Unix, to be clear.) We went from fine to fkd in less than 60secs from the alarm, terabytes tempdir jammed while we were trying to work out what was happening.
Finally decided to risk wiping some client emails and just wipe enough of recent tempdir to allow server load to drop enough for us to get some control.
Problem: rm crashed. Too many files.
Problem: even piping ls -t to it crashed for the same reason.
Solution: take advantage of oldskool lowlevel unix shell design intelligence of a pipe being a parent, which closes all its children as soon as the terminal process throws an exit value. Combined with intrapipe interprocess streaming, ie character by character. So despite ls still running like a loony, it's not hitting capacity limits because it's just vomiting what it reads, and as soon as head hits its parameter (streaming-from-0 rather than read-all-and-count-back like tail), it terminates, so pipe terminates, so pipe terminates all children --> shell can continue.
FILELIST=`ls -t | head -1000`
rm -f $FILELIST
ls|wc on another terminal showed the numbers dropping. Race Condition, and we were winning.
4-5hrs later we regained control, sorted it.
We'd contacted clients to warn them. As luck would have it (it was right on Close-Of-Business), no-one had to resend anything.
Yee. Haw. And. Phew.
Stern words the next day with the culprit website owner company, then their devs.