[Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))

[J C Lawrence]

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