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

[Chuq Von Rospach]

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.

It complicates bounce processing some, but a well-designed search 
system onto the email address (more on that later, if there's 
interest) gets around it. turns out you rarely have to do brute force 
searches for an address if you put a little thought into it.

>I contend that people will remember (one of) their email addresses
>better than they will remember a login name they've had to specially
>craft for the site.

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). You still have problems wehre companies re-arrange 
their e-mail name space and don't tell the workers (and that happens 
more often than you might think) but leave in aliases for the old 
names, but you won't get 100%.

To get into the account, you need one email address attached to it, 
and the password. To get the passowrd, you need to know any attached 
email address, and it's sent to that address. That way, they don't 
need to remember anything, but if they want to, they can.

>Authentication gets trickier when we're pulling users from external
>databases.  Do we authenticate with the userid/password of that
>external database?  Create our own for the mailing list account?  I
>suspect we may need to allow multiple authentication paths for each
>user.

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.

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

>To add a new address to your distro vector, a confirmation transaction
>will have to be approved by both an address on the vector already, and
>the new address being added to the vector.

After the first one, why? (note for future mumuring: leave an 
interface for the ability to build different validation setups, or 
allow them to validate via one of many. don't hardware mailbacks as 
THE validation setup...) -- you have an audit trail back to the 
person, so if they decide to try to spam someone you know who they 
are, and who to shoot. As long as you don't lose the authenticity 
trail, once is all you need (that would, I think, require 
authenticating another address before allowing deletion of the one 
that's authenticated, and disabling any account when all of the 
authenticated addresses are disabled by bounce processing...)

>So what about virtual domains?

Um, well... At a high level, it's simply another table in the schema, 
where you attach a host (and associated UI) around the core of 
mailman. So you could potentially (he says hopefully) have a list 
live on multiple domains, or even the same domain under multiple UIs 
through careful abuse of this interface...

(why do the latter? how about allowing me to have a "test" UI on the 
domain for development purposes, but having two 'mailman systems' on 
one virtual host under two URLs?)

>What I mean is, that I'm a member of 10 lists on python.org, 3 or 4 on
>zope.org, a dozen on SourceForge, and handfuls on other sites.  We can
>excuse the non-Mailman sites their shortsightedness, but I would
>really love to be able to manage my subscriptions to all those lists
>in a seamless, transparent manner.

but -- maybe the sites don't want that done? For marketing purposes, 
for identification purposes, for whatever purposes?

I don't even WANT to start thinking about sharing user data across 
physical machines. Virtual hosts are enough joy here.

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)

But my other mind looks at trying to do all this, and shudders. So I 
guess I'm in the school, at least right now, of saying "we have one 
mailman engine, N lists, M vhosts. And for every vhost, there are a 
subset of those N lists published, but if you access the admin page 
through that vhost, you get that vhost's UI -- but it's a portal into 
the global mailman data setup. If they have to be kept separate, run 
multiple instances of mailman with separate data stores.

The only burble I have with that is -- making sure the user knows 
where a given list exists in the space, so they can access it if they 
run into it while doing admin on a site where it's not published. 
Either that, or (I'd probably prefer it this way) you can't get info 
on subscribing to a list from other than a vhost it's advertised on, 
but anythign you're already subscribed to, you can manage. Basically, 
i guess, I'm treating public lists on other vhosts as private lists 
on this vhost... (I think that works. yet?))


-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

We're visiting the relatives. Cover us.