Re: [Mailman-Developers] Users, Bounces, and Virtual Domains (was (no subject))
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 |=--
At 2:52 PM -0800 12/15/00, J C Lawrence wrote:
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.
I disagree with this. The way I see it is this:
o Site admin: he has overall control of the mailman installation, and manages the system. He has CLI access, and admin access to all lists. Basically, he's god.
o List admin: manages a list on the site. He controls subscription policies and configuration setups for that list, unless the site admin has locked a value (for instance, teh site admin can lock reply-to coercion for a site-wide standard).
o list moderator: handles message approval or denial. May be list admin, but it's a separate function. you may not want a moderator to ahve access to list configuration options.
o list user: manages an individual account.
list admins don't deal with accounts, per se. They set list defaults that are adopted by the user when they subscribe, and whcih can be modified by the user, unless a list admin locks a value (no digest, for instance). List admins have address maintenance duties,but I think that's different than what you're implying here. List admins dn't act on a user or account 9except to fix something on request), the act on lists.
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.
agreed.
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.
I'm not sure I agree. here's why. Let's go back to my "subscribe N addresses to a list from account M", to allow them to be configured differently. The relationship for the list is to the email address, not the acccount, but the API has to have a function that allows you to query whether this address is a valid address. For privacy reasons, I don't think you hand over the addresses that aren't subscribed, but instead, you hand off an address and ask whether it can be allowed to post. I think you create a data leak by linking to the account that you don't want here, and you remove the ability to multiply subscribe to a list -- and while there aren't a lot of people who do this, I *do* know people who are subscribed both to messages and digests to lists, and want that option. (I do, too, when I'm developing or testing MLM stufff.....)
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.
It is, because we're the tool being used. By validating the address when it's added to the list, you simplify the user experience, make it easier on Mailman, and inhibit this attack significantly because the luser will (we hope) know he'll get flagged immediately and so not use us for the attack, and failing that, the attack-ee will be warned early that something is happening and hopefully be able to stop it before it hits hard.
it's a win win sitaution, since vallidating is waht the user is going to expect, makes our processing easier, and limits exposure to this attack. And it basically has no significant negative I can think of.
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
We're visiting the relatives. Cover us.
participants (2)
-
Chuq Von Rospach -
J C Lawrence