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

[Barry A. Warsaw]

    CVR> So in the redesign I'm doing, I'm assigning a user_id to an
    CVR> account, and it's unique to that account. you can then attach
    CVR> an email address to the account, and not have to worry about
    CVR> it wandering out into the rest of the database so it's easy
    CVR> to update. (one of these minutes I'll finish the key parts of
    CVR> the schema and post it). Assigning multiple addresses to an
    CVR> account, and defining one as the "receiver" address and the
    CVR> rest as poster addresses is a small enhancement from there.

Very cool.

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

Good.

    CVR> true. in fact, I probably wouldn't advertise an account/login
    CVR> name.

I agree.
    
    CVR> Instead, I'd use a password and any defined email, perhaps
    CVR> with a few carefully chosen heuristics to help find them if
    CVR> they're confused (for instance, users use earthlink.com and
    CVR> earthlink.net interchangeably).

Hadn't thought about that, and that is a good point.
    
    CVR> You still have problems wehre companies re-arrange their
    CVR> e-mail name space and don't tell the workers (and that
    CVR> happens more often than you might think) but leave in aliases
    CVR> for the old names, but you won't get 100%.

Right.  I don't think 100% coverage is necessary.  I really want to
handle the situations where someone knows his email is going to
change, or one where they purposely want different lists to deliver to
different addresses.

Here's another complication: are the delivery options set per-address
or per-list?  Maybe I want all deliveries to "barry at wooz" to be
digests.  Maybe I want lists A, B, and C to be regular deliveries.

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

Agreed.

    CVR> And another option is "none" -- where Mailman is simply the
    CVR> delivery agent for an address system controlled elsewhere and
    CVR> whic users aren't allowed to update via Mailman. Once you
    CVR> start going to external databases, either they're likely to
    CVR> be holding stores for a standard mailman database, or they're
    CVR> likely to be severely restricted access, or read-only from
    CVR> the Mailman point of view.

Good point.

    CVR> As a side note -- if we do this, we need to make sure we can
    CVR> assign different addresses to different lists, all under the
    CVR> same account.

Yup, absolutely, which is why I posed the config option question
above.
    
    CVR> So if someone wants to put eachlist to a
    CVR> different address, they can... that starts turning into an N
    CVR> x N mapping, so it can get complex (and it implies that the
    CVR> account has an account ID, whic points to 1 -> N email
    CVR> addresses, which each have an email ID, whic is what's used
    CVR> to do the actual subscription. So the schema starts getting
    CVR> complex...)

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.  A MailingList might actually want to deliver to multiple
Rosters, which is where I think the umbrella list stuff could be
improved.  I.e. you have a Roster for mailman-developers and a Roster
for mailman-users and mailman-announce contains a computed Roster
composed of those first two, along with it's own Roster.  Now you send
a message out to mailman-announce and everybody gets it (although what
do you do about Subject: munging, footer addition List-* headers and
the like?).  I also see creation of Rosters for list owners, site
administrators and so on, so you could do things like compute a Roster
for all-list-owners@mysite.com if you had urgent information for your
list admins.

    CVR> After the first one, why? (note for future mumuring: leave an
    CVR> interface for the ability to build different validation
    CVR> setups, or allow them to validate via one of many. don't
    CVR> hardware mailbacks as THE validation setup...)

Agreed (and I have some thoughts on the mailback thread which I'll try
to get to separately).
    
    CVR>  -- you have an
    CVR> audit trail back to the person, so if they decide to try to
    CVR> spam someone you know who they are, and who to shoot. As long
    CVR> as you don't lose the authenticity trail, once is all you
    CVR> need (that would, I think, require authenticating another
    CVR> address before allowing deletion of the one that's
    CVR> authenticated, and disabling any account when all of the
    CVR> authenticated addresses are disabled by bounce processing...)

I'm concerned about the scenario where I subscribe to a list, then add
your address to my account, then disable my address because I'm "going
on vacatin".  Now suddenly you're getting flooded with postings that
make no sense to you.  You don't know anything about Mailman, so
you're not even sure where to start complaining.  And it could get
very annoying very quickly.  Sure, once the admins are aware of the
problem they can trace it back to me and I'll get slapped around, but
in the meantime you're really pissed off.  Where if your address was
confirmed when I tried to add it, you might still be pretty confused,
but you shouldn't be annoyed.  (Come to think of it, without
protections, this is a nice annoyance spam route or DoS).

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

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

No doubt.  It's what I as a user of Mailman want though. :)

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

No, no, no, neither do I.  I was just musing.  Not to be seriously
considered for 3.0 (if at all!).

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

I'm firmly in agreement.

    CVR> Either that, or (I'd probably prefer it this way) you can't
    CVR> get info on subscribing to a list from other than a vhost
    CVR> it's advertised on, but anythign you're already subscribed
    CVR> to, you can manage. Basically, i guess, I'm treating public
    CVR> lists on other vhosts as private lists on this vhost... (I
    CVR> think that works. yet?))

Yes, that's what I've been thinking too.

-Barry