On Sat, 16 Dec 2000 15:28:42 -0500
Ken Kyler <ken(a)kyler.com> wrote:
>> Okay, let's split this out. There are five levels and a
>> pseudonymous sixth:
>> 1) Site owner -- SysAdm for the host
>> 2) Group owner -- Sets group defaults
>> 3) List owner -- Sets list defaults
>> 4) List moderator -- Controls day-to-day operation of list
>> 5) Member account -- Individual humans
>> 6) Email address
> Using the virtual host paradigm, it becomes...
> 1) SysAdmin -- God
> 2) Domain owner -- Virtual host administrator
> 3) Group owner -- Sets group defaults
> 4) List owner -- Sets list defaults
> 5) List moderator -- Controls day-to-day operation of list
> 6) Member account -- Individual humans
> 7) Email address
I don't see that there's enough gain added by splitting VHosts out
from groups to make the extra complextiy worth it. A group can be a
vhost, or it can be a more logical grouping. Given that the likely
tenuous life of vhosts (they've already started rolling out IPv6 on
a production basis in a few places) I really don't have much
temptation to bend that far when groups can accomplish the same end
(if need-be just create multiple groups representing factions of a
vhost).
--
J C Lawrence claw(a)kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
On Fri, 15 Dec 2000 00:10:13 -0800
Chuq Von Rospach <chuqui(a)plaidworks.com> wrote:
> At 6:27 PM -0800 12/14/00, J C Lawrence wrote:
>> Heck, remove the entire concept of mailing lists entirely and
>> make the very existance of a list and its configs and membership
>> dynamic:
>>
>> You send a message to <something>@lists.domain, Mailman receives
>> it, does an LDP query for every user with a <something> attribute
>> on their record, and broadcasts the message to that generated
>> list of addresses.
> you just defined the server I'm looking at rewriting, probably
> next summer. We did a preliminary of that a couple of months
> ago. it gets -- well, very interesting.
Care to comment?
>> Virtual hosts are a hack, and an ugly hack at that. I don't see
>> that they are worth wasting time on when multiple installation
>> appeases the privacy concerns.
> they're a necessary hack, too. We can't blow them off
> trivially. *I* need them for various things.
They are needed now, yes, this I don't argue. Post IPv6 I don't see
much use for them any more and I expect their use to almost vanish.
Heck, more simply, once application-centric VLANS (ala IPSec for
instance) become common (which is already happening but is really
pending IPv6 to get the address space) the whole problem is going to
get messy on a far different score (multiple addressing and
side-scale use of non-routable network blocks without accepted
authentication).
<<If you think the current BGP table size is a problem...>>
--
J C Lawrence claw(a)kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
On Thu, 14 Dec 2000 23:36:28 -0800
Chuq Von Rospach <chuqui(a)plaidworks.com> wrote:
> For every account, you can subscribe one or more address to a
> list. For every address subscribed, you have a set of list
> options. So a person could get both the messages and digest to
> separate addresses, and have a third address validated for posting
> but get nothing. Useful if that person is doing offline munging
> into a private archive (or if you're using this form to gateway
> into some scripting system as the admin, where the scripting isn't
> tied into Mailman. you could then have a single account, but
> attach all of the gateway addresses to it, and configure each one
> separately. Much neater administratively.)
We can generalise usefully here and punt the rest of the problem
into end-user configuration space. I suggest we make the following
divide:
At the general level list owners/moderators deal with accounts,
not email addresses. They set moderation controls etc on
accounts. It is an account that subscribes to a list, resulting
in every address on that account being a "member" etc.
Equally, at the general level, from a member's view, participation
in a list is configured at the email address level. This address
will or will not receive postings, and has this specific
configuration in regard to that list.
AccountX/AddressY is on ListZ and receives mail from ListZ.
ListOwner for ListZ approves AccountX for automatic posting to the
list (no moderation). AccountX/AddressQ then posts to the list,
and has his post go straight thru as his *account* is approved,
not the posting address.
If someone wants something different they can get something
different by taking responsibility for the membership problem in its
entirety and doing something else (sbclassing, plugins, et al as
previously discussed). However the above does what users natively
expect: They, the human, joined the list, and the list therefore
should be intelligent enough to know that even tho they subscribed
with their work email address, when they post from home or from
hotmail that it really is them and not some anonymous stranger.
>> I see a level of indirection coming to the rescue. MailingLists
>> have Rosters and Rosters have EmailAddresses which in turn link
>> back to the UserAccount.
> Let me think about this in pseudo-SQL terms a sec.
> A user creates an account. that is given an acct_id, which is
> unique to the system. He attaches 1..N email addresses to his
> account. Each email gets an email_ID, which is also unique to the
> system, so we now have a 1-> mapping from account to a set of
> email addresses. One or more of these addresses have been
> validated in some way to guarantee ownership.
<nod>
> question: are email addresses unique to the system? to the user?
> I'd argue they have to be, if for no other reason than if
> foo(a)bar.com is attached to two accounts and someone logs on via
> it, which acct does he get? So email addresses are unique but you
> can't use the email address as the primary key because it
> changes. So any time you add one or change one, you have to
> validate against uniqueness before accepting it.
Precisely.
> from the other side, the admin creates a list, which is assigned a
> list_id. when a user subscribes to that list, the relationship is
> between a user's email_id and the list_id, and there's a unique
> set of preferences attached to that relationship. the only way a
> list can find out who the user is is to refer back through the
> list_id to get the account_id, which, frankly, I don't think we
> want to allow anyway, on privacy issues. you only get the
> information you need to do the job.
Of course. We don't reveal that data to the list owner. However
the decisions that the list owner makes in regard to a given address
are applied to the account, not the address.
Yes, this means that with sufficient experiementation and
observation, a list owner could deduce most of an account definition
("I approved address XXX for posting and now YYY is also approved?
They must be on the same account!". I don't see that as a problem.
> Second, it opens you up to mailforward attacks (create a hotmail
> account. Sign up for 900 lists. Forward that account to someone
> you hate. disappear). At least with validations, a user sees it
> coming, and knowing they'll get warning, it'll only get used by
> stupid users...
I don't see this as our problem, simply because its not one we
either have control over or can defend against.
--
J C Lawrence claw(a)kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
On Fri, 15 Dec 2000 00:16:25 -0800
Chuq Von Rospach <chuqui(a)plaidworks.com> wrote:
> At 9:57 PM -0500 12/14/00, Barry A. Warsaw wrote:
>> You've just described Roundup's nosy lists:
> so now we've grafted Brad Templeton's old Knews (keyword usenet)
> idea with google and implemented both into mailman so the list
> server can figure out if you really want the email, granular to
> the individual message?
Yes, but better, since now (post v3) an individual can implement a
knews-style implementation without having to re-invent the weel, and
without even necessarily needing to have to.
Consider a mailing list system ala:
--<cut>--
From: Ka-Ping Yee [mailto:ping@lfw.org]
Sent: Monday, May 22, 2000 2:45 AM
To: Roundup users
Subject: {3} Welcome to the Singularity discussion system!
Issue: {3} http://headspaces.com/singularity/3
Description: -> Welcome to the Singularity discussion system!
Priority: -> 5
Keywords: -> admin
Nosy: -> ping(a)lfw.org
Hello everyone!
Thank you all for joining the Singularity discussion system
and helping to carry forward the dialogue and all the great
work that took place at this weekend's Foresight Gathering.
This system works much like a typical electronic mailing list,
but it does have some key features which should help improve
information flow (in one of my sessions, someone used the term
"noise management" and i thought it was great).
1. Only messages opening new threads are sent to
the entire mailing list. This happens when you
compose a new message and send it directly to
singularity(a)headspaces.com.
2. Starting a new thread in this way opens an "issue"
in the discussion system. The issue gets its
title from your subject line. Each issue maintains
its own list of interested people. Initially,
this list just contains you, the initial poster.
3. Issues show up on the website at headspaces.com.
They have a priority level that you can edit, and
they are listed so you can see which ones have been
most active recently. Issues are assigned keywords
so they can be classified and searched. To specify
keywords, put some words in square brackets in your
initial subject line, such as [nano upload]. If
you don't specify keywords, the system will pick
words from your subject.
4. Messages forwarded from the system will have a
number in curly-braces at the beginning of the
subject line, like {37}. This number identifies
the issue and causes further mail to collect on
the issue's web page.
5. When you reply to mail, preserve this id number
on your subject line. (A preceding "Re:" is no
problem.) You will be placed on the issue's
"nosy list" of interested parties, and your message
will get forwarded only to the other people on the
issue's list. If you "Cc:" anyone on your message,
they will also get added to the issue's list,
bringing them into the discussion.
6. If you want to join in on an issue after it has
already started, just go to the web page for the
issue (click on the issue id in the main list)
to catch up on all the discussion that has already
taken place. Join in by sending a message to
singularity(a)headspaces.com with the issue id as
the first thing in your subject line.
Of course, we are going to need a little discipline to
use the system best. For example, if an issue starts
to veer off-topic, please open a new issue so that
interested parties can join in. And when you're about
to create a new issue, have a look at the list of
existing issues first to see if there's already an issue
relevant to what you want to say.
It's a bit like running lots of mailing lists at once,
where creating a new list is effortless. You don't need
to worry about subscribing -- you just participate --
and you usually don't need to worry about unsubscribing:
issues will die down as they get resolved, and if a new
relevant point is raised, you will probably have wanted
to see it anyway. You can always edit the "nosy" field
of the issue directly if you need to.
As i mentioned in the closing session, the software is
new and experimental. We've used software like this where
i work, however, and it's worked out very well for us.
I hope that it helps keep the discussion going without
sending you an excessive volume of e-mail.
Please feel free to ask me any questions you have about
the system -- just reply to this message, and they will
become part of this issue.
Enjoy!
-- ?!ng
--<cut>--
And then consider how difficult that would be to implement under the
proposed Mailman v3 (I figure no more than a wekk (a few days more
like) over a default installation).
> Cool My grandkids might finish coding it... (giggle)
Uhh huh.
--
J C Lawrence claw(a)kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
I *think* I found two (more) bugs in Mailman, but my setup is sufficiently
hacked that I can't test it for sure. One of the two I tested on
python-list, and I think I saw it reproduced. The other one I'm not going to
test, because it's potentially destructive.
1) Subscription-confirmation-response-emails to *-request, with multiple
attachements, fail. The problem is that Mailman tries to interpret the MIME
boundary and content-type headers and what not as commands, rather than
taking the first attachement and parsing that. This wasn't a real problem
when I tested it on python-list, because my mailer doesn't put enough
headers in the first MIME part, but customers of ours have seen honest
problems with this. People mailing with HTML mail enabled, for instance, but
also people who get a signature attached to the email, without being able to
prevent it. This enforced signature is becoming more and more populair in
clueless paranoid companies :P
2) '\n.\n' screws up Mailman. This comes in two flavours :) If the '\n.\n'
sequence is late enough in the email, Mailman doesn't notice, and the rest
of the mail (including the '\n.\n') silently vanishes. If the sequence is a
bit higher, Mailman does notice: sendmail stops the transmission while
Mailman still has data to send. Mailman considers the mail not sent, and
tries again later -- but the first part of the mail is sent to all
recipients just fine.
This is a problem in particular with digests. One of our employees found out
she could skip the mailman-enforced signature by adding '\n.\n' to the end
of her own signature. She forgot about digests, however, and 5 other
employees got 300+ copies of the start of each digest, up to her signature.
Obviously, I don't want to test this on python.org's lists, unless Barry or
someone else is ready to edit the qfiles to remove the '\n.\n' sequence. Is
there a mailman-test-list on python.org or some 'vanilla' installation that
this could be tested on ?
--
Thomas Wouters <thomas(a)xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
I'm working on a design proposal for Mailman v3 and have arrived at
a few questions:
1) Is there a GPL distributed queue processing system ala IBM's MQ
about? I've not been able to find one. The specific problem
I'm attempting to solve in a performant manner is:
How does a given delivery process on a given system obtain
access to a message it is qualified to deliver with a minimum
of lock contention or other overhead while preventing any
other process from attempting to also access the message it
has acquired from that point forward, but while also allowing
another process to recover that message should the original
process or host fail?
Note that the queue directory and the delivery process may be
on different systems (eg NFS) and that there may be multiple
competing queue delivery processes on any given system as well
as across multiple systems.
NB Needs to be GPL as Mailman is a GNU project.
2) How much interest is there in optionally supporting VERP? I've
no interest in making Mailman v3 VERP-only, but I'd like to see
it as an option, and specifically, an option which can be
turned on and off dynamically on a configurable percentage of
posts basis (eg N% of the messages exploded from an arbitrary
list post are VERPed). I've got the basics worked out
(assuming the local MTA supports plus+addressing), but some of
the smaller bits are fiddly.
3) The current design requires messages to have MessageIDs which
are unique within the range of MessageIDs currently within the
new Mailman queue system (I'm using MessageIDs as the tag oc
choice for moderation by email). To do this, I'm proposing
that Mailman do a couple new things:
1) Insert MessageID headers with created values in messages
that don't contain any MessageID.
2) Detect collisions within its rather small/arbitrary
window, and auto-discard/reject messages subsequent messages
with a duplicate MessageID. This would not a rigorous dupe
check, but would only check for dupes against the messages
already in the Mailman queue (ie received and not yet sent
back out).
Any problems in messing with MessageIDs in this way?
I'm not keen on MessageID re-writing, however its worth noting
that the above two rules would only come into effect when the
mail system has already broken down at some level (MUA emitting
non-unique or no IDs, mail dupes, etc).
4) While it seems a subtlesmall point, its bugging me. Given user
account support, and messages to a given user bouncing, should
that user be unsubscribed from only that list, or from all
lists at that site? Where this is actually bugging me most is
for virtual domains and whether or not lists in a virtual
domains should be transparent or opaque to a bounce on a list
in a different virtual domain?
The admin in me says, "Hell yes!" The commercial reality nut
in me demurrs (think about list hosting for small companies and
their PR image given transparent virtual hosting).
For those interested the basic model is built upon arbitrary process
queues and pipes. Also please remember I'm coming up with a
proposal, not a mandate (ie Barry etc haven't seen or commented on
this yet).
--
J C Lawrence claw(a)kanga.nu
---------(*) : http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
On Thu, 14 Dec 2000 15:27:32 -0800
Chuq Von Rospach <chuqui(a)plaidworks.com> wrote:
> At 6:03 PM -0500 12/14/00, Barry A. Warsaw wrote:
>> Here's what I've been thinking about. There should be a
>> conceptual user account, with a primary key that may be internal
>> to the system.
> absoldefinitely. My current big machine uses the email address as
> the primary key in the databases. Makes sense at some level --
> until you realize the email address changes (a lot).
> So in the redesign I'm doing, I'm assigning a user_id to an
> account, and it's unique to that account. you can then attach an
> email address to the account, and not have to worry about it
> wandering out into the rest of the database so it's easy to
> update. (one of these minutes I'll finish the key parts of the
> schema and post it). Assigning multiple addresses to an account,
> and defining one as the "receiver" address and the rest as poster
> addresses is a small enhancement from there.
I *like* email-address based IDs. You can get the best of both
worlds with little effort much as you describe,
Abstract UserIDs are a nice idea that user's hate for the same
reason they hate passwords -- because it yet another abstract string
that they have to remember.
> true. in fact, I probably wouldn't advertise an account/login
> name. Instead, I'd use a password and any defined email, perhaps
> with a few carefully chosen heuristics to help find them if
> they're confused (for instance, users use earthlink.com and
> earthlink.net interchangeably).
Yeouch.
> And another option is "none" -- where Mailman is simply the
> delivery agent for an address system controlled elsewhere and whic
> users aren't allowed to update via Mailman. Once you start going
> to external databases, either they're likely to be holding stores
> for a standard mailman database, or they're likely to be severely
> restricted access, or read-only from the Mailman point of view.
This gets worse:
What about list "addresses" where the membership list is entirely
dynamic such that a message sent to it will be broadcast to a list
of addresses based on the content of the message?
Heck, remove the entire concept of mailing lists entirely and make
the very existance of a list and its configs and membership dynamic:
You send a message to <something>@lists.domain, Mailman receives
it, does an LDP query for every user with a <something> attribute
on their record, and broadcasts the message to that generated list
of addresses.
Marketeers will love thsi sort of thing when run against customer
databases. The advantage that an MLM brings to the table is in
scalability, bounce, and unsubscribe handling.
Account cusomisations (digests, metoo, nomail, etc) of course also
passes outside of Mailman's purview once account data goes outside.
>> Each mailing list in fact may have a vector of addresses to try
>> for this user. Perhaps there's a default for all lists unless
>> specifically overridden. Perhaps a user can create personal
>> distribution vectors and then can assign a distro vector to a
>> mailing list.
> As a side note -- if we do this, we need to make sure we can
> assign different addresses to different lists, all under the same
> account. So if someone wants to put eachlist to a different
> address, they can... that starts turning into an N x N mapping, so
> it can get complex (and it implies that the account has an account
> ID, whic points to 1 -> N email addresses, which each have an
> email ID, whic is what's used to do the actual subscription. So
> the schema starts getting complex...)
Its complicated until people get involved. Then it gets messy.
The problem is that this is an insolvable problem at our level.
Management is going to have one need, SysAdm another, and the end
users a third. At different times and different sites and in
different instances, each one is going to win some of the time.
We can't solve this one. What we can do is say:
If you are going to take control of membserhip list definition,
you have take control of all of it, and that encludes resolution
of ambiguities!
Not very pleasant mayhap, but whatever else we do someone is (quite
rightfully) going to scream
> I don't even WANT to start thinking about sharing user data across
> physical machines. Virtual hosts are enough joy here.
This is a problem we can handle by punting. We provide an internal
membership solution and make it easily replaceable by externals.
The external solutions can then do whatever their little masochistic
hearts desire, but yet again they have to take responsibility for
the whole problem, and that encludes ambiguity resolution.
> I"m of two minds here. One mind sees a reason why virtual hosts
> don't want to share -- but in that case, do we build this into the
> system, and if so, how? It's one set of data, and if they need to
> be left alone, aren't they better off running their own unique
> instance of mailman? (and can we validate the security of their
> data? I don't think we want to go there)
Virtual hosts are a hack, and an ugly hack at that. I don't see
that they are worth wasting time on when multiple installation
appeases the privacy concerns.
<<Prays busily for IPv6>>
--
J C Lawrence claw(a)kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
I made the same recommendation a few months ago. Later
scrutiny of how defer mode works (with 8.9.3, IIRC) uncovered that using
it caused relaying checks to be bypassed entirely. I retracted the
recommendation in early April:
http://csf.colorado.edu/archive/2000/mj2-dev/msg00219.html
Looking at the check_rcpt section of the stock configuration
files for sendmail 8.11.1, it appears that this is still the case.
If so, it is probably wise for administrators who, like me, have a
modest understanding of sendmail to use defer mode only on a restricted
interface.
Michael
On 14 Dec 09:48, Chuq Von Rospach wrote:
>
> Try setting
>
> O DeliveryMode=defer
>
> in your sendmail.cf. That causes sendmail to accept the mail without
> making a DNS lookup on it first. Note that this also implies
> DeliveryMode=queue, so stuff won't be delivered immediately. That
> means (if you already aren't) that you need to do queue runs
> aggressively using -q.
>
On Mon, 11 Dec 2000 19:27:06 -0800
Chuq Von Rospach <chuqui(a)plaidworks.com> wrote:
> At 7:16 PM -0800 12/11/00, J C Lawrence wrote:
>> Not exactly. My architecture has the ability to create messages
>> internally that are then passed back thru the processing system.
> oh, yeah. duh.
<snicker>
>> I kinda like the way you think.
> that should scare you...
According to my wife you should be terrified about now.
FWLIW I'm working on the following leading notes:
--<cut>--
Assumption: The localhost is Unix-like.
---
ObTheme: All config files should be human readable unless those
files are dynamically created and contain data which will be easily
and automatically recreated.
ObTheme: Unless a data set is inherently private to Mailman, Mailman
will not mandate a storage format or location for that data set, and
will allow that data set to be the result of a locally defined
abitrary replaceable process.
ObTheme: Every single program or process may be replaced with
something else, as long as that other thing accepts the same inputs,
generates outputs within spec, and performs a somewhat similar
function.
---
There are basically three approaches to scalability in use for this
sort of application:
1) Using multiple simultaneous processes/threads to parallelise
a given task.
2) Using multiple systems running parallel to parallelise a given
task.
3) Using multiple systems, each one dedicated to some portion(s)
or sub-set of the overall task (might be all working in
parallel on the entire problem (lock contention! failure
modes!)).
The intent is to be able to transparently support all three models
on a per-list basis or per-installation basis or some arbitrary mix
of the two (some sections of the problem for some lists handled by
dedicated systems, other sections of the problem for all the other
lists handled either by a different pool of systems or processes).
---
Observation: MLMs are primarily IO bound devices, and are
specifically IO bound on output. Internal processing on mail
servers, even given crypto authentication and expensive membership
generation processes (eg heavy SQL DB joins etc) are an order of
magnitude smaller problem than just getting the outbound mail off
the system.
Consider a mid-size list of 1K members. It is a busy list and
receives 500 messages a day, each of which is exploded to all 1K
members:
-- That's 500 authentication cycles per day.
-- That's 500 membership list generations.
-- That's 500,000 outbound messages
-- That's 500,000/MAX_RCPT_TOs SMTP transactions
Even given a MAX_RCPT_TOS of 500 (a bit large in my mind) that's 1K
high latency multi-process SMTP transactions versus 500 crytps
crypts or SQL queries.
---
Observation: In the real of MLM installations there are two end
points to the scalability problem:
1) Sites with lists with very large numbers of members
2) Sites with large numbers of lists which have few members.
Sites with large numbers of lists with large numbers of members (and
presumably large numbers of messages per list) are the pessimal
case, and is not one Mailman is currently targeting to solve.
The first case MLM is oubound bounnd. The second case may be local
storage IO bound as it spends significant time walking local
filesystems during queue processing which the outbound IO rates are
comparitively small (and unbursty). Possibly.
SourceForge falls into the second case.
---
Observation: Traffic bursts are bad. Minimally the MLM should
attempt to smooth out delivery rates to a given MTA to be no higher
than N messages/time. This doesn't mean the MLM doesn't deliver
mail quickly, just that in the case of a mail burst (suddenly
20Million messages sitting in the outbound queue), that the MLM will
give the MTA the opportunity to try and react intelligently rather
than overwhelming it near instantly with all 20M messages dumped in
the MTA spool over 30 seconds while the spool filesystem gags.
---
There are five basic transition points for a message passing thru a
mailing list server:
1) Receipt of message by local MTA
2) Receipt by list server
3) Approval/editing/moderation
4) Processing of message and emission of any resultant message(s)
5) Delivery of message to MTA for final delivery.
#1 is significant only because we can can rely on the MTA to
distinguish between valif list-related addresses and non-list
addresses.
#2 is just that. The message is received by the MLM and put
somewhere where it eill later be processed. The intent is that this
is a lightweight LDA process that does nothing but write queue
files. The MLM's business is to make life as easy as possible on
the MTA. This is part of that.
#3 Mainly occurs for moderation, and encludes editing, approval,
authentication, and any other requisite steps. The general purpose
of this step is to determine what (if any) subsequent processing
there will be of this message .
#4 Any requisite processing on the message occurs, and any messages
generated by that processing are placed int he outbound queue.
#5 An equivalent to the current queue runner process empties the
queue by creating SMTP transations for the entries in the queue.
The basic view I'm taking os the list server is that it is a staged
sequence of processes, each invokved distinctly, orchestrated in the
background by cron.
Note: Bounce processing and request processing re not detailed at
this point as their rate of occurance outside of DoS attacks is
comparitively low and are far cheaper than list broadcasts in
general.
---
List processing is a sequence of accepting a message, performing
various operations on it which cause state changes to the message
and the list processing system, and optionally emitting some number
of messages at the end.
As such this lends itself to process queues and process pipes.
---
We don't want an over-arching API, or the attempt to solve the
entire peoblem with either one hammer, or one sort of hammer. The
intent is to build something that the end user/SysAdm can adapt to
his local installation without either stretching or breaking the
model, and without needint to build an installation which is
necessarily structurally very different from either the very light
weight single machine small list system, or the larger
EGroups/Topica equivalent.
By using process queues based on cannonical names in known
filesystem locations and pre-defined data exchange formats between
processes we can make the processes themselves arbitrary black boxes
so long as they accept the appropriate inputs and generate the
expected output.
--<cut>--
--
J C Lawrence claw(a)kanga.nu
---------(*) : http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
On Thu, 14 Dec 2000 16:31:11 -0800
Chuq Von Rospach <chuqui(a)plaidworks.com> wrote:
> At 7:18 PM -0500 12/14/00, Barry A. Warsaw wrote:
>> It's not the MLM's problem (not to say it isn't the problem of
>> the simple-minded qrunner script we distribute and enable by
>> default). All I need to do is document the file format for the
>> outbound queue files and site administrators can take it from
>> there.
> except I see this as still part of the MLM, since it's the tool
> doing the MLM->MTA handoff, not part of the MTA itself.
We need to define what an MLM is and does: We're entering a scary
territory which goes far beyond the standard modesl of
subscriber-based list to more dynamic work-flow and collaborative
flow oriented entities where really the only thing the MLM does is
prove a named membership list, which it will yield on query after
passing some authentication mechanism such that the membership list
is associated with a particular message.
Actual delivery of messages, MTAs, transports, authentication
mechanisms, membership definitions, account definitions, etc, are
really outside of its purview. All an MLM does is provide names
which can be associated with lists of addresses, and a means for
associating those lists of addresses with a message.
--
J C Lawrence claw(a)kanga.nu
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--