On Tue, 3 Sep 2002, Joerg Sommer wrote:
> > Personally, I think "a good solution" is "accept all this mail, stick it
> > on your queue" so that the rsmtp command runs as quickly as possible.
> > You can do this with -odq or by using queue_only_file (as was pointed
> > out).
>
> Yes, this is one solution. Another, IMHO better for batches, would be, if
> rsmtp put all messages in a queue and if the end of the batch is reached,
> it starts a queue runner.
Well, you can write your own script that does that. If you run Exim as
"rsmtp" it is just the same as "exim -bS". All that says is "here are
messages in BSMTP format". It doesn't say anything about delivery. So
the default is to do its usual thing, which is to try to deliver each
message as soon as it has it.
> The top solution is, rsmtp puts every mail in the queue and starts a queue
> runner, if there aren't more then queue_run_max. If a queue runner
> delivers his mails, he looks if there are new mail arrived. If not it
> quits.
You can write a script that does that, as long as you have some private
mechanism for counting the number of queue runners.
> The point at the default behaviour, that distrub me, is that there more
> then queue_run_max processes started for delivering a batch.
The ONLY use of queue_run_max is to limit the number of queue runners
*started by the daemon*. If you start queue runners by other means, you
have to use your own mechanism for limiting their number.
As I said before, Exim was not designed for uucp and batches. So while
you can probably coerce it into doing what you want, it isn't the
default behaviour, and it isn't always very neat.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
