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 "Benoit Tellier (Jira)" <se...@james.apache.org> on 2020/07/06 11:21:00 UTC
[jira] [Updated] (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:all-tabpanel ]
Benoit Tellier updated JAMES-3295:
----------------------------------
Description:
*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.
was:
*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.
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.
> 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