The Java Apache Mail Enterprise Server (a.k.a. Apache James) is a 100% pure Java SMTP and POP3 Mail server and NNTP News server. We designed James to be a complete and portable enterprise mail engine solution based on currently available open protocols.

Features

• mbox support
• Mail attributes
• JavaMail 1.3.1
• dnsjava 1.6.2, includes auto-discover DNS servers
• FetchMAIL, deprecating FetchPop
• Quotas
• Extensive message redirect system
• Improved network address handling
• Multiple remote delivery gateway servers
• Many performance improvements
• Many new matchers and mailets
• Many bug fixes
• And much more!

Links

Latest JAMES release info

Change Log

Articles on James: An introduction to Apache's James enterprise e-mail, Build e-mail based applications with matchers and mailets

James is really nice - especially if you are not a Sendmail/Postfix/QMail guru. We are currently prototyping on using James for mailing-list handling, and it is really nice to be able to write mail-handling plugins in Java. The only thing that still keeps us from using it as our only mail system is the incomplete IMAP support. Anyways, great project.

How does this compare to Qmail / Courier IMAP / etc?

I've recently gone through the process of getting my mail server set up using Qmailtoaster and the excellent script from Nate Davis. All in all it took an hour or so to get installed. I've been tweaking it to include SpamAssassin with Bayesian spam filtering and directories for users to drop in spam for it to learn + customizing Squirrelmail for a couple of weeks, but it's been functioning out of the box after an hour. And the whole thing takes up less than 10MB of resident memory on my Linux box... the spamd with the bayes actually has 20MB allocated because of the bayes database, but all but 2MB is swapped out.

Can James or any Java App hope to do this? There's a time and a place for Java, and low level system services like this ain't it. Dan Bernstein's Qmail is fast and secure (I think I remember him putting up a challenge for anyone to find a security flaw that's never been claimed), so why re-invent the wheel?

There's a time and a place for Java, and low level system services like this ain't it.

I have no idea of how James compares to Qmail (i'm a Qmail user and have never tried James), but I not sure I can see how an email server written in java is all that different from an applciation server written in java or that it's any lower level of a service.

-Watter

so why re-invent the wheel?

I not sure I can see how an email server written in java is all that different from an applciation server written in java

Java does not play well as an embedded thing, nor it easily wraps other systems.
So the tendency: lets rewrite everything in Java.
I wish all those efforts were spent on making Java play nicely with other systems….

There's a time and a place for Java, and low level system services like this ain't it. Dan Bernstein's Qmail is fast and secure (I think I remember him putting up a challenge for anyone to find a security flaw that's never been claimed), so why re-invent the wheel?

Well I agree that Qmail is secure, but that's an exception rather than the norm. I'd like to see more low level system services being implemented in Java to finally eliminate buffer overflows.

I've been tweaking it to include SpamAssassin with Bayesian spam filtering and directories for users to drop in spam for it to learn + customizing Squirrelmail for a couple of weeks, but it's been functioning out of the box after an hour.

You've just said in took you a couple of weeks to get everything set up? So what was functioning out of the box? Did not look like the software you've used satisfied your requirements out of the box, so its working in a hour is not a fair statement.

I've got James setup in less than an hour satisfactory to my requirements and have it working just fine. No compiling of the code on an appropriate platform and etc. THat is what's good about it - cross-platform, given the existence of an appropriate JVM, whithout mundane compilation. Unzip, configure and run.

Can James or any Java App hope to do this? There's a time and a place for Java, and low level system services like this ain't it.

Memory is the only concern, although you can get a Java service down to a 10-20 MB allocated memory if you try very hard. James is at around 32MB, not much of a difference given the amounts of memory world works with now days.

Otherwise Java is just fine for any low-level services and more it allows much greater extensibility and flexibility without much hassle (reflection, bindings and etc.). Look at James and its plugin capability. Very cleanly defined XML metadata too. APIs for that are widely available and supported and are standard in many cases, so Java can do the work no worse than any other language implementation.

So I think you are being a bit too judgemental about capabilities of Java and apps written in it.

so why re-invent the wheel?

To come up with something better, more secure and easier to use. And in addition reinventing the wheel would be coming up with an SMTP or POP3 or etc. protocol again, not by developing a product, maybe similar to others, which function is to manage the communication and data across such protocols. Otherwise we would not have any competing products and would not have any choice.

Sincrely,

Artem D. Yegorov

You've just said in took you a couple of weeks to get everything set up? So what was functioning out of the box? Did not look like the software you've used satisfied your requirements out of the box, so its working in a hour is not a fair statement.

Squirrelmail is a webmail component and the poster was certainly talking about tweaking HTML pages to his liking. I don't see webmail listed in the feature set of James, although it's probably possible to add one of the existing open-source webmail layers to James' mail content - over IMAP or connect to DB with mail content.

It would be interesting to know if James is actually used in a production environment anywhere and if so, what volume of mail it handles, number of users, on what hardware platform, with what sort of uptime, that sort of stuff: the website doesn't have any info on this. Looking at the TODO list, it's apparent
to me that James is way behind most modern mail servers like sendmail and postfix (to limit comparisons to open source products) with respect to mail features. Also, are there spam and virus scanners or a way to integrate with existing tools like SpamAssassin and Clamd - without those, mail servers are hardly useful these days.

James is definitely not as advanced as postfix or sendmail and other veterans, but it is a good and practical application, taht can be extended and integrated to anyone's liking. I just do not like judgements, that Java is no good for low-level service, just because such services written in it do not have all the features of the applications that have been written and rewritten and debugged and fixed for way longer than them.

James will match up to its counterparts, just give it time. For the basic mail server needs though, it is better than all the hassle of configuring sendmail for instance.

Also, are there spam and virus scanners or a way to integrate with existing tools like SpamAssassin and Clamd - without those, mail servers are hardly useful these days.

You can, just gotto learn how to do plugins for James.

It is pretty extensive.

It would be interesting to know if James is actually used in a production environment anywhere and if so, what volume of mail it handles, number of users, on what hardware platform, with what sort of uptime, that sort of stuff: the website doesn't have any info on this.

I use it in a production environment where it is setup to relay personalised email generated by another process to a corporate mailgate. We've extended James a little so we can maintain the status of individiual emails in a database, using a VERP variant. James is running on W2K server and uptime is somewhere in the months. The mailvolume is not very large (thousands of outbound mails/day), but in a period with a lot of mail worm activity it has to deal with a fair amount of incoming mail too. I'm happy with James, especially with how easy it is to setup, configure and extend.

After some experimenting it seems that deprecating fetchpop has been to early. James works fine as a mail server, I will believe on first sigth that the mailets work fine.
Fetchmail is sheer horror. After 10 hours of work it still won't work. It will not work out of the box with my ISP (ParseException) and it will not work on one of its own accounts (error in determining remote accounts). The configuration of fetchmail is too complex, way over the top. Whatever you tweak or try, it will bnever work. Too bad since fetchmail/fetchpop would make James very useful.