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

[Chuq Von Rospach]

At 6:27 PM -0800 12/14/00, J C Lawrence wrote:

>I *like* email-address based IDs.  You can get the best of both
>worlds with little effort much as you describe,

But it gets gnarly fast. Trust me. I'm slogging around 
umpty-bazillion of them in my database every day. it makes Change of 
address ugly, nad it's also a long string, which can affect your 
searching and linking performance.

>Abstract UserIDs are a nice idea that user's hate for the same
>reason they hate passwords -- because it yet another abstract string
>that they have to remember.

that's why I don't think the user ever sees it. No need for them to. 
I'm using the ID to do table linkiing as primary key, but presenting 
the email address to the user as their external identifier. it's just 
then that when they COA the address, none of the table relationships 
have to be changed, just the email table.

>  > they're confused (for instance, users use earthlink.com and
>>  earthlink.net interchangeably).
>
>Yeouch.

man, you don't want to know some of the things users do consistently. 
let's nt even talk about what MSN has done to its users 
(email.msn.com? classic.msn.com? msn.com?), or worldnet, or (sigh) 
compuserve (numerics, anyone? how about .cs.com instead of 
compuserve.com? yada yada). Or users who put spaces into their names 
like AOL lets them. Or....

>  > And another option is "none" -- where Mailman is simply the
>>  delivery agent for an address system controlled elsewhere and whic
>>  users aren't allowed to update via Mailman. Once you start going
>>  to external databases, either they're likely to be holding stores
>>  for a standard mailman database, or they're likely to be severely
>>  restricted access, or read-only from the Mailman point of view.
>
>This gets worse:

and -- lest we forget -- we always have the option of drawing lines 
in the sand and saying "this we don't do. This we can't do. this we 
do later. This we leave an API, and if you want it, submit the 
results...

>Heck, remove the entire concept of mailing lists entirely and make
>the very existance of a list and its configs and membership dynamic:
>
>   You send a message to <something>@lists.domain, Mailman receives
>   it, does an LDP query for every user with a <something> attribute
>   on their record, and broadcasts the message to that generated list
>   of addresses.

you just defined the server I'm looking at rewriting, probably next 
summer. We did a preliminary of that a couple of months ago. it gets 
-- well, very interesting.

>Marketeers will love thsi sort of thing when run against customer
>databases.  The advantage that an MLM brings to the table is in
>scalability, bounce, and unsubscribe handling.

not necessarily. (he says, carefully). That's one reason my really 
big machine is fully custom. Nobody could do it the way it was 
needed, at the scale it was needed. And many times, they don't WANT 
all the features or offer the user that many choices. or have needs 
that aren't easily transmogrified into a MLM's paradigm. By the time 
Mailman gets to this point, it might (or might not) handle my big 
machine, but by then, my big machine will be headed off into other 
directions again that Mailman won't be able to touch (and I really 
can't say more than that...), but I've actually got the next two 
years work on the big machine, more or less, drafted out already.

>Account cusomisations (digests, metoo, nomail, etc) of course also
>passes outside of Mailman's purview once account data goes outside.

and you start running into data ownership issues up the ying yang. 
that was something my site-subscriber thingie was aimed at starting 
to deal with, how you can have an integrated subscription service to 
a site with a shared data suite and multiple sets of integrated data 
that's specific to diffferent modules and private from each other.

>Its complicated until people get involved.  Then it gets messy.

let's just forget the people, and write ;systems that only computers 
can opperate. Easier that way...

>The problem is that this is an insolvable problem at our level.

I'm not sure I agree. But it's going to come down to authentication 
and ownership of data, and perhaps down to the column tlevel. 
Definitely to the table level. An d it's going to require work to do 
right and avoid security issues.

>Management is going to have one need, SysAdm another, and the end
>users a third.  At different times and different sites and in
>different instances, each one is going to win some of the time.
>
>We can't solve this one.

yes we can, at least to a good degree, through careful authentication 
and hierarchies of data, with the possibility of data delegation. And 
that is both at the people level (site mom authorizes list mom to 
operate a list and set the subject notice, but not coerce reply-tos. 
List mom authorizes content dude to moderate messages, but not tweak 
list configurations.) but at the procedure level. Which actually 
sounds gnarlier than it is.

>Virtual hosts are a hack, and an ugly hack at that.  I don't see
>that they are worth wasting time on when multiple installation
>appeases the privacy concerns.

they're a necessary hack, too. We can't blow them off trivially. *I* 
need them for various things.

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

We're visiting the relatives. Cover us.