On Fri, 15 Dec 2000 20:39:19 -0800 Chuq Von Rospach chuqui@plaidworks.com wrote:
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:
-- 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.
-- 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).
-- 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.
-- 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.
Okay, let's split this out. There are five levels and a pseudonymous sixth:
- Site owner -- SysAdm for the host
- Group owner -- Sets group defaults
- List owner -- Sets list defaults
- List moderator -- Controls day-to-day operation of list
- Member account -- Individual humans
- Email address
The site owner has CLI access etc. The Group owner runs, say, a vhost and defines the default for a class of lists as well as handling creation of lists within that class. The List owner configures and defines a given list. The list moderator implements the human side of enforcing list policy and handles the day to day chores of running a list (post approval etc). A member account subscribes to a given list with one or more of its email addresses, each of which has a configuration for that list which is unique to that email address.
But, this is slightly confusing and deceptive. A list moderator in the course of their normal duties may do the following (among other things):
-- Kick someone off a list -- State that all future posts from a given member will not be hand moderated -- State that the next N posts from a specific member will be hand moderated -- State that all future posts from a given member will not be hand moderated and will be automatically posted. -- Write an arbitrary note that is then associated with a member such that any moderator for that list will see that note when presented with data concerning that member (eg a post held for moderation).
In each case what the list moderator sees in terms of the definition of the member, and what they define the above actions against, is an email address. They flag email address XXX as being hand moderated from here out. They do something else to email address YYY.
My point however is that in the general case for these commands, the list owner is actually not interested in a specific email address, but in the account. When the moderator decides to auto-approve a specific account for autoposting, he generally is intending to approve the human and not just the one email address.
Yes, that Chuq guy posts signal. Please auto-post everything he writes. That claw guy however is a dweeb and keeps argiung about stoopid things. I want to hand moderate all his posts from here on.
While moderatator decisions are typically phrased in terms of email addresses, the actual intent is typically in terms of humans.
There are of course exceptions:
I want to hand moderate all his posts from his work address because they auto-append legal cruft I want to delete.
He only posts from Yahoo when he's drunk -- unsubscribe that address.
And a host of others. Of course account groupings (dealing by human above) can be approximated by just issueing enough commands for every intersection of an account and a list (should you know the intersections), but that's a royal pain. If I as moderator decide that Bubba is just a source of noice and really needs to be kicked from my list I want all of his addresses kicked, not just the one, and in fact I want my list config to remember that fact so that should Bubba try and re-join he's either auto-refused or his subscription is held for moderator approval (depsite the fact that everyone else gets let thru automatically).
We need to be able to implement moderator rulings at both the address and account levels. This does not mean that a moderator should be able to query, "show me all the addresses that re part of account XXX", but that he should be able to issue a command which summates to:
Do XXX to every intersection of the account that owns email address EEE and this list.
Where XXX and EEE are arbitrary.
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.....)
While there is a data leak, yes, there isn't in the general case, and should that fact be of sufficient concern the admin command processing ionterface (which I'm looking at in exactly the same replaceable compnonent manner as members, and everything else) can be replaced with something that will *ONLY* process addresses (and which quite likely removes all concept of member accounts in the first place.
My intent above is not to build a system that approaches a Grecian Ideal, but to build something that is maximally workable for both list members and list moderators, and which can be adapted towards local definitions of "ideal".
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.
I'm not arguing against mailback validation. I consider that's actually a very good thing (as it demonstrates control of the address and some level of ackknowledgemnt of the change).
I think we're talking across each other. There is nothing that can prevent the following:
I create a hotmail account.
I subscribe that hotmail account to 500 lists of various flavours.
I now configure that hotmail account to auto-forward all received messages to <person_I_don't_like>
There is nothing we can do about this because the forwarding decision is outside of our control or purview. The subscriptions were perfectly legitimate from our stance -- they were acknowledged and everything. Its the forwarding decision that was bad, and that we had nothing to do with.
For those interested the reverse vector of this just happened to a list I'm on. Some fine fellow got a Hotmail account, subscribed it to several dozen porn lists and then forwarded that account to the list I was on (which had open posting).
We can't stop it. We can't eevn impede it other than by applying standard authentication rules to incoming posts (envelope, From:, whatever).