Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-3819

[GSOC] James as a (distributed) MX server

Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • SMTPServer


      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.

      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


      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!


        Issue Links


          This comment will be Viewable by All Users Viewable by All Users


            Unassigned Unassigned
            btellier Benoit Tellier




                Issue deployment