El Viernes, 23 de Junio de 2006 13:34, Tony Finch escribió:
> > > Is this possible today? Any chance to get it implemented? Any help to
> > > implement it?
> >
> > Switch off exim's own queue runners, and use an ACL to stick the
> > priorities in a header in the mail (erasing any such that already
> > exists).
>
> You could just use an acl_m* variable, since these are stored in the queue
> files and don't require fiddling with the header.
Those are great clues to implement this multilevel queue management with exim.
> You can almost use exipick to do this, except that it can't sort the
> output in the way you want. But if you only have a couple of priority
> levels then this isn't a problem: just run an exipick for each priority
> level in turn.
Yes... exipick seems the right way to do it. I guess that this method will be
somehow a waste of resources when the queues get full. Listing the queue,
sorting based on the queue level will take a few cpu cicles when queues hold
20.000 messages. Maybe the "right way" to do this is to split the queue in
several directories (one for each priority level) and then work out an
algorithm to run the queue.
It may be worth to try to add this to exim (if the main architects of exim
think that this is an interesting feature). I'll try to work this out if
such interest exists.
> > Is this wise, though? In your scheme low-priority mails could be queued
> > indefinitely behind higher-priority ones, and delayed for an arbitrarily
> > long time, which sounds undesirable.
>
> It may be OK to try delivering the low priority messages at slack times,
> e.g. overnight.
Thats exactly what is planned: low priority mail will be pushed to final
servers overnight, out of business hours, when it doesn't matter if any other
mail gets slowed down.
