From wizard at syntheticsw.com Sun Mar 7 04:31:44 2004 From: wizard at syntheticsw.com (Torsten Giebl) Date: Sun Mar 14 21:32:51 2004 Subject: [Mailman3-dev] Starting MM3 Talks ? Message-ID: <404AEC00.5040309@syntheticsw.com> Hello ! Is it possible to start talking about MM3 ? CU From barry at python.org Sun Mar 14 18:17:46 2004 From: barry at python.org (Barry Warsaw) Date: Sun Mar 14 21:35:02 2004 Subject: [Mailman3-dev] Mailman 3 Contributors Agreement Message-ID: <1079306265.5218.11.camel@geddy.wooz.org> Since Mailman 3 will be a near total rewrite, we have an opportunity to clean up Mailman's IP. I plan to make a few changes to the copyright and contribution procedure we use for Mailman 3. Please note that nothing will change for Mailman 2. A summary of the changes: * I will retain copyright for Mailman 3; I won't be assigning copyright to the Free Software Foundation. * For all contributions from others, I'm going to ask you to sign a joint ownership agreement, similar to what is done for Zope contributions. * Mailman 3 will still be released under the GPL, but I reserve the right to dual-license Mailman 3. I want to retain copyright for Mailman 3 because I want to be able to control Mailman's future. For example, it may be that the Python Software Foundation is ultimately a better steward of Mailman's copyright. I also feel that a joint ownership agreement on all contributions acknowledges the hard work of contributors, by allowing them to retain an ownership stake in their own code. I believe the GPL is still the appropriate license for Mailman 3, and I want to assure contributors that their code will always be included in a free/open source release. But I can see situations where alternative dual-license options should be considered, perhaps to make some non-GPL uses available, or to gain some commercial support. I have a draft of the Mailman 3 Contributors Agreement available here: http://zope.org/Members/bwarsaw/MailmanDesignNotes/MM3ContributorsAgreement.pdf I'd like to come to some agreement about this so that the agreement will be ready for the Mailman 3 sprints at PyConII. So now I don my asbestos underwear and invite your comments. :) -Barry From barry at python.org Sun Mar 14 18:34:28 2004 From: barry at python.org (Barry Warsaw) Date: Sun Mar 14 21:35:08 2004 Subject: [Mailman3-dev] Sprinters count Message-ID: <1079307268.5218.29.camel@geddy.wooz.org> I'm trying to get a head count for Mailman 3 sprinters at PyconII. I'd also like to get a breakdown of sprinters for each day. I'm currently planning on being there each of Saturday, Sunday, Monday, and Tuesday. >From the sprint wiki: http://www.python.org/cgi-bin/moinmoin/SprintPlan2004 http://www.python.org/cgi-bin/moinmoin/Mailman3Sprint I'm counting the following folks: Fred Drake Dale Newfield Maki Kato Sean Reifschneider Jacob Hallen LD Landis Kevin McCann If any one else is planning on coming who hasn't signed up on the wiki, please let me know. If any of the above folks know they won't be MM3 sprinting, also let me know. I will be checking the MM3 code into SourceForge one day this coming week, so you can get a look at what I've done so far. Thanks, -Barry From barry at python.org Sun Mar 14 22:51:53 2004 From: barry at python.org (Barry Warsaw) Date: Sun Mar 14 22:51:56 2004 Subject: [Mailman3-dev] Re: list delays In-Reply-To: References: <1079306265.5218.11.camel@geddy.wooz.org> Message-ID: <1079322713.6004.27.camel@geddy.wooz.org> On Sun, 2004-03-14 at 22:16, Mark A. Mandel wrote: > The posts from Rene Hertell (Date: Fri, 27 Feb 2004 09:30:06 +0200 ) and > Torsten Giebl (Date: Sun, 07 Mar 2004 10:31:44 +0100) just reached me. > While I am no expert, the headers suggest that the delay was at > mail.python.org (an excerpt from the headers of Hertell's post is > below). Did others experience similar delays? Is this a bug or a > feature? ;-) > > Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org) > by mail.python.org with esmtp (Exim 4.22) > id 1B2huO-0003BW-Nq > for mamandel@ldc.upenn.edu; Sun, 14 Mar 2004 21:32:52 -0500 > Received: from virtual.netsonic.fi ([194.29.192.50]) > by mail.python.org with esmtp (Exim 4.22) id 1AwcRz-000873-L9 > for mailman3-dev@python.org; Fri, 27 Feb 2004 02:30:23 -0500 Check the X-Mailman-Approved-At header. They were actually sitting in the requests db until just tonight. I'll be better at approving posts in a more timely manner. -Barry From mamandel at ldc.upenn.edu Sun Mar 14 22:16:09 2004 From: mamandel at ldc.upenn.edu (Mark A. Mandel) Date: Sun Mar 14 23:01:17 2004 Subject: [Mailman3-dev] list delays In-Reply-To: <1079306265.5218.11.camel@geddy.wooz.org> References: <1079306265.5218.11.camel@geddy.wooz.org> Message-ID: The posts from Rene Hertell (Date: Fri, 27 Feb 2004 09:30:06 +0200 ) and Torsten Giebl (Date: Sun, 07 Mar 2004 10:31:44 +0100) just reached me. While I am no expert, the headers suggest that the delay was at mail.python.org (an excerpt from the headers of Hertell's post is below). Did others experience similar delays? Is this a bug or a feature? ;-) Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org) by mail.python.org with esmtp (Exim 4.22) id 1B2huO-0003BW-Nq for mamandel@ldc.upenn.edu; Sun, 14 Mar 2004 21:32:52 -0500 Received: from virtual.netsonic.fi ([194.29.192.50]) by mail.python.org with esmtp (Exim 4.22) id 1AwcRz-000873-L9 for mailman3-dev@python.org; Fri, 27 Feb 2004 02:30:23 -0500 -- Mark A. Mandel Linguistic Data Consortium, University of Pennsylvania From barry at python.org Sun Mar 14 23:05:37 2004 From: barry at python.org (Barry Warsaw) Date: Sun Mar 14 23:05:50 2004 Subject: [Mailman3-dev] Starting MM3 Talks ? In-Reply-To: <404AEC00.5040309@syntheticsw.com> References: <404AEC00.5040309@syntheticsw.com> Message-ID: <1079323537.6004.39.camel@geddy.wooz.org> On Sun, 2004-03-07 at 04:31, Torsten Giebl wrote: > Is it possible to start talking about MM3 ? Yes, please! -Barry From barry at python.org Sun Mar 14 23:08:31 2004 From: barry at python.org (Barry Warsaw) Date: Sun Mar 14 23:08:35 2004 Subject: [Mailman3-dev] Mailman 3 features In-Reply-To: References: Message-ID: <1079323710.6004.43.camel@geddy.wooz.org> On Fri, 2004-02-27 at 02:30, Rene Hertell wrote: > For the moment it seems to me that the current version of Mailman has > some problems in handling foreign languages that uses characters that > are outside the us ASCII character set. One example is when the list > is running in the Finnish language, and it receives an email with > characters like ?,? and ? (å ä ö) in the > subject-field. It seems like Mailman fails to update the > message-achieve because of this. I think the basic problem is that internationalization was wedged into Mailman 2 instead of being designed for it from the start. The key is probably to treat all strings internally as Unicode instead of 8-bit strings, converting to and from Unicode at the edges. That's the general approach that Zope 3 takes and I think it's the only rational approach for handling non-ASCII character sets. Note that we may have to modify the email package to help with this, but the email-sig does have a mission to produce version 3.0 for Python 2.4. -Barry From marilyn at deliberate.com Sun Mar 14 23:14:53 2004 From: marilyn at deliberate.com (Marilyn Davis) Date: Sun Mar 14 23:26:34 2004 Subject: [Mailman3-dev] Mailman 3 features In-Reply-To: <1079323710.6004.43.camel@geddy.wooz.org> Message-ID: Multiple-domain support? User-generated polls? Marilyn Davis From claw at kanga.nu Sun Mar 14 23:27:44 2004 From: claw at kanga.nu (J C Lawrence) Date: Sun Mar 14 23:33:08 2004 Subject: [Mailman3-dev] Mailman 3 Contributors Agreement In-Reply-To: Message from Barry Warsaw of "Sun, 14 Mar 2004 18:17:46 EST." <1079306265.5218.11.camel@geddy.wooz.org> References: <1079306265.5218.11.camel@geddy.wooz.org> Message-ID: <19487.1079324864@kanga.nu> On Sun, 14 Mar 2004 18:17:46 -0500 Barry Warsaw wrote: > http://zope.org/Members/bwarsaw/MailmanDesignNotes/MM3ContributorsAgreement.pdf My quibbles: I specifically don't want to see Mailman under a "...or any future version of the GPL..." such that it could become subject to an Affero-like license. I'm uncomfortable with unconstrained re-licensing. Specifically I dislike the idea of (for example) an MIT/BSD licensing fork which would allow the third party to then relicense Mailman again under a license they made up. I'd be happier with a constraint on the relicensing forms which stated that third parties would only be allowed to use the code under the license they acquired it under. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From mm3 at vsabio.com Sun Mar 14 23:54:58 2004 From: mm3 at vsabio.com (Vince Sabio) Date: Mon Mar 15 09:48:33 2004 Subject: [Mailman3-dev] Suggested Features Message-ID: Hi folks, I am currently using Lyris List Manager on an Ultra I running Solaris 8. The hosting site is pretty large -- we have about 50 mailing lists, with a dozen of them numbering at 1000 or more subscribers. I have 15 "Listmoms" who help manage the lists, including moderation approval/rejection of posts. Not surprisingly, MLM features are important to us. I'm considering a move to Mailman on FreeBSD, but it is difficult to tell if M2 has certain specific features that have become part of our day-to-day list management in Lyris. Now, I'm not expecting anyone to design an MLM around the features that we're looking for ... but since you're soliciting input for M3, I figure it can't hurt. So, with that in mind, the features in question are (see below before replying to these): * "Semi-moderated" mailing lists (i.e., subscribers are moderated for "N" posts when they subscribe, and "graduate" to unmoderated status after N _approved_ posts) * "Spot" moderation (i.e., the ability to [re-]moderate an individual for "N" posts, or to permanently moderate him, at the moderator's discretion). It is VERY IMPORTANT that moderation be persistent -- i.e., if someone figures out he's been permanently moderated, he can't unsubscribe and resubscribe and thus go back to being moderated for only "N" posts. (Upon unsub/resub, the implementation should set his moderation for the higher of the default list moderation count and his previous moderation setting.) * Moderation via e-mail -- both approve/reject (important) and ability to set/change a user's moderation state (less important). * Ability to create "filters" (preferably via the web UI) that can act based on the content of incoming messages, and return a customized message to the subscriber -- e.g., if a message contains the word "dingleberries" (insert your favorite word there), it can reject the post and send the poster a customized document, with a copy of the post, including headers, attached at the bottom (in this case, the "customized document" would state that, e.g., the post was being returned because it contained profanity). - A modification to this feature is the ability to send messages to the moderation queue based on their content. That is, a message that would otherwise post to the list would instead be submitted for moderation if its content matches a specific filter. This particular feature is not in our version of Lyris (I do not know if it is in later versions). * Ability to strip certain headers, such as "Precedence:", "Priority:", and the like. * Ability to add custom headers, both static headers (same for all subscribers) and mail-merged headers (e.g., "X-Message-To:
", with the subscriber's address in the header). * Ability for subscribers set NOMAIL mode for a specific length of time (and/or until a specific date), at which time their previous delivery mode will be restored. (This is useful when going on vacation; no need to remember to set their delivery mode back to MAIL, DIGEST, etc.) * Ability to ban certain users from subscribing to mailing lists -- both on a per-list basis and on a site-wide basis. * Ability to ban certain subscribers from posting to mailing lists (i.e., from ever even entering the moderation queue). (This feature isn't terribly important, since we can pretty well handle this in moderation.) That's a start. Now, I know that the feature list in M2 includes such things as "New moderation and privacy controls," "emergency moderation," "Majordomo-style e-mail commands," "regex-based topic filtering," etc., but I'm not sure if those features translate into the specifics that I mentioned above. Since we use these features on a daily (or nearly daily) basis, I wanted to be explicit about the feature set we're looking for. Again, I'm not expecting anyone to design an M3 around our requirements, but I igured it couldn't hurt to state them, and might stimulate some interesting discussion. :-) Questions: * Is the Welcome message customizable? If not, it would be necessary for us to be able to customize it. * Can users request a copy of the customized Welcome message via e-mail? (I know they can get a "help" message via e-mail.) * The "Urgent" message feature in M2 is nice -- but can use of it be limited to just list owners/moderators? * Is it possible to REQUIRE/FORCE all e-mail addresses to be concealed? That is, not even give the users the option? Please feel free to ask for clarification on any of these points. There are probably more features that we'd be interested in, but I didn't want to wear out my welcome on the first message (figured I'd wait until the third or fourth message for that ;-). -- ________________________________________________________________________ Vince Sabio mm3@vsabio.com From jonc at nc.rr.com Mon Mar 15 00:12:45 2004 From: jonc at nc.rr.com (Jon Carnes) Date: Mon Mar 15 09:48:34 2004 Subject: [Mailman3-dev] Suggestions for MMV3 Message-ID: <1079327565.4317.29.camel@localhost.localdomain> we should consider contacting folks like CPanel who already incorporate Mailman in their products and see what we can do to make it easier for them, and what features they would like to see most in the next version. If we plan MMv3 with a nod in this directions it could significantly cut down on the frustration level of folks who use Mailman via a third-party implementation. I've also had some comments from folks who really don't like the use of -bounces as the sender of email lists in version 2.1. If we could rename this to something like -distribute it would help folks who are using broken MTU's that display the envelope sender. Also, we need to more fully automate the aliases creations for various MTA's. I would be happy to work on this for MMv3. It should be easy enough for folks to input their MTA into a variable in mm_cfg.py and then to code the aliases creation based on that information. For some MTA's this might mean modifying the exiting rights of aliases files... The big feature that all folks will be looking for is the ability to create same name lists on different virtual domains. A web-based Stat's page per list (and one for whole domains) would also be nice to see added as a built-in feature. Built-in integration with HTDig would enable a lot of folks to stop rolling their own RPM's or installing from source (just to get the HTDig patches). A link to the web-based FAQ, included with error dumps might also alleviate some users pain for common Mailman problems A web-based tool for editing/removing older archives for a list (a pipermail request). A lot of folks would like the ability to remove single messages from the arhives, as well as archived messages older than a specified date. I can help with this, as I've already written some stuff that does something similar (though I would have to re-do it in Python :-) Better message threading within the archives (Another Pipermail request). Logging that displays the amount of system resources used by Mailman as it is running. I'm slammed with starting up a VoIP phone company in RTP, but I would still like to help out with the MMv3 effort, so let me know what I can do to bring value to this project. Jon Carnes 919.459.2309 From iane at sussex.ac.uk Mon Mar 15 05:59:45 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Mon Mar 15 09:48:36 2004 Subject: [Mailman3-dev] Mailman 3 features In-Reply-To: References: Message-ID: <2147483647.1079348385@beeding.central.susx.ac.uk> I've said something like this in the wiki... I'm postmaster for the University of Sussex. We use mailman for lists that are mostly for internal use, but some lists may have external users. I'd like mailman to permit authentication with a username, against our ldap server. Ideally, it would then fetch a real name and email address from the ldap server. At the same time, I'd like mailman to retain an internal user database. This would allow us to have lists which are open to external people, too. On top of that, I'd like simple controls to allow posting from Sussex people, even when they aren't members of the list. And, I'd like to have some lists closed to external membership. Of course, people authenticating against the ldap server would not need to confirm subscription requests through email verification. -- Ian Eiloart Servers Team Sussex University ITS From mamandel at ldc.upenn.edu Mon Mar 15 09:59:51 2004 From: mamandel at ldc.upenn.edu (Mark A. Mandel) Date: Mon Mar 15 09:59:55 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: References: Message-ID: Ability to modify the HTML template for more than the couple of pages that I can change now. It is currently difficult approaching impracticable to go from reading, say, the Jan. 31 archive mail to the Feb. 1 mail (assuming monthly archiving). The levels of view are: 1. "The [whatever]-list Archives" page, which shows a table of the monthly archives 2. view one month 3. view an individual post When you've selected a month, worked your way through a whole thread, and come to the end of the month, there is no easy way to get to the next month. You can click BACK BACK BACK BACK... in your browswer or go to the browser's BACK list till you get to the Archives page in the above list, or you can follow the link "More info on this list", and on that page find and click on the link to the top level, but there's no direct link to "next month" or "previous month", or even to the Archives page itself. While I'm on this topic, I sure wish I could get the sorted by-month displays, or at least the Date view, to show the date of the messages. When you're searching through 100 messages for one whose date you know, that sure would help. -- Mark A. Mandel Linguistic Data Consortium, University of Pennsylvania From mitchell at cuip.net Mon Mar 15 11:28:43 2004 From: mitchell at cuip.net (Mitchell Marks) Date: Mon Mar 15 11:30:59 2004 Subject: [Mailman3-dev] Suggested feature: direct & enhanced "umbrella list" support In-Reply-To: References: Message-ID: The MM2 handling of sublists/superlists is largely by subscribing a sublist address as a member of the superlist, or by periodically running a script to reconstitute the superlist by merging the addresses from the sublists. The specific support built into MM2 for these situations does not seem to go much beyond the "umbrella list" attribute which affects how reminders are handled. I'd very much welcome some way of having that type of relationship more inherently recognized. Suppose I could designate that "Seniors", "Juniors", and "Sophs" constituted "Students". Then: -- someone getting subscribed to Seniors will start receiving mail sent to Students immediately (or as soon as they start receiving Seniors mail) -- When a message goes through Students, recipients via the sublist will get a Subject line tag like [Students] but not the whole stack "[Seniors][Students]". OR make that configurable. (Note that it's not enough to say "leave the tag out of the settings for Seniors", as it should appear when a message is going directly to that sublist.) -- When a recipient of a Students message through the Seniors sublist goes to reply (assuming list-reply rather than individual-poster-reply is on), should that mean Seniors or Students? Probably should be configurable. -- Suppose for some reason a student is on both Juniors and Seniors lists. A message that comes through Students should probably result in only one copy going to that dual-subscribed person. (I've seen the contrary view. Maybe that means it should be configurable -- maybe even per-user configurable, with admin override.) -- If an individual is subscribed directly to the Students superlist, the system should treat them as an individual and not as a sublist,l for such matters as reminders and bounce handling. (That's roughly like saying the MM2 "umbrella list" attribute should be applied not to the superlist but per-subscriber, marking whether the subscriber is a list or an individual.) OR if that's conceptually messy, maybe achieve the same effect by having a neutral or transparent sublist for that these individuals would belong to, but which would not be a separate valid list address. Thanks for considering these, == Mitch Marks -- Mitchell Marks CUIP & WIT Tech Coordinator CUIP: Chicago Public Schools / Univ. of Chicago Internet Project WIT: Web Institute for Teachers http://cuip.net/cuip http://tech.cuip.net/ http://wit.uchicago.edu/wit 5640 S Ellis Ave AAC-045, Univ of Chgo, Chgo IL 60637 Phones: Area 773 (O) 702-6041 (F) 702-8212 (H) 241-7166 (C) 620-6744 Email: Primary address: mitchell@cuip.net Alternate UofC addresses (use especially to report problems with CUIP\WIT mail!): mitchell@cs.uchicago.edu and mmar@midway.uchicago.edu Off-campus (ISP) address: mmarks@pobox.com Honk if you support Modus Ponens. From iane at sussex.ac.uk Mon Mar 15 11:35:28 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Mon Mar 15 11:35:47 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: References: Message-ID: <2147483647.1079368528@beeding.central.susx.ac.uk> --On domingo, 14 marzo 2004 23:54 -0500 Vince Sabio wrote: > Hi folks, > > I am currently using Lyris List Manager on an Ultra I running Solaris 8. > The hosting site is pretty large -- we have about 50 mailing lists, with > a dozen of them numbering at 1000 or more subscribers. I have 15 > "Listmoms" who help manage the lists, including moderation > approval/rejection of posts. > > Not surprisingly, MLM features are important to us. I'm considering a > move to Mailman on FreeBSD, but it is difficult to tell if M2 has certain > specific features that have become part of our day-to-day list management > in Lyris. Now, I'm not expecting anyone to design an MLM around the > features that we're looking for ... but since you're soliciting input for > M3, I figure it can't hurt. So, with that in mind, the features in > question are (see below before replying to these): > > * "Semi-moderated" mailing lists (i.e., subscribers are moderated for "N" > posts when they subscribe, and "graduate" to unmoderated status after N > _approved_ posts) This is sort of supported, but the moderator has to do the counting, as far as I know. > * "Spot" moderation (i.e., the ability to [re-]moderate an individual for > "N" posts, or to permanently moderate him, at the moderator's > discretion). It is VERY IMPORTANT that moderation be persistent -- i.e., > if someone figures out he's been permanently moderated, he can't > unsubscribe and resubscribe and thus go back to being moderated for only > "N" posts. (Upon unsub/resub, the implementation should set his > moderation for the higher of the default list moderation count and his > previous moderation setting.) I think this works, but I haven't tried it. Again, the moderator would have to do the counting. > * Moderation via e-mail -- both approve/reject (important) and ability to > set/change a user's moderation state (less important). That is supported > * Ability to create "filters" (preferably via the web UI) that can act > based on the content of incoming messages, and return a customized > message to the subscriber -- e.g., if a message contains the word > "dingleberries" (insert your favorite word there), it can reject the post > and send the poster a customized document, with a copy of the post, > including headers, attached at the bottom (in this case, the "customized > document" would state that, e.g., the post was being returned because it > contained profanity). > > - A modification to this feature is the ability to send messages to > the moderation queue based on their content. That is, a message that > would otherwise post to the list would instead be submitted for > moderation if its content matches a specific filter. This particular > feature is not in our version of Lyris (I do not know if it is in later > versions). > > * Ability to strip certain headers, such as "Precedence:", "Priority:", > and the like. Hmm, you could do this with your MTA, perhaps. Don't think you can do it with mailman - but I don't know any mail clients that use them, so I'm not sure why you would. You can choose to munge reply-to: headers. > * Ability to add custom headers, both static headers (same for all > subscribers) and mail-merged headers (e.g., "X-Message-To:
", > with the subscriber's address in the header). Mailman supports variable envelope return paths - which let you know where bounced messages came from. It also processes the bounces for you, and can unsubscribe someone who keeps bouncing mail. It also adds List-* headers and so on, which comply with RFC 2369 > * Ability for subscribers set NOMAIL mode for a specific length of time > (and/or until a specific date), at which time their previous delivery > mode will be restored. (This is useful when going on vacation; no need to > remember to set their delivery mode back to MAIL, DIGEST, etc.) No, I think you have to remember to turn it back on. You can do this for one list or all lists on the host. > * Ability to ban certain users from subscribing to mailing lists -- both > on a per-list basis and on a site-wide basis. Can do this on a per-list basis. Not sure about site wide. You could knock up a shell script to do this, though. > * Ability to ban certain subscribers from posting to mailing lists (i.e., > from ever even entering the moderation queue). (This feature isn't > terribly important, since we can pretty well handle this in moderation.) Yes, you can do this. > That's a start. Now, I know that the feature list in M2 includes such > things as "New moderation and privacy controls," "emergency moderation," Emergency moderation switches moderation ON for all users on a list - to let a flame war die down, for example. When emergency moderation is switched off, the list is restored to its previous state. > "Majordomo-style e-mail commands," "regex-based topic filtering," Topics allow people to get just some of the list posts, for example, a "fruit" list might have an "apple" topic and an "orange" topic. I could choose whether to get posts that related to "apple" or posts related to "orange", or all posts. You could create a profanity topic, I guess, and let people opt out from receiving profanity. I don't think it would work well, though. > etc., > but I'm not sure if those features translate into the specifics that I > mentioned above. Since we use these features on a daily (or nearly daily) > basis, I wanted to be explicit about the feature set we're looking for. > Again, I'm not expecting anyone to design an M3 around our requirements, > but I igured it couldn't hurt to state them, and might stimulate some > interesting discussion. :-) > > Questions: > > * Is the Welcome message customizable? If not, it would be necessary for > us to be able to customize it. It is customizable - globally and per list. > * Can users request a copy of the customized Welcome message via e-mail? > (I know they can get a "help" message via e-mail.) not sure > * The "Urgent" message feature in M2 is nice -- but can use of it be > limited to just list owners/moderators? > > * Is it possible to REQUIRE/FORCE all e-mail addresses to be concealed? > That is, not even give the users the option? yes > Please feel free to ask for clarification on any of these points. There > are probably more features that we'd be interested in, but I didn't want > to wear out my welcome on the first message (figured I'd wait until the > third or fourth message for that ;-). OK! -- Ian Eiloart Servers Team Sussex University ITS From kmccann at bellanet.org Mon Mar 15 13:26:19 2004 From: kmccann at bellanet.org (Kevin McCann) Date: Mon Mar 15 13:34:22 2004 Subject: [Mailman3-dev] Flexible data storage Message-ID: <4055F54B.8060408@bellanet.org> I am going down to the sprint this weekend with one main mission: to see if I can influence the design and development such that Mailman 3 will support SQL database data storage - as a choice - for the 3 main data sources: - list config - member information - message archives At this point I don't really care if it's MySQL or Postgres. The choice would not hurt, though. I am confident that MM3 will have all of the necessary features to support flexible, multi-purpose mailing lists. I don't think Barry would have it any other way. MM2 is already there in many ways, but there is room for improvement, and I look forward to seeing what MM3 will bring. But after lists have been created, after members are added, and after mail is delivered, I want access to that information on *my own terms*. Don't get me wrong - MM2 has a fine admin interface. And Pipermail ... well ... it's better than nothing. For the majority of sites, this is fine. But many organizations want to access MLM data in ways that MLM interface developers may not have thought of or have not seen the need for. The same need/problem exists with Lyris. It's got a ton of features, it delivers the mail, but dag-nab-it, the interface just doesn't do what I need it to do. And this is why I have developed various home-grown interfaces to Lyris over the last several years. For me, the one-stop-shopping view is nice: 1) user logs in 2) user sees on left side menu a list of lists he/she belongs to 3) user clicks on a list name 4) archives for that list appear in display area beside the menu 5) user clicks on message subject and sees message 6) profile information for the person that sent the list is displayed below the message 7) links to attachments will be available 8) user clicks on another list name in the menu, does same for that list 9) if the list is set to show subcriber list, there will be a link to the subscriber list 10) if the user is an admin of the list, there will be an admin menu below the lists of lists menu 11) there'll be a stats and trends section where users can see the most popular or most recently created lists 12) and on and on ... But there are *so many* ways to access and manipulate MLM data to suit the needs of any given organization. And there are many other community-building sofware solutions that could pull in this data. For example, there are tons of PHP applications - PHP-Nuke, Postnuke, Xaraya, eGroupware, ezPublish, etc. - that could pull in a list's archives and/or membership info and offer it in addition to news, calendar, documents, web links, books, and other things that help build a community of practice. While a really cool interface might be developed as part of MM3, I urge everyone to give due consideration to the aspect of data storage simply because different people and different organizations have different needs. And why SQL as a choice? Well, for one thing, it's easy. It's hugely popular. And there is demand. You know, if I had a dollar for every list or forum message that I have read, in which the author is desperate for a way to get his Mailman list to talk to his PHP app, or get the data into his MySQL database ... well, I'd be a wealthy guy. Just check out the Mailman user list archives or check out the list archives of all the aforementioned CMS's if you have any doubts. I understand where all these people are coming from because I am trying to crack that very same nut. I hope that MM3 will be the ultimate solution in the open source MLM landscape. It can be - by allowing for SQL-based data storage - at least as a choice - for all of the major data sources. - Kevin From ezk at cs.sunysb.edu Mon Mar 15 13:52:29 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 13:54:37 2004 Subject: [Mailman3-dev] Mailman 3 features In-Reply-To: Your message of "Sun, 14 Mar 2004 20:14:53 PST." Message-ID: <200403151852.i2FIqT1d025433@agora.fsl.cs.sunysb.edu> In message , Marilyn Davis writes: > > Multiple-domain support? > > User-generated polls? Sounds interesting. How about some details (esp. motivation). Thanks, Erez. From ezk at cs.sunysb.edu Mon Mar 15 14:00:03 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 14:00:11 2004 Subject: [Mailman3-dev] list manager control Message-ID: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> I'd like to see more features that'd allow admins more control over lists. Some of these may be small features issues (and may be already in the latest v2). 1. I maintain about 30 lists. I'd like it to be possible for my browser to 'remember' a cookie and my password so I don't have to type my admin passwd each time. 2. Is it possible to configure the frequency and date(s) when mailman sends out subscription notifications? I also like to be able to click on button to send a notification to a single user that forgot their password. 3. I often carefully configure one list, then I want to clone it (I don't want to change the global defaults b/c I have several 'classes' of lists). I have to first create the new list, then dump one old list's config, edit it by hand, then reconfigure the new list with the edited config. I'd like a simple command that'd automate much of this for me: that is, a "cp-list" command that will clone a list fully, and just ask me a few questions like "full name for the list" and "do you want to migrate the subscribership and/or archives"? 4. I'd like an integrated (Web) interface for people to manage lists: create new lists (subject to someone's overall authority to approve it), and close+destroy lists permanently. Cheers, Erez. From ezk at cs.sunysb.edu Mon Mar 15 14:05:24 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 14:05:30 2004 Subject: [Mailman3-dev] anti-spam related features Message-ID: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> The amount of spam is increasing in a scary way. All of my lists are closed to non-subscribers (is anyone in their right mind still uses open lists? :-). On occasion I still get some valid posting from a non-subscriber: sometimes from a new person, and sometimes from an existing subscriber that uses a different email address. So I cannot just drop all posts by non-subscribers b/c I don't want to miss those few good ones; OTOH, every day I have to wade through many spams that are left for me to moderate, and reject/discard each one. Here's what I'd like to see: - a one button to accept/reject/discard ALL pending messages. - a way to automatically purge pending messages that haven't been accepted, rejected, or discarded after N days of waiting. That way I don't have bother logging in and cleaning them up every day. - another posting mode that uses an authentication challenge-response mechanism such as the confirmation process that's used during the subscription. Most spammers use bogus addresses and never check them, which is why I personally find challenge-response personal anti-spam systems like ASK and TMDA very effective. Using a challenge-response, I can essentially allow valid posters who are not subscribers to authenticate their pending posting and let it get posted to the list on their own; this saves me (the list owner) time. - integration with Spamassassin and friends, so I can set a rule that says "discard every message with a score > 5.0". - I want a way to reject and/or moderate all non-plaintext email (html, foreign languages, mime encoded, etc.) b/c that's far more likely to be spam. And a bounce message to go with that to tell the person why their message got rejected. - a way for valid subscribers to add aliases to their subscription. That avoids the usual problem of rejecting/holding a posting from a valid subscriber who sent the post from a different email account. I don't like the idea of adding a filter rule to allow all future posts for such a person, b/c that rule remains forever, while the original user could have already unsubscribed. Cheers, Erez. From Dale at Newfield.org Mon Mar 15 14:14:29 2004 From: Dale at Newfield.org (Dale Newfield) Date: Mon Mar 15 14:19:53 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <4055F54B.8060408@bellanet.org> References: <4055F54B.8060408@bellanet.org> Message-ID: On Mon, 15 Mar 2004, Kevin McCann wrote: > - list config > - member information > - message archives A mailing list package is a tool for distributing messages. It is the pipeline through which messages pass. As such it should be described by the pipeline, not by the items passing through it. While I agree two of the most basic concepts in the system are lists and subscribers, I am completely unconvinced that this system should contain the messages passing through it once the tool has done it's job. This is not a message repository--if it is, then what you want is usenet, or yahoo groups, or some other tool. You are welcome to build a new yahoo groups, and I will be glad to shape the mailman design in such a way that it can be a useful tool to help you do just that. I don't, however, want mailman to *be* that tool. I want it to do well that which it does, and in a highly configurable manner so it can be utilized in *many* larger systems. --- Dale Newfield "They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety." - Benjamin Franklin, on the Statue of Liberty From kmccann at bellanet.org Mon Mar 15 15:14:23 2004 From: kmccann at bellanet.org (Kevin McCann) Date: Mon Mar 15 15:14:30 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: References: <4055F54B.8060408@bellanet.org> Message-ID: <40560E9F.4070905@bellanet.org> Dale Newfield wrote: > A mailing list package is a tool for distributing messages. It is the > >pipeline through which messages pass. As such it should be described by >the pipeline, not by the items passing through it. While I agree two of >the most basic concepts in the system are lists and subscribers, I am >completely unconvinced that this system should contain the messages >passing through it once the tool has done it's job. This is not a message >repository--if it is, then what you want is usenet, or yahoo groups, or >some other tool. You are welcome to build a new yahoo groups, and I will >be glad to shape the mailman design in such a way that it can be a useful >tool to help you do just that. I don't, however, want mailman to *be* >that tool. I want it to do well that which it does, and in a highly >configurable manner so it can be utilized in *many* larger systems. > > I do not believe our goals are mutually exclusive. The last third of your paragraph is precisely what I'm getting at. I don't expect MM3 to be a yahoo groups (I thought I was clear on this), but it would be nice for others to be able to develop a yahoo groups or a whatever-groups using MM3 as the backend. Or to use MM3 data in something else like an exisitng CMS. To that end, it would be nice to turn on SQL storage of data, including messages, as a *choice*. Not unlike how personalization is a choice, at the expense of performance. The choice is there because the need is there. I envision a MM3 which can both a) focus on message delivery and *nothing* more, and b) be flexible with regard to data storage, including archives, all depending on the need. Those who want to deliver mail and nothing more can do just that. So be it. And those who want to develop exciting. community building tools can do so, too, using MM3. I believe there is room to think beyond what the definition of a mailing list is, at least in as far as you have decribed it in your first few sentences. What you have said may be true, historically, but must it always be so? This is MM3, a new beginning. Surely we ought to be able to move beyond traditional definitions in our thinking. But again, I see nothing wrong with having an MLM that can run in "traditional mode" or "enhanced mode." The need is there. - Kevin From barry at python.org Mon Mar 15 14:37:16 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 15:15:06 2004 Subject: [Mailman3-dev] Mailman 3 Contributors Agreement In-Reply-To: <19487.1079324864@kanga.nu> References: <1079306265.5218.11.camel@geddy.wooz.org> <19487.1079324864@kanga.nu> Message-ID: <1079379435.5149.205.camel@anthem.wooz.org> On Sun, 2004-03-14 at 23:27, J C Lawrence wrote: > On Sun, 14 Mar 2004 18:17:46 -0500 > Barry Warsaw wrote: > > > http://zope.org/Members/bwarsaw/MailmanDesignNotes/MM3ContributorsAgreement.pdf > > My quibbles: > > I specifically don't want to see Mailman under a "...or any future > version of the GPL..." such that it could become subject to an > Affero-like license. I had to look up what "Affero-like license" meant. AFAICT, it's an attempt to "close the ASP loophole" which I take to mean stopping or controlling the use of GPL'd software in for-fee ASP environments without releasing modifications. Please correct me if I'm wrong. FWIW, I would have no interest in constraining Mailman's use in this way. I /like/ the fact that folks can provide Mailman list hosting services by integrating it into their existing sites. I have no problems with a for-fee ASP delivery model. > I'm uncomfortable with unconstrained re-licensing. Specifically I > dislike the idea of (for example) an MIT/BSD licensing fork which > would allow the third party to then relicense Mailman again under a > license they made up. I'd be happier with a constraint on the > relicensing forms which stated that third parties would only be > allowed to use the code under the license they acquired it under. I don't think anything in the agreement would allow third parties to dual-license Mailman, although /I/ could do it. By guaranteeing Mailman 3 is released under the GPL, this guarantees that it will remain free software, and any contributions will also be available in a free software release. So if I ever did something evil (which I don't plan to do ;), there would also be a GPL'd version of Mailman 3 available that others could fork and continue to release as free software. I see that part of the agreement as insurance to the Mailman and free software communities. Say three years from now someone offers the Mailman Foundation $1M for a non-exclusive alternative-licensed copy of the code. That would be of benefit to the Mailman community because it would help pay for future developments. It's that kind of thing that I want to keep as a possibility. So contributors are just acknowledging that, in addition to their contributions going into a free software release, it's possible that their work may show up in a non-free version. It's never going to be the case that someone would contribute to Mailman 3 and their work would go only into a non-free version. That can't happen because of the guarantee for a free software release of their contribution. A more likely scenario is this: my employer may pay me to add some Mailman-like features to a product. Because of my agreement with them, the relevant bits can also go into the free Mailman 3 distribution. If someone then provides a patch to Mailman that ought to also go into the product, it would be unworkable for me to not cross-port that patch back. So the agreement also makes my life easier by not having to worry about re-implementing patches that make sense on both sides of the fence. Which seems fair to me if my employer were in part helping to support the free Mailman 3 development effort. Does that make sense? -Barry From marilyn at deliberate.com Mon Mar 15 14:44:28 2004 From: marilyn at deliberate.com (Marilyn Davis) Date: Mon Mar 15 15:30:35 2004 Subject: [Mailman3-dev] anti-spam related features In-Reply-To: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> Message-ID: On Mon, 15 Mar 2004, Erez Zadok wrote: > > The amount of spam is increasing in a scary way. All of my lists are closed > to non-subscribers (is anyone in their right mind still uses open lists? > :-). On occasion I still get some valid posting from a non-subscriber: > sometimes from a new person, and sometimes from an existing subscriber that > uses a different email address. So I cannot just drop all posts by > non-subscribers b/c I don't want to miss those few good ones; OTOH, every > day I have to wade through many spams that are left for me to moderate, and > reject/discard each one. Here's what I'd like to see: > > - a one button to accept/reject/discard ALL pending messages. > > - a way to automatically purge pending messages that haven't been accepted, > rejected, or discarded after N days of waiting. That way I don't have > bother logging in and cleaning them up every day. > > - another posting mode that uses an authentication challenge-response > mechanism such as the confirmation process that's used during the > subscription. Most spammers use bogus addresses and never check them, > which is why I personally find challenge-response personal anti-spam > systems like ASK and TMDA very effective. Using a challenge-response, I > can essentially allow valid posters who are not subscribers to > authenticate their pending posting and let it get posted to the list on > their own; this saves me (the list owner) time. Oh yes! Please do this! Marilyn Davis > > - integration with Spamassassin and friends, so I can set a rule that says > "discard every message with a score > 5.0". > > - I want a way to reject and/or moderate all non-plaintext email (html, > foreign languages, mime encoded, etc.) b/c that's far more likely to be > spam. And a bounce message to go with that to tell the person why their > message got rejected. > > - a way for valid subscribers to add aliases to their subscription. That > avoids the usual problem of rejecting/holding a posting from a valid > subscriber who sent the post from a different email account. I don't like > the idea of adding a filter rule to allow all future posts for such a > person, b/c that rule remains forever, while the original user could have > already unsubscribed. > > Cheers, > Erez. > > _______________________________________________ > Mailman3-Dev mailing list > Mailman3-Dev@python.org > Unsubscribe: http://mail.python.org/mailman/options/mailman3-dev/marilyn%40deliberate.com > > -- From Dale at Newfield.org Mon Mar 15 15:50:05 2004 From: Dale at Newfield.org (Dale Newfield) Date: Mon Mar 15 15:50:10 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <40560E9F.4070905@bellanet.org> References: <4055F54B.8060408@bellanet.org> <40560E9F.4070905@bellanet.org> Message-ID: On Mon, 15 Mar 2004, Kevin McCann wrote: > I envision a MM3 which can both a) focus on message delivery and > *nothing* more, and b) be flexible with regard to data storage, > including archives, all depending on the need. Those who want to > deliver mail and nothing more can do just that. So be it. And those who > want to develop exciting. community building tools can do so, too, using > MM3. The questions of "who defines what nouns (tables) exist," "who defines how those nouns (tables) translate into mailing lists," and "who manages the nouns (rows in tables)" are critical here. If MM is to function, it clearly needs to expect to be able to determine some nouns and manage them. It isn't necessarily *the* repository, though. While MM3 bolted onto XYZ community system will need to be able to know something about "subscribers," that community system probably already defines a "user/member" table, and the questions above become paramount. I suggest we build this thing in a modular manner, letting it be realized in configurable fashions. An example I keep going back to is for a school. They likely already have in place something that says "these students exist" and "these classes exist" and crossover tables that say "this student is in this class". Why not be able to set up one list-type as "class-list". It would require adding a "list-configuration" foreign key either for the entire list-type or per-class, and it would require adding a "subscription" foreign key to the crossover table. It would require somehow storing per-subscriber (instead of per-subscription) info in either the student table directly, or maybe a foreign key. This would enable the "student" table to exist within the app, the "subscriber" table to exist within MM3 and linkages between them. I've attempted to write about this in a general way several times before and feel I've never succeeded well. This is why I'm looking forward to the sprint. Separately: While there's plenty of complexity here, it's all in managing the pipeline. The things moving through it are bags of bits and while those bags may have internal structure, handling them as anything more than bags of bits is really out of scope. We've got plenty of complexity without trying to come up with yet another way to store structured email headers/body/attachments/etc. in a DB in a queryable manner. --- Dale Newfield "They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety." - Benjamin Franklin, on the Statue of Liberty From marilyn at deliberate.com Mon Mar 15 15:02:18 2004 From: marilyn at deliberate.com (Marilyn Davis) Date: Mon Mar 15 16:13:09 2004 Subject: [Mailman3-dev] User-generated polls In-Reply-To: <200403151852.i2FIqT1d025433@agora.fsl.cs.sunysb.edu> Message-ID: On Mon, 15 Mar 2004, Erez Zadok wrote: > In message , Marilyn Davis writes: > > > > Multiple-domain support? > > > > User-generated polls? > > Sounds interesting. How about some details (esp. motivation). My motivation is a deep love of democracy and the hope that bringing forward a truly cooperative model of decision-making will help the world. But any list that invites input from the members for decision-making (like this one), might like to use it for polling, rather than having someone do a hand count of the votes in messages. There is a patch for Mailman 2.0.13 at http://www.sourceforge.net/projects/evote that attaches polling/voting facilities to Mailman lists. Any user can poll the list by sending the command: --- eVote poll public visible [y/n] message: Shall we implement polling/voting? --- for example, to the list address. eVote sucks the mail out of the mail stream and generates instructions that go to the list. The "eVote" keyword is used for voting, changing your vote when the discussion changes your mind, querying the results, seeing how others voted (if public), and generating new polls -- which can be numeric, multiple choice, or rate the choices. If you wish to see this in action, you are welcome to play with the fiddle@deliberate.com list. Regrettably, it is a majordomo list since we don't allow web access at deliberate.com's mail-server. But it works the same on Mailman 2.0.13, i.e., no web interface. eVote's mail messages are generated in C, the underlying specialized database server (The Clerk) is in C++. A Python-generated web interface would be lovely and much easier to use. If anyone wants to fiddle with the existing eVote/Clerk software, you are welcome to fiddle: 1. Write to: majordomo@deliberate.com 2. Subject doesn't matter. 3. Message should say: subscribe fiddle Then follow the directions that will be sent to you to generate a poll. The members of the list will be delighted to vote on your poll and welcome you to the fiddle-with-eVote place. > > Thanks, Thank you for your question. Marilyn Davis, Ph.D marilyn@deliberate.com -1 650 965-7121 Author of eVote(R)/Clerk http://www.deliberate.com > Erez. > > _______________________________________________ > Mailman3-Dev mailing list > Mailman3-Dev@python.org > Unsubscribe: http://mail.python.org/mailman/options/mailman3-dev/marilyn%40deliberate.com > > -- From mamandel at ldc.upenn.edu Mon Mar 15 16:19:21 2004 From: mamandel at ldc.upenn.edu (Mark A. Mandel) Date: Mon Mar 15 16:19:25 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: References: Message-ID: I'm rather concerned, seeing proposals like "the list is the pipeline; if you want an archive, set it up yourself and attach it" -- or so I interpret some of what I've just seen here. I'm an administrator and a linguist, not an engineer; and the engineers who work for this project and the institutes that it's connected to are already overloaded. While there are a number of improvements I'd like to see in the archiving functionality, it's much, much better than having none, or having to kludge our own. -- Mark A. Mandel Linguistic Data Consortium, University of Pennsylvania From jon at indelible.org Mon Mar 15 15:04:13 2004 From: jon at indelible.org (Jon Parise) Date: Mon Mar 15 16:20:42 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> Message-ID: <20040315200413.GB62742@indelible.org> On Mon, Mar 15, 2004 at 02:00:03PM -0500, Erez Zadok wrote: > 2. Is it possible to configure the frequency and date(s) when mailman sends > out subscription notifications? Because this is handled by a cron job, the frequency is completely configurable by the administrator. I think this is the best way to handle these types of reminders. -- Jon Parise (jon@indelible.org) :: "Scientia est Potentia" From ezk at cs.sunysb.edu Mon Mar 15 16:22:00 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 16:22:04 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: Your message of "Mon, 15 Mar 2004 14:14:29 EST." Message-ID: <200403152122.i2FLM0kj027245@agora.fsl.cs.sunysb.edu> In message , Dale Newfield writes: > On Mon, 15 Mar 2004, Kevin McCann wrote: > > - list config > > - member information > > - message archives > > A mailing list package is a tool for distributing messages. It is the > pipeline through which messages pass. As such it should be described by > the pipeline, not by the items passing through it. While I agree two of > the most basic concepts in the system are lists and subscribers, I am > completely unconvinced that this system should contain the messages > passing through it once the tool has done it's job. This is not a message > repository--if it is, then what you want is usenet, or yahoo groups, or > some other tool. You are welcome to build a new yahoo groups, and I will > be glad to shape the mailman design in such a way that it can be a useful > tool to help you do just that. I don't, however, want mailman to *be* > that tool. I want it to do well that which it does, and in a highly > configurable manner so it can be utilized in *many* larger systems. I suspect that over the coming weeks, we'll easily get into genuine disagreements over the scope of the work. One person's vision and desire for certain features may easily conflict with another's. A total rewrite of such an important package comes once is a long time (and I applaud Mailman's maintainers for having the guts and foresight to take on such a big task). I'm sure no one would want to have to rewrite Mailman yet again. Any good software package has to accommodate its own evolution through flexible EXTENSIBILITY mechanisms (i.e., hooks and published APIs). I think the design of MM3 should be such that it will have a good deal of decoupled modules that "talk" to each other using well-established and flexible APIs. We have a rare opportunity to create a design that'd last for many years. - It should be easy, for example, for anyone to replace the current plaintext storage subsystem with an SQL backend. - I should be able to easily define a chain of pre-processing filters (e.g., spamc) to get a hold of the message before MM does. - Similarly, post-processing hooks: what if I want to pipe each message to PGP or some other crypto tool before it's saved on disk. - even the management API could be decoupled from the current HTML one. What if I wanted to write a GNOME or SNMP API to manage mailman? - Imagine that with a pre-subscription hook, I could ask for someone to input their PGP public key. Then, with a compatible hook just before sending a message to a subscriber, I could sign the message with the key. I'm not sure if this is a feature that we want to put in MM3 from the very beginning, but the *hooks* should be there. With a highly-flexible design, we would find that many people will contribute extensions and modules for MM3; and commercial vendors will be very happy too (I surmise from the IP discussions that Barry wants to keep the GPL but also accommodate commercial uses of MM w/o the usual restrictions of the GPL -- the ever more popular dual-mode license). Cheers, Erez. From barry at python.org Mon Mar 15 16:24:19 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 16:24:27 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <4055F54B.8060408@bellanet.org> References: <4055F54B.8060408@bellanet.org> Message-ID: <1079385858.5149.261.camel@anthem.wooz.org> On Mon, 2004-03-15 at 13:26, Kevin McCann wrote: > I am going down to the sprint this weekend with one main mission: to > see if I can influence the design and development such that Mailman 3 > will support SQL database data storage - as a choice - for the 3 main > data sources: > > - list config > - member information > - message archives I actually think there may be four data sources. I've been thinking that we may want to separate out member information and what might be called authentication information. Specifically the latter is "username and password", where for our purposes, username is probably email address (but this may not be evident in the interface). The reason for this is that list member information will be fairly application specific, i.e. foo@example.com has a bounce score of 3.0 and gets digests. I can envision a site wanting to separate these two sources of data, such that username:password authentication comes out of their corporate LDAP database, while they're perfectly happy to let Mailman manage the application specific data. -Barry From barry at python.org Mon Mar 15 16:26:20 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 16:26:29 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: References: <4055F54B.8060408@bellanet.org> Message-ID: <1079385980.5149.264.camel@anthem.wooz.org> On Mon, 2004-03-15 at 14:14, Dale Newfield wrote: > A mailing list package is a tool for distributing messages. It is the > pipeline through which messages pass. As such it should be described by > the pipeline, not by the items passing through it. While I agree two of > the most basic concepts in the system are lists and subscribers, I am > completely unconvinced that this system should contain the messages > passing through it once the tool has done it's job. I think we've identified use cases in the past where Mailman wants access to a message store. Thus I believe it is in our interest to define an interface which allows Mailman to read and write the message store data it will be interested in. -Barry From barry at python.org Mon Mar 15 16:31:06 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 16:31:14 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: References: <4055F54B.8060408@bellanet.org> <40560E9F.4070905@bellanet.org> Message-ID: <1079386265.5149.270.camel@anthem.wooz.org> On Mon, 2004-03-15 at 15:50, Dale Newfield wrote: > The questions of "who defines what nouns (tables) exist," "who defines how > those nouns (tables) translate into mailing lists," and "who manages the > nouns (rows in tables)" are critical here. If MM is to function, it > clearly needs to expect to be able to determine some nouns and manage > them. This is the primary thing I want to come out of the sprint with: an interface, defined in Pythonic/Zopeish/PyProtocolli nomenclature, of the types of data that Mailman will want to read and write. This will be the primary communications mechanism for those writing the db backends -- which will have to map those interfaces to whatever storage formats are most appropriate -- and the Mailman source code, which will not care about the implementation of the backends. Of course, there are tricky bits at the edges such as, how do you define which storages Mailman actually uses? How do you create them? How do you cleanly close them? How do you define transaction boundaries? How do you manage transactions across multiple different data storages? I have some stuff about this in the MM3 source, which I will soon be checking in. I'm not entirely happy with it... > This would > enable the "student" table to exist within the app, the "subscriber" table > to exist within MM3 and linkages between them. I've attempted to write > about this in a general way several times before and feel I've never > succeeded well. This is why I'm looking forward to the sprint. Me too. It's hard stuff. -Barry From ezk at cs.sunysb.edu Mon Mar 15 16:31:43 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 16:31:47 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: Your message of "Mon, 15 Mar 2004 16:24:19 EST." <1079385858.5149.261.camel@anthem.wooz.org> Message-ID: <200403152131.i2FLVhru027496@agora.fsl.cs.sunysb.edu> In message <1079385858.5149.261.camel@anthem.wooz.org>, Barry Warsaw writes: > On Mon, 2004-03-15 at 13:26, Kevin McCann wrote: > > I am going down to the sprint this weekend with one main mission: to > > see if I can influence the design and development such that Mailman 3 > > will support SQL database data storage - as a choice - for the 3 main > > data sources: > > > > - list config > > - member information > > - message archives > > I actually think there may be four data sources. I've been thinking > that we may want to separate out member information and what might be > called authentication information. Specifically the latter is "username > and password", where for our purposes, username is probably email > address (but this may not be evident in the interface). BTW, it'd be nice if the subscriber list and their passwords will also be encrypted on disk somehow. I fear the day when hackers manage to break into mailing list systems just to steal a huge subscriber list. And, while I'm on the subject of extensibility, how about a hook to force passwords to expire and have to be changed; and another hook for enforcing password quality (min/max length, mix of alpha, numbers, upper/lower case, special chars, etc.). Erez. From barry at python.org Mon Mar 15 16:38:12 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 16:38:23 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <200403152122.i2FLM0kj027245@agora.fsl.cs.sunysb.edu> References: <200403152122.i2FLM0kj027245@agora.fsl.cs.sunysb.edu> Message-ID: <1079386691.5149.278.camel@anthem.wooz.org> On Mon, 2004-03-15 at 16:22, Erez Zadok wrote: > I suspect that over the coming weeks, we'll easily get into genuine > disagreements over the scope of the work. One person's vision and desire > for certain features may easily conflict with another's. A total rewrite of > such an important package comes once is a long time (and I applaud Mailman's > maintainers for having the guts and foresight to take on such a big task). Some would say we're insane and delusional. :) > I'm sure no one would want to have to rewrite Mailman yet again. Any good > software package has to accommodate its own evolution through flexible > EXTENSIBILITY mechanisms (i.e., hooks and published APIs). I think the > design of MM3 should be such that it will have a good deal of decoupled > modules that "talk" to each other using well-established and flexible APIs. > We have a rare opportunity to create a design that'd last for many years. I totally agree. I'm thinking of Mailman 3 more as a library or a framework than an application. Of course, only a small number of hackers will care about that, and we need to keep in mind that we're going to distribute something useful. Which means that there will be default implementations of most of the APIs. Having a turnkey list manager that's at least as easy and featureful as MM2 is a high priority. > - It should be easy, for example, for anyone to replace the current > plaintext storage subsystem with an SQL backend. +1 > - I should be able to easily define a chain of pre-processing filters (e.g., > spamc) to get a hold of the message before MM does. +0, mostly because we have to tease out where the boundary between the MTA and the MLM is going to be. For example, a virus detector probably belongs in the MTA long before Mailman sees the message. A spam detector /might/ belong in the MTA, but clearly Mailman wants to do some classification of messages before it hits the list membership. > - Similarly, post-processing hooks: what if I want to pipe each message to > PGP or some other crypto tool before it's saved on disk. +1 > - even the management API could be decoupled from the current HTML one. > What if I wanted to write a GNOME or SNMP API to manage mailman? Or Cocoa . +1 > - Imagine that with a pre-subscription hook, I could ask for someone to > input their PGP public key. Then, with a compatible hook just before > sending a message to a subscriber, I could sign the message with the key. > I'm not sure if this is a feature that we want to put in MM3 from the very > beginning, but the *hooks* should be there. +1 -Barry From barry at python.org Mon Mar 15 16:42:18 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 16:42:28 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <200403152131.i2FLVhru027496@agora.fsl.cs.sunysb.edu> References: <200403152131.i2FLVhru027496@agora.fsl.cs.sunysb.edu> Message-ID: <1079386937.5149.283.camel@anthem.wooz.org> On Mon, 2004-03-15 at 16:31, Erez Zadok wrote: > BTW, it'd be nice if the subscriber list and their passwords will also be > encrypted on disk somehow. I fear the day when hackers manage to break into > mailing list systems just to steal a huge subscriber list. That would probably be the role of the backend storage, but it does have implications for the API and the functionality. For example, if the backend is allowed to encrypt passwords, it may be impossible to do password recovery. Password resets may be the only option. We need a flexible interface to be able to express those options. (Aside: Mailman 3 will have no monthly password reminders. I don't know if y'all hate those as much as I do, but we should look forward to the day where we don't have to celebrate our monthly curse: Mailman Day. :) > And, while I'm on the subject of extensibility, how about a hook to force > passwords to expire and have to be changed; and another hook for enforcing > password quality (min/max length, mix of alpha, numbers, upper/lower case, > special chars, etc.). It's something we should definitely keep in mind, as an extension probably. This is where a defined data model will be useful since such hooks can be written against the backend data perhaps. -Barry From barry at python.org Mon Mar 15 16:44:16 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 16:44:25 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: References: Message-ID: <1079387055.5149.286.camel@anthem.wooz.org> On Mon, 2004-03-15 at 16:19, Mark A. Mandel wrote: > I'm rather concerned, seeing proposals like "the list is the pipeline; > if you want an archive, set it up yourself and attach it" -- or so I > interpret some of what I've just seen here. I'm an administrator and a > linguist, not an engineer; and the engineers who work for this project > and the institutes that it's connected to are already overloaded. While > there are a number of improvements I'd like to see in the archiving > functionality, it's much, much better than having none, or having to > kludge our own. Don't worry, I want Mailman 3 to be at least as usable out of the box as Mailman 2 is. I'm confident that Pipermail can be poked and prodded to work with Mailman 3, barring some industrious high schooler with nothing better to do, taking ownership of creating a next generation archiver. -Barry From barry at python.org Mon Mar 15 16:49:46 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 16:49:54 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> Message-ID: <1079387385.5149.292.camel@anthem.wooz.org> On Mon, 2004-03-15 at 14:00, Erez Zadok wrote: > 1. I maintain about 30 lists. I'd like it to be possible for my browser to > 'remember' a cookie and my password so I don't have to type my admin > passwd each time. +1. The way I see it is that you will have one login per Mailman site (note that on virtual host systems, you will have one login per virtual host). Once you've logged in, you will have permission to admin any list you are an owner of, or change your profile, which includes information about all the lists you're a member of. > 2. Is it possible to configure the frequency and date(s) when mailman sends > out subscription notifications? I also like to be able to click on > button to send a notification to a single user that forgot their > password. I'm not sure I understand. Do you mean password reminders? (See my previous message about that.) I would like to see the admins able to do some of the things they now have to do via a user's options page. > 3. I often carefully configure one list, then I want to clone it (I don't > want to change the global defaults b/c I have several 'classes' of > lists). I have to first create the new list, then dump one old list's > config, edit it by hand, then reconfigure the new list with the edited > config. I'd like a simple command that'd automate much of this for me: > that is, a "cp-list" command that will clone a list fully, and just ask > me a few questions like "full name for the list" and "do you want to > migrate the subscribership and/or archives"? +1. List styles. Yes, yes, yes. I'm not sure whether styles will be hierarchical or flat though. > 4. I'd like an integrated (Web) interface for people to manage lists: create > new lists (subject to someone's overall authority to approve it), and > close+destroy lists permanently. While you will be able to run Mailman 3 with no web interface, or a web interface of your own design, I really want the default one to be much more usable than MM2's. It should also be moderately more customizable. But I'm not a html artist, so we'll have to recruit one, or grow them from our own community. -Barry From ezk at cs.sunysb.edu Mon Mar 15 16:56:20 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 16:56:31 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: Your message of "Mon, 15 Mar 2004 16:42:18 EST." <1079386937.5149.283.camel@anthem.wooz.org> Message-ID: <200403152156.i2FLuKri028130@agora.fsl.cs.sunysb.edu> In message <1079386937.5149.283.camel@anthem.wooz.org>, Barry Warsaw writes: > On Mon, 2004-03-15 at 16:31, Erez Zadok wrote: > > (Aside: Mailman 3 will have no monthly password reminders. I don't know > if y'all hate those as much as I do, but we should look forward to the > day where we don't have to celebrate our monthly curse: Mailman Day. :) I take it you that over the years you got "a few" complaints about this? :-) Actually I like that feature. What I don't like is that the reminders all come on the same day by default. It's easy to fix it if MM2 would just pick a random day to stick in the cron job; or better yet, that this would be a configurable feature. I don't like losing features in newer releases, just b/c they're annoying to _some_ people. It is useful to others. You could turn off the reminder by default, and allow an admin to set it to some frequency as they see fit. Erez. From barry at python.org Mon Mar 15 17:03:31 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 17:03:38 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <200403152156.i2FLuKri028130@agora.fsl.cs.sunysb.edu> References: <200403152156.i2FLuKri028130@agora.fsl.cs.sunysb.edu> Message-ID: <1079388210.5149.308.camel@anthem.wooz.org> On Mon, 2004-03-15 at 16:56, Erez Zadok wrote: > I take it you that over the years you got "a few" complaints about this? :-) Yep, from admins and users. There are several problems with the current implementation. It requires a site-list (the old situation of picking a random list to send the reminders from sucked worse). If your bounce processing isn't smart enough, admins will get bombarded with bounce backs. Users complain bitterly about the cleartext passwords they get. Most users /still/ can't figure out how to get themselves unsubscribed from their lists (we get lots of replies which quote the whole password reminder and ask us to unsub them). Other than that, they work great. :) The one potentially useful feature is that they can help identify dead addresses, but I think (hope, pray) that with 2.1.5 we'll get a sensible enough bounce processing algorithm that piggybacking it on password reminders won't be necessary. > Actually I like that feature. What I don't like is that the reminders all > come on the same day by default. It's easy to fix it if MM2 would just pick > a random day to stick in the cron job; or better yet, that this would be a > configurable feature. > > I don't like losing features in newer releases, just b/c they're annoying to > _some_ people. It is useful to others. You could turn off the reminder by > default, and allow an admin to set it to some frequency as they see fit. Do you think a password reminder that comes from noreply@lists.example.com, throws away bounces, and doesn't include plain text passwords would still be useful? -Barry From ezk at cs.sunysb.edu Mon Mar 15 17:09:39 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 17:09:47 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: Your message of "Mon, 15 Mar 2004 16:38:12 EST." <1079386691.5149.278.camel@anthem.wooz.org> Message-ID: <200403152209.i2FM9d29028427@agora.fsl.cs.sunysb.edu> In message <1079386691.5149.278.camel@anthem.wooz.org>, Barry Warsaw writes: > On Mon, 2004-03-15 at 16:22, Erez Zadok wrote: > I totally agree. I'm thinking of Mailman 3 more as a library or a > framework than an application. Of course, only a small number of > hackers will care about that, and we need to keep in mind that we're > going to distribute something useful. Which means that there will be > default implementations of most of the APIs. Having a turnkey list > manager that's at least as easy and featureful as MM2 is a high > priority. Agreed. A library alone would not be terribly useful to anyone. It has to have at least a superset of sorts of the features of V2. On a related note, it's vital that MM3 will be as much as possible a drop-in replacement for MM2. If a configuration/format change is required then I don't mind running a script "convert-v2-to-v3.py" but I don't want to have to hand-fix or hack my lists for V3. It'd be even nicer if there were a backout option ("convert-v3-to-v2.py"). All these will be crucial for MM3's adoption (you don't want to be stuck maintaining both v2 and v3 for years, right?) I'm reminded that one of the reasons why EXT3 was adopted so quickly was that there had always been a simple procedure for converting an EXT2 file system to EXT3 -- *and* back(!) > > - I should be able to easily define a chain of pre-processing filters (e.g., > > spamc) to get a hold of the message before MM does. > > +0, mostly because we have to tease out where the boundary between the > MTA and the MLM is going to be. For example, a virus detector probably > belongs in the MTA long before Mailman sees the message. A spam > detector /might/ belong in the MTA, but clearly Mailman wants to do some > classification of messages before it hits the list membership. Yes, well, there's a raging debate where anti-spam/anti-virus things should be addressed: the MTA, LDA, per-user, ingress routers, or even congress. I personally think that ultimately the entire Internet will have to move to a strongly authenticated form of SMTP -- that seems to me like the most appropriate place for such filtering software. But we're a long way from that happening, so for the time being, it'd be nice if MM3 could support it. Therefore, it is even more important that the way for supporting anti-spam packages in MM3 would be through flexible hooks/APIs. One day, when we have anti-spam integrated into SMTP, I'd want to turn *off* Mailman's support for that (in fact, even today you could buy routers that have anti-spam built in --- yes, they have to assemble whole SMTP messages from individual packets, inspect each message, then fragment the message again into packets for sending to the next hop). Erez. From ezk at cs.sunysb.edu Mon Mar 15 17:13:00 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 17:13:07 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: Your message of "Mon, 15 Mar 2004 16:49:46 EST." <1079387385.5149.292.camel@anthem.wooz.org> Message-ID: <200403152213.i2FMD04F028551@agora.fsl.cs.sunysb.edu> In message <1079387385.5149.292.camel@anthem.wooz.org>, Barry Warsaw writes: > On Mon, 2004-03-15 at 14:00, Erez Zadok wrote: > > > 2. Is it possible to configure the frequency and date(s) when mailman sends > > out subscription notifications? I also like to be able to click on > > button to send a notification to a single user that forgot their > > password. > > I'm not sure I understand. Do you mean password reminders? (See my > previous message about that.) I would like to see the admins able to do > some of the things they now have to do via a user's options page. Yes, I meant password reminders (which are wonderfully in cleartext :-). Hmm, maybe a different form of a password reminder might be to send the user a temporary "cookie'd" URL saying "click here within 24 hours to go to the Web page that will show you your password." Of course to make that more secure, HTTPS would be needed. Erez. From ezk at cs.sunysb.edu Mon Mar 15 17:17:52 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 17:18:01 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: Your message of "Mon, 15 Mar 2004 17:03:31 EST." <1079388210.5149.308.camel@anthem.wooz.org> Message-ID: <200403152217.i2FMHq47028689@agora.fsl.cs.sunysb.edu> In message <1079388210.5149.308.camel@anthem.wooz.org>, Barry Warsaw writes: > On Mon, 2004-03-15 at 16:56, Erez Zadok wrote: > > Do you think a password reminder that comes from > noreply@lists.example.com, throws away bounces, and doesn't include > plain text passwords would still be useful? > > -Barry Yes, that'd be useful. See the post I just made regarding sending a cookie'd URL that will expire within N hours, for the user to click on, to view their password. Erez. From jon at indelible.org Mon Mar 15 15:00:03 2004 From: jon at indelible.org (Jon Parise) Date: Mon Mar 15 17:19:55 2004 Subject: [Mailman3-dev] anti-spam related features In-Reply-To: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> References: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> Message-ID: <20040315200003.GA62742@indelible.org> On Mon, Mar 15, 2004 at 02:05:24PM -0500, Erez Zadok wrote: > - a way for valid subscribers to add aliases to their subscription. That > avoids the usual problem of rejecting/holding a posting from a valid > subscriber who sent the post from a different email account. I don't like > the idea of adding a filter rule to allow all future posts for such a > person, b/c that rule remains forever, while the original user could have > already unsubscribed. I like this idea. It would be conceptually similar to the notion of a "profile". Subscribers would be able to add or remove email addresses from their profile, and each address could be configured with the various list options (hold message, no-MIME). Adding or removing an address might require a confirmation step. A subscriber could manage their profile by using any of their subscribed addresses as the "key". -- Jon Parise (jon@indelible.org) :: "Scientia est Potentia" From barry at python.org Mon Mar 15 17:20:50 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 17:20:58 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <200403152209.i2FM9d29028427@agora.fsl.cs.sunysb.edu> References: <200403152209.i2FM9d29028427@agora.fsl.cs.sunysb.edu> Message-ID: <1079389249.5149.314.camel@anthem.wooz.org> On Mon, 2004-03-15 at 17:09, Erez Zadok wrote: > On a related note, it's vital that MM3 will be as much as possible a drop-in > replacement for MM2. If a configuration/format change is required then I > don't mind running a script "convert-v2-to-v3.py" but I don't want to have > to hand-fix or hack my lists for V3. It'd be even nicer if there were a > backout option ("convert-v3-to-v2.py"). All these will be crucial for MM3's > adoption (you don't want to be stuck maintaining both v2 and v3 for years, > right?) > > I'm reminded that one of the reasons why EXT3 was adopted so quickly was > that there had always been a simple procedure for converting an EXT2 file > system to EXT3 -- *and* back(!) Excellent point. We should strive for that. > Yes, well, there's a raging debate where anti-spam/anti-virus things should > be addressed: the MTA, LDA, per-user, ingress routers, or even congress. I > personally think that ultimately the entire Internet will have to move to a > strongly authenticated form of SMTP -- that seems to me like the most > appropriate place for such filtering software. But we're a long way from > that happening, so for the time being, it'd be nice if MM3 could support it. > > Therefore, it is even more important that the way for supporting anti-spam > packages in MM3 would be through flexible hooks/APIs. The filtering working group of ASRG is trying to flesh out interoperability standards for headers and such. I haven't had time to follow the group closely, but I think that will be relevant here. -Barry From barry at python.org Mon Mar 15 17:23:12 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 17:23:22 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <200403152213.i2FMD04F028551@agora.fsl.cs.sunysb.edu> References: <200403152213.i2FMD04F028551@agora.fsl.cs.sunysb.edu> Message-ID: <1079389391.5149.316.camel@anthem.wooz.org> On Mon, 2004-03-15 at 17:13, Erez Zadok wrote: > Hmm, maybe a different form of a password reminder might be to send the user > a temporary "cookie'd" URL saying "click here within 24 hours to go to the > Web page that will show you your password." Of course to make that more > secure, HTTPS would be needed. Maybe subscription reminders without clear text passwords, but including a "reset your password" link? -Barry From barry at python.org Mon Mar 15 17:28:19 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 17:28:27 2004 Subject: [Mailman3-dev] anti-spam related features In-Reply-To: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> References: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> Message-ID: <1079389698.5149.319.camel@anthem.wooz.org> On Mon, 2004-03-15 at 14:05, Erez Zadok wrote: > - a one button to accept/reject/discard ALL pending messages. +1 > - a way to automatically purge pending messages that haven't been accepted, > rejected, or discarded after N days of waiting. That way I don't have > bother logging in and cleaning them up every day. +1 > - another posting mode that uses an authentication challenge-response > mechanism such as the confirmation process that's used during the > subscription. Most spammers use bogus addresses and never check them, > which is why I personally find challenge-response personal anti-spam > systems like ASK and TMDA very effective. Using a challenge-response, I > can essentially allow valid posters who are not subscribers to > authenticate their pending posting and let it get posted to the list on > their own; this saves me (the list owner) time. +1. I like the way Gmane does it. > - integration with Spamassassin and friends, so I can set a rule that says > "discard every message with a score > 5.0". I'd also like to see some integration efforts with Spambayes. Getting a generic interface and U/I for this stuff is going to be tricky. > - I want a way to reject and/or moderate all non-plaintext email (html, > foreign languages, mime encoded, etc.) b/c that's far more likely to be > spam. And a bounce message to go with that to tell the person why their > message got rejected. > > - a way for valid subscribers to add aliases to their subscription. +1 -Barry From ezk at cs.sunysb.edu Mon Mar 15 17:36:36 2004 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Mon Mar 15 17:36:45 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: Your message of "Mon, 15 Mar 2004 17:23:12 EST." <1079389391.5149.316.camel@anthem.wooz.org> Message-ID: <200403152236.i2FMaaVZ029154@agora.fsl.cs.sunysb.edu> In message <1079389391.5149.316.camel@anthem.wooz.org>, Barry Warsaw writes: > On Mon, 2004-03-15 at 17:13, Erez Zadok wrote: > > > Hmm, maybe a different form of a password reminder might be to send the user > > a temporary "cookie'd" URL saying "click here within 24 hours to go to the > > Web page that will show you your password." Of course to make that more > > secure, HTTPS would be needed. > > Maybe subscription reminders without clear text passwords, but including > a "reset your password" link? That'd work too: no dangerous cleartext passwords. And for the person who doesn't remember their password, let 'em reset it (which of course comes in cleartext :-) Erez. From roy at rant-central.com Mon Mar 15 17:41:51 2004 From: roy at rant-central.com (Roy M. Silvernail) Date: Mon Mar 15 17:48:54 2004 Subject: [Mailman3-dev] Close coupling of RSS generation? Message-ID: <1079390511.21734.4.camel@localhost> I've worked a bit with the unofficial RSS patch to HyperArchive. It would be great to see better RSS generation (support for content:encoded and access to message content pre-HTMLized) integrated into MM3. -- Roy M. Silvernail is roy@rant-central.com, and you're not Never Forget: It's Only 1's and 0's! SpamAssassin->procmail->/dev/null->bliss http://www.rant-central.com From barry at python.org Mon Mar 15 18:12:56 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 18:13:05 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: References: Message-ID: <1079392375.8401.4.camel@anthem.wooz.org> On Sun, 2004-03-14 at 23:54, Vince Sabio wrote: > * "Semi-moderated" mailing lists (i.e., subscribers are moderated for > "N" posts when they subscribe, and "graduate" to unmoderated status > after N _approved_ posts) Currently manual, but I could see automating this. > * "Spot" moderation (i.e., the ability to [re-]moderate an individual > for "N" posts, or to permanently moderate him, at the moderator's > discretion). It is VERY IMPORTANT that moderation be persistent -- > i.e., if someone figures out he's been permanently moderated, he > can't unsubscribe and resubscribe and thus go back to being moderated > for only "N" posts. (Upon unsub/resub, the implementation should set > his moderation for the higher of the default list moderation count > and his previous moderation setting.) This is an important point. I'm wondering if Mailman 3 should ever totally "forget" about a user? > * Ability to create "filters" (preferably via the web UI) that can > act based on the content of incoming messages, and return a > customized message to the subscriber -- e.g., if a message contains > the word "dingleberries" (insert your favorite word there), it can > reject the post and send the poster a customized document, with a > copy of the post, including headers, attached at the bottom (in this > case, the "customized document" would state that, e.g., the post was > being returned because it contained profanity). I have some thoughts on a more flexible "actions" framework that would allow an admin to set up better allow, hold, reject, discard rules. > * Ability to add custom headers, both static headers (same for all > subscribers) and mail-merged headers (e.g., "X-Message-To: >
", with the subscriber's address in the header). I have a neat approach for mail merging that I think will be pretty efficient, and should allow for stuff like the latter. > * Ability for subscribers set NOMAIL mode for a specific length of > time (and/or until a specific date), at which time their previous > delivery mode will be restored. (This is useful when going on > vacation; no need to remember to set their delivery mode back to > MAIL, DIGEST, etc.) Long talked about. > * Is the Welcome message customizable? If not, it would be necessary > for us to be able to customize it. Yes, but via the file system. A good question to start talking about is whether and what parts will be editable through the web, and what level of permission would be required to edit some pages through the web (i.e. a site may not trust all its list admins). We definitely want to be careful here not to re-invent Zope in Mailman. ;) > * The "Urgent" message feature in M2 is nice -- but can use of it be > limited to just list owners/moderators? Urgent requires a list admin password. -Barry From barry at python.org Mon Mar 15 18:16:58 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 18:17:07 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: References: Message-ID: <1079392617.8401.9.camel@anthem.wooz.org> On Mon, 2004-03-15 at 09:59, Mark A. Mandel wrote: > Ability to modify the HTML template for more than the couple of pages > that I can change now. It is currently difficult approaching > impracticable to go from reading, say, the Jan. 31 archive mail to the > Feb. 1 mail (assuming monthly archiving). Let me say right now that while I deeply sympathize with people who want a better archiver, it's not on my plate for Mailman 3.0 I think the best we can hope for is adapting the current Pipermail software to fit into the MM3 architecture, unless someone steps forward to champion the archiver effort. I continue to encourage volunteers to do so! -Barry From barry at python.org Mon Mar 15 18:30:34 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 18:30:43 2004 Subject: [Mailman3-dev] Suggested feature: direct & enhanced "umbrella list" support In-Reply-To: References: Message-ID: <1079393434.8401.21.camel@anthem.wooz.org> On Mon, 2004-03-15 at 11:28, Mitchell Marks wrote: > The MM2 handling of sublists/superlists is largely by subscribing a > sublist address as a member of the superlist, or by periodically running a > script to reconstitute the superlist by merging the addresses from the > sublists. The specific support built into MM2 for these situations does > not seem to go much beyond the "umbrella list" attribute which affects how > reminders are handled. I've had a rough idea for a feature I'm calling "rosters". Think of them as a level of indirection between members and lists. For example, a list could be composed of several rosters, the list owners could be a roster, etc. It's only a vague notion at the moment, but here's how some of your suggestions would pan out: > I'd very much welcome some way of having that type of relationship more > inherently recognized. Suppose I could designate that "Seniors", > "Juniors", and "Sophs" constituted "Students". Then: > > -- someone getting subscribed to Seniors will start receiving mail sent > to Students immediately (or as soon as they start receiving Seniors > mail) > > -- When a message goes through Students, recipients via the sublist will > get a Subject line tag like [Students] but not the whole stack > "[Seniors][Students]". > OR make that configurable. I think, not configurable. The idea behind rosters is that it's mostly just a mechanism for discovering the list of recipients for a particular mailing. Thus it's possible the Students list had no roster of its own, but was composed from the Fresh, Soph, Jr, and Sr rosters. A message to Students then would get decorated with all the Students list chrome, and the de-duped union of all four rosters would get the message. A message then to the Seniors list would be chromed for Seniors and only that roster would get th emessage. > -- When a recipient of a Students message through the Seniors sublist > goes to reply (assuming list-reply rather than individual-poster-reply is > on), should that mean Seniors or Students? Students, because the /message/ went to the Students list even though the recipients were calculated from the Seniors list. > -- Suppose for some reason a student is on both Juniors and Seniors > lists. A message that comes through Students should probably result in > only one copy going to that dual-subscribed person. Yes. > -- If an individual is subscribed directly to the Students superlist, > the system should treat them as an individual and not as a sublist,l for > such matters as reminders and bounce handling. (That's roughly like > saying the MM2 "umbrella list" attribute should be applied not to the > superlist but per-subscriber, marking whether the subscriber is a list or > an individual.) Yes, if the Students list has a separate roster. -Barry From barry at python.org Mon Mar 15 18:41:48 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 18:41:56 2004 Subject: [Mailman3-dev] Suggestions for MMV3 In-Reply-To: <1079327565.4317.29.camel@localhost.localdomain> References: <1079327565.4317.29.camel@localhost.localdomain> Message-ID: <1079394108.8401.33.camel@anthem.wooz.org> On Mon, 2004-03-15 at 00:12, Jon Carnes wrote: > we should consider contacting folks like CPanel who already incorporate > Mailman in their products and see what we can do to make it easier for > them, and what features they would like to see most in the next version. I've sent messages to the CPanel folks, inviting them to join this list. If there are any other big 3rd party folks you know of, feel free to let them know about this list. It's all in the open and everyone can voice their opinions. > I've also had some comments from folks who really don't like the use of > -bounces as the sender of email lists in version 2.1. If we > could rename this to something like -distribute it would help > folks who are using broken MTU's that display the envelope sender. I get that complaint sometimes too. It irks me to have to worm around broken MUAs, but I also don't like to get crushed by the 800lb gorillas. > Also, we need to more fully automate the aliases creations for various > MTA's. I would be happy to work on this for MMv3. It should be easy > enough for folks to input their MTA into a variable in mm_cfg.py and > then to code the aliases creation based on that information. For some > MTA's this might mean modifying the exiting rights of aliases files... What part of MM2 doesn't work here? I think the current basic architecture is sound, but maybe we could just use more input from other MTA authors. AFAIK, at least Postfix, Qmail, and Exim are fairly well supported, and I think Sendmail works too. > The big feature that all folks will be looking for is the ability to > create same name lists on different virtual domains. Yes, absolutely. This is a requirement. > A web-based Stat's page per list (and one for whole domains) would also > be nice to see added as a built-in feature. The key for MM3 right now is to make sure we gather and log relevant stats. Once we do that, we (or 3rd parties) can build the pretty gui's to display this information. > Built-in integration with HTDig would enable a lot of folks to stop > rolling their own RPM's or installing from source (just to get the HTDig > patches). We're going to have to discuss uber-distros. OT1H I'm not psyched about including 3rd party applications that have a lifecycle of their own, but OTOH, we'll probably end up doing some of that anyway. I'm not sure what the right thing is here. > A link to the web-based FAQ, included with error dumps might also > alleviate some users pain for common Mailman problems Interesting idea. > A web-based tool for editing/removing older archives for a list (a > pipermail request). A lot of folks would like the ability to remove > single messages from the arhives, as well as archived messages older > than a specified date. I can help with this, as I've already written > some stuff that does something similar (though I would have to re-do it > in Python :-) :) Yep, this is another reason why I think we want some kind of message store. And possibly a dynamic archive interface (i.e. a process, not from the file system directly). > Better message threading within the archives (Another Pipermail > request). > > Logging that displays the amount of system resources used by Mailman as > it is running. Heh. > I'm slammed with starting up a VoIP phone company in RTP, but I would > still like to help out with the MMv3 effort, so let me know what I can > do to bring value to this project. Be involved in the early phases and when we get to coding, bite off a big chunk that I don't want to do. :) -Barry From barry at python.org Mon Mar 15 18:43:01 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 18:43:07 2004 Subject: [Mailman3-dev] Close coupling of RSS generation? In-Reply-To: <1079390511.21734.4.camel@localhost> References: <1079390511.21734.4.camel@localhost> Message-ID: <1079394181.8401.35.camel@anthem.wooz.org> On Mon, 2004-03-15 at 17:41, Roy M. Silvernail wrote: > I've worked a bit with the unofficial RSS patch to HyperArchive. It > would be great to see better RSS generation (support for content:encoded > and access to message content pre-HTMLized) integrated into MM3. I keep hearing how RSS and similar syndication stuff is the future of the web. I'm sympathetic, and would like to understand better how we can build a framework to make this possible (either out of the box or as a more cleanly installed 3rd party package). -Barry From mamandel at ldc.upenn.edu Mon Mar 15 18:52:20 2004 From: mamandel at ldc.upenn.edu (Mark A. Mandel) Date: Mon Mar 15 18:52:23 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: <1079392617.8401.9.camel@anthem.wooz.org> References: <1079392617.8401.9.camel@anthem.wooz.org> Message-ID: On Mon, 15 Mar 2004, Barry Warsaw wrote: #On Mon, 2004-03-15 at 09:59, Mark A. Mandel wrote: #> Ability to modify the HTML template for more than the couple of pages #> that I can change now. It is currently difficult approaching #> impracticable to go from reading, say, the Jan. 31 archive mail to the #> Feb. 1 mail (assuming monthly archiving). # #Let me say right now that while I deeply sympathize with people who want #a better archiver, it's not on my plate for Mailman 3.0 I think the #best we can hope for is adapting the current Pipermail software to fit #into the MM3 architecture, unless someone steps forward to champion the #archiver effort. Maybe I don't belong on THIS list, because I'm not a developer. Pipermail is not part of Mailman? Ah. I'm not asking for a better archiver, as I understand it; just a change in the HTML template in which the archive levels are presented. Even if the monthly archive pages and the individual posts (such as .../pipermail/LISTNAME/2004-March/date.html and ...//pipermail/cyp-list/2004-March/000123.html) had links BACK TO THE MAIN ARCHIVE PAGE (.../pipermail/LISTNAME/) -- a single static link in the HTML templates -- it would be a real improvement. The posts and the monthly archive pages now have links saying "More information about the LISTNAME mailing list" "More info on this list... " which both point to ...mailman/listinfo.cgi/cyp-list If that can be generated, so can a link to .../pipermail/LISTNAME/ . So... where do I ask, if not here? -- Mark A. Mandel Linguistic Data Consortium, University of Pennsylvania From roy at rant-central.com Mon Mar 15 19:03:21 2004 From: roy at rant-central.com (Roy M. Silvernail) Date: Mon Mar 15 19:03:19 2004 Subject: [Mailman3-dev] Close coupling of RSS generation? In-Reply-To: <1079394181.8401.35.camel@anthem.wooz.org> References: <1079390511.21734.4.camel@localhost> <1079394181.8401.35.camel@anthem.wooz.org> Message-ID: <1079395401.24566.4.camel@localhost> On Mon, 2004-03-15 at 18:43, Barry Warsaw wrote: > On Mon, 2004-03-15 at 17:41, Roy M. Silvernail wrote: > > I've worked a bit with the unofficial RSS patch to HyperArchive. It > > would be great to see better RSS generation (support for content:encoded > > and access to message content pre-HTMLized) integrated into MM3. > > I keep hearing how RSS and similar syndication stuff is the future of > the web. I'm sympathetic, and would like to understand better how we > can build a framework to make this possible (either out of the box or as > a more cleanly installed 3rd party package). It may be easier than you think if MM3 is going to use an active mail store db. I'd imagine that HyperArchive would morph into report styles on top of the db, and RSS (and/or its bretheren) would then be just another report style. I'll hang back a bit and get a better picture of how MM and HyperArchive interrelate before I go shooting my mouth off too much. -- Roy M. Silvernail is roy@rant-central.com, and you're not Never Forget: It's Only 1's and 0's! SpamAssassin->procmail->/dev/null->bliss http://www.rant-central.com From tkikuchi at is.kochi-u.ac.jp Mon Mar 15 18:51:46 2004 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon Mar 15 19:13:35 2004 Subject: [Mailman3-dev] anti-spam related features In-Reply-To: <1079389698.5149.319.camel@anthem.wooz.org> References: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> <1079389698.5149.319.camel@anthem.wooz.org> Message-ID: <40564192.7090506@is.kochi-u.ac.jp> FYI, some of the requests are already implemented in patches. Barry Warsaw wrote: > On Mon, 2004-03-15 at 14:05, Erez Zadok wrote: > > >>- a one button to accept/reject/discard ALL pending messages. > > > +1 http://sourceforge.net/tracker/index.php?func=detail&aid=810675&group_id=103&atid=300103 > > >>- a way to automatically purge pending messages that haven't been accepted, >> rejected, or discarded after N days of waiting. That way I don't have >> bother logging in and cleaning them up every day. > > > +1 http://sourceforge.net/tracker/?func=detail&aid=790494&group_id=103&atid=300103 >>- integration with Spamassassin and friends, so I can set a rule that says >> "discard every message with a score > 5.0". http://sourceforge.net/tracker/index.php?func=detail&aid=640518&group_id=103&atid=300103 -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From kmccann at bellanet.org Mon Mar 15 20:38:26 2004 From: kmccann at bellanet.org (Kevin McCann) Date: Mon Mar 15 20:13:56 2004 Subject: [Mailman3-dev] Close coupling of RSS generation? In-Reply-To: <1079395401.24566.4.camel@localhost> References: <1079390511.21734.4.camel@localhost> <1079394181.8401.35.camel@anthem.wooz.org> <1079395401.24566.4.camel@localhost> Message-ID: <40565A92.2080509@bellanet.org> Roy M. Silvernail wrote: >>I keep hearing how RSS and similar syndication stuff is the future of >>the web. I'm sympathetic, and would like to understand better how we >>can build a framework to make this possible (either out of the box or as >>a more cleanly installed 3rd party package). >> >> > >It may be easier than you think if MM3 is going to use an active mail >store db. I'd imagine that HyperArchive would morph into report styles >on top of the db, and RSS (and/or its bretheren) would then be just >another report style. I'll hang back a bit and get a better picture of >how MM and HyperArchive interrelate before I go shooting my mouth off >too much. > > Yes. I provide RSS feeds from my Lyris-based yahoo-groups-like tool (Dgroups). Very easy, especially when you have quick and simple access to all of the main data. With simple SQL queries, I can provide RSS feeds such as - latest public lists created (URLs point to intro page for list) - most popular lists (URLS point to intro page) - latest message subjects for a particular list (URLs point to archive of list) - newest members of a particular list (URLS point to profile info) - you imagination is your limit RSS is yet another example of how easy access to all of the main data, including message data, is a Good Thing. - Kevin From barry at python.org Mon Mar 15 21:57:07 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 15 21:57:15 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: References: <1079392617.8401.9.camel@anthem.wooz.org> Message-ID: <1079405826.8401.56.camel@anthem.wooz.org> On Mon, 2004-03-15 at 18:52, Mark A. Mandel wrote: > Maybe I don't belong on THIS list, because I'm not a developer. > Pipermail is not part of Mailman? Ah. Yes and no. Pipermail was a separate project for its early life, then it was fused into Mailman and now I think that's its only incarnation. On the whole, Pipermail was an excellent addition, providing very important functionality. But everyone agrees it needs work. Designing and implementing an archiver is A Project Unto Itself and I don't want to hold up Mailman 3 waiting for an archiver rewrite. > I'm not asking for a better archiver, as I understand it; just a change > in the HTML template in which the archive levels are presented. Even if > the monthly archive pages and the individual posts (such as > .../pipermail/LISTNAME/2004-March/date.html and > ...//pipermail/cyp-list/2004-March/000123.html) had links BACK TO THE > MAIN ARCHIVE PAGE (.../pipermail/LISTNAME/) -- a single static link in > the HTML templates -- it would be a real improvement. That's a possibility. > The posts and the monthly archive pages now have links saying > "More information about the LISTNAME mailing list" > "More info on this list... " > which both point to > ...mailman/listinfo.cgi/cyp-list > > > If that can be generated, so can a link to .../pipermail/LISTNAME/ . > So... where do I ask, if not here? I'd ask around on mailman-developers, since this could be a Mailman 2.1 feature. -Barry From mlm at kaibren.com Mon Mar 15 22:52:00 2004 From: mlm at kaibren.com (MLM Subscriber) Date: Tue Mar 16 00:59:14 2004 Subject: [Mailman3-dev] Monthly reminders Message-ID: <6.0.0.22.2.20040315224651.02e36858@localhost> I run several community lists where many months go by without posts. While the password reminders are somewhat annoying, they do help keep the lists current. I agree it would be nice to have them go out on days other than the first of the month. -mb Mike Brenner From mlm at kaibren.com Mon Mar 15 23:08:29 2004 From: mlm at kaibren.com (MLM Subscriber) Date: Tue Mar 16 00:59:16 2004 Subject: [Mailman3-dev] More on reminders and bounces In-Reply-To: <1079388210.5149.308.camel@anthem.wooz.org> References: <200403152156.i2FLuKri028130@agora.fsl.cs.sunysb.edu> <1079388210.5149.308.camel@anthem.wooz.org> Message-ID: <6.0.0.22.2.20040315230054.02deb498@pop.sprynet.com> At 05:03 PM 3/15/2004, Barry Warsaw wrote: >Do you think a password reminder that comes from >noreply@lists.example.com, throws away bounces, and doesn't include >plain text passwords would still be useful? Sort of... I guess I want the monthly automatic "probe" function where bounces are the primary value of the messages. Even better if I get to modify the default text and leave out the passwords. "This is your monthly reminder that you are a valued member of mylist." Now, if the bounce handling for a given email is done across all lists on the same server.... -mb Mike Brenner From Dale at Newfield.org Tue Mar 16 08:16:23 2004 From: Dale at Newfield.org (Dale Newfield) Date: Tue Mar 16 08:16:29 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: <1079392375.8401.4.camel@anthem.wooz.org> References: <1079392375.8401.4.camel@anthem.wooz.org> Message-ID: On Mon, 15 Mar 2004, Barry Warsaw wrote: > > * "Spot" moderation (i.e., the ability to [re-]moderate an individual > > for "N" posts, or to permanently moderate him, at the moderator's > > discretion). It is VERY IMPORTANT that moderation be persistent -- > > i.e., if someone figures out he's been permanently moderated, he > > can't unsubscribe and resubscribe and thus go back to being moderated > > for only "N" posts. (Upon unsub/resub, the implementation should set > > his moderation for the higher of the default list moderation count > > and his previous moderation setting.) > This is an important point. I'm wondering if Mailman 3 should ever > totally "forget" about a user? One distinction we don't have in MM2 but that I think we need in MM3 is that between a subscriber and a subscription. The point made here about more than "not forgetting about a subscriber" (that involves preserving user-level info, like password or the set of addresses they may send from) but is about "not forgetting about a subscription" (that involves preserving subscription-level info, like moderation count or delivery type or delivery address (so people can say "for this list, send to name+list@foo.bar)). In a DB world this really just means that subscriptions contain "start" and "stop" dates, but not a uniqueness constraint on user. This allows subscriptions to be ended but not removed from the DB. It also allows for more after-the-fact auditing. --- Dale Newfield "They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety." - Benjamin Franklin, on the Statue of Liberty From iane at sussex.ac.uk Tue Mar 16 08:22:47 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Tue Mar 16 08:22:51 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: <1079392617.8401.9.camel@anthem.wooz.org> References: <1079392617.8401.9.camel@anthem.wooz.org> Message-ID: <2147483647.1079443367@beeding.central.susx.ac.uk> --On lunes, 15 marzo 2004 18:16 -0500 Barry Warsaw wrote: > On Mon, 2004-03-15 at 09:59, Mark A. Mandel wrote: >> Ability to modify the HTML template for more than the couple of pages >> that I can change now. It is currently difficult approaching >> impracticable to go from reading, say, the Jan. 31 archive mail to the >> Feb. 1 mail (assuming monthly archiving). > > Let me say right now that while I deeply sympathize with people who want > a better archiver, it's not on my plate for Mailman 3.0 I think the > best we can hope for is adapting the current Pipermail software to fit > into the MM3 architecture, unless someone steps forward to champion the > archiver effort. > > I continue to encourage volunteers to do so! > Hmm, I think I'd like to have mailman able to deliver the message to an LMTP server, and have the LMTP server drop the message into a shared mailbox, so that I can use my regular mail client to read mail from the archive. If I switch of mail delivery, I don't even need to duplicate the contents of the message this way. The tricky bit would be synchronising the permissions on the mailbox with the membership of the list. Oh, and keeping the LMTP server up to date with the list of lists. If I can do that, why do I need a list archive? Why do I need a list manager at all? Well, because some of our list members don't belong to the university, so they won't have access to the IMAP server. -- Ian Eiloart Servers Team Sussex University ITS From barry at python.org Tue Mar 16 09:29:14 2004 From: barry at python.org (Barry Warsaw) Date: Tue Mar 16 09:29:23 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: References: <1079392375.8401.4.camel@anthem.wooz.org> Message-ID: <1079447354.10434.29.camel@anthem.wooz.org> On Tue, 2004-03-16 at 08:16, Dale Newfield wrote: > One distinction we don't have in MM2 but that I think we need in MM3 is > that between a subscriber and a subscription. The point made here about > more than "not forgetting about a subscriber" (that involves preserving > user-level info, like password or the set of addresses they may send from) > but is about "not forgetting about a subscription" (that involves > preserving subscription-level info, like moderation count or delivery type > or delivery address (so people can say "for this list, send to > name+list@foo.bar)). In a DB world this really just means that > subscriptions contain "start" and "stop" dates, but not a uniqueness > constraint on user. This allows subscriptions to be ended but not removed > from the DB. It also allows for more after-the-fact auditing. This is a good point, thanks for bringing it up. Especially since we're now going to have a single sign-on per domain, I think once a person has registered with the site, we never forget about them. (Well, there may be an admin or cli way to totally zap an account, backend db willing). I'm looking forward to fleshing out the data model next week! -Barry From barry at python.org Tue Mar 16 09:31:41 2004 From: barry at python.org (Barry Warsaw) Date: Tue Mar 16 09:31:52 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: <2147483647.1079443367@beeding.central.susx.ac.uk> References: <1079392617.8401.9.camel@anthem.wooz.org> <2147483647.1079443367@beeding.central.susx.ac.uk> Message-ID: <1079447501.10434.32.camel@anthem.wooz.org> On Tue, 2004-03-16 at 08:22, Ian A B Eiloart wrote: > Hmm, I think I'd like to have mailman able to deliver the message to an > LMTP server, Not for final delivery of the message, though. > and have the LMTP server drop the message into a shared > mailbox, so that I can use my regular mail client to read mail from the > archive. If I switch of mail delivery, I don't even need to duplicate the > contents of the message this way. > > The tricky bit would be synchronising the permissions on the mailbox with > the membership of the list. Oh, and keeping the LMTP server up to date with > the list of lists. > > If I can do that, why do I need a list archive? Why do I need a list > manager at all? Well, because some of our list members don't belong to the > university, so they won't have access to the IMAP server. Another way to look at it is that messages go into a message store, and that message store would have the ability to export messages through imap, nntp, rss, and html/http. -Barry From iane at sussex.ac.uk Tue Mar 16 09:37:29 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Tue Mar 16 09:37:35 2004 Subject: [Mailman3-dev] list manager control In-Reply-To: <1079387385.5149.292.camel@anthem.wooz.org> References: <200403151900.i2FJ036X025572@agora.fsl.cs.sunysb.edu> <1079387385.5149.292.camel@anthem.wooz.org> Message-ID: <2147483647.1079447849@beeding.central.susx.ac.uk> > > +1. List styles. Yes, yes, yes. I'm not sure whether styles will be > hierarchical or flat though. Hmm, I need to define some list styles for in house use, and put together some documentation on how to configure a list to a style. I may even make some scripts to convert a list to a particular style. Is there a list of styles out there that I could get started with? Is there any documentation on how best to configure mailman certain types of list? Actually, I'm not so sure a *list* style is what I need. Here are some dimensions that I need to apply styles in: 1. membership policy: un/subscribe options, and bounce processing forced: members are synced with some other list, and people can't subscribe or unsubscribe through mailman. Bounce processing should be off. Admins should be notified of changes made through mailman. controlled: list admin must approve requests to join/leave local-open: only people with sussex.ac.uk addresses can join. wide-open: anyone can join 2. posting policy: sender filters local-open: any sussex.ac.uk address can post to the list closed: only list members (and other authorised posters) can post announce: only authorised posters can post to the list. 3. urgency policy: controls digestability high: not digestable (for health and safety alerts, etc) normal: digestable 4. privacy policy: visibility of archives, membership lists, news gateways public: public anyone open normal: private list members private: no archive admin-only Anyway, I'm thinking that list styles aren't naturally heirarchical, but rather that certain policies of each list (like its membership, its visibility, its openness) could usefully have styles applied. While some of these policy styles may imply others, I don't think that's normally the case. For example, an announce only list could have public archives but private membership list. -- Ian Eiloart Servers Team Sussex University ITS From barry at python.org Tue Mar 16 09:40:51 2004 From: barry at python.org (Barry Warsaw) Date: Tue Mar 16 09:41:00 2004 Subject: [Mailman3-dev] Re: Flexible data storage Message-ID: <1079448050.10434.52.camel@anthem.wooz.org> In private email, it was suggested that Mailman should treat internal users different than external users. I wanted to get my response into the list archives and make it part of the discussion because I think it's an important design point. --- That's an interesting use case, although I think Mailman itself should largely be ignorant of whether they are internal or external users. The way I've been thinking about it ties back to the roster notion. Rosters may be tied via conduits to a back-end storage, and each storage would have its own policies for reading and writing. Take our Students list example. You might have some grad students who were also employees of the university, so they'd be in the employee database. Perhaps you couldn't write password updates to that database through the Mailman conduit. But the GradStudent list would be composed of a non-employee roster (which Mailman managed completely) and an employee roster (which Mailman imported through a conduit). -Barry From iane at sussex.ac.uk Tue Mar 16 10:02:06 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Tue Mar 16 10:02:13 2004 Subject: [Mailman3-dev] anti-spam related features In-Reply-To: <1079389698.5149.319.camel@anthem.wooz.org> References: <200403151905.i2FJ5O7H025634@agora.fsl.cs.sunysb.edu> <1079389698.5149.319.camel@anthem.wooz.org> Message-ID: <2147483647.1079449326@beeding.central.susx.ac.uk> --On lunes, 15 marzo 2004 17:28 -0500 Barry Warsaw wrote: > > I'd also like to see some integration efforts with Spambayes. Getting a > generic interface and U/I for this stuff is going to be tricky. I don't know if this is generally the case, but our spam filter (bogofilter) adds a header, which can be easily parsed. A generic interface would just match a specified header with a regular expression to extract some number - that's a site configuration, so U/I isn't that important. You'd then want to convert those numbers to, say, a spamicity percentage. Finally, you'd have three thresholds defined: 1. A site threshold (Ts) - probably 100% or 101% to be conservative. A minimum list threshold (Tlm), perhaps 80% which would allow: 2. List thresholds (Tl). You might let list admins specify a number above 80. List admins could specify a minimum personal threshold (Tpm) 3. Personal thresholds (Tp) for subscribers. List admins would be able to set a minimum - or disable personal thresholds by setting the lowest possible personal threshold equal to the list threshold. messages would pass if their: spamicity < Ts and (spamicity < max( Tl, Tlm) or spamicity < max( Tp, Tpm, Tlm)) Thus, lists can set low thresholds, but individuals can increase those thresholds for themselves if they wish. Oh, I've lost myself now. I think, though, that the general principle is that people should be allowed to choose what they get, but within limits. We should allow people to get as much spam as they want. We should let them choose low thresholds, but not so low that they miss a lot of genuine posts, and maybe there should be no spam filtering on closed lists at all. -- Ian Eiloart Servers Team Sussex University ITS From iane at sussex.ac.uk Tue Mar 16 11:12:08 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Tue Mar 16 11:12:13 2004 Subject: [Mailman3-dev] Flexible data storage In-Reply-To: <1079447811.10434.38.camel@anthem.wooz.org> References: <200403152131.i2FLVhru027496@agora.fsl.cs.sunysb.edu> <1079386937.5149.283.camel@anthem.wooz.org> <2147483647.1079444330@beeding.central.susx.ac.uk> <1079447811.10434.38.camel@anthem.wooz.org> Message-ID: <2147483647.1079453528@beeding.central.susx.ac.uk> --On martes, 16 marzo 2004 09:36 -0500 Barry Warsaw wrote: > On Tue, 2004-03-16 at 08:38, Ian A B Eiloart wrote: > >> I've said before that I'd like to manage internal users (members of the >> University) differently than external users. If we could eliminate the >> sending of passwords to internal users (we manager their passwords in >> LDAP), and also guarantee that external users only had one password in >> the database, that would cut the number of reminders drastically. > > That's an interesting use case, although I think Mailman itself should > largely be ignorant of whether they are internal or external users. > > The way I've been thinking about it ties back to the roster notion. > Rosters may be tied via conduits to a back-end storage, and each storage > would have its own policies for reading and writing. Well, if a roster is a membership list which can be included in another membership list, then that's OK. I need to have rosters with heterogeneous membership though. Some members from one conduit, and others from another. And, I want mailman to be able to tie "sussex.ac.uk" email addresses to a particular conduit. My read only LDAP conduit as it happens. I don't want people in that domain (or susx.ac.uk) to be able to register through another conduit. Further, I want some lists to be tied to a specific conduit. I don't want people subcribing to "staff@sussex.ac.uk" unless they have a sussex email address. > Take our Students list example. You might have some grad students who > were also employees of the university, so they'd be in the employee > database. Perhaps you couldn't write password updates to that database > through the Mailman conduit. But the GradStudent list would be composed > of a non-employee roster (which Mailman managed completely) and an > employee roster (which Mailman imported through a conduit). > > -Barry Er, what's a GradStudent? Is that a current student who already has a degree (a post-graduate), or someone who graduated here but isn't a student (an alumnus). We don't use the term "grad student" in the UK. Anyway, all current students are on our LDAP database, along with the staff. Alumni aren't - they'd be an example of an external user. Regarding rosters: I'd like to be able to fetch rosters with SQL queries from a separate database. So, I want to populate lists from ORACLE, but then get email addresses for each list member from LDAP, and when users log in, I want to authenticate against the LDAP database. Then, I'd like to be able to create a list membership with full boolean rules. For example, I'd like to have a list lifesci-ug-1 whose membership was lifesci-ug AND ug-1 (composed of first year undergraduates in life sciences). Or science-ug-1 defined as "(lifesci-ug OR scitech-ug) AND ug-1". Or local-ug defined as "ug AND NOT overseas-ug" Caching these memberships would be useful for performance. A 24 hour cache would be acceptable. Finally, for each list, I'd like the list admin to be able to configure the role-based membership, and then maintain a list of additional members (perhaps a tutor, technician or an *external* examiner) and a list of exceptions (no, I don't know why). I guess the additions and exceptions would just be two more rosters, perhaps. So the real rule for, say science-ug-1 would be "((lifesci-ug OR scitech-ug) AND ug-1 OR my-additions) AND NOT my-exceptions" where my-additions and my-exceptions were special rosters for each list. I guess the default membership rule for a list would be "my-members", a synonym for "my-additions". So, a roster might be the result of an SQL query, or an LDAP query, or a list from a flat file or python database. But, it might also be any boolean combination of other rosters. -- Ian Eiloart Servers Team Sussex University ITS From roy at rant-central.com Tue Mar 16 11:42:27 2004 From: roy at rant-central.com (Roy M. Silvernail) Date: Tue Mar 16 11:42:28 2004 Subject: [Mailman3-dev] Suggested Features In-Reply-To: <1079447501.10434.32.camel@anthem.wooz.org> References: <1079392617.8401.9.camel@anthem.wooz.org><2147483647.1079443367@beeding.central.susx.ac.uk> <1079447501.10434.32.camel@anthem.wooz.org> Message-ID: <39334.127.0.0.1.1079455347.squirrel@mesmer.rant-central.com> Barry Warsaw said: > Another way to look at it is that messages go into a message store, and > that message store would have the ability to export messages through > imap, nntp, rss, and html/http. +1 Perfect view. The only difference between imap, nntp and rss is the report style. That naturally lends itself to developing more and different report styles. Clean, elegant and extensible. -- Roy M. Silvernail is roy@rant-central.com, and you're not Never Forget: It's Only 1's and 0's! SpamAssassin->procmail->/dev/null->bliss http://www.rant-central.com From jmhayes at speakeasy.net Tue Mar 16 16:27:20 2004 From: jmhayes at speakeasy.net (Jordan Hayes) Date: Tue Mar 16 16:33:50 2004 Subject: [Mailman3-dev] Feature request Message-ID: <01c401c40b9d$775bea60$1048a8c0@rupt> I'd like a more flexible way to deal with the mbox file; I run a list that has several years of archives, and if I left all the postings in a single mbox file, it would be over 1GB ... which means it would get backed up nightly :-) What I do now is once per year trim it down, move the generated archives somewhere safe, and start over. I'd like a way to rotate the mbox file like I do the archives. /jordan From barry at python.org Wed Mar 17 17:01:50 2004 From: barry at python.org (Barry Warsaw) Date: Wed Mar 17 17:01:54 2004 Subject: [Mailman3-dev] Re: Umbrella Lists --> CMS In-Reply-To: <20040317192838.029F9E242E8@ns1.duane.com> References: <20040317192838.029F9E242E8@ns1.duane.com> Message-ID: <1079560909.7963.65.camel@geddy.wooz.org> On Wed, 2004-03-17 at 14:28, mtech@duane.com wrote: > I agree that we need to come up with a new way of handling superlists > and sublists and membership within them so that people only get > one e-mail even if they're on multiple lists on the same server. > I'd like to see a list of all lists a given message was delivered to > at the top of the message when a message is delivered to more than one list. I was with you until the last sentence. I'm not sure how you'd convey that information, or whether you'd actually want people to know all the other lists this message was delivered to. > I'd like to see mailing lists run in a database such as MySQL or PostGres, > and allow for additional fields for each user to be configured as needed. > This would be useful so that profiles of users could be offered and > additional contact information could be provided. The way I'm thinking about is that there would be an interface for asking about additional profile information about a recipient (probably using the email address as a key). That way, information about addresses kept outside Mailman's databases could still be supplied to, say the mail-merge facility. > I see Mailman as growing towards being an extensible > Content Management System, such that options like a photo gallery, > web based polls, registration forms, file repository, etc. could > be added--such that it offers more of the features that YahooGroups offers. I'm very intrigued with developing something like a YahooGroups lookalike. OTOH, what I think we're working toward here is a flexible library that could be used as part of a YG knockoff. IOW, Mailman wouldn't become a CMS, but it could be used with a CMS to provide all those extra features. > I don't know how much of this we want to work on for MM3, and how we'll > go about handling authentication among the various components. That's going to be the really tough part. -Barry From iane at sussex.ac.uk Thu Mar 18 08:37:10 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Thu Mar 18 08:37:16 2004 Subject: [Mailman3-dev] Re: Umbrella Lists --> CMS In-Reply-To: <1079560909.7963.65.camel@geddy.wooz.org> References: <20040317192838.029F9E242E8@ns1.duane.com> <1079560909.7963.65.camel@geddy.wooz.org> Message-ID: <2147483647.1079617030@beeding.central.susx.ac.uk> --On Wednesday, March 17, 2004 5:01 pm -0500 Barry Warsaw wrote: > > The way I'm thinking about is that there would be an interface for > asking about additional profile information about a recipient (probably > using the email address as a key). That way, information about > addresses kept outside Mailman's databases could still be supplied to, > say the mail-merge facility. Oh, no. Please don't use the email address as the key. I have many email addresses. Three supplied by my employer, PLUS all the email addresses in my personal domain. -- Ian Eiloart Servers Team Sussex University ITS From barry at python.org Thu Mar 18 09:30:03 2004 From: barry at python.org (Barry Warsaw) Date: Thu Mar 18 09:30:50 2004 Subject: [Mailman3-dev] Re: Umbrella Lists --> CMS In-Reply-To: <2147483647.1079617030@beeding.central.susx.ac.uk> References: <20040317192838.029F9E242E8@ns1.duane.com> <1079560909.7963.65.camel@geddy.wooz.org> <2147483647.1079617030@beeding.central.susx.ac.uk> Message-ID: <1079620203.26767.30.camel@anthem.wooz.org> On Thu, 2004-03-18 at 08:37, Ian A B Eiloart wrote: > --On Wednesday, March 17, 2004 5:01 pm -0500 Barry Warsaw > wrote: > > > > > The way I'm thinking about is that there would be an interface for > > asking about additional profile information about a recipient (probably > > using the email address as a key). That way, information about > > addresses kept outside Mailman's databases could still be supplied to, > > say the mail-merge facility. > > Oh, no. Please don't use the email address as the key. I have many email > addresses. Three supplied by my employer, PLUS all the email addresses in > my personal domain. I should have been more precise. I'm thinking that the email address will probably the login, but that internally, there will be a member id that's the key. The member id may be an integer or it may be a hash generated at the time the member registered. There will probably also be a mapping from member id to email addresses and vice versa to facilitate logins, etc. The tricky part will be trying to manage a confederation of membership management with multiple external storages, each of which has their own notion of "a member id". Right now, I'm not sure how to do that. -Barry From iane at sussex.ac.uk Thu Mar 18 11:13:21 2004 From: iane at sussex.ac.uk (Ian A B Eiloart) Date: Thu Mar 18 11:13:24 2004 Subject: [Mailman3-dev] Re: Umbrella Lists --> CMS In-Reply-To: <1079620203.26767.30.camel@anthem.wooz.org> References: <20040317192838.029F9E242E8@ns1.duane.com> <1079560909.7963.65.camel@geddy.wooz.org> <2147483647.1079617030@beeding.central.susx.ac.uk> <1079620203.26767.30.camel@anthem.wooz.org> Message-ID: <2147483647.1079626401@beeding.central.susx.ac.uk> --On Thursday, March 18, 2004 9:30 am -0500 Barry Warsaw wrote: > On Thu, 2004-03-18 at 08:37, Ian A B Eiloart wrote: >> --On Wednesday, March 17, 2004 5:01 pm -0500 Barry Warsaw >> wrote: >> >> > >> > The way I'm thinking about is that there would be an interface for >> > asking about additional profile information about a recipient (probably >> > using the email address as a key). That way, information about >> > addresses kept outside Mailman's databases could still be supplied to, >> > say the mail-merge facility. >> >> Oh, no. Please don't use the email address as the key. I have many email >> addresses. Three supplied by my employer, PLUS all the email addresses >> in my personal domain. > > I should have been more precise. I'm thinking that the email address > will probably the login, but that internally, there will be a member id > that's the key. The member id may be an integer or it may be a hash > generated at the time the member registered. There will probably also > be a mapping from member id to email addresses and vice versa to > facilitate logins, etc. > > The tricky part will be trying to manage a confederation of membership > management with multiple external storages, each of which has their own > notion of "a member id". Right now, I'm not sure how to do that. > > -Barry OK, that's good. Let me give you a scenario that might help if you can generalise from it. I guess you're familiar with a lot of what we want to do, by now... A user logs in to our mailing list web site. What they present may be a username, or an email address. Let's assume that "@" is not a valid character in a username. USERNAME: mailman searches our LDAP server for a user with that username. If found, it attempts to authenticate against the server. If not found, mailman moves on to the next highest priority external storage - probably an sql database. If found, and authenticated, mailman logs me in, and fetches my email aliases from the ldap server. If found and authentication fails, then mailman represents the login. EMAIL ADDRESS: mailman searches our LDAP server for a mail alias, if found, it substitutes the associated username and attempts to authenticate. Failures follow the pattern above. All this is simplified if we make certain assumptions: 1. usernames don't contain "@". 2. usernames are unique across all storage containers. 3. there is an ordered list of priority for storage containers. Assumption (2) might be relaxed by allowing the user to specify a container. For example, we could ask them if they are using a SUSSEX.AC.UK email address. Or we may use a cookie. This might allow us, for example, to host lists for another institution. In that case, you might want a partially ordered list of containers (think MX priorities). Imagine that we were hosting lists for the University of Brighton, for example. We can't guarantee to have distinct usernames, so we would have to check BOTH containers (say, our LDAP server, and theirs) for username. If we find the username on both, we can give the user the opportunity to pick which user s/he is *before* proceeding to authenticate - this avoids the possibility that a user stumbles across their doppleganger's password. If the username is not found on either LDAP server, we can move on to check (say) an sql database for other users. We might express this thus: container priority SUSSEX_LDAP 10 BRIGHTON_LDAP 10 MISC_SQL 20 -- Ian Eiloart Servers Team Sussex University ITS From jonc at nc.rr.com Thu Mar 18 11:23:19 2004 From: jonc at nc.rr.com (Jon Carnes) Date: Thu Mar 18 11:23:24 2004 Subject: [Mailman3-dev] Add ability for admin to change email addresses inside List database In-Reply-To: <5.1.0.14.2.20040318100914.02cd4e30@pop.mindspring.com> References: <5.1.0.14.2.20040318100914.02cd4e30@pop.mindspring.com> Message-ID: <1079626999.4514.9.camel@localhost.localdomain> On Thu, 2004-03-18 at 10:19, Nancy S wrote: > Jon wrote: > > > >I don't think anyone on Mailman-dev wants to encourage the bad practice > >of allowing folks to be subscribed without their approval (except by the > >list admin), so don't look for this feature to be changed in MMv3. > > This may be slightly off this particular topic, but I run several mailman lists with the options: > o) Administrator approval is required for all subscriptions > o) No confirmation is required for subscriptions > > These are relatively "closed" communities of nontechnical people, where the administrator has tight connections to the subscribers and there is some "offline" or "unstructured" confirmation that occurs outside of Mailman itself. > > The problem I've been having is that there doesn't seem to be a way for the LIST ADMIN to change a subscriber's e-mail address without a confirmation (unless one goes through a subscribe/unsubscribe which risks changing user options and the user password). For these particular communities we really do not want confirmation required -- and if it's not required for the initial subscription, why is it required for the address change? > That's a nice feature and a good justification for it. I'll forward that along to the MMv3 list and see if folks like it. It almost trivial to write a command line tool that would change an email address inside the list database. The harder part will be adding it to the Admin's web form. Jon Carnes From Dale at Newfield.org Thu Mar 18 11:29:05 2004 From: Dale at Newfield.org (Dale Newfield) Date: Thu Mar 18 11:29:10 2004 Subject: [Mailman3-dev] Re: Umbrella Lists --> CMS In-Reply-To: <2147483647.1079626401@beeding.central.susx.ac.uk> References: <20040317192838.029F9E242E8@ns1.duane.com> <1079560909.7963.65.camel@geddy.wooz.org> <2147483647.1079617030@beeding.central.susx.ac.uk> <1079620203.26767.30.camel@anthem.wooz.org> <2147483647.1079626401@beeding.central.susx.ac.uk> Message-ID: On Thu, 18 Mar 2004, Ian A B Eiloart wrote: > All this is simplified if we make certain assumptions: > 1. usernames don't contain "@". > 2. usernames are unique across all storage containers. > 3. there is an ordered list of priority for storage containers. We need to distinguish between authentication source and data source... ...you may want to use LDAP for authentication, but when you want to store mailman-specific information (bounce score, for example), the installation may want to store that info in SQL. Which means that usernames will likely *not* be unique across storage containers. -Dale From dallas at dreamhost.com Thu Mar 18 18:57:56 2004 From: dallas at dreamhost.com (Dallas Bethune) Date: Fri Mar 19 09:26:21 2004 Subject: [Mailman3-dev] virtual host implementation Message-ID: <13FC43F0-7938-11D8-8F32-000A95AA76E0@dreamhost.com> I was wondering how much is currently known about the virtual host implementation in Mailman 3. We use Mailman to provide discussion lists for several thousand virtually hosted domains (we're a webhost). It has already been said that lists with the same name at different domains will be supported (yay!). Are other details currently known? It would be ideal to have as much independent control over each 'domain' as possible. Each domain would have its own administrator in addition to the one main super administrator and that domain administrator would have access to set useful options that would affect all lists under the domain, etc. Is there a list somewhere of features definitely on the todo list? Dallas From dario at ita.chalmers.se Fri Mar 19 03:45:34 2004 From: dario at ita.chalmers.se (=?ISO-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Fri Mar 19 09:26:23 2004 Subject: [Mailman3-dev] Re: Umbrella Lists --> CMS In-Reply-To: References: <20040317192838.029F9E242E8@ns1.duane.com> <1079560909.7963.65.camel@geddy.wooz.org> <2147483647.1079617030@beeding.central.susx.ac.uk> <1079620203.26767.30.camel@anthem.wooz.org> <2147483647.1079626401@beeding.central.susx.ac.uk> Message-ID: <405AB32E.9040502@ita.chalmers.se> Dale Newfield wrote: > > We need to distinguish between authentication source and data source... > ...you may want to use LDAP for authentication, but when you want to store > mailman-specific information (bounce score, for example), the installation > may want to store that info in SQL. > Very simplified: I would very much like to have the following distinctions, at the very least on a *logical* level: * user-source what users do we have * authentication-source how to authenticate users * authorisation-source how to get users' permissions to access resources * property-source how to access properties (metadata) on users * group-source how to put users into groups * mapping-source how to map users from one source to another. These source can be aggregatem ie. I can have several authetication source, preferably in a cascaded sort of way, etc. AFAICT, this covers pretty much everything we need to know about users. List-membership is deduced from group membership, ie. a group can have one or more lists associated to it. umbrella-lists are implemented by groups having other groups as members. IMHO, this gives us all the expressive power we need to manage lists - specialised membership rules can be either deduced from membership in groups or from the authorisation source(s). Anything else, such as dealing with special features for special cases, complicates things too much, and does not always necessitate a technical solution - perhaps they can be solved by clever usage of existing feratures. This is the part that Mailman shpouild borrow the most from CMS systems and other multiuser systems. The publishing part is not that hard to do either, just make it easy to associate pages with groups and lists, and provide a neato-interface to edit them TTW, with a neato templating laguage... (disclaimer: I am a zope-fanatic :-). Cheers, /dario -- -- ------------------------------------------------------------------- Dario Lopez-Ka"sten, IT Systems & Services Chalmers University of Tech. From barry at python.org Sat Mar 20 08:39:28 2004 From: barry at python.org (Barry Warsaw) Date: Sat Mar 20 08:39:41 2004 Subject: [Mailman3-dev] Sprinting today Message-ID: <1079789968.13834.5.camel@anthem.wooz.org> Just a reminder that we'll be sprinting today at Pycon. Hopefully I'll see some of you down at GWU in a while. My gig ran pretty late last night, but I'm going to try to get down there by 10am. gotta-drink-a-big-pot-of-coffee-ly y'rs, -Barry From r.barrett at openinfo.co.uk Thu Mar 25 06:15:38 2004 From: r.barrett at openinfo.co.uk (Richard Barrett) Date: Thu Mar 25 10:34:12 2004 Subject: [Mailman3-dev] URLs on Mailman web GUI and archive pages Message-ID: The URLs generated on web pages, both static and dynamically generated pages, by Mailman 2.1.x code are a mixture of absolute and relative URLs. My view is that, during the the Mailman 3 development, the code generating such URLs should all be such that all URLs are generated as page relative URLs. The URL generation arrangements should also support the ability to configure the addressing scheme used for MM's web GUI in a more flexible way; for instance: a. the ability to use http for public/authenticated access but https for restricted/authenticated access. b. the ability to use http for some lists but https for other lists The page relative URL generation suggested above should also simplify achieving the addressing scheme objectives. The present URLs are a problem for a number of reasons: 1. using a mixture of addressing schemes would assist with the problem cited by one of my correspondents: > On Wed, 24 Mar 2004, Richard Barrett wrote: > : > : You pretty much have to decide to use https for the whole web > : interface, both admin and list user, but I do not see that as a > problem > : with SSL capable browsers being the norm these days. > > The problem is that on a server which hosts multiple virtual domains, > you > can either (a) buy a cert for every virtual hostname (expensive) or (2) > use a self-signed cert and let people click-thru the certificate > mismatch > warning. I find that the less technically-inclined users are thrown > into a > tizzy when they see the certificate mismatch warning - they are totally > unsure whether or not it is safe to proceed. > > These are the kinds of admin issues that programmers often don't think > about. ;) 2. allowing access to a Mailman servers through a transparent, reverse-proxying server is infeasible unless a rewriting HTML filter is applied to the pages returned to it by the Mailman server. This situation creates the requirement for MM to exclusively generate page relative URLs; server relative URLs still make a rewriting HTML filter necessary. 3. links in archived mail to attachments extracted by the present pipermail archiver are currently generated as server relative given the present state of the list privacy. This means that changing a list's archive privacy status leaves links to attachments broken unless bin/arch is used to rebuild the entire list archive. Whichever archiver is packaged with MM3 should avoid this problem. ----------------------------------------------------------------------- Richard Barrett http://www.openinfo.co.uk From barry at python.org Mon Mar 29 12:11:34 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 29 12:11:42 2004 Subject: [Mailman3-dev] URLs on Mailman web GUI and archive pages In-Reply-To: References: Message-ID: <1080580294.32170.5.camel@anthem.wooz.org> On Thu, 2004-03-25 at 06:15, Richard Barrett wrote: > The URLs generated on web pages, both static and dynamically generated > pages, by Mailman 2.1.x code are a mixture of absolute and relative > URLs. > > My view is that, during the the Mailman 3 development, the code > generating such URLs should all be such that all URLs are generated as > page relative URLs. In general, I agree. MM2's page generation system never did this consistently or correctly, so I found that switching to an absolute url scheme was the only way to get it to work most (more?) of the time. > The URL generation arrangements should also support the ability to > configure the addressing scheme used for MM's web GUI in a more > flexible way; for instance: > > a. the ability to use http for public/authenticated access but https > for restricted/authenticated access. > > b. the ability to use http for some lists but https for other lists > > The page relative URL generation suggested above should also simplify > achieving the addressing scheme objectives. > > The present URLs are a problem for a number of reasons: > > 1. using a mixture of addressing schemes would assist with the problem > cited by one of my correspondents: > 2. allowing access to a Mailman servers through a transparent, > reverse-proxying server is infeasible unless a rewriting HTML filter is > applied to the pages returned to it by the Mailman server. This > situation creates the requirement for MM to exclusively generate page > relative URLs; server relative URLs still make a rewriting HTML filter > necessary. > > 3. links in archived mail to attachments extracted by the present > pipermail archiver are currently generated as server relative given the > present state of the list privacy. This means that changing a list's > archive privacy status leaves links to attachments broken unless > bin/arch is used to rebuild the entire list archive. Whichever archiver > is packaged with MM3 should avoid this problem. These are all excellent use cases. Can you add them to the MM3 wiki so they don't get lost? -Barry From barry at python.org Mon Mar 29 12:16:57 2004 From: barry at python.org (Barry Warsaw) Date: Mon Mar 29 12:17:08 2004 Subject: [Mailman3-dev] virtual host implementation In-Reply-To: <13FC43F0-7938-11D8-8F32-000A95AA76E0@dreamhost.com> References: <13FC43F0-7938-11D8-8F32-000A95AA76E0@dreamhost.com> Message-ID: <1080580616.32170.14.camel@anthem.wooz.org> On Thu, 2004-03-18 at 18:57, Dallas Bethune wrote: > I was wondering how much is currently known about the virtual host > implementation in Mailman 3. We use Mailman to provide discussion > lists for several thousand virtually hosted domains (we're a webhost). > > It has already been said that lists with the same name at different > domains will be supported (yay!). Are other details currently known? > It would be ideal to have as much independent control over each > 'domain' as possible. Each domain would have its own administrator in > addition to the one main super administrator and that domain > administrator would have access to set useful options that would affect > all lists under the domain, etc. Permissions will be based on a simplified role architecture. There will be (at least) the following roles: - site admin - vdomain admin - list admin - list moderator - registered user - stranger With all but the last, you'll log into the system and you'll just get your assigned roles, so you'll be able to perform any tasks allowed to that role. At pycon we sketched out an approach for delegating control of configuration variables up and down the hierarchy (e.g. a site admin can delegate the ability to change footers to the vdomain admin, who might /not/ allow her list admins to change their footers). -Barry From dario at ita.chalmers.se Wed Mar 31 03:22:30 2004 From: dario at ita.chalmers.se (=?ISO-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Wed Mar 31 03:22:40 2004 Subject: [Mailman3-dev] virtual host implementation In-Reply-To: <1080580616.32170.14.camel@anthem.wooz.org> References: <13FC43F0-7938-11D8-8F32-000A95AA76E0@dreamhost.com> <1080580616.32170.14.camel@anthem.wooz.org> Message-ID: <406A7FC6.5090202@ita.chalmers.se> Barry Warsaw wrote: > At pycon we sketched out an approach for [...] any chances of those sketches/notes being put online? Cheers, /dario -- -- ------------------------------------------------------------------- Dario Lopez-K?sten, IT Systems & Services Chalmers University of Tech.