Major Description
MX (mail exchange) servers do rely on delays for some things like spam and abuse detection thus this is a critical capability for a mail queue component of a server aiming at being used as an MX.
So far, RabbitMQ mail queue does not support delays. Its usage is then discouraged within an MX server (though it is perfectly suited for an MDA).
We can relatively easily implement delays within the RabbitMQ mail queue:
- When a delay is specified, we save the message in the object storage,
fire a message on a *MailQueueDelayExchange*, and persist it on the
MailQueueView. - Each James listens on a single Queue plugged to the
*MailQueueDelayExchange*. - For each incoming message, the receiver will position a timer until
the planned delivery (date). - Upon timer completion, we ack the message of MailQueueDelayExchange,
then we put the corresponding message in the mail RabbitMQMailQueue (no
need to update the mailQueueView nor store again the blob). - Upon connection loss, the message will be nacked and will be then
handled by another s/consumer/jamesServer/.
Obviously:
- We need synchronized clocks "best-effort" - think NTP
- This solution can duplicate emails upon connection loss - a local
James needs to invalidate the entries he is waiting for upon connection loss. - *flush* needs to be broadcasted so that all James servers can release the retained delayed emails into the mail queue.