This is the idea behind Qrschedule.

qmail-send schedules mail for delivery. It reads /vqr/qmail/queue/remote/* and decides which
remote deliveries will be taken. This is necessary so qmail-send can track the number of
outgoing connections. When qmail-send decided that a specific delivery will be taken it
notifies qmail-rspawn of this which itself forks a qmail-remote process that delivers the mail.

This split of work keeps qmail-send away from all network activities while it allows it to
limit the number of outgoing connections.

I don't say that the idea is bad. I only see that the way it is done is not the best possible
way. In fact it is the most simple and most inefficient way mails can be delivered. SMTP
allows delivery of one mail to multiple recipients in one connection. qmail sends one mail to
one recipient. When you send out a mail to 100 recipients qmail will do 100 single deliveries.
If the mail has a 10 MB attachment you have created 1 GB of mail traffic instead of 10 MB as it
could be.

The reason behind this was it made deliveries simple and stable. But things have changed. Email
is of much more importance this days. Even the stupid salesdroids are able to (ab)use mail
clients these days. And they really tend to send around mail with large attachments to many
recipients (I only say "Powerpoint"). On the other hand faster and cheaper internet connections
are available today. This also lets people send more and bigger mails. On the other hand it does
not mean that you don't have to pay for your traffic.

This brings me to the point where I think it's time to do it a other and hopefully better way.

My point is to keep the idea and change the implementation. qmail-send will see that a mail
needs service. It forks Qrschedule with the message to deliver. Qschedule first sorts the
recipients by domain. Then it does MX lookups. Since the recipients are sorted by domain it
will lookup every domain only once. After this step it sorts all MX entries and finds all
duplicates. These duplicates are also put together. These sorting also handles MX priority
mismatches: host a with priority 10 and b with priority 15 is considered identical to a(1)
and b(42) but not to a(2) and b(1).

Qschedule handles the file in remote/ completely alone once it is triggered. Currently I have
no idea how bounce creation will be done.

The tracking of the number of used remote slots will still be handled by qmail-send. Before it
starts Qschedule qmail-send will set up a pipe for communication between the two processes.
Once it has started Qremote computes the number of possible remote deliveries. It tells
qmail-send the number which decides if enough slots are free. It then tells Qschedule the
number of slots it may use. If this number is smaller than the requested Qschedule will delay
some of the remote connections. If slots will not be used again it also notifies qmail-send of
this so they can be reused by other processes.