multisite MaildropHost

PURPOSE

To allow different virtual sites (in the following we consider Plone sites) in the same Zope instance to use MaildropHost with different parameters.
To keep compatibility with the original MaildropHost product.

SCOPE

This is an extension to MaildropHost 1.20; we tested it with Plone 2.1.2 and, partially, with Plone 2.5.3.

MOTIVATION

It is a common case, for us, to have multiple Plone sites in the same Zope instance.
In the past, we used MailHost/SecureMailHost to send mail; each site had specific mail setting.
If we wanted to use MaildropHost instead - to benefit from asynchronous mail sending - no more we were able to specify different configurations.
We need, in particular, to specify the address of the SMTP server and, sometimes, login name and password for authentication.
I've heard that recently Andreas Jung has checked-in some changes to the MailHost product, adding to it the functionality previously requiring SecureMailHost, MaildropHost, and more.
But, since the new MailHost is based on zope.sendmail, I suppose that it cannot be used in Plone 2.x; if I'm wrong, please correct me.

CONFIGURATION

Take as reference the README.txt and INSTALL.txt files in the root directory of MaildropHost 1.20, and the README file in the maildrop/bin sub-directory.

Create a different config file, named config<site_it>.py per Plone site; we suppose that Plone sites inside the same Zope instance have different ids, even if this could be not true in general (only if multiple ZODB mount points are used).

Create a different daemon script, named maildropd_<site_id>, per Plone site.
Each daemon should call the shell scripts start_maildrop and stop_maildrop with a specific parameter: <site_id>.
You should also change the value of the local variable "name" from maildrop to maildropd_<site_id>.
Possibly, create dynamic links to the daemon scripts so that the daemons be executed at system startup (boot).

Create a different home directory, with its directory subtree, per Plone site, for holding the variable data; eg:
- home directory: /tmp/maildrop_<site_id>
- spooling directory: /temp/maildrop_<site_id>/spool
- log file: /tmp/maildrop_<site_id>/var/maildrop.log
- pid file: /tmp/maildrop_<site_id>/var/maildrop.pid
A good choice could be to put all those home directories inside a common parent directory (/temp or other).

USE

Take as reference the README.txt and INSTALL.txt files in the root directory of MaildropHost 1.20, and the README file in the maildrop/bin sub-directory.

When you execute manually the start_maildrop and stop_maildrop shell scripts, you must add the <site_id> parameter to the command line if you want to exploit the multi-site features.
If you create multiple daemon scripts, you must start/stop individually each process.

IMPLEMENTATION

The shell script /Products/MaildropHost/maildrop/bin/start_maildrop executes the Python script /Products/MaildropHost/maildrop/maildrop.py passing to it the parameter as an argument.
The shell script /Products/MaildropHost/maildrop/bin/stop_maildrop uses the input parameter to access the file with the right pid (the id of the process to be killed, that was created by the corresponding execution of maildrop_start.

The Python script /Products/MaildropHost/maildrop/maildrop.py

• dynamically imports a specific set of parameters from the config file corresponding to input argument, named config<site_id>.py
• the remainder of it is like the original maildrop.py script.

The MaildropHost module has been modified in a similar way:

• a number of instance variables have been added to the class MaildropHost, to hold the values of the settings
• the __init__ method of the class MaildropHost, dynamically imports a specific set of parameters from the config<site_id>.py file; the site id is the id of the MaildropHost instance's parent object
• also the manage_makeChanges method dynamically imports those parameters, so that the corresponding attributes of the MaildropHost instance are refreshed if the config file has been modified
• the remainder the MaildropHost.py module is almost unchanged.

BACK-COMPATIBILITY

The proposed extended product should still work if

• you have only one Plone site in the Zope instance
• you have multiple Plone sites, but they can share the MaildropHost settings.

In such a case you need not create multiple configuration files and multiple daemons.
If a specific configuration file is not found, the default one (config.py) is being used.

COMPATIBILITY WITH SECUREMAILHOST

Plone 2.1.x uses SecureMailHost, whose interface extends that of MailHost.
Since MaildropHost doesn't include such extension, I also installed a patch to it, in the form of a minimal Zope product (only __init__.py), following the instructions found at http://dev.plone.org/plone/ticket/5584 .
 
SUMMARY

In conclusion we have:

• multiple config files, multiple (slightly different) daemons, multiple home directories for variable data (same subtree structure)
• a common MaildropHost class, made parametric by dynamic importing the required config file
• common shell scripts for starting and stopping the spooling processes, slightly modified to handle an input/output parameter
• a common maildrop spooling script (maildrop.py), made parametric by dynamic importing the required config file.

Matching spool feeding and spool emptying processes, for the same (Plone) site, share the same config file.