[ https://issues.apache.org/jira/browse/JAMES-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686513#comment-17686513 ]
Maxim Solodovnik commented on JAMES-3819: ----------------------------------------- Thanks! https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2023+Ideas+list is updated :) > [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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org