Back when I did a multi-million account mail system, we had eight incoming servers like this. They did some basic milter checks, then accepted the mail to a very fast spool (definitely use SSDs these days) and then were configured to send the queue to the internal systems. At this level of traffic, even the little stuff will make huge speed improvements. Setting the servers to send inward at 20 messages per tcp session saves a bunch of resources to setup and teardown the tcp connections. Tweaking the timeouts on the incoming connections will reduce how many open connections can just sit there, etc.
Fun stuff is indeed coming your way. There is a *ton* of performance tuning that can make a real difference in systems like these, that would never even be worth looking at on small systems with only a few emails per hour. -Steve On May 23, 2013, at 11:55 AM, Gabriel Gunderson wrote: > On Thu, May 23, 2013 at 11:07 AM, Jacob Albretsen <[email protected]> wrote: >> Back in my BYU days, we used a dedicated box for spam filtering. MX records >> for our domains were pointed to this server. Then mail that was not filtered >> was sent on to other servers for respective domains. Each mail server was >> then configured not to accept mail from anyone except the spam filter IP. >> That >> way spammers could not bypass the filter using A records. > > Great feedback, thanks! I'm getting excited about this project :) > > > Gabe /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
