[jira] [Commented] (JAMES-2896) RabbitMQ MailQueue should support delays

["Sam (Jira)" <se...@james.apache.org>]

    [ https://issues.apache.org/jira/browse/JAMES-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17321390#comment-17321390 ] 

Sam commented on JAMES-2896:
----------------------------

maybe, with RabbitMQ this could be implemented using combination of message [TTL function|https://www.rabbitmq.com/ttl.html] and the [dead-lettering function|https://www.rabbitmq.com/dlx.html] like https://www.sysorchestra.com/delay-processing-in-rabbit-with-dead-letter-exchanges/

> RabbitMQ MailQueue should support delays
> ----------------------------------------
>
>                 Key: JAMES-2896
>                 URL: https://issues.apache.org/jira/browse/JAMES-2896
>             Project: James Server
>          Issue Type: Improvement
>          Components: Queue, rabbitmq
>            Reporter: Benoit Tellier
>            Priority: Major
>              Labels: feature
>
> 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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org