Java Email Server - Status and Future

I've covered the History of JES, as well as the JES 2.0 branch. This post will cover the current status and future of JES.

In short JES is in maintenance mode. I have no plans to make any significant changes to the JES code base. As I outlined in my first post in this series, I believe JES fits a niche as a very simple and easy to use email server, and the best way to keep it simple is avoid adding features.

For the past several years, nearly all of the improvements to JES have been made by the community. I listed the names in the history post, and these folks really are the drivers to JES today. As new updates come in, I'll check them out and roll them up into a release as appropriate.

As the Sourceforge Download Statistics indicate, JES as popular now as ever, averaging about 1,000 downloads per month. As long as people find JES useful, I'll continue to provide support (primarily through email) and release updates.

I want to thank everyone who has contributed ideas, reported or helped track down bugs, or submitted code. Without your help, JES would not be what it is today.

5 comments:

  1. How is testing done in JES?
    How can users (or those who would like to improve JES) test JES in order to be sure/confidet?
    (an email server is a pretty vital part for any company, so confidence is vital :) )

    I mean:
    #1 tests that the RFC standards are 100% covered
    #2 loading testing to see how it behaves under heavy load.

    I couldn't find any tests files in the JES source code :(

    Thank you,

    Demetrios.

    ReplyDelete
  2. The short answer is that JES I don't have anything to demonstrate #1 or #2.

    JES was written before I got the unit test religion, so my initial testing was all done manually.

    As far as a load perspective, I've done some work on it over time (as have some contributors), but I don't have any formalized test to share.

    ReplyDelete
  3. > The short answer is that JES I don't have anything to demonstrate #1 or #2.
    :(. That's not very good :(.
    The problem is here not with the developers but with "managers" - to convince them to accept JES, just so.

    > JES was written before I got the unit test religion, so my initial testing was all done manually.
    Well my point is here not unit testing but RFC compliance.

    > As far as a load perspective, I've done some work on it over time (as have some contributors), but I don't have any formalized test to share.
    Well, you do't have to reinvent the wheel here. There must be tools to do this. E.g. there's a JAMES subproject called Postage
    that is supposed to be generic (but I saw it working only with JAMES so far).

    I think numbers for #1 and #2 are very important for the "decision takers".

    JES looks so nice and simple and I think much more users could use it if some "numbers" were available.

    Thank you,

    Demetrios.

    ReplyDelete
  4. I've found a problem sending message to remote smtp server. JES only relay message to its default smtp server. In SMTPRemoteSender.java, when default smtp server is not enabled, it always throw an exception, "Could not connet to any SMTP server for domain: somedomain.com". I think there's a litle mistake. You never use the MX record you've queried from DNS server. I use JES-1.6. Can you fix it? I'd like to help if you want me to. By the way, can I join your JES project in sf.net? I'd like to build some mailing list plugin to your JES.

    ReplyDelete
  5. Suyono,

    Yes, the issue you mentioned has already been reported, and I have a release candidate build I am testing.

    Please mail me directly (eric at ericdaugherty.com) if you want the test build and to talk about doing some work to extend JES.

    ReplyDelete