head	1.5;
access;
symbols
	TIGRIS_1_1_0RC2:1.5
	TIGRIS_1_1_0RC1:1.5
	TIGRIS_1_1:1.5.0.12
	TIGRIS_1_0_8:1.5
	TIGRIS_1_0_8RC3:1.5
	TIGRIS_1_0_8RC2:1.5
	TIGRIS_1_0_8RC1:1.5
	TIGRIS_1_0_7:1.5
	TIGRIS_1_0_7RC3:1.5
	TIGRIS_1_0_7RC2:1.5
	TIGRIS_1_0_7RC1:1.5
	TIGRIS_1_0_6:1.5
	TIGRIS_1_0_6RC5:1.5
	TIGRIS_1_0_6RC4:1.5
	TIGRIS_1_0_6RC3:1.5
	TIGRIS_1_0_6RC2:1.5
	TIGRIS_1_0_6RC1:1.5
	TIGRIS_1_0_5:1.5
	TIGRIS_1_0_5RC6:1.5
	TIGRIS_1_0_5RC5:1.5
	TIGRIS_1_0_5RC4:1.5
	TIGRIS_1_0_5RC3:1.5
	TIGRIS_1_0_5RC2:1.5
	TIGRIS_1_0_5RC1:1.5
	TIGRIS_1_0_4:1.5
	TIGRIS_1_0_3:1.5
	TIGRIS_1_0_2:1.5
	TIGRIS_1_0_1:1.5
	TIGRIS_1_0:1.5.0.14
	TIGRIS_1_0_0:1.5
	TIGRIS_1_0_0_RC1:1.5.0.10
	dlr:1.1.1
	TIGRIS_0_9_2_4:1.5
	TIGRIS_0_9_2_3:1.5
	HELM_PEER_PORT_BRANCH:1.1.1.1
	TURBINE_PEER:1.5
	TIGRIS_0_9_2_1:1.5
	TIGRIS_0_9_2:1.5.0.8
	TIGRIS_0_9_0:1.5.0.6
	TIGRIS_0_8_4:1.5.0.4
	TIGRIS_NOV_12_2000:1.5
	OLDHELM:1.5.0.2
	TIGRIS_NOV_11_2000:1.5
	TIGRIS_SEP_13_2000:1.4.0.2
	TIGRIS_BASELINE:1.5;
locks; strict;
comment	@# @;


1.5
date	2000.09.20.03.13.18;	author brian;	state Exp;
branches;
next	1.4;

1.4
date	2000.07.06.20.12.47;	author ed;	state Exp;
branches;
next	1.3;

1.3
date	2000.07.01.04.49.29;	author dlr;	state Exp;
branches;
next	1.2;

1.2
date	2000.06.30.20.51.35;	author dlr;	state Exp;
branches;
next	1.1;

1.1
date	2000.06.30.19.29.40;	author ed;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	2001.02.21.00.37.06;	author dlr;	state Exp;
branches;
next	;


desc
@@


1.5
log
@
Obtained from:
Submitted by:
Reviewed by:

Moved from org.helm to org.tigris.helm
Moved from org/helm to org/tigris/helm

perl -pi.bak -e, how I love thee

note: this update was done POST-CVS-REPOSITORY surgury.  In order to
get this right, you may need to remove the directories

$CVSROOT/helm/java/org/helm
$CVSROOT/helm/data/htdoc/look/www/org/helm
$CVSROOT/helm/templates/org/helm

before doing the "CVS update" call, since those directories don't
exist anymore and CVS will try to create lockfiles for you in them,
giving you an error.
@
text
@<html><head><title>Design for Mail Alias/List Management</title>
</head>
<body>

<h1>Mail Alias/List Management</h1>
<b>Author: Ed Korthof</b>

<p>
<h2>1. Introduction</h2>
<h3>1.1 Scope</h3>

<p>This document outlines a system to manage mailing aliases and
lists for Tigris.  The system described here is a prototype, to be built
as a test of certain ideas.

<p>The system should satisfy the following goals:

<ul>
  <li>Mail alias/list management should be centralized within a
    single module.
  <li>The system used to update the file system should not increase
    the overall complexity of tigris any more than is necessary.
  <li>The system must work with the current MTA (qmail) and MLM (ezmlm),
    but as much as is reasonable, it should be possible to modify so
    that other MTAs/MLMs are supported through use of the adapter pattern.
  <li>Multiple domains must be supported.
  <li>The system must scale reasonably.
</ul>

<h3>1.2 Overview</h3>
<p><b>Current System</b>

<p>To manage mailing lists, there is a body of Java code in
org.tigris.helm.admin.ProjMail* which relates to the user interface. This runs
within the servlet engine (JServ) and provides access to a class
(org.tigris.helm.tool.MailingList) which handles the core logic.  It stores the
resulting information in an SQL database (MySQL) and then calls a Perl
CGI script, update.cgi, which makes updates to data files stored on
the file system. 

<p>User management is done via org.tigris.helm.admin.User* classes; these
store the users' e-mail addresses (for which we create aliases) in 
MySQL.  When update.cgi is called, it also recreates the aliases for 
those users.

<p>Domain management is not integrated into Tigris currently.


<p><b>Proposed System</b>

<p>The Perl scripts responsible for updating the file system will be
replaced with a Java process on the mail server, accessed via RMI.  This
server--using file system data--will return information about and make 
changes to the current state.  However, it will not contain core
business logic in this iteration.

<p>The Java server accessible via RMI on the mail server (which may
be the same as the webserver) will use interfaces which are not specific
to ezmlm (thus allowing for easy swapping of the MLM).  The interfaces
are defined in section 3.  <i>TODO: Come up with a name for the Java process
running on the mail server, perhaps something like "Tigris mail agent."</i>

<p>The initial layer of Java code living within JServ/Helm will be
retained.  However, the <code>MailingList</code> class will be changed
to <code>MailingListSpec</code>, with a number of differences behind
the API.  It will use RMI to talk with a Java process on the mail server
(rather than talking with the MySQL database).  In this implementation,
the communication may be "inefficient," in that many RMI calls will be
used -- the assumption is that the net speed will still be acceptable,
and the operation of creating or editing a mailing list will be fairly
infrequent.

<p>The handling of user mail aliases will be explicitly broken
out.  A new class will be created,
<code>org.tigris.helm.tool.MailingAliasSpec</code>,
which will deal with the mail server in a similar way to
<code>MailingListSpec</code>.


<h2>2. System Outline</h2>

<h3>2.1 User Interface/Helm serlvets</h3>

<p>The user interface is part of Helm; it uses servlets in the
org.tigris.helm.admin package.  It runs built within the Joist framework, using
WebMacro templates.  These servlets allow autorized users to
create/configure/destroy mailing lists, and to edit the list of
subscribers to each list.  Security is implemented through the Joist
framework.

<h3>2.2 Servlet API for talking with the Mail Server</h3>

<p>This will consist of classes within the org.tigris.helm.tool package, which will
communicate via RMI to a java process on the mail server (possibly the
same machine).  These classes will be responsible for any business logic
which does not relate to MTA/MLM internals.

<h3>2.3 Mail Server</h3>

<p>The code running in the mail server Java process will handle dealing
directly with the mail transfer agent and mailing list manager.  It will
contain any business logic related to MTAs and MLMs -- both those which
are specific to qmail/ezmlm, and those which are general for tigris.

<h2>3. Detailed Design</h2>

<h3>3.1 Interfaces</h3>

<p>The following 3 interfaces are defined: MailingAddressManager, 
MailingList, MailingAlias.  These extend Remote and are used on the
mail server.

<p><b>AddressManager</b>
<ul>Methods:
<li>public String[] getListNames(String domain, String initialSubstring)
<li>public MailingList getList(String domain, String list)
<li>public MailingList createList(String domain,
    String list, String options)
<li>public MailingAlias createAlias(String domain, String alias
    String destination)
<li>public void addDomain(String domain)
<li>public Logger getLogger()
<li>public File getMailDirectory(String domain)
</ul>

<p><b>MailingList</b>
<p>This interface extends remote.  Classes implementing it are used on the
mail server to represent actual lists.
<ul>Methods:
<li>public void update(String options)
<li>public void delete()
<li>public void setOption(String option, boolean value)
<li>public boolean getOption(String option)
<li>public void setStringOption(String option, String value)
<li>public String getStringOption(String option)
<li>public void setModeratorList(String list)
<li>public void setFileContents(String filename, String contents)
<li>public String mlmType()
<li>public void subscribe(String[] addresses, String group)
<li>public void unsubscribe(String[] addresses, String group)
<li>public String[] listMembers(String group)
</ul>

<p>For ezmlm, group must be one of "Subscribers", "Digest Subscribers", and
"Moderators".  If setModeratorList is used, "Moderators" is not allowd as
one of the list types.

<p>Note that there is no "clean" way to delete an ezmlm list according
to the API.  To try to do this, we will delete the associated directory, and
the following aliases: (list), (list)-accept-default, (list)-reject-default,
(list)-return-default, (list)-owner, (list)-digest, (list)-digest-owner,
(list)-digest-return-default, (list)-default.  Aliases matching one of
these forms will be disallowed by MailingAlias, so deleting these should
be safe.

<p><b>MailingAlias</b>
<p>This interface extends remote.  Classes implementing it are used on
the mail server to represent mailing aliases which are not lists.
<ul>Methods:
<li>public String getDestination()
<li>public void update(String destination)
<li>public void delete() throws RemoteException
</ul>

<h3>3.2 Classes</h3>

<p><b>QmailEzmlmManager</b>
<p>This class implements MailingAddressManager.  It adds the following
function(s):
<ul>
<li>public MailingAddressManager(String confFile)
<li>public File getEzmlmBinariesDirectory()
</ul>

<p><b>org.tigris.helm.mailserver.EzmlmList</b>
<p>This class implements MailingList.  The only logic it contains is
calling the appropriate ezmlm programs.  It adds the following
functions:
<ul>
<li>public EzmlmList (String domain, String list, String options,
    AddressManager manager) throws AddressInUseException
<li>public EzmlmList (String domain, String list, AddressManager manager)
    throws AddressNotFoundException
<li>public static String[] getListNames(String domain,
    String initialSubstring, AddressManager manager)
<li>public static boolean isList(String domain, String list,
    AddressManager manager)
<li>public static boolean isListAlias(String domain, String address,
    AddressManager manager)
</ul>
Note that this class will store the literal command line arguments in a
file (this is done currently by the Perl code); when instantiated for an
existing mailing list, it will read that file to determine the options
used.

<p><code>isList</code> distinguishes ezmlm lists by the fact that the 
list will have a corresponding directory.

<p><code>isListAlias</code> distinguishes aliases associated with lists 
by treating
a limited set of suffixes specially, and testing to see if an associated
directory exists.  The following suffixes indicate aliases which will
recieve special testing: -accept-default, -reject-default, -default,
-digest-owner, -digest-return-default, -owner, -return-default.

<p><b>org.tigris.helm.mailserver.QmailAlias</b>

<p>This class implements <code>MailingAlias</code>.  It looks at the 
.qmail-* files in
{sandbox}/tigrisq; however, it will not properly recognize all addresses
associated with an ezmlm mailing list: EzmlmMailingList should be used for
that.

<ul>
<li>public MailingAlias(File mailDirectory, String domain, String alias,
    String destination) throws AddressInUseException, IOException
<li>public MailingAlias(File mailDirectory, String domain, String alias)
    throws AddressNotFoundException, IOException
</ul>

<p><b>org.tigris.helm.mailserver.Logger</b>

<p>This class is a simple logger, designed so that better logging can
be added at a later date.
<ul>Methods
<li>public Logger()
<li>public void log(String message)
<li>public void log(Exception e)
<li>public void log(String message, Exception e)
<li>public void debug(String message, int level)
<li>public void setDebugFlag(int level)
</ul>
<ul>Variables
<li>public static final DEBUG_LEVEL_NONE
<li>public static final DEBUG_LEVEL_WARN
<li>public static final DEBUG_LEVEL_INFO
</ul>

<p><b>org.tigris.helm.tool.MailingAliasSpec</b>

<p>This class will be within the serlvet engine (not the mail server's
Java process).  The static lookup function and create() will get a
reference to a <code>MailingAddressManager</code> (via <code>
java.rmi.Naming.Lookup</code>, using
a system property for the location of the resource to lookup).  This
class will then use that to create or find a MailingAlias, and operate
on it.  Note that the constructor does not actually create: <code>create</code>
must be called explicitly.  (This is for symetry with
<code>MailingListSpec</code>.)

<ul>Methods:
<li>public MailingAliasSpec(String domain, String alias,
    String destination) throws HandlerException
<li>public static MailingAliasSpec lookup(String domain, String alias)
    throws AddressNotFound, HandlerException
<li>public void create () throws HandlerException, AddressInUse
<li>public void update (String destination) throws HandlerException
<li>public void delete () throws HandlerException
</ul>

<p>Because mailing aliases are very similar from one MTA to another,
there is no need to make this class specific to qmail.

<p><b>org.tigris.helm.tool.MailingListSpec</b>

<p>This class also will be used by the servlet engine (not the mail
server's Java process), and will start in a similar manner.  As
with MailingAliasSpec, the constructor will not actually create
the list: <code>create()</code> must be called.

<ul>Methods:
<li>public MailingListSpec(String domain, String list)
<li>public static MailingListSpec lookup (String domain, String list)
    throws AddressNotFound, HandlerException
<li>public void setOption(String option, boolean value)
    throws InvalidOption
<li>public boolean getOption(String option)
    throws InvalidOption
<li>public void setStringOption(String option, String value)
    throws InvalidOption
<li>public String getStringOption(String option, String value)
    throws InvalidOption
<li>public void create() throws HandlerException
<li>public void update() throws HandlerException
<li>public void delete() throws HandlerException
</ul>

<p>Note that this class will need to transform the options (boolean and
String) into command line arguments -- and parse those back.

<p>Also, note that because MLMs do differ greatly (in capabilities,
logical structure, and so on), it is necessarily to make this
class specific to ezmlm.

<h3>3.3 Exceptions</h3>
Generally, classes will throw RemoteException with an appropriate
error message.  Where it is possible to have more intelligent behavior 
based on the nature of the exception, a different class will be used.  
At the least, that will include the following classes:

<pre>public class AddressInUseException extends RemoteException
public class AddressNotFoundException extends RemoteException
public class DomainInUseException extends RemoteException
public class InvalidDomainException extends RemoteException
public class InvalidGroupException extends RemoteException
public class InvalidFileException extends RemoteException
public class InvalidOptionException extends RemoteException
</pre>

</body></html>
@


1.4
log
@changes per peer review:
* EzmlmMailingListSpec -> MailingListSpec (now MLM independent)
* associated with that -- put the ezmlm logic on the mail server,
  and just live with lots of RMI calls
* provide an api for setting the moderators list to another list
  (this is useful w/in ezmlm, and probably makes sense in other MLMs).
* explain how to do deletes for mailing lists safely (enumerate the
  possible associated lists)
* remove the api for getting the list of aliases (since this can't
  be implemented efficiently w/in java)
@
text
@d34 1
a34 1
org.helm.admin.ProjMail* which relates to the user interface. This runs
d36 1
a36 1
(org.helm.tool.MailingList) which handles the core logic.  It stores the
d41 1
a41 1
<p>User management is done via org.helm.admin.User* classes; these
d75 1
a75 1
<code>org.helm.tool.MailingAliasSpec</code>,
d85 1
a85 1
org.helm.admin package.  It runs built within the Joist framework, using
d93 1
a93 1
<p>This will consist of classes within the org.helm.tool package, which will
d175 1
a175 1
<p><b>org.helm.mailserver.EzmlmList</b>
d206 1
a206 1
<p><b>org.helm.mailserver.QmailAlias</b>
d221 1
a221 1
<p><b>org.helm.mailserver.Logger</b>
d239 1
a239 1
<p><b>org.helm.tool.MailingAliasSpec</b>
d264 1
a264 1
<p><b>org.helm.tool.MailingListSpec</b>
@


1.3
log
@Added a some <code> markers and changed a couple phrasings.
@
text
@d57 5
a61 2
<p>TODO: Come up with a name for the Java process running on the mail 
server, perhaps something like "Tigris mail agent."
d64 8
a71 6
retained.  However, the <code>MailingList</code> class will be renamed
<code>EzmlmMailingListSpec</code>, and will be changed in other ways.  
It will use RMI
to talk with a Java process on the mail server (rather than talking
directly with the MySQL database); and it will actually construct the
command line arguments to the MLM (this logic was in Perl code).
d73 1
a73 1
<p>Finally, the handling of user mail aliases will be explicitly broken
d77 1
a77 1
<code>EzmlmMailingListSpec</code>.
a78 3
<p>The Java server accessible via RMI on the mail server (which may
be the same as the webserver) will use interfaces which are not specific
to ezmlm (thus allowing for easy swapping of the MLM).
d93 4
a96 4
<p>This will consist of classes within the org.helm.tool package, which will c
ommunicate via RMI to a java process on the mail server (possibly the
same machine).  These classes will generally be responsible for the business
logic.
d101 3
a103 2
directly with the mail transfer agent and mailing list manager.
They will not contain significant logic in this iteration.
d105 1
a105 1
<h2>3. Detail Design</h2>
a114 1
<li>public String findAddressType(String domain, String address)
a115 1
<li>public String[] getAliasNames(String domain, String initialSubstring)
d132 7
d145 2
a146 1
"Moderators".
d148 7
a154 17
<p>The use of a single String to represent the options means that there
is only loose error checking on the contents; consequently, the core
business logic should not be handled on this side for this class.  This
should be redone later using SOAP (XML which would provide a clean way
to describe the mailing list during IPC).  Because of the fact that we
use RMI, using more sophisticated means of communicating the structure
of the mailing list would add extra coupling without any significant
advantages.

<p>Note that there is no "clean" way to delete an ezmlm list.
Currently, we accomplish this by deleting everything whose name starts
with the list name; this should usually be correct, but would prove
incorrect if the creation of random aliases is allowed.

<p>Finally, it is the responsibility of implementations of this class to
ensure that the options string used to create the list is returned
verbatim, when an existing list is edited.
d203 2
a204 2
recieve special testing: -default, -digest-owner, -digest-return-default,
-owner, -return-default.
a218 4
<li>public static String[] getAliasNames(File mailDirectory, String domain,
    String initialSubstring) throws IOException
<li>public static boolean isAlias(File mailDirectory, String domain,
    String alias) throws IOException
a219 4
Note that currently <code>getAliasNames</code> will not be functional, 
due to the
difficulty of distinguishing between aliases associated with a mailing
list and those which are actually separate aliases.
d248 2
a249 2
must be called explicitly.  (This is for symetry with <code>
EzmlmMailingListSpec</code>.)
d264 1
a264 1
<p><b>org.helm.tool.EzmlmMailingListSpec</b>
d272 2
a273 2
<li>public EzmlmMailingListSpec(String domain, String list)
<li>public static EzmlmMailingListSpec lookup (String domain, String list)
d306 2
@


1.2
log
@looking good...
@
text
@d61 3
a63 2
retained.  However, the MailingList class will be renamed
EzmlmMailingListSpec, and will be changed in other ways.  It will use RMI
d69 2
a70 1
out.  A new class will be created, org.helm.tool.MailingAliasSpec,
d72 1
a72 1
EzmlmMailingListSpec.
d256 1
a256 1
on it.  Note that the constructor does not actually create: create
d275 1
a275 1
<p>This class also will be within the servlet engine (not the mail
@


1.1
log
@design for mail management system.  this is not final, but is current.
@
text
@d12 2
a13 2
<p>This document is outlines a system to manage mailing aliases and
lists for Tigris.  The system describe here is a prototype, to be built
d16 1
a16 1
<p>The system should attempt to satisfy the following goals:
d19 5
a23 5
  <li>mail alias/list management should be centralized within a
    single framework
  <li>the system used to update the file system should not increase
    the overall complexity of tigris any more than is necessary
  <li>the system must work with the current MTA (qmail) and MLM (ezmlm),
d25 3
a27 3
    that other MTAs/MLMs are supported.
  <li>multiple domains must be supported, and the system must
    scale reasonably.
d37 8
a44 2
resulting information in an SQL database (MySQL) and then calls a perl
CGI script, update.cgi, which makes updates to the file system. 
d46 1
a46 5
<p>User management is done via org.helm.admin.User*; this stores the
users' e-mail addresses (for which we create aliases) in MySQL.  When
update.cgi is called, it also recreates the aliases for those users.

<p>Domain management is not integrated into tigris currently.
d51 1
a51 1
<p>The perl scripts responsible for updating the file system will be
d53 6
a58 3
server -- using the file system -- return information about the current
state and make changes to the current state.  However, it will not
contain core business logic in this iteration.
d65 1
a65 1
command line arguments (this logic was in perl code).
d74 1
a74 1
to ezmlm
d89 3
a91 3
<p>This will be classes within the org.helm.tool package.  They will
communicate via RMI to a java process on the mail server (possibly the
same machine).  These classes will generally be responsible for business
d129 2
a130 2
<li>public void subscribe(String addresses[], String group)
<li>public void unsubscribe(String addresses[], String group)
d157 1
a157 2
the mail server to represent mailing aliases which are not
lists.
d191 1
a191 1
file (this is done currently by the perl code); when instanciated for an
d195 1
a195 1
<p>isList distinguishes ezmlm lists by the fact that the 
d198 2
a199 1
<p>isListAlias distinguishes aliases associated with lists by treating
d207 2
a208 1
<p>This class implements MailingAlias.  It looks at the .qmail- files in
d223 2
a224 1
Note that currently getAliasNames will not be functional, due to the
d250 2
a251 1
reference to a MailingAddressManager (via java.rmi.Naming.Lookup, using
d255 2
a256 1
must be called explicitly.  (This is for symetry with EzmlmMailingListSpec.)
d276 1
a276 1
the list: create() must be called.
d304 3
a306 3
error.  Where it is possible to have more intelligent behavior based on
the nature of the exception, a different class will be used.  At the
least, that will include the following classes:
@


1.1.1.1
log
@Replacing the HEAD with the HELM_PEER_PORT_BRANCH.
@
text
@d12 2
a13 2
<p>This document outlines a system to manage mailing aliases and
lists for Tigris.  The system described here is a prototype, to be built
d16 1
a16 1
<p>The system should satisfy the following goals:
d19 5
a23 5
  <li>Mail alias/list management should be centralized within a
    single module.
  <li>The system used to update the file system should not increase
    the overall complexity of tigris any more than is necessary.
  <li>The system must work with the current MTA (qmail) and MLM (ezmlm),
d25 3
a27 3
    that other MTAs/MLMs are supported through use of the adapter pattern.
  <li>Multiple domains must be supported.
  <li>The system must scale reasonably.
d34 1
a34 1
org.tigris.helm.admin.ProjMail* which relates to the user interface. This runs
d36 7
a42 9
(org.tigris.helm.tool.MailingList) which handles the core logic.  It stores the
resulting information in an SQL database (MySQL) and then calls a Perl
CGI script, update.cgi, which makes updates to data files stored on
the file system. 

<p>User management is done via org.tigris.helm.admin.User* classes; these
store the users' e-mail addresses (for which we create aliases) in 
MySQL.  When update.cgi is called, it also recreates the aliases for 
those users.
d44 1
a44 1
<p>Domain management is not integrated into Tigris currently.
d49 1
a49 1
<p>The Perl scripts responsible for updating the file system will be
d51 3
a53 3
server--using file system data--will return information about and make 
changes to the current state.  However, it will not contain core
business logic in this iteration.
d55 6
a60 5
<p>The Java server accessible via RMI on the mail server (which may
be the same as the webserver) will use interfaces which are not specific
to ezmlm (thus allowing for easy swapping of the MLM).  The interfaces
are defined in section 3.  <i>TODO: Come up with a name for the Java process
running on the mail server, perhaps something like "Tigris mail agent."</i>
d62 2
a63 13
<p>The initial layer of Java code living within JServ/Helm will be
retained.  However, the <code>MailingList</code> class will be changed
to <code>MailingListSpec</code>, with a number of differences behind
the API.  It will use RMI to talk with a Java process on the mail server
(rather than talking with the MySQL database).  In this implementation,
the communication may be "inefficient," in that many RMI calls will be
used -- the assumption is that the net speed will still be acceptable,
and the operation of creating or editing a mailing list will be fairly
infrequent.

<p>The handling of user mail aliases will be explicitly broken
out.  A new class will be created,
<code>org.tigris.helm.tool.MailingAliasSpec</code>,
d65 1
a65 1
<code>MailingListSpec</code>.
d67 3
d76 1
a76 1
org.tigris.helm.admin package.  It runs built within the Joist framework, using
d84 1
a84 1
<p>This will consist of classes within the org.tigris.helm.tool package, which will
d86 2
a87 2
same machine).  These classes will be responsible for any business logic
which does not relate to MTA/MLM internals.
d92 2
a93 3
directly with the mail transfer agent and mailing list manager.  It will
contain any business logic related to MTAs and MLMs -- both those which
are specific to qmail/ezmlm, and those which are general for tigris.
d95 1
a95 1
<h2>3. Detailed Design</h2>
d105 1
d107 1
d124 2
a125 9
<li>public void setOption(String option, boolean value)
<li>public boolean getOption(String option)
<li>public void setStringOption(String option, String value)
<li>public String getStringOption(String option)
<li>public void setModeratorList(String list)
<li>public void setFileContents(String filename, String contents)
<li>public String mlmType()
<li>public void subscribe(String[] addresses, String group)
<li>public void unsubscribe(String[] addresses, String group)
d130 1
a130 2
"Moderators".  If setModeratorList is used, "Moderators" is not allowd as
one of the list types.
d132 17
a148 7
<p>Note that there is no "clean" way to delete an ezmlm list according
to the API.  To try to do this, we will delete the associated directory, and
the following aliases: (list), (list)-accept-default, (list)-reject-default,
(list)-return-default, (list)-owner, (list)-digest, (list)-digest-owner,
(list)-digest-return-default, (list)-default.  Aliases matching one of
these forms will be disallowed by MailingAlias, so deleting these should
be safe.
d152 2
a153 1
the mail server to represent mailing aliases which are not lists.
d170 1
a170 1
<p><b>org.tigris.helm.mailserver.EzmlmList</b>
d187 1
a187 1
file (this is done currently by the Perl code); when instantiated for an
d191 1
a191 1
<p><code>isList</code> distinguishes ezmlm lists by the fact that the 
d194 1
a194 2
<p><code>isListAlias</code> distinguishes aliases associated with lists 
by treating
d197 2
a198 2
recieve special testing: -accept-default, -reject-default, -default,
-digest-owner, -digest-return-default, -owner, -return-default.
d200 1
a200 1
<p><b>org.tigris.helm.mailserver.QmailAlias</b>
d202 1
a202 2
<p>This class implements <code>MailingAlias</code>.  It looks at the 
.qmail-* files in
d212 8
a219 1
</ul>
d221 1
a221 1
<p><b>org.tigris.helm.mailserver.Logger</b>
d239 1
a239 1
<p><b>org.tigris.helm.tool.MailingAliasSpec</b>
d243 1
a243 2
reference to a <code>MailingAddressManager</code> (via <code>
java.rmi.Naming.Lookup</code>, using
d246 2
a247 3
on it.  Note that the constructor does not actually create: <code>create</code>
must be called explicitly.  (This is for symetry with
<code>MailingListSpec</code>.)
d262 1
a262 1
<p><b>org.tigris.helm.tool.MailingListSpec</b>
d264 1
a264 1
<p>This class also will be used by the servlet engine (not the mail
d267 1
a267 1
the list: <code>create()</code> must be called.
d270 2
a271 2
<li>public MailingListSpec(String domain, String list)
<li>public static MailingListSpec lookup (String domain, String list)
d295 3
a297 3
error message.  Where it is possible to have more intelligent behavior 
based on the nature of the exception, a different class will be used.  
At the least, that will include the following classes:
a303 2
public class InvalidFileException extends RemoteException
public class InvalidOptionException extends RemoteException
@


