> > 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".
This is our first router
begin routers
# This router passes any mail older than 24 hours to slowcoach in order
# to keep queues down on frontline servers
too_old:
driver = manualroute
condition = ${if > {$message_age}{86400}{yes}{no}}
transport = remote_smtp
route_list = * slowcoach.lut.ac.uk
So we keep our outgoing email server clear of old undeliverable guff by
moving it to lower spec machine called slowcoach. Then if it has still
not been delivered after 8 days it times out.
Is this the sort of thing you were trying to do ?
Ron
On Fri, 2005-01-21 at 10:36 +0000, Philip Hazel wrote:
> 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
>
