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

[Chuq Von Rospach]

At 7:59 PM -0500 12/14/00, Barry A. Warsaw wrote:
>
>     CVR> Instead, I'd use a password and any defined email, perhaps
>     CVR> with a few carefully chosen heuristics to help find them if
>     CVR> they're confused (for instance, users use earthlink.com and
>     CVR> earthlink.net interchangeably).
>
>Hadn't thought about that, and that is a good point.

you learn these the hard way. Guess how many ways there are to 
misspell hotmail.com...

>Right.  I don't think 100% coverage is necessary.

My motto: get the first 90% right, then work on the next 90% of 
what's left. Especially with email, 100% solutions don't exist, 
because of disasters like lotus notes and other non-conformant 
systems.

>Here's another complication: are the delivery options set per-address
>or per-list?  Maybe I want all deliveries to "barry at wooz" to be
>digests.  Maybe I want lists A, B, and C to be regular deliveries.

Neither, really.

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.)

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

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.

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.

>  A MailingList might actually want to deliver to multiple
>Rosters, which is where I think the umbrella list stuff could be
>improved.  I.e. you have a Roster for mailman-developers and a Roster
>for mailman-users and mailman-announce contains a computed Roster
>composed of those first two, along with it's own Roster.  Now you send
>a message out to mailman-announce and everybody gets it (although what
>do you do about Subject: munging, footer addition List-* headers and
>the like?).

and you need to do duplicate supression, too. I think the headers 
have to come from the list subscribed to, because that's the list the 
user will try to ujnsubscribe from, and all the documentation in the 
world won't explain why headers for mailman-announce won't work for 
you because you're really on mailman-users.

>  I also see creation of Rosters for list owners, site
>administrators and so on, so you could do things like compute a Roster
>for all-list-owners@mysite.com if you had urgent information for your
>list admins.

and a meta-list for all subscribers for the same.

But then you get into the issue of who has permission to post to 
what, and you end up with an authentication database (which is not a 
bad idea, FWIW.) Especially if you want ot get into whether the site 
admin wants to allow list admins to set reply-to coercion or not...


>     CVR>  -- you have an
>     CVR> audit trail back to the person, so if they decide to try to
>     CVR> spam someone you know who they are, and who to shoot. As long
>     CVR> as you don't lose the authenticity trail, once is all you
>     CVR> need (that would, I think, require authenticating another
>     CVR> address before allowing deletion of the one that's
>     CVR> authenticated, and disabling any account when all of the
>     CVR> authenticated addresses are disabled by bounce processing...)
>
>I'm concerned about the scenario where I subscribe to a list, then add
>your address to my account, then disable my address because I'm "going
>on vacatin".

I thought about it at the hockey game, and now I disagree with 
myself. all addresses are validated. Otherwise, it gets gnarly. 
First, if you validate an address and add others, and the first 
bounces -- what do you do? you can't subscribe the others until 
they'r evalidated. That is the wrong time from user expectation to 
ask for that. At best, you confuse the hell out of someone.

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

So yea, on further review, forget i suggested that.

>

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

We're visiting the relatives. Cover us.