Apache JAMES 2.3.0 has been released. JAMES is a 100% pure Java SMTP and POP3 Mail server and NNTP News server that provides extension points through the use of Mailets, which allow classification of mail and specific routing of mail. This version lists no changes from the recent release candidate, but going final gives it a stamp of approval. JAMES is meant to run as a standalone product, although it can be embedded in a J2EE container through the use of the JMXLauncher (according to the mailing list). However, one wonders if JAMES doesn't "feel old" - while it's useful to have a Java product that manages mail, there are alternative architectures that might be more "J2EE-ish," meaning that they use standard APIs to retrieve, serve, and process mail. For example, in the J2EE samples, there's a Connector that retrieves mail and routes it to a message queue, where a message-driven bean can store it in a database; also, Ironflare AB wrote a set of applications that used the servlet API to implement mail services. While these are incomplete examples, one could easily see a fully-integrated mail container being designed. JAMES is based on Avalon (a microkernel architecture whose success has been debatable in light of J2EE's broad market penetration.) Do you think that JAMES is the "right way" to go about a mail container? Do you see any use for a "more traditional" J2EE or Java EE application that manages mail?

Last time I looked at it, JAMES did not stream the emails to disk: The whole email would be received in memory and then persisted... If serveral large emails (serveral MB) would be received simultaneously the server could consume all its memory and crash. In my opinion this was a very amateurish way of building a mail server. Do you know if that has changed?

Amateurish? How much do you have to fork out to get a copy of James into your environment? You wascal you!

I run James at home for my own personal mail server. I'm running it as a service on XP Pro. As a Java developer, I felt like I should eat my own dog food, so being Java was a must. I've been pleased with how little I have to worry about it day-to-day (remember, I'm a programmer, not an admin). The Mailet API was a big attraction. I believe the Mailet API is the way to go, much as Servlet is to HTTP. I wrote my own Bayesian Spam Filter, as well as a wildcard e-mail address acceptor. It was easy, and even fun. I do wish James ran natively in a container. I looked at JBoss Mail, but coudln't get my head wrapped around it. So instead I deal with James out-of-container. I don't have any complaints. I just wish it weren't built on an end-of-lifed micro-kernel. I think it Mailet were made a J2EE API, then you might start seeing better commercial offerings for mail applications (servers, proxies, etc.).

Just wanted to pipe in that I am using james for commercial email hosting for 2 different companies (small businesses) and have been pleased with it. I saved lots of time and heartache using james in comparison with other mail servers. Just try setting up SMTP auth for sendmail which you need to do if your customers don't have static ip addresses.

I saved lots of time and heartache using james in comparison with other mail servers. Just try setting up SMTP auth for sendmail which you need to do if your customers don't have static ip addresses.

Yeah. But postfix is a drop-in replacement and it's very easy to configure.

I used version 2.1.X back in 2004 to build a custom spam filter (based on reputations) that a company of 1500 users used. It was more stable than Brightmail and only need one old server (versus two stronger ones for the Symantec software). Go Java! I've been waiting for this new release so that I can take my new client version of a spamfilter and turn it into a server solution (and give it away, since I'm just one person). Now I have to get off my arse..... The only thing I didn't like was not being able to easily move a message back to a queue to reprocess it. It would be nice to just move the file to a queue folder and be done. I think the only way to accomplish this is to add another mailet that uses a "FromRepository" attribute. Ugggh. Bob

FYI, I am maintaining a list of SMTP servers in the Javapedia: http://wiki.java.net/bin/view/Javapedia/SMTP

Dont forget this one: http://www.gnome.sk/Dwarf/dwarf_mail.html

We've been using JAMES as our production email server for about 2 years now and are very happy with it. Due to the nature of our business, we often receive emails with very large attachments (up to 50mb) and JAMES has coped admirably. I agree that the beauty of JAMES is the level of control it gives you, particularly with the MailLet API. It would be nice to see more management capabilities though, and the documentation could be better. Greg.

Congratulation to JAMES developers. From the first view it is much simpler than Postfix and Sendmail, also I hope it is much secure (since it can't have buffer overflow). Several questions: Does JAMES have spam filter and is it possible to add spam assassin to it? Is it possible to add ClamAV to JAMES? How about TLS support? (http://james.apache.org/server/2.3.0/usingTLS.html returns 404) What is approximate size of mail database JAMES can work? Regards, Vitaliy S

"feels old"? I guess it would have a younger, more sprightly feel by adding the bloat of some J2EE. One of the best things about James is it is lightweight and very easy to install.

I used to review James code for several years from now. I am running a large nation-wide ISPs mail servers which are Sun machines (java is just begging to be the only application on these machines), some of the customers want really weird configuration which exim mail server can hardly cope with. So I decided to check James out, so that I can satisfy customers requirements by adding custom Java modules. Well what can I say after several attempts (lasting YEARS) to use James... It's architecture is way too old and small-business-use centric and developers community (especially leaders) is conservative and unresponsive to architecture change requests. Empty words? Ok! I'm an author and maintainer of javamaildir library (Java library for Maildir mailbox access) my first attempt to add support for maildir dates back to year 2003. My patches were largerly discussed, nobody was against, but the patches were never applied. (I they are now (year 2006) credits go to Joachim Draeger.) Maildir access is a small feature which does not change architecture at all and it took 3 years for James leaders to accept the feature!!! James is ok on its own, and could be a very performing mail server, if only the community and leaders of the project was more responsive.

didnt notice it was "title" field

We found JAMES to be just too big and cumbersome for what we wanted to do. However the idea of the Mailet API was very appealing to us. We therefore wrote our own very small footprint, Mailet implementation server; MailCatcher. Head over to http://developer.spikesource.com/projects/mailcatcher/ for more details. We are using this production and a number of our sites are using it for their incoming email processing.