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

[Barry A. Warsaw]

Cool, I've read through this thread and I think I see where you're
heading.  I like a lot of what you guys have posted, and much of it I
agree with.  I need to break down the separate threads so that each
can be captured in the Wiki for posterity.

>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

    JCL> 4) While it seems a subtlesmall point, its bugging me.
    JCL> Given user account support, and messages to a given user
    JCL> bouncing, should that user be unsubscribed from only that
    JCL> list, or from all lists at that site?  Where this is actually
    JCL> bugging me most is for virtual domains and whether or not
    JCL> lists in a virtual domains should be transparent or opaque to
    JCL> a bounce on a list in a different virtual domain?

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.
Users can associate multiple email addresses with their account and
can authenticate with the system using any of these addresses as their
login.  Any one of those email addresses can be deleted at any time
with no restrictions, or the entire account can be wiped.

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.  Plus, it's likely they've already crafted some
unique login @aol.com or @hotmail.com, so why have to potentially
craft and remember yet another one just to interact with Mailman at
this site?  I'm leary about having shorter login names as
abbreviations of the email address because today's unique-to-5-chars
login may be tomorrow's collision.

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.

Once authenticated, a user can edit their options, one of which is a
mapping of email addresses in their account to mailing lists.  They
want to join mailman-users with "barry at digicool.com" but dc-bass
with "barry at wooz.org".  They can do this on their options pages.

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.

When an address is disabled due to bouncing, Mailman can fallover to
the next address in the distro vector.  This way, users can plan ahead
if they know they're moving.  Plus it gives Mailman a way to notify a
user when their primary delivery address begins to hard fail.

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.  The actual mechanism of
this confirmation will be discussed in a separate thread.

So what about virtual domains?

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> I unsubscribe from the site. I'm sure at some point, an email
    CVR> sent from A might bounce and still be valid if sent from B,
    CVR> but that case is so rare I wouldn't think of wasting time on
    CVR> it, because the only way I can see taht happen (minus broken
    CVR> systems, of course) is someone who decides to try to
    CVR> unsubscribe by blocking a list, isntead of following the
    CVR> directions. And I don't see we need to write code into
    CVR> mailman to help users not follow the instructions.... (grin)

Agreed.

    CVR> since we've talked about a single data store for subscriber
    CVR> data, I think you do it globally. If they really want
    CVR> opaqueness across virtual domains, run mujltiples copies of
    CVR> Mailman. that'll still be an option, after all.

I completely agree.  In fact, as a user I probably want /more/
globalization of my options and distro vectors, not less.  That may be
at odds with what some sites want, but too bad.  They either run
multiple copies or hack the code themselves.

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.

Maybe this is done by editing my accounts with an app on my local
system that interfaces to all those Mailmen via CORBA.  Maybe it's a
Java applet that I configure locally with the list of sites, and it
screenscrapes and presents a consolidated view to me.  Maybe it only
works with a cooperative federation of Mailmen sharing ZEO
connections.  Whatever.  I'm not expecting this to be implemented
first, or even ever, but it's my vision of how a user /should/ be able
to interact with the system.

-Barry