[
https://issues.apache.org/jira/browse/JAMES-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709190#comment-17709190
]
Benoit Tellier commented on JAMES-964:
--------------------------------------
A little wrap up on this topic.
I did start contributing to smtp-nio:
- Missing email commands
- DATA command without javax.mail dependency and allowing streaming of
InputStream
- Removed logback dependency
I did experiment with it locally and it works great.
To be fully satisfied I miss still some features: pipelining, opportunistic
STARTTLS.
But my believe is that this is a GREAT candidate to rework RemoteDelivery and
do a "javax.mail-free" version of it.
My approach would be to :
- 1/ Split Gatewaying from direct delivery: two dedicated distinct mailets
`GatewayDelivery` and `DirectDelivery`. This will make the overall set up
cleaner and more straightforward for the user with use-case-driven defaults
(connection reuse, ssl set up, etc...) and enhanced performance (avoid
per-domain email split?).
- 2/ Set up those mailets into a dedicated maven module
`james-server-smtp-delivery` in `server/mailet`.
- 3/ Fully reactive remote delivery
- 4/ Deliver experimental mailets first, then remove experiment tag,
eventually deprecate RemoteDelivery to be removed on a future 4.0 release.
- 5/ Start with `GatewayDelivery` first...
Why this move:
- Javax.mail maintainance is questionnable at best and switching to
jakarta.mail did fail CF https://github.com/apache/james-project/pull/923
https://github.com/apache/james-project/pull/939. Getting rid of Javax.mail in
remote delivery would be a move in the right direction
- Performance: Connection reuse for gatewaying... Reactive remote delivery.
- Fined grained control on outgoing DSN parameters.
- Error management with javax.mail is a mess.
Uncertainties:
- Liveness of the smtp-nio project: unusable as is, all commands are missing,
and contributing upstream is hard (breaking changes might be refused despite
being necessary), not vendor neutral. If needed we can fork it and include it
as `server/protocols/smtp-client-netty`...
- Supporting as many options as `javax.mail` might be a pain...
- Reactive DSN resolution? :-)
Next steps:
- Open a draft pull request for Proof of Concept.
- Open an Architecture Decision Record on this topic.
Disclaimer: this is to be a personal effort, distinct for the interest of my
employer.
> Write a NIO based RemoteDelivery replacement
> --------------------------------------------
>
> Key: JAMES-964
> URL: https://issues.apache.org/jira/browse/JAMES-964
> Project: James Server
> Issue Type: Task
> Components: Remote Delivery
> Reporter: Norman Maurer
> Assignee: Norman Maurer
> Priority: Major
> Fix For: 3.0.0
>
>
> Currently we use javamail to send our emails. I think it would be better to
> roll our own based on NIO for delivery. This will prolly improve performance.
> And will help to be not tied on javamail in the future
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
