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'd like to see Exim be able to handle separate queues, without any
hackery required from the user. I know it is possible by using two
Exim's with different configuration files (or by using .ifdef magic
surrounding spool_directory plus some), however, this makes the
messages in question be delivered twice, which is a performance killer.
I/O performance (esp. latency) to the spool directory is in my
experience -the- limiting factor as to how well Exim can perform.
One use case where I want this would be in a few Exim clusters owned
by some major mobile operators in Norway, which relay MMS messages
between most operators in Scandinavia and a few somewhere else. I'd
very much be able to have one separate queue per peering operator.
Why? Because if /one/ of the majors peers have troubles accepting, the
queue fills with deferred messages to that operator, which ends up
affecting traffic to all other peers as well. And because of the high
volume passing trough the system, using hacks as mentioned above would
affect overall performance too much.
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
and of course just set $acl_m0 to /var/spool/exim-whatever in one of
of the ACLs as I saw fit. And of course I'd need separate queue
runners started with -DSPOOL_DIRECTORY=/whatever. Not sure how it'd
affect immediate deliveries though..
How about it? Is it doable without too much hassle?
PS: If someone has another clever solution to the problem I
described above, I'd be most interested in hearing about it.
PPS: Looking forward to see you all in Birmingham in February! :-)
Kind regards,
--
Tore Anderson
