From friedrich@pythonpros.com Thu Feb 26 22:23:40 1998 From: friedrich@pythonpros.com (Robin Friedrich) Date: Thu, 26 Feb 1998 16:23:40 -0600 Subject: List entry indexing Message-ID: <34F5EB6C.4F37CD1E@pythonpros.com> In a prior round of email, Ken mentioned that we would need to key the mail list entries to something other than the person's actual email address in order to implement the flexible user information editing capability of the web (changing one's sendto address, etc.). I agree that this is needed, sooner or later. Since I haven't seen the code yet, how difficult is it to just make a unique key for each subscriber and key the database off that with address as just one value? I hope I'm not using this list too soon. -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich@pythonpros.com http://www.pythonpros.com From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Feb 26 22:34:00 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 26 Feb 1998 17:34:00 -0500 (EST) Subject: [Mailman-developers] List entry indexing References: <34F5EB6C.4F37CD1E@pythonpros.com> Message-ID: <13557.60757.153547.236351@anthem.CNRI.Reston.Va.US> >>>>> "RF" == Robin Friedrich writes: RF> In a prior round of email, Ken mentioned that we would need to RF> key the mail list entries to something other than the person's RF> actual email address in order to implement the flexible user RF> information editing capability of the web (changing one's RF> sendto address, etc.). I agree that this is needed, sooner or RF> later. Since I haven't seen the code yet, how difficult is it RF> to just make a unique key for each subscriber and key the RF> database off that with address as just one value? I haven't looked at the code either, but you could default to using the mailbox as the name key to start with, and then just append unique numbers to this if there are duplicates. I wonder if there should be some way that a user can change keys, or specify different defaults, say if their mailbox is Some.Really.Long.Name@mean.com. -Barry From friedrich@pythonpros.com Thu Feb 26 22:53:26 1998 From: friedrich@pythonpros.com (Robin Friedrich) Date: Thu, 26 Feb 1998 16:53:26 -0600 Subject: [Mailman-developers] List entry indexing References: <34F5EB6C.4F37CD1E@pythonpros.com> <13557.60757.153547.236351@anthem.CNRI.Reston.Va.US> Message-ID: <34F5F265.294A8899@pythonpros.com> Barry A. Warsaw wrote: > >>>>> "RF" == Robin Friedrich writes: > > RF> In a prior round of email, Ken mentioned that we would need to > RF> key the mail list entries to something other than the person's > RF> actual email address in order to implement the flexible user > RF> information editing capability of the web (changing one's > RF> sendto address, etc.). I agree that this is needed, sooner or > RF> later. Since I haven't seen the code yet, how difficult is it > RF> to just make a unique key for each subscriber and key the > RF> database off that with address as just one value? > > I haven't looked at the code either, but you could default to using > the mailbox as the name key to start with, and then just append unique > numbers to this if there are duplicates. I wonder if there should be > some way that a user can change keys, or specify different defaults, > say if their mailbox is Some.Really.Long.Name@mean.com. The key should be invisible to the subscriber and therefore she shouldn't care. Is there something wrong with just having mailman generate a key for every subscription like "uniq42" and go from there? I also encourage people to enter real names somehow and use these on the info page. I also like the (admittedly extreme) option of using PIL to generate a gif of the address for placement on the individual subscriber's info page. Call me whacky but it just might be thought of as a kewl feature for the list manager consuming public to drop their archaic majordumo. -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich@pythonpros.com http://www.pythonpros.com From klm@python.org Thu Feb 26 22:53:28 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 26 Feb 1998 17:53:28 -0500 (EST) Subject: [Mailman-developers] List entry indexing In-Reply-To: <34F5EB6C.4F37CD1E@pythonpros.com> Message-ID: On Thu, 26 Feb 1998, Robin Friedrich wrote: > In a prior round of email, Ken mentioned that we would need to key the > mail list entries to something other than the person's actual email > address in order to implement the flexible user information editing > capability of the web (changing one's sendto address, etc.). I agree > that this is needed, sooner or later. Since I haven't seen the code yet, > how difficult is it to just make a unique key for each subscriber and > key the database off that with address as just one value? Actually, that's not what i meant to imply. In a maillist system where users have "accounts" - ie some kind of identity which they can control and which has resources associated with it - it seems to me that the reception email address is precisely the right characteristic for identifying that account. It is only thing you really know with any assurance *at all* about the user. Everything else is on their say so. To understand this perspective, consider that any user can hit the "send me my password" button for any account. The important thing is that the password gets sent to the email address for the account, not some arbitrary address of the user's choosing. The password and the only invariant of the account are tightly coupled. We do *not* want to allow any subscriber to specify different addresses for delivery of their password and delivery of their subsciption postings - the would allow pranksters and other malicious folk to subscribe and inflict unwanted mail from our lists on arbitrary people. No, i think it's important to keep the email address as the account identifier, and not let the user change that within the same account. The nice thing mailman offers is change of anything else - digest or non-digest, concealment, etc. > I hope I'm not using this list too soon. I don't think so. And btw, i'm hoping to finish packaging up my full set of patches to release within an hour or two - i'll be posting to both lists when it's ready... Ken From klm@python.org Thu Feb 26 23:08:32 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 26 Feb 1998 18:08:32 -0500 (EST) Subject: [Mailman-developers] List entry indexing In-Reply-To: <13557.60757.153547.236351@anthem.CNRI.Reston.Va.US> Message-ID: On Thu, 26 Feb 1998, Barry A. Warsaw wrote: > >>>>> "RF" == Robin Friedrich writes: > > I haven't looked at the code either, but you could default to using > the mailbox as the name key to start with, and then just append unique > numbers to this if there are duplicates. I wonder if there should be > some way that a user can change keys, or specify different defaults, > say if their mailbox is Some.Really.Long.Name@mean.com. Continuing monotonically from my prior rant (:-), i'd further say that it strikes me that "duplicate" mailboxes should be considered identical - like "duplicate" user ids on a single host system. Ken From friedrich@pythonpros.com Thu Feb 26 23:14:37 1998 From: friedrich@pythonpros.com (Robin Friedrich) Date: Thu, 26 Feb 1998 17:14:37 -0600 Subject: [Mailman-developers] List entry indexing References: Message-ID: <34F5F75D.7DE1F362@pythonpros.com> Ken Manheimer wrote: > Actually, that's not what i meant to imply. In a maillist system where > users have "accounts" - ie some kind of identity which they can control > and which has resources associated with it - it seems to me that the > reception email address is precisely the right characteristic for > identifying that account. It is only thing you really know with any > assurance *at all* about the user. Everything else is on their say so. Maybe I need to retune my frequency... hold on.... Ok. What I was suggesting was that mailman simply generate an internal keyword for that subscriber and then set the email address attribute on that account id to the address they are sending it from. This doesn't violate anything you have said. AFTER the subscription is made and a password has been secured, then we allow the user to alter the address attribute using our form. Otherwise we are stuck with a unsubscribe/resubscribe process for those who have changed their email accounts. -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich@pythonpros.com http://www.pythonpros.com From klm@python.org Fri Feb 27 01:03:41 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 26 Feb 1998 20:03:41 -0500 (EST) Subject: Took care of the proliferating subject-line prefix Message-ID: <199802270103.UAA15964@glyph.CNRI.Reston.Va.US> For anyone that's interested, i've packaged up my current version of mailman as three files in ftp://www.python.org/pub/python/contrib/Networking/mailman (Note that the klm.p1 patches *supercede* any prior patch packages i sent out - lots of developments today and yesterday. I will try to stick with incremental patches for incremental releases from this point forward.) mailman-1.0b1.tar.gz - The most recent surviving version (since his server crash and data loss) of john viegas mailman distribution that i could find, and klm.p1 - patches i've assembled over three or four days of hacking, to bring the revision to 1.0b1.1 (from 1.0b1). They implement a bunch of features, some of which i found imperative. There's a synopsis of the new features in... klm.notes1 - notes about the first set of patches. Here's the major highlights: - optional anti-spam filter, imposing the constraint that postings with the 'require_explicit_destination' option set must have the name of the list among the explicit recipients ('to' or 'cc') addrs in the message. This measure has been working *quite* nicely on the majordomo lists that i hacked it onto. - rmlist now does *not* get nasty and delete all the lists, templates, and archive hierarchies if you invoke it without any arguments. ! - All the list configuration defaults are collected in modules/mm_cfg.py, so ideally the installer compiles the wrappers, puts the files in place, and then applies their settings to this file to configure all the defaults for all the lists. - monthly password reminders are sent out collecting together each users passwords in a single message, rather than sending a message per password. - Prevent cascading subject-line list prefix (which effect many of you on the meta-sig may have noticed in the initial postings - i hadn't tried using the subject-line prefix in my test lists!-) There's more - read klm.notes1 for details. And these fixes are really not so big compared to the very nice features mailman offers in the first place. I won't go into that here, just suggest you try it out if you're looking for a good maillist mechanism... Note that i'll be away most of tomorrow and this weekend (in the grand python tradition of being unreachable just after a release). Barring any catastrophic behaviors of the setup in my absence, i'll probably be announcing this on the python newsgroup early next week, and switching over the rest of the python.org mailing lists at that point. (I will probably work with andrew kuchling to integrate with the newer pipermail, first.) Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From klm@python.org Fri Feb 27 01:10:17 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 26 Feb 1998 20:10:17 -0500 (EST) Subject: [Mailman-developers] List entry indexing In-Reply-To: <34F5F75D.7DE1F362@pythonpros.com> Message-ID: On Thu, 26 Feb 1998, Robin Friedrich wrote: > What I was suggesting was that mailman simply generate an internal keyword for > that subscriber and then set the email address attribute on that account id to > the address they are sending it from. This doesn't violate anything you have > said. AFTER the subscription is made and a password has been secured, then we > allow the user to alter the address attribute using our form. Otherwise we are > stuck with a unsubscribe/resubscribe process for those who have changed their > email accounts. Heck, i suppose we could set something up that simply creates the new account, copies over the settings and subscriptions from the old one, and deletes the old one - sending email adresses to both addresses in the process. I suppose the nice thing will be having the subscriptions follow - though currently mailman keeps the subscription info with the lists and not with the accounts. I'll have to think about it some more, but it does sound worth doing. Is this approaching what you're seeking? Ken From Robin.Friedrich@pdq.net Fri Feb 27 05:11:14 1998 From: Robin.Friedrich@pdq.net (Robin Friedrich) Date: Thu, 26 Feb 1998 23:11:14 -0600 Subject: [Mailman-developers] List entry indexing References: Message-ID: <34F64AD3.269822BC@pdq.net> Ken Manheimer wrote: > > Heck, i suppose we could set something up that simply creates the new > account, copies over the settings and subscriptions from the old one, > and deletes the old one - sending email adresses to both addresses in > the process. I suppose the nice thing will be having the subscriptions > follow - though currently mailman keeps the subscription info with the > lists and not with the accounts. I'll have to think about it some more, > but it does sound worth doing. > > Is this approaching what you're seeking? I suppose. Although since you say that the subscriptions are kept with the lists that would be a chore to change in the code. It may be too much trouble. I was thinking from the subscriber's perspective rather than the list's perspective which is of course how these things are structured. Reversing the sense of this in the code would probably be a pain. I'll just let it simmer in the back of my cranium for now and try not to let it bother me;-] -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich@pythonpros.com http://www.pythonpros.com From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Feb 27 17:34:49 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 27 Feb 1998 12:34:49 -0500 (EST) Subject: [Mailman-developers] List entry indexing References: <34F5EB6C.4F37CD1E@pythonpros.com> Message-ID: <13558.63403.994132.759366@anthem.CNRI.Reston.Va.US> I would definitely like to see a user-centric view of the world, as opposed to a list-centric view, especially when we're talking about users managing their presence via the Web. I want to be able to pull up one Web page that gives me a form by which I can change my email address in one fell swoop, perhaps have different email addresses per list, change my visibility per list, etc. If I had to visit a list-centric page for every list I'm a member of, that would be a huge pain. (But list-centric Web pages still have their uses, so the same database could drive both views). Maybe the code isn't set up for this now, but it should be a goal of future development. In that case, while I agree with Ken that the email account is critical as the user's identity, having some other unique key to identify the user is helpful when email addresses change, as is inevitable. Requiring or using a public key system seems excessive, but I don't see how to keep the user id from being given to the user. I might not remember what address I'm subscribed with on which list (I see this happen a lot with Majordomo users actually). -Barry From jtv2j@cs.virginia.edu Fri Feb 27 18:23:50 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Fri, 27 Feb 1998 13:23:50 -0500 (EST) Subject: State of mailman (was: Re: list entry indexing) Message-ID: <199802271823.NAA12238@adder.cs.Virginia.EDU> > I would definitely like to see a user-centric view of the world, as > opposed to a list-centric view, especially when we're talking about > users managing their presence via the Web. I want to be able to pull > up one Web page that gives me a form by which I can change my email > address in one fell swoop, perhaps have different email addresses per > list, change my visibility per list, etc. If I had to visit a > list-centric page for every list I'm a member of, that would be a huge > pain. (But list-centric Web pages still have their uses, so the same > database could drive both views). > > Maybe the code isn't set up for this now, but it should be a goal of > future development. In that case, while I agree with Ken that the > email account is critical as the user's identity, having some other > unique key to identify the user is helpful when email addresses > change, as is inevitable. Requiring or using a public key system > seems excessive, but I don't see how to keep the user id from being > given to the user. I might not remember what address I'm subscribed > with on which list (I see this happen a lot with Majordomo users > actually). Okay, sorry I'm late in jumping into these discussions, but I've been away. A little bit of background for anyone who doesn't know: I had been developing mailman off and on, until I lost several months worth of changes in a disk crash (blame Greg Stein for not doing backups :). I'm slightly uncomfortable seeing people use the version that is now getting passed around, but I am certainly happy people are using it. The above problem was once changed. I kept a centralized user database. The way you could change your email address was with your password... there was no need for any sort of public key, etc. Some other stuff that was lost (some of this might actually be there, but I don't think so): - going to the listinfo CGI script w/o an argument should give a list of lists, except for the ones that are configured to be "hidden". - If a user appears in the TO or CC lines, and we can determine that he is on our mailing list, don't send him mail, because he already got it. Don't count such addresses towards the "this is probably spam" threshhold. - If a list admin gets lazy, and doesn't handle approvals for a long time, automatically send back rejections. - A site config page, including a password for the site manager, which works on any list. - A change to the way prefixes are handled, which it looks like Ken reimplemented already. - Talk to port 25 instead of calling sendmail, to make portability to other MTAs easier. There might have been a few more things. Those are the important things I can remember. However, Mailman was never 100% of the way to where I'd like it to be. One of the big problems is that I started out with a lot of majordomo experience, so a lot of the model is the same. What I'd most like to change, is to make mailman a daemon process that is always running, and use threads effectively. This would reduce the overhead of always having to start up a python interpreter and init mailman whenever a request comes in. It could also improve the grainularity of the locking mechanism, which is something that I feel really needs to be done. Anyway, my situation is that I don't have too much spare time to be coding until I finish the thesis I'm writing (though maybe a little bit). That shouldn't be any later than June 1. However, I'd be more than happy to accept changes from other people, and go back to actually releasing this software, if there is an interested development community this time around. All of the things mentioned above, I'd like to see happen, but anything that improves mailman, I'd like to incorporate. John ---------------------------------------------------------------------------- |John Viega "The public at large tends to confuse the | |viega@list.org composing of a symphony with the writing of | |http://list.org/~viega/ its score." | |University of Virginia -- Edsger Dijkstra | ---------------------------------------------------------------------------- From friedrich@pythonpros.com Thu Feb 26 22:23:40 1998 From: friedrich@pythonpros.com (Robin Friedrich) Date: Thu, 26 Feb 1998 16:23:40 -0600 Subject: List entry indexing Message-ID: <34F5EB6C.4F37CD1E@pythonpros.com> In a prior round of email, Ken mentioned that we would need to key the mail list entries to something other than the person's actual email address in order to implement the flexible user information editing capability of the web (changing one's sendto address, etc.). I agree that this is needed, sooner or later. Since I haven't seen the code yet, how difficult is it to just make a unique key for each subscriber and key the database off that with address as just one value? I hope I'm not using this list too soon. -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich@pythonpros.com http://www.pythonpros.com From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Feb 26 22:34:00 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 26 Feb 1998 17:34:00 -0500 (EST) Subject: [Mailman-developers] List entry indexing References: <34F5EB6C.4F37CD1E@pythonpros.com> Message-ID: <13557.60757.153547.236351@anthem.CNRI.Reston.Va.US> >>>>> "RF" == Robin Friedrich writes: RF> In a prior round of email, Ken mentioned that we would need to RF> key the mail list entries to something other than the person's RF> actual email address in order to implement the flexible user RF> information editing capability of the web (changing one's RF> sendto address, etc.). I agree that this is needed, sooner or RF> later. Since I haven't seen the code yet, how difficult is it RF> to just make a unique key for each subscriber and key the RF> database off that with address as just one value? I haven't looked at the code either, but you could default to using the mailbox as the name key to start with, and then just append unique numbers to this if there are duplicates. I wonder if there should be some way that a user can change keys, or specify different defaults, say if their mailbox is Some.Really.Long.Name@mean.com. -Barry From friedrich@pythonpros.com Thu Feb 26 22:53:26 1998 From: friedrich@pythonpros.com (Robin Friedrich) Date: Thu, 26 Feb 1998 16:53:26 -0600 Subject: [Mailman-developers] List entry indexing References: <34F5EB6C.4F37CD1E@pythonpros.com> <13557.60757.153547.236351@anthem.CNRI.Reston.Va.US> Message-ID: <34F5F265.294A8899@pythonpros.com> Barry A. Warsaw wrote: > >>>>> "RF" == Robin Friedrich writes: > > RF> In a prior round of email, Ken mentioned that we would need to > RF> key the mail list entries to something other than the person's > RF> actual email address in order to implement the flexible user > RF> information editing capability of the web (changing one's > RF> sendto address, etc.). I agree that this is needed, sooner or > RF> later. Since I haven't seen the code yet, how difficult is it > RF> to just make a unique key for each subscriber and key the > RF> database off that with address as just one value? > > I haven't looked at the code either, but you could default to using > the mailbox as the name key to start with, and then just append unique > numbers to this if there are duplicates. I wonder if there should be > some way that a user can change keys, or specify different defaults, > say if their mailbox is Some.Really.Long.Name@mean.com. The key should be invisible to the subscriber and therefore she shouldn't care. Is there something wrong with just having mailman generate a key for every subscription like "uniq42" and go from there? I also encourage people to enter real names somehow and use these on the info page. I also like the (admittedly extreme) option of using PIL to generate a gif of the address for placement on the individual subscriber's info page. Call me whacky but it just might be thought of as a kewl feature for the list manager consuming public to drop their archaic majordumo. -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich@pythonpros.com http://www.pythonpros.com From klm@python.org Thu Feb 26 22:53:28 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 26 Feb 1998 17:53:28 -0500 (EST) Subject: [Mailman-developers] List entry indexing In-Reply-To: <34F5EB6C.4F37CD1E@pythonpros.com> Message-ID: On Thu, 26 Feb 1998, Robin Friedrich wrote: > In a prior round of email, Ken mentioned that we would need to key the > mail list entries to something other than the person's actual email > address in order to implement the flexible user information editing > capability of the web (changing one's sendto address, etc.). I agree > that this is needed, sooner or later. Since I haven't seen the code yet, > how difficult is it to just make a unique key for each subscriber and > key the database off that with address as just one value? Actually, that's not what i meant to imply. In a maillist system where users have "accounts" - ie some kind of identity which they can control and which has resources associated with it - it seems to me that the reception email address is precisely the right characteristic for identifying that account. It is only thing you really know with any assurance *at all* about the user. Everything else is on their say so. To understand this perspective, consider that any user can hit the "send me my password" button for any account. The important thing is that the password gets sent to the email address for the account, not some arbitrary address of the user's choosing. The password and the only invariant of the account are tightly coupled. We do *not* want to allow any subscriber to specify different addresses for delivery of their password and delivery of their subsciption postings - the would allow pranksters and other malicious folk to subscribe and inflict unwanted mail from our lists on arbitrary people. No, i think it's important to keep the email address as the account identifier, and not let the user change that within the same account. The nice thing mailman offers is change of anything else - digest or non-digest, concealment, etc. > I hope I'm not using this list too soon. I don't think so. And btw, i'm hoping to finish packaging up my full set of patches to release within an hour or two - i'll be posting to both lists when it's ready... Ken From klm@python.org Thu Feb 26 23:08:32 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 26 Feb 1998 18:08:32 -0500 (EST) Subject: [Mailman-developers] List entry indexing In-Reply-To: <13557.60757.153547.236351@anthem.CNRI.Reston.Va.US> Message-ID: On Thu, 26 Feb 1998, Barry A. Warsaw wrote: > >>>>> "RF" == Robin Friedrich writes: > > I haven't looked at the code either, but you could default to using > the mailbox as the name key to start with, and then just append unique > numbers to this if there are duplicates. I wonder if there should be > some way that a user can change keys, or specify different defaults, > say if their mailbox is Some.Really.Long.Name@mean.com. Continuing monotonically from my prior rant (:-), i'd further say that it strikes me that "duplicate" mailboxes should be considered identical - like "duplicate" user ids on a single host system. Ken From friedrich@pythonpros.com Thu Feb 26 23:14:37 1998 From: friedrich@pythonpros.com (Robin Friedrich) Date: Thu, 26 Feb 1998 17:14:37 -0600 Subject: [Mailman-developers] List entry indexing References: Message-ID: <34F5F75D.7DE1F362@pythonpros.com> Ken Manheimer wrote: > Actually, that's not what i meant to imply. In a maillist system where > users have "accounts" - ie some kind of identity which they can control > and which has resources associated with it - it seems to me that the > reception email address is precisely the right characteristic for > identifying that account. It is only thing you really know with any > assurance *at all* about the user. Everything else is on their say so. Maybe I need to retune my frequency... hold on.... Ok. What I was suggesting was that mailman simply generate an internal keyword for that subscriber and then set the email address attribute on that account id to the address they are sending it from. This doesn't violate anything you have said. AFTER the subscription is made and a password has been secured, then we allow the user to alter the address attribute using our form. Otherwise we are stuck with a unsubscribe/resubscribe process for those who have changed their email accounts. -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich@pythonpros.com http://www.pythonpros.com From klm@python.org Fri Feb 27 01:03:41 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 26 Feb 1998 20:03:41 -0500 (EST) Subject: Took care of the proliferating subject-line prefix Message-ID: <199802270103.UAA15964@glyph.CNRI.Reston.Va.US> For anyone that's interested, i've packaged up my current version of mailman as three files in ftp://www.python.org/pub/python/contrib/Networking/mailman (Note that the klm.p1 patches *supercede* any prior patch packages i sent out - lots of developments today and yesterday. I will try to stick with incremental patches for incremental releases from this point forward.) mailman-1.0b1.tar.gz - The most recent surviving version (since his server crash and data loss) of john viegas mailman distribution that i could find, and klm.p1 - patches i've assembled over three or four days of hacking, to bring the revision to 1.0b1.1 (from 1.0b1). They implement a bunch of features, some of which i found imperative. There's a synopsis of the new features in... klm.notes1 - notes about the first set of patches. Here's the major highlights: - optional anti-spam filter, imposing the constraint that postings with the 'require_explicit_destination' option set must have the name of the list among the explicit recipients ('to' or 'cc') addrs in the message. This measure has been working *quite* nicely on the majordomo lists that i hacked it onto. - rmlist now does *not* get nasty and delete all the lists, templates, and archive hierarchies if you invoke it without any arguments. ! - All the list configuration defaults are collected in modules/mm_cfg.py, so ideally the installer compiles the wrappers, puts the files in place, and then applies their settings to this file to configure all the defaults for all the lists. - monthly password reminders are sent out collecting together each users passwords in a single message, rather than sending a message per password. - Prevent cascading subject-line list prefix (which effect many of you on the meta-sig may have noticed in the initial postings - i hadn't tried using the subject-line prefix in my test lists!-) There's more - read klm.notes1 for details. And these fixes are really not so big compared to the very nice features mailman offers in the first place. I won't go into that here, just suggest you try it out if you're looking for a good maillist mechanism... Note that i'll be away most of tomorrow and this weekend (in the grand python tradition of being unreachable just after a release). Barring any catastrophic behaviors of the setup in my absence, i'll probably be announcing this on the python newsgroup early next week, and switching over the rest of the python.org mailing lists at that point. (I will probably work with andrew kuchling to integrate with the newer pipermail, first.) Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From klm@python.org Fri Feb 27 01:10:17 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 26 Feb 1998 20:10:17 -0500 (EST) Subject: [Mailman-developers] List entry indexing In-Reply-To: <34F5F75D.7DE1F362@pythonpros.com> Message-ID: On Thu, 26 Feb 1998, Robin Friedrich wrote: > What I was suggesting was that mailman simply generate an internal keyword for > that subscriber and then set the email address attribute on that account id to > the address they are sending it from. This doesn't violate anything you have > said. AFTER the subscription is made and a password has been secured, then we > allow the user to alter the address attribute using our form. Otherwise we are > stuck with a unsubscribe/resubscribe process for those who have changed their > email accounts. Heck, i suppose we could set something up that simply creates the new account, copies over the settings and subscriptions from the old one, and deletes the old one - sending email adresses to both addresses in the process. I suppose the nice thing will be having the subscriptions follow - though currently mailman keeps the subscription info with the lists and not with the accounts. I'll have to think about it some more, but it does sound worth doing. Is this approaching what you're seeking? Ken From Robin.Friedrich@pdq.net Fri Feb 27 05:11:14 1998 From: Robin.Friedrich@pdq.net (Robin Friedrich) Date: Thu, 26 Feb 1998 23:11:14 -0600 Subject: [Mailman-developers] List entry indexing References: Message-ID: <34F64AD3.269822BC@pdq.net> Ken Manheimer wrote: > > Heck, i suppose we could set something up that simply creates the new > account, copies over the settings and subscriptions from the old one, > and deletes the old one - sending email adresses to both addresses in > the process. I suppose the nice thing will be having the subscriptions > follow - though currently mailman keeps the subscription info with the > lists and not with the accounts. I'll have to think about it some more, > but it does sound worth doing. > > Is this approaching what you're seeking? I suppose. Although since you say that the subscriptions are kept with the lists that would be a chore to change in the code. It may be too much trouble. I was thinking from the subscriber's perspective rather than the list's perspective which is of course how these things are structured. Reversing the sense of this in the code would probably be a pain. I'll just let it simmer in the back of my cranium for now and try not to let it bother me;-] -- Robin K. Friedrich Houston, Texas Python Professional Services, Inc. friedrich@pythonpros.com http://www.pythonpros.com From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Feb 27 17:34:49 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 27 Feb 1998 12:34:49 -0500 (EST) Subject: [Mailman-developers] List entry indexing References: <34F5EB6C.4F37CD1E@pythonpros.com> Message-ID: <13558.63403.994132.759366@anthem.CNRI.Reston.Va.US> I would definitely like to see a user-centric view of the world, as opposed to a list-centric view, especially when we're talking about users managing their presence via the Web. I want to be able to pull up one Web page that gives me a form by which I can change my email address in one fell swoop, perhaps have different email addresses per list, change my visibility per list, etc. If I had to visit a list-centric page for every list I'm a member of, that would be a huge pain. (But list-centric Web pages still have their uses, so the same database could drive both views). Maybe the code isn't set up for this now, but it should be a goal of future development. In that case, while I agree with Ken that the email account is critical as the user's identity, having some other unique key to identify the user is helpful when email addresses change, as is inevitable. Requiring or using a public key system seems excessive, but I don't see how to keep the user id from being given to the user. I might not remember what address I'm subscribed with on which list (I see this happen a lot with Majordomo users actually). -Barry From jtv2j@cs.virginia.edu Fri Feb 27 18:23:50 1998 From: jtv2j@cs.virginia.edu (John Viega) Date: Fri, 27 Feb 1998 13:23:50 -0500 (EST) Subject: State of mailman (was: Re: list entry indexing) Message-ID: <199802271823.NAA12238@adder.cs.Virginia.EDU> > I would definitely like to see a user-centric view of the world, as > opposed to a list-centric view, especially when we're talking about > users managing their presence via the Web. I want to be able to pull > up one Web page that gives me a form by which I can change my email > address in one fell swoop, perhaps have different email addresses per > list, change my visibility per list, etc. If I had to visit a > list-centric page for every list I'm a member of, that would be a huge > pain. (But list-centric Web pages still have their uses, so the same > database could drive both views). > > Maybe the code isn't set up for this now, but it should be a goal of > future development. In that case, while I agree with Ken that the > email account is critical as the user's identity, having some other > unique key to identify the user is helpful when email addresses > change, as is inevitable. Requiring or using a public key system > seems excessive, but I don't see how to keep the user id from being > given to the user. I might not remember what address I'm subscribed > with on which list (I see this happen a lot with Majordomo users > actually). Okay, sorry I'm late in jumping into these discussions, but I've been away. A little bit of background for anyone who doesn't know: I had been developing mailman off and on, until I lost several months worth of changes in a disk crash (blame Greg Stein for not doing backups :). I'm slightly uncomfortable seeing people use the version that is now getting passed around, but I am certainly happy people are using it. The above problem was once changed. I kept a centralized user database. The way you could change your email address was with your password... there was no need for any sort of public key, etc. Some other stuff that was lost (some of this might actually be there, but I don't think so): - going to the listinfo CGI script w/o an argument should give a list of lists, except for the ones that are configured to be "hidden". - If a user appears in the TO or CC lines, and we can determine that he is on our mailing list, don't send him mail, because he already got it. Don't count such addresses towards the "this is probably spam" threshhold. - If a list admin gets lazy, and doesn't handle approvals for a long time, automatically send back rejections. - A site config page, including a password for the site manager, which works on any list. - A change to the way prefixes are handled, which it looks like Ken reimplemented already. - Talk to port 25 instead of calling sendmail, to make portability to other MTAs easier. There might have been a few more things. Those are the important things I can remember. However, Mailman was never 100% of the way to where I'd like it to be. One of the big problems is that I started out with a lot of majordomo experience, so a lot of the model is the same. What I'd most like to change, is to make mailman a daemon process that is always running, and use threads effectively. This would reduce the overhead of always having to start up a python interpreter and init mailman whenever a request comes in. It could also improve the grainularity of the locking mechanism, which is something that I feel really needs to be done. Anyway, my situation is that I don't have too much spare time to be coding until I finish the thesis I'm writing (though maybe a little bit). That shouldn't be any later than June 1. However, I'd be more than happy to accept changes from other people, and go back to actually releasing this software, if there is an interested development community this time around. All of the things mentioned above, I'd like to see happen, but anything that improves mailman, I'd like to incorporate. John ---------------------------------------------------------------------------- |John Viega "The public at large tends to confuse the | |viega@list.org composing of a symphony with the writing of | |http://list.org/~viega/ its score." | |University of Virginia -- Edsger Dijkstra | ----------------------------------------------------------------------------