Way too aggressive for now in the world of Tarako and servers that cap connection counts and get suspicious of spammer-like activity.  I don't expect TCP slow start to be our dominant problem here.  But mainly the concern would be limited memory devices and this heuristic resulting in potentially eternal breakage of the email app unless we make sure to increment a give-up counter on the message and commit it before we start the send process.

Abstractly, I think it'd be okay to use a connection-pool type implementation for this and set the maximum connections to 1 initially.  But opposed to that, right now my brain is thinking that maybe this job should be more of a self rescheduling job given the realities of our job implementation.  Specifically, if we have 8 messages queued up, it would be nicer for the responsiveness of everything else we do if we let other jobs run in between those 8 messages.

The big question is how we'll eventually overhaul the job stuff between killing mutexes and what not.  Since you are very likely to be doing a lot of work in that area, I'm interested in your thoughts on that.  I will sleep on this a little.