[Exim] exim in large-scale production environment

Hi,

Our group is about to go through the process of completely overhauling
our Sendmail based mailhub. We deliver on the order of 190,000 messages
per day, about 50,000 of which are non-local deliveries.

We balance our incoming load over three servers. These servers then
re-distribute mail to 7 POP/IMAP servers for user access. We have one
server dedicated to relay mail to outside hosts.

Our current operation uses Sun servers running Solaris 7 and our
(slightly) modified version of Sendmail (8.9). We are looking to
overhaul our system as our user-base continues to get larger and we are
not impressed with Sendmail's performance, security, and filtering
abilities.

I am part of a team that is investigating alternate MTA solutions. Being
a home-user of Exim for over a year and a strong advocate of Exim as a
replacement for Sendmail, I would like to see Exim become our primary
MTA.

Of course, I have much research ahead of me and will most likely have to
prepare a pilot test; but, I would first like to ask this list for
insight as to the feasibility of this.

It is my understanding that Exim is optimized to be secure, with
flexible, yet simple configuration. There is a clause in the
documentation that reports that Exim has been used in a production
environment of ~100,000 deliveries per day. However, not many details
were given.

Does anyone have any knowledge of Exim being used for such a high-volume
mail system? Is Exim optimized for speed at all?

Another team is investigating the possibility of switching to another
platform (most likely Intel/BSD or Intel/Linux). Is there information
available about Exim's performance across various platforms?

We would most likely modify Exim as we did Sendmail to suit our
authentication procedures and to optimize for speed where possible. If
our team's proposal is accepted, we would be more than willing to
contribute any speed optimizations back to the Exim project.

Any insight or relevant information would be appreciated.

Thank you,
J.R. Van Valen