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.
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
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` or `URIRBLHandler` smtp hook for instance. This can be moved as an extension IMO.
We would need a little performance benchmark to document performance implications of activating DNS-RBL.
Finally as quoted by a gitter guy: it would make more sens to have this done as a MailHook rather as a RcptHook as it would avoid doing the same job again and over again for each recipients. See
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 ?
I would expect a student to do his own little audit and come up with extra suggestions!
|Implement RFC-8689 RequireTLS||Open||Unassigned|
|Simple Mail Transfer Protocol Extension for Message Transfer Priorities||Open||Unassigned|
|IP filtering with CrowdSec||Open||Unassigned||