Great Circle Associates List-Managers
(February 2001)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: FAQ: MLM comparisons and features
From: J C Lawrence <claw @ kanga . nu>
Date: Tue, 20 Feb 2001 09:31:02 -0800
To: "Peter Galbavy" <peter . galbavy @ knowledge . com>
Cc: list-managers @ greatcircle . com
In-reply-to: Message from "Peter Galbavy" <peter . galbavy @ knowledge . com> of "Tue, 20 Feb 2001 17:08:07 GMT." <011c01c09b5f$b5cd4160$77cb87d4 @ n3 . uk . knowtion . net>
References: <026001c09b23$cfadac00$77cb87d4 @ n3 . uk . knowtion . net> <29415 . 982688031 @ kanga . nu> <011c01c09b5f$b5cd4160$77cb87d4 @ n3 . uk . knowtion . net>

On Tue, 20 Feb 2001 17:08:07 -0000 
Peter Galbavy <peter .
 galbavy @
 knowledge .
 com> wrote:

>> While Mailman is not current a good choice for this, the
>> architecture that we've been discussing for V3 (essentially a mix
>> of discrete processing and process queues) would adapt to this
>> pattern easily.

> My current thought are to leave queue management and outward mail
> delivery with exim, as we can use the logging output in an
> integrated fashion with normal mail. This will likely be a
> dedicated exim process/queue/etc. rather than part of the normal
> mailer. I *like* the way exim queues mail, attempt retries and
> logs success and error...

You are misunderstanding me (which is not surprinsing as I didn't
detail this).  Mailman is not intentding to take over any of the MTA
jobs, be it Exim, Postfix, QMail, or even Sendmail.  Mailman is MTA
agnostic and is intended to remain so.

The queue processing I allude to above is in terms of Mailman's
internal operations.  Messages come into queues, move among a series
of queues as they wander through the system, and finally end up in
queues before being handed off to the MTA for final delivery.  By
taking a process queue model and discreete processing it becomes
very easy to make Mailman promiscuous and integrated with the rest
of system.  

  Where does your membership list come from?  LDAP?  SQL?  text
  file?  Run-this-program-to-find-out?  All of the above
  simultaneously?  Not a problem.  Just drop the appropriate modules
  in the right places and it will work just fine.

  Mail will be received by system A, authenticated by system B, the
  membership list is only available on system C, and you'd like to
  the outbound processing on system D (think security models, DMZ's,
  and compartmentalisation)?  Not a problem.  The queues just link
  up.

  You're running SourceForge and need everything to parallelise?
  Not a problem.  Just provide basic lock semantics on queue
  entries and the rest happens automatically.

  You're running EGroups and need fine grained resource control and
  allocation?  Just replace Mailman's internal queue processing
  system (which will be pretty wimpy) with a real one ala MQS and
  then define your allocation and processing rules as appropriate.

Divide, be promiscuous, and conquer.

-- 
J C Lawrence                                       claw @
 kanga .
 nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--



Follow-Ups:
References:
Indexed By Date Previous: Re: A List-Manager Issue: Dealing with attacks via personal email.
From: Tim Bowden <tcbowden @ clovis . nerdnosh . org>
Next: Re: FAQ: MLM comparisons and features
From: "Peter Galbavy" <peter . galbavy @ knowledge . com>
Indexed By Thread Previous: Re: FAQ: MLM comparisons and features
From: "Peter Galbavy" <peter . galbavy @ knowledge . com>
Next: Re: FAQ: MLM comparisons and features
From: "Peter Galbavy" <peter . galbavy @ knowledge . com>

Google
 
Search Internet Search www.greatcircle.com