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

Chuq Von Rospach chuqui@plaidworks.com
Fri, 15 Dec 2000 20:39:19 -0800


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.