Sieve Proposal (Request For Comments)

[Steve Brewin <sb...@synsys.com>]

Hi,

Following on from the discussions in the "Future Directions" thread, and in
particular the final part of
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
.org&msgId=1146701, here is a proposal on how to implement Sieve.

1) Implement a Java implementation of Sieve that...
a) Accepts a script read from a java.io.InputStream and a
javax.mail.internet.MailMessage as input.
b) Defines the RFC3028 required commands and tests as interfaces.
c) Implement the interfaces in (1b) above where no specific mail processing
is required.

2) Using JavaMail...
a) Implement any remaining interfaces from (1b) not implemented by (1c)
where JavaMail provides the required functionality.
b) Optionally, implement Vendor Defined Extensions, as defined in RFC3028
Section 6, to exploit extra JavaMail functionality as desired.

3) Using James[1]...
a) Provide a mechanism(s) for invoking the Java implementation of Sieve
described in (1) above.
b) Implement any remaining interfaces from (1b) not implemented by (1c) or
(2a) using James specific functionality.
c) Optionally, implement Vendor Defined Extensions, as defined in RFC3028
Section 6, to exploit extra James functionality as desired.

In this layered approach, layers 1 and 2 do not have anything to do with
James at all. Still, within Apache, James seems the most fertile ground in
which to grow them.

Layer 3 touches James. Within James, the mechanism(s) of (3a) maybe via one
or more of a Sieve container[2], a mailet, something new.

To prove to myself that this is do-able in a reasonable time-frame, I
created...

- A parseable definition of the Sieve grammar expressed in JavaCC which
correctly parses all of the Sieve script examples in RFC3028.
- An interpreter, which executes the parsed objects, invoking Sieve Commands
and Tests against a MailMessage.

So, that's step (1) above almost done (I got a little carried away)!

I <MAY> go further and complete at least (2) above, but first...

? Is the proposal described above the correct way of implementing Sieve ?

I have worked out a way to do this stuff, but before I expend the time and
effort on a full scale implementation, it would be good to get a consensus
confirming that this is the right way to go about it.

Hence, RFC!

-- Steve

[1] Any other Java enabled thing that delivers the required functionality
could be used.
[2] The container refactoring work will need to be done before this.


- - - - - - - - - - - - - - - - - -

This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited.

If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox.


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

Re: Sieve Proposal (Request For Comments)

[Serge Knystautas <se...@lokitech.com>]

Steve Brewin wrote:
> Following on from the discussions in the "Future Directions" thread, and in
> particular the final part of
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
> .org&msgId=1146701, here is a proposal on how to implement Sieve.

Sounds great to me.  I think it would be helpful to create some unit 
tests (sample messages and sample sieve scripts) for 1.  That could be a 
separate repository we host.

I thought that mailets could be added as sieve extensions, but that may 
or may not be germane to what you're currently working on.

-- 
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


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

Re: Sieve Proposal (Request For Comments)

["Richard O. Hammer" <RO...@EarthLink.net>]

Noel J. Bergman wrote:
> ... please be aware that sometime next year, we will be
> switching from CVS to Subversion, and probably all ASF code will reside in a
> single SVN repository.

Gak!  Just when I bought a $25 book on CVS.



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

RE: Sieve Proposal (Request For Comments)

["Noel J. Bergman" <no...@devtech.com>]

> here is a proposal on how to implement Sieve.
> 1) Implement a Java implementation of Sieve that...
>     a) Accepts a script read from a java.io.InputStream and a
>        javax.mail.internet.MailMessage as input.

I assume that you meant MineMessage.  I am leaning against using MimeMessage
for specific reasons.  Please review in detail the RFC 3028 operations.
*If* we can implement them against a Stream, I think that we would be better
off because the MimeMessage interface really expects that at least once you
start processing the message, it is memory resident.  I'm concerned about
performance and scalability with our Sieve implementation.  Implementing a
MimeMessage subclass that doesn't expect to be memory resident appears to
involve largely rewriting the package.

Thoughts?

With respect to Serge's comment about a separate CVS repository, we could
have james-sieve, but please be aware that sometime next year, we will be
switching from CVS to Subversion, and probably all ASF code will reside in a
single SVN repository.

	--- Noel


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