On Sun, 22 Oct 2006, Peter Bowyer wrote:
> Philip often states that Exim's delivery model was designed for an
> always-connected situation where most of the mail is deliverable on
> the first attempt.
Indeed I do. Thank you for saving me the trouble of saying it again. :-)
> There was certainly no concept of business-as-usual deliberate
> deferral (of which greylisting is an example) around then.
In 1995, in our environment (which of course is what I was designing
for), that was certainly the case. We still deliver most messages at the
first attempt, but because of the huge increase in volume, the small
percentage that get deferred is nowadays quite a large absolute number.
> It's not trivial to tune Exim's retry mechanism to optimize delivery
> under greylisting I guess.
One feature of Exim that helps is that, if the remote host has more than
one IP address, Exim will try another one if there is a temporary error
on the first one. So a greylisted message shouldn't be delayed too much.
And as it was a per-recipient defer, it should not affect other
addresses that are routed to the same host.
> > Speaking accross the board, is it true that Exim has bad (it need more
> > resources) queue handling? For Exim on the sender site, is greylisting a
> > problem?
>
> Resources in what sense?
What is bad when the mail queue is very large is that it takes a long
time to scan it. Using split_spool_directory helps, because Exim then
scans it a bit at a time. (The messages in the spool directory *are* the
queue; there is no separate message list. Thus, to scan the queue, the
directory has to be scanned - and if information about messages is
needed, the -H file for each message has to be read.)
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
