james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zsombor <gzsom...@gmail.com>
Subject Re: Imap status
Date Wed, 04 Jun 2008 13:25:09 GMT
On Wed, Jun 4, 2008 at 2:44 PM, Robert Burrell Donkin <
robertburrelldonkin@gmail.com> wrote:

> On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak <ihsiak@gmail.com> wrote:
> > Robert Burrell Donkin pisze:
> >>
> >> On 6/4/08, Ihsiak <ihsiak@gmail.com> wrote:
> >>>
> >>> Hello
> >>
> >> Hi
> >>
> >>>  I am part of a team that works on integrating James with webbased
> >>> mailing solution. So far, we have sucessfully developed integration for
> >>> smtp and pop3, and now we are going to work on IMAP. I know that
> current
> >>> IMAP is not production ready - yet, so we want to work closely with you
> >>> and make it better (for you) and usefull (for us). If we get
> permission,
> >>> therewill be probably 2 persons available for about 2-3 months for that
> >>> project. But before we get to that I need to know what's current stare
> >>> of IMAP code, and what areas requies work. Can anyone describe it to
> me?
> >>
> >> There are currently two IMAP implementations on trunk. One has a
> >> straightforward design and is currently unmaintained. The second is an
> >> experimental rewrite. This code is under active development but is
> >> difficult to work with (my interest is in advanced high performance
> >> mail architectures and it's an in-place rewrite since I use it for my
> >> mail).
> >>
> >> The main implementation is incomplete, buggy and leaks memory. The new
> >> implementation works ok with the clients I use and is very close to
> >> being feature complete. But the original should be fixable by
> >> cross-porting.
> >> Which version interests you?
> >
> > Definitely the second one (we don't want to duplicate integration work,
> and
> > do "waste" bug fixing on the old code, and then on the new one).
> good. i'll talk only the second from now on.
> > We should be able to donate two persons to work on that project - can you
> > estimate how long it would take to complete "feature complete" version
> IMAP (as a specification) is interesting :-/
> 4rev1 is specified by RFC2060 and again in RFC3501. the major
> difference is that STARTTLS is not supported by RFC2060 but is
> mandated by RFC3501. AIUI newish clients all use RFC3501, ancient
> clients use RFC3501. IMAPS works but STARTTLS is to be implemented.
> STARTTLS should be straight forward but ideally want to push generic
> support into the JAMES socket handling layer. any volunteers?

A year ago I've made a mina based IMAPS/IMAP module, for the old,
straightforward design.
If there is some interest to merge, I can rework it, for the more difficult
design - if there is no plan to simpify/redesign that :) Currently I dont
know what were my greatest concern with it. STARTTLS support is documented
in the mina site, so I doesn't have to be too difficult.
 You can look into at


> everything else is just about feature complete but with some areas of
> buggy code which are yet to be rewritten (mainly in FETCH and APPEND).
> the biggest remaining effort is going to be proving the implementation
> works. this requires improving the functional test suite (and fixing
> all bugs found), in particular by simulating a variety of clients.
> but feature complete is a way from being production ready. the current
> backend needs a complete rewrite, for example.
> IMAP also has quite a number of additional RFCs which define extra features

Especially if you want to target limited devices, smartphones/pdas.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message