TipJar::MTA appears to run on one machine and replace qmail. It handles temporary delivery failures by exponential retry delay. I'm not sure I need to replace qmail-inject and qmail-queue for a non clustering situation. Maybe you'd like an all-perl system? I haven't noticed any problem with qmail's retry schedule. As far as breaking out TipJar::MTA::queue, we don't need to interact about headers, we're done, queue it. I don't think so.
IPC::DirQueue enables clustering by queueing the actual message files and/or queue administration protocol files (means of dialog with other server nodes) on nfs. Its set up to do FIFO queuing, no delays between retries and keep retrying continuously, but there is a touch_active_lock() call that enables a thread to hold on to its lock indefinitely. That means a thread can do its own exponential retry delay. The data file could contain the path to the real message file(see plugin http://perlq.org/user_maildir.html http://perlq.org/user_maildir.bz2 for the path). IPC::DirQueue seems like the shortest route to clustering. That would be clustering mysql, dspam, cyrus murder, the qpsmtpd frontend, and qmail coincidentally with the qpsmtpd machines. Writing the messages to disk on the qpsmtpd machines would mean not losing any mail. lmtp could be attempted with different backend machines before writing message to disk on fail. The disk-based nfs queue system would mainly be used during startup and shutdown of the various machines. qmail has its own disk caching for messages bound for external addresses. -Bob
