src/site/xdoc/todo.xml - james-project - Git at Google

 <?xml version="1.0"?>
 <!--
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
 -->
 <document>

  <properties>

   <title>James Server - To Do</title>
   <author email="sergek@lokitech.com">Serge Knystautas</author>
   <author email="charles@benett1.co.uk">Charles Benett</author>
   <author email="farsight@alum.mit.edu">Peter M. Goldstein</author>

  </properties>

 <body>

 <section name="James Server - To Do">

 <p>Please add your wisches on the JIRA for 'Roadmap for Apache James Server 3.1' (<a href="https://issues.apache.org/jira/browse/JAMES-1272">JAMES-1272</a>).</p>

 <!--
 <p>This is a living document that will give new and existing volunteers some areas where we need help.  As always, any help is appreciated, be it documentation, code, suggestions, or feedback.
 Last Updated July 2006.</p>

 </section>

 <section name="Cross-Service Issues">

 <p>Determine a way to support multiple domains.</p>
 <p>Revisit UserRepository.  The interface must support multiple authentication types per user,
 aliasing (both local and non-local), as well as per-user quotas.  It may be desirable to be able
 to associate attributes with users in the repository.</p>
 <p>Revisit the MailRepository interface and associated implementations.  Special consideration is
 necessary to support IMAP Search functionality.  It should be possible to associate attributes
 with mail messages stored in the repository.</p>
 <p>Revisit the SpoolRepository implementations and do away with the current exception-generating
 two-phase message retrieval.</p>
 <p>Define a simple mechaism for addressing repositories in a uniform way.</p>
 <p>Add support for mbox mail file repository.</p>
 <p>Add support for the <a href="http://cr.yp.to/proto/maildir.html">maildir</a> file repository.</p>
 <p>Add support for DRAC login/relay authorization.  This feature records the IP addresses and times of
 POP3 logins.  SMTP connections from these same IP addresses are considered authenticated  if they occur
 within a fixed period of the POP3 authentication.</p>
 <p>Develop repository migration tools so that users of the old repositories can easily migrate to newer repositories.</p>
 </section>

 <section name="SMTP Service">
 <p>Add support for the 8BITMIME extension.</p>
 <p>Expand the SMTP server so it supports a variety of SASL authentication mechanisms.</p>
 <p>Complete support for delivery service notification (<a href="http://www.faqs.org/rfcs/rfc1891.html">RFC 1891</a>).</p>
 <p>Discuss optional support for VRFY and EXPN.</p>
 </section>

 <section name="IMAP Service">
 <p>Get IMAP server to alpha standard (i.e. basic interoperation with e-mail clients).</p>
 <p>Add #news namespace to IMAP system</p>
 </section>

 <section name="POP3 Service">
 <p>Give admins the option to enforce one access at a time to a POP3 mailbox.</p>
 </section>

 <section name="NNTP Service">
 <p>Refactor NNTP code base.</p>
 <p>Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.</p>
 </section>

 <section name="List Management">
 <p>Write a list server implementation with functionality comparable to ezmlm.  This would include
 the capability to handle multiple lists of 100,000+ members, double opt-in subscription mechanisms,
 and a full suite of mail-driven commands.</p>
 </section>
 <section name="Container options">
 <p>Discuss and agree future architecture in the light of Avalon's demise. Modify codebase to implement architecture design.</p>
 </section>

 <section name="Mailet API">
 <p>Discuss and design the next revision of the Mailet API.</p>
 </section>

 <section name="DNS Server">
 <p>Improve the debugging output, including a) catching that DNS servers are not correct (at least have DNS log channel record DNS server usage)</p>
 </section>

 <section name="SpoolManager">
 <p>Add support for better mailet router/processing (maybe like RequestDispatcher) - Use Stage/Pipeline pattern</p>
 <p>Add support for deployable message processing apps using Camelot pattern</p>
 </section>

 <section name="Remote Management">
 <p>Rewrite RemoteManager to be an exposed object that can be controlled via RMI or what have you, and have the remote manager telnet interface make appropriate calls to this interface.</p>
 <p>Take advantage of Phoenix JMX capabilities to enable more complete measurement of James behavior.</p>
 <p>Add support in the RemoteManager to manage repositories.  This includes listing what's in a repository, viewing individual messages, deleting messages, copying messages, and moving messages.</p>
 <p>Add needed functions to RemoteManager, Including Stop and ReConfigure (?), Reinject mail (this should just be copying/moving messages...), Store RemoteManger password securely.</p>
 </section>

 <section name="Documentation">
 <p>Document instructions on configuring logging in James.</p>

 -->

 </section>

 </body>

 </document>
	<?xml version="1.0"?>
	<!--
	Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.
	-->
	<document>

	<properties>

	<title>James Server - To Do</title>
	<author email="sergek@lokitech.com">Serge Knystautas</author>
	<author email="charles@benett1.co.uk">Charles Benett</author>
	<author email="farsight@alum.mit.edu">Peter M. Goldstein</author>

	</properties>

	<body>

	<section name="James Server - To Do">

	<p>Please add your wisches on the JIRA for 'Roadmap for Apache James Server 3.1' (<a href="https://issues.apache.org/jira/browse/JAMES-1272">JAMES-1272</a>).</p>

	<!--
	<p>This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback.
	Last Updated July 2006.</p>

	</section>

	<section name="Cross-Service Issues">

	<p>Determine a way to support multiple domains.</p>
	<p>Revisit UserRepository. The interface must support multiple authentication types per user,
	aliasing (both local and non-local), as well as per-user quotas. It may be desirable to be able
	to associate attributes with users in the repository.</p>
	<p>Revisit the MailRepository interface and associated implementations. Special consideration is
	necessary to support IMAP Search functionality. It should be possible to associate attributes
	with mail messages stored in the repository.</p>
	<p>Revisit the SpoolRepository implementations and do away with the current exception-generating
	two-phase message retrieval.</p>
	<p>Define a simple mechaism for addressing repositories in a uniform way.</p>
	<p>Add support for mbox mail file repository.</p>
	<p>Add support for the <a href="http://cr.yp.to/proto/maildir.html">maildir</a> file repository.</p>
	<p>Add support for DRAC login/relay authorization. This feature records the IP addresses and times of
	POP3 logins. SMTP connections from these same IP addresses are considered authenticated if they occur
	within a fixed period of the POP3 authentication.</p>
	<p>Develop repository migration tools so that users of the old repositories can easily migrate to newer repositories.</p>
	</section>

	<section name="SMTP Service">
	<p>Add support for the 8BITMIME extension.</p>
	<p>Expand the SMTP server so it supports a variety of SASL authentication mechanisms.</p>
	<p>Complete support for delivery service notification (<a href="http://www.faqs.org/rfcs/rfc1891.html">RFC 1891</a>).</p>
	<p>Discuss optional support for VRFY and EXPN.</p>
	</section>

	<section name="IMAP Service">
	<p>Get IMAP server to alpha standard (i.e. basic interoperation with e-mail clients).</p>
	<p>Add #news namespace to IMAP system</p>
	</section>

	<section name="POP3 Service">
	<p>Give admins the option to enforce one access at a time to a POP3 mailbox.</p>
	</section>

	<section name="NNTP Service">
	<p>Refactor NNTP code base.</p>
	<p>Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.</p>
	</section>

	<section name="List Management">
	<p>Write a list server implementation with functionality comparable to ezmlm. This would include
	the capability to handle multiple lists of 100,000+ members, double opt-in subscription mechanisms,
	and a full suite of mail-driven commands.</p>
	</section>
	<section name="Container options">
	<p>Discuss and agree future architecture in the light of Avalon's demise. Modify codebase to implement architecture design.</p>
	</section>

	<section name="Mailet API">
	<p>Discuss and design the next revision of the Mailet API.</p>
	</section>

	<section name="DNS Server">
	<p>Improve the debugging output, including a) catching that DNS servers are not correct (at least have DNS log channel record DNS server usage)</p>
	</section>

	<section name="SpoolManager">
	<p>Add support for better mailet router/processing (maybe like RequestDispatcher) - Use Stage/Pipeline pattern</p>
	<p>Add support for deployable message processing apps using Camelot pattern</p>
	</section>

	<section name="Remote Management">
	<p>Rewrite RemoteManager to be an exposed object that can be controlled via RMI or what have you, and have the remote manager telnet interface make appropriate calls to this interface.</p>
	<p>Take advantage of Phoenix JMX capabilities to enable more complete measurement of James behavior.</p>
	<p>Add support in the RemoteManager to manage repositories. This includes listing what's in a repository, viewing individual messages, deleting messages, copying messages, and moving messages.</p>
	<p>Add needed functions to RemoteManager, Including Stop and ReConfigure (?), Reinject mail (this should just be copying/moving messages...), Store RemoteManger password securely.</p>
	</section>

	<section name="Documentation">
	<p>Document instructions on configuring logging in James.</p>

	-->

	</section>

	</body>

	</document>