On Tue, 20 Feb 2001 17:08:07 -0000
Peter Galbavy <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
