On Fri, Jan 21, 2005 at 02:14:41PM +0000, Philip Hazel wrote:
> > There are two times when you need to know the spool directory: when
> > writing the message as it is received, which Exim starts to do after the
> > message header has arrived; and when reading the message to attempt
> > delivery.
If the number of peers is small, and they're usually on-line, another
approach would be to have a separate instance of Exim running for each
peer. Each Exim would have its own configuration file, spool_directory
and monitor its own local_interface and port. If the "main" Exim was
unable to deliver to a peer, it would fall though to a router that would
pass the message to an auxillary Exim over the local_interface. That will
get those messages out of the main Exim spool. These auxillary Exim's
can either wait for an ETRN or attempt to run the queue at infrequent
intervals.
> That is only if you are thinking about a message. The spool directory
> contains stuff other than the queue. For instance, the callout hints.
> Those are needed at ACL time.
But they're only hints and aren't required. If a main Exim handled all
input, would it be much overhead to have separate .db files for the
auxillary Exims?
> It's plausible, but I think thought would have to be applied to the
> other cases, such as manual prodding of a message. If you want to
> "deliver 1Crkvw-00017U-5M" say, are you going to require the sysadmin to
> have to find out where that particular message is stored? Personally, I
exim4 -C /etc/exim4/configuration.peer1 -M 1Crkvw-00017U-5M
> don't think I'd like to release a system of that type. However, I guess
> in the case where we are just talking about varying "input", Exim could
> search all of them, as it does for split_spool_directory.
Each peer would have its own instance of Exim, a separate spool_directory,
and all queued messages would be destined for that peer.
> Bottom line: Before doing anything along these lines, I would need to
> think a lot more, read the code a lot more, make some proposals, and
> think through their consequences.
Having separate instances of Exim serving each peer seems doable without
coding changes. I don't believe the overhead of the separate spool
directories would amount to much. There is the overhead of passing
messages from one Exim to another over the local_interface, but if the
peers are usually available, and this is just a backup scheme to keep
from cluttering up the main Exim spool_directory, I think it would work.
Steve
----------------------------------------------------------------------
Steven A. Reisman <sar@???> P.O. Box 409
Press Enter LLP 421 N 2nd Street
715-426-2100 or 651-436-5254 River Falls, WI 54022
----------------------------------------------------------------------
