[Mailman-Developers] GUI hacking for SA integration

J C Lawrence claw at kanga.nu
Sun Nov 30 20:18:40 EST 2003

On Sun, 30 Nov 2003 19:52:10 -0500 
Phil Barnett <philb at philb.us> wrote:
> On Sunday 30 November 2003 5:05 pm, Barry Warsaw wrote:

>> Also, for admins who just can't use IMAP, we'd need to provide
>> /some/ web interface for them to deal with things.

> Why not just integrate with IMP? Does what you want, requires no
> further coding.

Adding IMP to the mix adds a very large, unrelated, and
deployment-unfriendly set of dependencies to Mailman.  There's also
precious little need to involve yet another web scripting language with

Other notes: 

 Twisted already supports IMAP4 at the protocol level.  Pythonic IMAPd
 implementations appear to be thin on the ground.  It also appears to be
 an unprofitable course to chase: IMAP is a vomit-inducing and
 non-trivial protocol.  Using an external IMAPd implementation with
 hierarchal folder support (which I think they all support) is a
 relatively minor additional requirement, especially as given that it
 opens the possibility for:

   a) The IMAPd deployment to be on a different host

   b) Initial receipt of mail and injection into a an IMAP "queue"
   folder to occur on a different host than Mailman itself runs on,
   without Mailman's direct involvement (ie Mailman polls the
   status/contents of the queue folder periodically).

   c) For Mailman's queue runner to transparently execute on yet a third

  All without NFS or other filesystem sharing/locking problems.  IMAPd
  implementations already know how to handle locking and lock

    ObNote: Some care would have to go to segmenting the Mailman account
    usage at the IMAP level to minimise lock contention.

  Which loosely sums to allowing segmentation of the Mailman processes
  and dependencies across hosts and across security domains (eg either
  side of firewalls/DMZs).  This becomes especially interesting with
  things like external membership rosters (eg LDAP/SQL) which may reside
  on hosts/protocols with different security requirements than the rest
  of the mail system.

I'm not sure I like the IMAP idea in toto.  It is interesting, but also
seems fragile as a design, as well as moving Mailman thoroughly away
from the ideal-for-small/ignorant-sites model.

J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw at kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

More information about the Mailman-Developers mailing list