You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "René Cordier (Jira)" <se...@james.apache.org> on 2020/07/08 02:22:00 UTC
[jira] [Commented] (JAMES-3295) Integration tests : SMTP out -
retry back off leveraging MailRepositrories and reprocessing
[ https://issues.apache.org/jira/browse/JAMES-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153181#comment-17153181 ]
René Cordier commented on JAMES-3295:
-------------------------------------
[https://github.com/linagora/james-project/pull/3543] introduced integration tests to demonstrate the issues
> Integration tests : SMTP out - retry back off leveraging MailRepositrories and reprocessing
> -------------------------------------------------------------------------------------------
>
> Key: JAMES-3295
> URL: https://issues.apache.org/jira/browse/JAMES-3295
> Project: James Server
> Issue Type: New Feature
> Components: Queue, rabbitmq, Remote Delivery, tests
> Reporter: Benoit Tellier
> Priority: Major
> Attachments: aca6e77b-c720-42a2-b78e-0e74d77aa424.png
>
>
> *Context*
> Distributed James do not support MailQueue delays making it unusable as a MX server.
> However given a fixed network of suppliers to work with, delays are not an issues, SMTP error just need to be correctly handled.
> retrying without delay could enhance the situation by working around some transient remote server errors. It’s better than not retrying at all (or doing all the retries without delays).
> Given manual intervention, it is possible to correctly
> *Requirements*
> Such a solution should:
> - Attempt delivery a single time
> - Store transient and permanent failure in different mail repository
> - After a given number of tries, transient failures should be considered permanent
> *Definition of done*
> Write potentially failing mailet integration tests demonstrating the above proposed RemoteDelivery error handling.
--
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