james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: JavaMail API and SMTP transport for Geronimo
Date Wed, 26 Jan 2005 06:00:07 GMT
Danny Angus wrote:
>>1) How do we know they are compatible?
> Thats the nightmare for you! not only do you have to conform to the java
> mail spec but also
> to the miriad RFC's for mail.

Yep - that's why I'm seeking help :-)

> We have a lot of knowedge about how the stds should be implemented, but not
> a test kit of any kind.

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 

"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.

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.

> It is certainly reasonable to use James as a testbed, James' architecture
> provides several points at which
> test cases could be inserted.

Any chance you could point me in the general direction?

> Its probably worth restating the enormity of the task, for the spec and an
> impl you'd have to test conformance with RFC's for:
> domain names
> email addresses
> SMTP & ESMTP (for both send and receive)
> Message format
> MIME - including providing handlers for at least a few common content
> types, especially the gruesome multipart/* ones.

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.

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

> James relies on JavaMail to provide a lot of this, simply because the
> effort of producing reliable conformant implementations
> far outweighs the benefit of "ownership". Why re-invent the wheel when
> there weren't a great many of the JavaMail classes we'd like to change?
> Though I think that if it made proper use of interfaces as types we'd be
> more inclined to replace some of the key ones.
>>2) Transport providers, especially SMTP
> James uses the sun RI ones, but we have some issues with them and would
> like to have the resources to write our one ones.
> Sadly we haven't done so yet.
> I can understand that the licence is an issue, we had an issue with it
> which we resolved by only distributing them with binaries.
> I also think we'd be happy to collaborate, I'm much less sure how much we
> can realistically offer beyond our knowedge.

Knowledge and expertise alone will help a lot.


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

View raw message