james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <Danny_An...@slc.co.uk>
Subject What about IMAP support?
Date Mon, 10 Nov 2003 10:26:12 GMT

Zoe, (Beware, long answer!)

Ist point.. James IMAP component is very much alpha status *still* .

2nd point.. A James installation is an assembly of services in a container,
each of those services declares dependancies on other services, we use the
Avalon framework for managing this and distribute James installed in the
Avalon Phoenix container.

None of James' services are intended to run outside of an Avalon container,
hence we are quite comfortable with them depending upon Avalon packages,
the API which defines the services does not depend upon Avalon and hence
alternative implementations do not have to either.

The Mailet API is a *small* public API maintained by the James project and
providing a framework and contracts for server processing of e-mail, it
provides a formal description of a processing system and agnostic access to
services, accounts and to repositories of accounts which it is then the
responsibility of the service to use.

James' Stores and events (not many event hierarchies in James because of
its deterministic nature) may in many cases be equivalent, but not equal to
JavaMail ones, the reason for this would be that JavaMail is explicitly and
in its detail a mail client API, it lacks support in may areas for the kind
of server functionality James provides and it is not always easy, and often
impossible, to force James to use JavaMail interfaces and classes for many
of the tasks of a server. In fact the behaviour of many JavaMail methods
are themselves skewed to provide client functionality. The example of
MimeMessage.saveChanges() is a clear one:

In MimeMessage any changes to the body must be actioned by calling
saveChanges() MimeMessage will give every message a new message_id header
value when this method is called. This is because changes to a message in a
mail client _do_ represent the creation of a new message. However in a
server changes might represent the additon of a footer, or the removal of
an attachement by a virus scanner, and not a new message.

The answer is to subclass MimeMessage and override saveChanges() such that
it gets and stores the message_id, calls super.saveChanges(), and then
restores the message_id.
This is insane as the efficiant course of action would be to have
MimeMessage.saveChanges() *not* alter the message_id and in the client
scenario use a subclass which overrides saveChanges() to change the

That is but one of many examples of the issues we would have to (and are
unwilling to) tackle.

A JavaMail design example is the bias inherent in Session. Take a look and
tell me how _that_ works nicely in a server where you might have hundreds
or thousands of accounts, it combines access to Store and Transport, in a
way that takes little or no account of the fact that incoming, outgoing and
stored mail have very different requirements for authentication.
Outgoing mail might need to authenticate against an external server,
incoming mail against *any account* on this server and stored mail for all
accounts should be available with out authenticating, but requires the
protocol which is delivering it to require authentication from the remote
host. Practiaclly the opposite, in many cases, of the internal requirements
of a mail server.

Another example is in the names of many of the interfaces and classes, for
instance lets look "Transport" and "Store":

Transport represents outgoing mail, and has a single implementation in
sun's refrence implementation of JavaMail, SMTP, this only acknowedges one
direction of SMTP, outgoing, there is no equivalent in JavaMail for
incoming SMTP (push).
Store represents fetching mail (pull), and the RI implements IMAP and POP3.
For a server they are outgoing protocols, not Stores at all.

Store expresses the assumption that the root folder is called "INBOX" this
is not a problem, its only a name after all, but is a symptom of the
underlying assertion of the architecture  that this is a client API, after
all a server has a different, and more subtle, interpretation of "in" and
"out" than that inherent in the design of JavaMail.
This begs the question what else is there, of a more subtle nature, that
would cause us problems if we attempt to integrate JavaMail throughout
James? My opinion is that there will be so many compromises required that
James would end up turning into a nightmare of subclassing simply in order
to correct that bias, and in the end James' JavaMail classes might (should)
be compatible with JavaMail, but with no real benefit as the
specialisations required to make a server work will not be part of the
JavaMail API and hence not useable by other code without abandoning the

That said I'm still hopeful that we can implement these interfaces and
provide support for two wayTransport, and for the use of Store by james for
the local storage of mail, but (perhaps understandably) no one seems very
keen to dip their toes in the water!

So.. What is the answer for ZOE...

 Well my impression of James is that I think that it would be foolhardy to
take James' alpha IMAP and try to rewrite it with no reference to James,
Avalon or Mailet and I think it would be exceedingly tortuous (but not
necessarily impossible) to implement an IMAP server using JavaMail.

It might be worth looking at Avalon Phoenix or Merlin and see whether you
could implement (or integrate) a container within ZOE to allow you to run
IMAP.  The mail stores and the User repositories are defined as interfaces
in the Mailet API, and as such you could easily wrap any provision of
similar functionality with delegating wrappers which map the Mailet API
methods onto the methods you actually have.


The information in this e-mail is confidential and for use by the addressee(s) only. If you
are not the intended recipient (or responsible for delivery of the message to the intended
recipient) please notify us immediately on 0141 306 2050 and delete the message from your
computer. You may not copy or forward it or use or disclose its contents to any other person.
As Internet communications are capable of data corruption Student Loans Company Limited does
not accept any  responsibility for changes made to this message after it was sent. For this
reason it may be inappropriate to rely on advice or opinions contained in an e-mail without
obtaining written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to scan attachments
(if any). Opinions and views expressed in this e-mail are those of the sender and may not
reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message