Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
On Thu, 14 Dec 2000 15:27:32 -0800 Chuq Von Rospach <chuqui@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@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--
"JCL" == J C Lawrence <claw@kanga.nu> writes:
JCL> What about list "addresses" where the membership list is
JCL> entirely dynamic such that a message sent to it will be
JCL> broadcast to a list of addresses based on the content of the
JCL> message?You've just described Roundup's nosy lists:
http://software-carpentry.codesourcery.com/entries/track/Roundup/Roundup.htm...
T'would be very cool to support this in Mailman. I'm calling this Computed Rosters.
JCL> If you are going to take control of membserhip list
JCL> definition, you have take control of all of it, and that
JCL> encludes resolution of ambiguities!Excellent point. I agree.
-Barry
On Thu, 14 Dec 2000 21:57:08 -0500 Barry A Warsaw <barry@digicool.com> wrote:
You've just described Roundup's nosy lists:
http://software-carpentry.codesourcery.com/entries/track/Roundup/Roundup.htm...
Brilliant stuff!
-- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--
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?
Cool My grandkids might finish coding it... (giggle)
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
We're visiting the relatives. Cover us.
At 6:27 PM -0800 12/14/00, J C Lawrence wrote:
I *like* email-address based IDs. You can get the best of both worlds with little effort much as you describe,
But it gets gnarly fast. Trust me. I'm slogging around umpty-bazillion of them in my database every day. it makes Change of address ugly, nad it's also a long string, which can affect your searching and linking performance.
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.
that's why I don't think the user ever sees it. No need for them to. I'm using the ID to do table linkiing as primary key, but presenting the email address to the user as their external identifier. it's just then that when they COA the address, none of the table relationships have to be changed, just the email table.
they're confused (for instance, users use earthlink.com and earthlink.net interchangeably).
Yeouch.
man, you don't want to know some of the things users do consistently. let's nt even talk about what MSN has done to its users (email.msn.com? classic.msn.com? msn.com?), or worldnet, or (sigh) compuserve (numerics, anyone? how about .cs.com instead of compuserve.com? yada yada). Or users who put spaces into their names like AOL lets them. Or....
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:
and -- lest we forget -- we always have the option of drawing lines in the sand and saying "this we don't do. This we can't do. this we do later. This we leave an API, and if you want it, submit the results...
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.
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.
not necessarily. (he says, carefully). That's one reason my really big machine is fully custom. Nobody could do it the way it was needed, at the scale it was needed. And many times, they don't WANT all the features or offer the user that many choices. or have needs that aren't easily transmogrified into a MLM's paradigm. By the time Mailman gets to this point, it might (or might not) handle my big machine, but by then, my big machine will be headed off into other directions again that Mailman won't be able to touch (and I really can't say more than that...), but I've actually got the next two years work on the big machine, more or less, drafted out already.
Account cusomisations (digests, metoo, nomail, etc) of course also passes outside of Mailman's purview once account data goes outside.
and you start running into data ownership issues up the ying yang. that was something my site-subscriber thingie was aimed at starting to deal with, how you can have an integrated subscription service to a site with a shared data suite and multiple sets of integrated data that's specific to diffferent modules and private from each other.
Its complicated until people get involved. Then it gets messy.
let's just forget the people, and write ;systems that only computers can opperate. Easier that way...
The problem is that this is an insolvable problem at our level.
I'm not sure I agree. But it's going to come down to authentication and ownership of data, and perhaps down to the column tlevel. Definitely to the table level. An d it's going to require work to do right and avoid security issues.
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.
yes we can, at least to a good degree, through careful authentication and hierarchies of data, with the possibility of data delegation. And that is both at the people level (site mom authorizes list mom to operate a list and set the subject notice, but not coerce reply-tos. List mom authorizes content dude to moderate messages, but not tweak list configurations.) but at the procedure level. Which actually sounds gnarlier than it is.
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.
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
We're visiting the relatives. Cover us.
participants (3)
-
barry＠digicool.com -
Chuq Von Rospach -
J C Lawrence