著者: Michael Haardt 日付: To: exim-users 題目: Re: [exim] High Perf server - was (exim allowed someone to slam my
mailserver for 3 hours)
> If you are going for serious throughput optimisation then exim is > probably the wrong place to start - in many cases the vast majority of
> messages could be switched through a box without touching the disk at
> all (you would hold off acknowledging the incoming message until the
> next hop had acked your onward transmission of it).
And queue the message, in case it does not, or if it is too large, or...
Is there any free MTA working that way, which is additionally as nice
to configure as Exim? :-) If so, it can not have been fun to write it.
Exim queues first to be safe. The faster the queue, the better this
decision is. I think the code is easier to understand and get right
that way. AFAIK, all free MTAs went that road so far, but only their
authors can tell why for sure.
Seriously, if queueing would be twice or three times as fast, CPU
time would become an issue. I did not yet measure if optionally
storing messages in wireformat would help to reduce that. Right now,
Exim stores messages witout CRLF and not dot stuffed. That's great for
local delivery, but not for remote. News systems usually use wireformat,
that's why I wonder about it. But it is not an issue right now.
