On Fri, 21 Jan 2005, Tore Anderson wrote:
> I'm very surprised I didn't find this on the WishList already, even
> though the FAQ implies that it is an issue raised frequently. So, here
> goes:
I don't think it worth putting an item that is in effect "completely
re-design the way Exim works" on the wish list. :-)
> I'd like to see Exim be able to handle separate queues, without any
> hackery required from the user.
I'm sorry, but it just isn't designed that way. The environment I wrote
Exim for is one in which well over 90% of messages are delivered right
away, and consequently, the queue is short. OK, it's now 10 years later,
and the volumes have gone up enormously, so even 5% is a lot more
messages than it used to be. Also, I never foresaw that people would be
using Exim to handle millions of messages a day.
> For example, spool_directory could just be expanded. Then I could
> just configure it thusly:
>
> .ifdef SPOOL_DIRECTORY
> spool_directory = SPOOL_DIRECTORY
> .else
> spool_directory = ${if def:acl_m0 {$acl_m0}{/var/spool/exim}}
> .endif
That is an interesting idea, but it would involve deciding exactly
when the expansion should take place. Also, it wouldn't work because of
a chicken-and-egg problem. The variable $acl_m0 is stored, for each
message, .... wait for it .... *on the spool* :-( So when an instance
of Exim is started to deliver message X, it has to read X from the spool
before it can find the spool. Hmm. See what I mean about redesign?
> and of course just set $acl_m0 to /var/spool/exim-whatever in one of
> of the ACLs as I saw fit.
But how would you choose a queue? Remember that a message may have
multiple recipients. Or would you restrict such messages to a single
recipient?
> And of course I'd need separate queue
> runners started with -DSPOOL_DIRECTORY=/whatever. Not sure how it'd
> affect immediate deliveries though..
Immediate deliveries are no different from any other deliveries, except
that they start as soon as a message arrives.
> How about it? Is it doable without too much hassle?
I doubt it, but I have been proved wrong in the past when I've said
that. :-)
> PS: If someone has another clever solution to the problem I
> described above, I'd be most interested in hearing about it.
The usual workaround is to shunt off messages that cannot be
delivered quickly onto a "backup queueing host".
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
