[jira] [Updated] (JAMES-3819) [GSOC] James as a (distributed) MX server

["Benoit Tellier (Jira)" <se...@james.apache.org>]

     [ https://issues.apache.org/jira/browse/JAMES-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benoit Tellier updated JAMES-3819:
----------------------------------
    Labels: gsoc gsoc2023 part-time  (was: gscoc2023 gsoc)

> [GSOC] 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
>            Priority: Major
>              Labels: gsoc, gsoc2023, part-time
>
> 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` 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 JAMES-3820 .
> *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!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org