Mailman-Developers December 2000

mailman-developers@python.org

39 participants
73 discussions

Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
by J C Lawrence 17 Dec '00

17 Dec '00

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 |=--

1 0

Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
by J C Lawrence 16 Dec '00

16 Dec '00

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 |=--

2 1

Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
by J C Lawrence 16 Dec '00

16 Dec '00

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 |=--

2 1

Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
by J C Lawrence 16 Dec '00

16 Dec '00

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 |=--

1 0

2 bugs, but I need a confirmation :-)
by Thomas Wouters 15 Dec '00

15 Dec '00

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!

3 3

(no subject)
by J C Lawrence 15 Dec '00

15 Dec '00

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 |=--

4 9

Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
by J C Lawrence 15 Dec '00

15 Dec '00

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 |=--

3 4

Re: Slow Performance on semi-large lists
by Michael Yount 15 Dec '00

15 Dec '00

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. >

3 3

Re: [Mailman-Developers] (no subject)
by J C Lawrence 15 Dec '00

15 Dec '00

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 |=--

3 12

Re: [Mailman-Developers] Responsiveness
by J C Lawrence 15 Dec '00

15 Dec '00

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 |=--

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers December 2000