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