[
https://issues.apache.org/jira/browse/JAMES-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3588.
---------------------------------
Resolution: Fixed
https://github.com/apache/james-project/pull/443 fixed this.
> LMTP + MailetContainer: Propagate errors back to the LMTP client
> ----------------------------------------------------------------
>
> Key: JAMES-3588
> URL: https://issues.apache.org/jira/browse/JAMES-3588
> Project: James Server
> Issue Type: Improvement
> Components: lmtp, MailStore & MailRepository
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h3. Why?
> Today the MailetContainer is thought to be asynchronous, thus need to
> explicitly handle failures. The classic way to do this is through 'error'
> processors, which stores the email in a MailRepository for potential later
> processing.
> However, in an LMTP execution context it makes sense to escalate the failure
> to the LMTP client. That way the client can requeue the email and plan for a
> later delivery.
> h3. How?
> We could have a way to propagate the failure back to the caller:
> {code:java}
> <mailet match="All" class="ToRepository">
> <repositoryPath>cassandra://var/mail/error/</repositoryPath>
> <onMailetException>propagate</onMailetException>
> </mailet>
> {code}
> h3. Side benefits
> - It allow avoiding ignoring failures of the error processor
> - I allows in a SMTP (asynchronous) execution context to requeue fail mails.
> h3. Unknown
> The management of partial failures will need to be explored.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
