On Thu, 14 Dec 2000 23:36:28 -0800 Chuq Von Rospach <chuqui@plaidworks.com> wrote:
For every account, you can subscribe one or more address to a list. For every address subscribed, you have a set of list options. So a person could get both the messages and digest to separate addresses, and have a third address validated for posting but get nothing. Useful if that person is doing offline munging into a private archive (or if you're using this form to gateway into some scripting system as the admin, where the scripting isn't tied into Mailman. you could then have a single account, but attach all of the gateway addresses to it, and configure each one separately. Much neater administratively.)
We can generalise usefully here and punt the rest of the problem into end-user configuration space. I suggest we make the following divide:
At the general level list owners/moderators deal with accounts, not email addresses. They set moderation controls etc on accounts. It is an account that subscribes to a list, resulting in every address on that account being a "member" etc.
Equally, at the general level, from a member's view, participation in a list is configured at the email address level. This address will or will not receive postings, and has this specific configuration in regard to that list.
AccountX/AddressY is on ListZ and receives mail from ListZ. ListOwner for ListZ approves AccountX for automatic posting to the list (no moderation). AccountX/AddressQ then posts to the list, and has his post go straight thru as his *account* is approved, not the posting address.
If someone wants something different they can get something different by taking responsibility for the membership problem in its entirety and doing something else (sbclassing, plugins, et al as previously discussed). However the above does what users natively expect: They, the human, joined the list, and the list therefore should be intelligent enough to know that even tho they subscribed with their work email address, when they post from home or from hotmail that it really is them and not some anonymous stranger.
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.
Let me think about this in pseudo-SQL terms a sec.
A user creates an account. that is given an acct_id, which is unique to the system. He attaches 1..N email addresses to his account. Each email gets an email_ID, which is also unique to the system, so we now have a 1-> mapping from account to a set of email addresses. One or more of these addresses have been validated in some way to guarantee ownership.
<nod>
question: are email addresses unique to the system? to the user? I'd argue they have to be, if for no other reason than if foo@bar.com is attached to two accounts and someone logs on via it, which acct does he get? So email addresses are unique but you can't use the email address as the primary key because it changes. So any time you add one or change one, you have to validate against uniqueness before accepting it.
Precisely.
from the other side, the admin creates a list, which is assigned a list_id. when a user subscribes to that list, the relationship is between a user's email_id and the list_id, and there's a unique set of preferences attached to that relationship. the only way a list can find out who the user is is to refer back through the list_id to get the account_id, which, frankly, I don't think we want to allow anyway, on privacy issues. you only get the information you need to do the job.
Of course. We don't reveal that data to the list owner. However the decisions that the list owner makes in regard to a given address are applied to the account, not the address.
Yes, this means that with sufficient experiementation and observation, a list owner could deduce most of an account definition ("I approved address XXX for posting and now YYY is also approved? They must be on the same account!". I don't see that as a problem.
Second, it opens you up to mailforward attacks (create a hotmail account. Sign up for 900 lists. Forward that account to someone you hate. disappear). At least with validations, a user sees it coming, and knowing they'll get warning, it'll only get used by stupid users...
I don't see this as our problem, simply because its not one we either have control over or can defend against.
-- J C Lawrence claw@kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--