High Level Architecture

Click to enlarge image

James is a multi-protocol message processing and storage engine. James currently consists of:

  • Four mail protocol services: SMTP, POP3, IMAP4 and LMTP.
  • Support for SMTP Auth.
  • A remote administration server.
  • Support for TLS/SSL.
  • A mail processing engine that supports the Mailet API.
  • File-system message storage and a message storage interface to RDBMS's.
  • File-system user record storage and an experimental interface to LDAP directories.

The mail protocol services use the mailbox librairies to fetch/store mails.

When a mail arrives via SMTP, it gets processed by the SMTP services and is placed in a Apache ActiveMQ queue (ActiveMQ is the Java Messaging Service JMS implementation at Apache)

This allow to decouple mail spooling from the rest of the incoming traffic.

After being the put in the queue, the mailetcontainer is responsible to get the next mail to process from the ActiveMQ queue.

The mailets defined in mailetcontainer.xml are applied to define if the mail is to be treated as a Local or Remote delivery.

The Local and Remote deliveries are treated by their corresponding mailet.

The LocalDelivery mailet uses the SieveMailet which uses the mailbox/message manager to store the mail.

The result of the mail can be either:

  • Gets stored in the mailbox.
  • Gets relayed to another server.
  • Gets relayed to another server.
  • Gets bounced back if it can not be handle by the james instance (this may happen during a previous step)
  • Gets stored in the "mailstore" which is a special format for spam, virus,... (in future release, we may also store those mails in the mailbox).

Technical Architecture

Click to enlarge image

James uses many other components: Spring, ActiveMQ, OpenJPA, Netty, Jackrabbit, Derby...

The modules can be classified into 3 categories:

  • API: They do not include implementation details, they do not have dependencies (or at most they have very common dependencies like mailet-api, javamail, commons-logging).
  • Library: They only depend on API modules or external jars. They don't depend on other internal libraries. These libraries should be shared by functions (no need to have a Library when it is used only by a function).
  • Functions: Everything else. It is harder to see a case of "direct" reuse of a function jar. Most times we'll only have code reuse. It is preferable to limit Function to Functions dependencies.

Server Coding Guidelines

LogEnabled interface as the preferred way, except for non-server code and classes that have no bean definition. LogEnabled should be used wherever logging is needed and no "session-scoped" Log is provided.

Design Objectives


These are some of the currently implemented features:

Complete portability Apache James is be a 100% pure Java application based on the Java 2 platform and the JavaMail 1.4 API.

Protocol abstraction Unlike other mail engines, protocols are seen only like "communication languages" ruling comunications between clients and the server. Apache James is not be tied to any particular protocol but follow an abstracted server design (like JavaMail did on the client side)

Complete solution The mail system is able to handle both mail transport and storage in a single server application. Apache James works alone without the need for any other server or solution.

Mailet support Apache James supports the Apache Mailet API. A Mailet is a discrete piece of mail-processing logic which is incorporated into a Mailet-compliant mail-server's processing. This easy-to-write, easy-to-use pattern allows developers to build powerful customized mail systems. Examples of the services a Mailet might provide include: a mail-to-fax or mail-to-phone transformer, a filter, a language translator, a mailing list manager, etc. Several Mailets are included in the James distribution (see documentation).

Resource abstraction Like protocols, resources are abstracted and, accessed through defined interfaces (JavaMail for transport, JDBC for spool storage or user accounts in RDBMS's, Apache Mailet API). The server is highly modular and reuse solutions from other projects.

Secure and multi-threaded design Based on well known frameworks such as Spring, ActiveMQ, OpenJPA, Netty,..., Apache James has a careful, security-oriented, full multi-threaded design, to allow performance, scalability and mission-critical use.

Anything else you may want if you help us write it :-)

Standards Compliance

It is the existence of published "open" standards which allows independant teams to develop interoperable software.

James attempts to support a number of these standards most of which are IETF RFC's and in the areas covered by these standards the published standard is our requirements document.

This sometimes leads to confusion where behaviour is not the subject of a relevant standard, or conflict where common (de-facto) behaviour is actually at odds with a supported standard.

We believe that it is our responsibility to adhere to the published standard. If we allow our implementation to deviate it means that we are tacitly encouraging the situation whereby interoperability is no longer guarenteed by standards compliance alone, but also requires access to undocumented and possibly even commercially licenced technology. There is no easy route for a newcomer to aquire these secrets, and interoperabilty becomes something only available to the elite.

The James policy for issues of non-compliance tries to tread the fine line between a pragmatic acceptance of other people's misinterpretation of the RFC's and an evangelical defence of open standards as the key to freedom of interoperation.

In practice this policy is that certain well argued of cases of non-compliance which can be *safely* worked around, will be tolerated by James.

In cases (like jira issue JAMES-344) where variance from a published standard is required it is desirable that this functionality is disabled in James by default, it must be prominently and clearly documented that this causes James to violate the relevant standard, and should be enabled by explicit configuration, making its use a conscious decision of the user rather than an decision taken by the James team.

In cases where the required behaviour is not within the scope of any standard which James claims to support (such as behaviour which is a de-facto standard or an internet draft RFC but not yet subject of a standards track RFC) it is acceptable to implement the behaviour so long as it is adequately documented (for instance by refrence to an internet draft or other public document) and users can be clear about what to expect from James.