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

[J C Lawrence]

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:

  1) Site owner     -- SysAdm for the host
  2) Group owner    -- Sets group defaults
  3) List owner     -- Sets list defaults
  4) List moderator -- Controls day-to-day operation of list
  5) Member account -- Individual humans
  6) 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).

-- 
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--