james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <danny.an...@gmail.com>
Subject Re: JavaMail API and SMTP transport for Geronimo
Date Wed, 26 Jan 2005 11:03:34 GMT

> One problem I have is that the spec and API doc are not always clear
> about what should be done - e.g. from the JavaDoc for
> InternetAddress.validate():
> "The current implementation checks many, but not all, syntax rules."
> It would be nice to know what was supposed to be checked and what wasn't.
This would initially depend upon what specific version of the RFC is
supported,  but also they may not support all of the rules, for
example there are a load of paragraphs in some RFC's which specifiy
special rules for military things (time format is one). Sun may have
taken the view that things like this are not necessary.

In this case you need to decide what it is you want, 100% RFC
compliance, a do-or-die TCK pass, or a pragmatic set of useful

James already have some address validation which is stronger than
Sun's, the problem would come if the TCK has specific test cases which
are ambiguous, for instance they may be expected to pass Suns
pragmatic validation yet fail more rigorous validation and v.v.

For an example the RFC's say that the domain part of an address is not
case sensitive but the username part is. Almost no one enforces this
(in James its optional). The question is does the TCK enforce it?

> I am hoping the JavaMail TCK can clear some of these things up, but
> empirical knowledge (which I don't have, I'm no mail expert) would help.

Agreed, I'm sure that we (James greybeards ;-) could look at the TCK
and arrive at a some understanding of what Sun expect to be mandatory
and what is optional.

> Any chance you could point me in the general direction?

Well James uses (for the time being) Avalon to assemble itself at
runtime, most of the services are declared in config files as
implementations for interfaces and can therfore be swapped for highly
specialised alternatives with little problem.

For example the (incoming) SMTP handler might be replaced with an
alternative which rather than listening simply introduces predefined
test cases into the processing pipeline.

The heart of James are the Mailet processors which are used to route
and transform the messages. Mailets are processing components which
are specified by the Mailet API, and could quite easily be used to
apply the incoming test messages to various JavaMail functions, such
as constructing and deconstructing multipart messages, parsing
content, validating addresses, invoking transports etc.

> For Geronimo we can cut back on this a little - the J2EE specification
> only requires that we provide a transport that supports addresses of
> type InternetAddress and messages of type MimeMessage; we do not need to
> support any store protocols.

If you only have to provide implementations, in effect implement the
same functions as Suns reference implementation and not duplicate the
API then I'm think this is achievable. If you have to recreate the API
as well I think you have a significant obstacle, in fact it may well
be easier to sort out the legal issue.
An SMTP transport is one thing we'd love to have, Suns RI doesn't fire
any events and James could make good use of events raised by

> However, for this to be of general use I agree that we should provide
> good implementations of as many of these as we can.

I fear that implementing any of the javax.mail stuff will suck us down
a pit we can only get out of by recreating the whole thing. And sadly
as Sun, in their wisdom, have made their API out of classes not
interfaces this is not trivial.

To implement the bits the API expects us to implement is more reasonable.
> Knowledge and expertise alone will help a lot.

We'll I can't offer a lot of effort but what knowledge I have is yours.

One question I have is this, do you envisage this as being geronimo
code, or would you consider collaborating on an effort in James?


P.S. Should we take this to the geronimo lists or keep it here?

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

View raw message