Benoit Tellier created JAMES-3819:
-------------------------------------
Summary: James as a (distributed) MX server
Key: JAMES-3819
URL: https://issues.apache.org/jira/browse/JAMES-3819
Project: James Server
Issue Type: Improvement
Components: SMTPServer
Reporter: Benoit Tellier
h3. Why ?
Alternatives like Postfix...
- Do not offer a unified view of the mail queue across nodes
- Requires statefull persistent storage
Given Apache James recent push to adopt a distributed mail queue based on
Pulsar supporting delays (JAMES-3687), it starts making sense developing
tooling for MX related tooling.
I propose myself to mentor a Gsoc on this topic.
h3. Benefits for the student
At the end of this GSOC you will...
- Have a solid understanding of email relaying and associated mechanics
- Understand James modular architecture (mailet/ matcher / routes)
- Have a hands-on expertise in SQL / NoSQL working with technologies like
Cassandra, Redis, JPA...
- Identify fix and solve architecture problems.
- Conduct performance tests and develop an operational mindset
h3. Inventory...
James ships a couple of MX related tools within smtp-hooks/mailets in default
packages. It would make sense to me to move those as an extension.
James supports today...
- *checks agains DNS blacklists*. `DNSRBLHandler` smtp hook for instance.
I did get an operational issue here: querying the blacklist on each mail can be
slow. I bet a cache here would make sense to reduce the load on such blacklist.
We could have a non-distributed extension based on a memory cache
We could have a distributed extension based on a Redis cache.
We would also need a little performance benchmark to document performance
implications of activating DNS-RBL.
- *Grey listing*. There's an existing implementation using JDBC as an
underlying storage.
Move it as an extension.
Remove JDBC storage, propose 2 storage possibilities: in-memory for single
node, REDIS for a distributed topology.
- Some work around *whitelist mailets*? Move it as an extension, propose JPA,
Cassandra, and XML configured implementations ? With a route to manage entries
in there for JPA + Cassandra ?
- Lossly related but a *distributed fail2ban* would be awesome to me!
- I would expect a student to do his own little audit and come up with extra
suggestions!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
