Re: [exim] Small modification for queue runners?

> Suppose an email is addressed to two recipients, A and B, on different
> mail servers. When Exim has delivered to A, it notices that there is
> another email that previously could not get through to A. So it forks a
> new process and hands over the connection to it. Now it goes on and
> delivers to B. Waiting for the B delivery to happen is a bad idea,
> because you are holding the SMTP connection to A open. And anyway, there
> may also be C and D and E...

Now I got it. How about putting that somewhere in the code as comment? :)

If a message has many recipients, it may start a bunch of deliveries.
Typical newsletters without VERP thus avoid the otherwise controlled
parallelism after a failure like too high local load, possibly resulting
in a new load peak.

Would anybody object if the choice were only a) to delay delivery of
B until all messages were transmitted to the host for A or b) never to
send messages down the same channel?

Neither would need a pipe, thus making multiple deliveries from one
queue runner very easy.

That sounds like I wanted to avoid using a semaphore for the number of
concurrent deliveries. Given the portability of semaphores and shared
memory in the existing Unix world, I do, because Exim currently runs on
a bunch of odd systems.

> > If you reduce the retry time for a host or domain, existing messages
> > will not be delivered, because it does not change the existing
> > earliest retry times.
>
> But that is true already. If you reduce the retry time for a host, it
> does not affect the existing hints data, which includes the next time to
> try that host.

Yes, but it's just one host, so using fixdb to change its record causes
delivery of all messages.

Michael