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

[J C Lawrence]

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 |=--