From lists05 at equinephotoart.com Sun May 1 01:21:04 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Sun May 1 01:21:06 2005 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <4945d6d882e151d8b7c8086f2eb01efe@kabissa.org> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <4945d6d882e151d8b7c8086f2eb01efe@kabissa.org> Message-ID: <427412E0.6080108@equinephotoart.com> Tobias Eigen wrote: >>> - New third party archiving option that uses The Mail Archive. The >>> implementation subscribes or unsubscribes the >>> archive@mail-archive.com address from the subscriber list. >> > > I find this whole discussion fascinating. I've been thinking about > these types of possibilities for a while, and have been watching gmane > and mail-archive off and on for inspiration for what Kabissa might do. > Archiving is getting to be a big 'problem' at Kabissa currently, esp > as our archives get older and bigger, and we desire to move to a more > interactive and useful format for archiving discussions and making > them more accessible via the web, i.e. in forums. Maybe the short-term > answer is to encourage the listowners of our very busy lists to move > their archives to mail-archive or gmane. This looks like a good opportunity to mention that mailman-users and mailman-developers are now also archived at: See this particular thread at: They asked for permission to join -dev so that it could be archived on their site. At the time, their archives didn't have munged email addresses, and Barry and I decided that if they fixed their archives to not expose email addresses, he would give them permission to join -dev and to archive mailman lists.. I like gmane's feature of making lists accessible in a newsgroup fashion, and I like free.net's format of providing the list in a threaded fashion via the web. This is not an endorsement of either site, just a personal observation of some of the positive features each of them offers over traditional list archives. Some list admins might want to offer their lists to be mirrored/archived at more than one site. While RFC 2369 only allows for one List-Archive: URL, I wonder if email client implementations that understand 2369 (is there a list of which ones are?) are generous in their response when a list email has more than List-Archive header... Be generous in what you accept and all that... :-) jc From jeff at jab.org Sun May 1 22:36:50 2005 From: jeff at jab.org (Jeff Breidenbach) Date: Sun May 1 22:14:22 2005 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: Message-ID: Hi, I'm the other Jeff from The Mail Archive. >Any subscriber might be keeping and publishing an archive of the list >posts. If the listmaster doesn't like that, he should be vetting each >subscription, and making sure that each subscriber understands the >rules. The list administrator may also add the "X-No-Archive: Yes" header to messages. This header says "no matter what, please don't archive this message". It is machine parsable and automatically honored by all reputable archiving services, including The Mail Archive and Gmane. From barry at python.org Mon May 2 15:10:56 2005 From: barry at python.org (Barry Warsaw) Date: Mon, 02 May 2005 09:10:56 -0400 Subject: [Mailman-Developers] max_days_to_hold Message-ID: <1115039456.10178.109.camel@presto.wooz.org> I just upgraded all the lists @python.org from 2.1.5 to 2.1.6rc3. I noticed that they all grew a max_days_to_hold = 3 value. I actually don't understand this since version.py has a add_only_if_missing('max_days_to_hold', 0) call. So shouldn't they all have gotten set to zero? I'd like to figure this out before we release 2.1.6 final. Also, I plan on changing DEFAULT_MAX_DAYS_TO_HOLD to 0 in Defaults.py.in because I don't think this should be enabled by default for new lists (it's a new feature in a maintenance release). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050502/db85bc40/attachment.pgp From sgwillis at deepskytech.com Mon May 2 17:39:23 2005 From: sgwillis at deepskytech.com (Steven G. Willis) Date: Mon, 2 May 2005 15:39:23 +0000 Subject: [Mailman-Developers] [ mailman-Bugs-871050 ] Uncought runner exception: Empty module name In-Reply-To: Message-ID: It hath once been written: >UITB-Originating-Server: 194.109.24.25 (smtp-vbr5.xs4all.nl) The email (SMTP) server at 194.109.24.25 has been documented as: sending unsolicted email; on a network that sends unsolicited email; participated in a coordinated attack on our network (open bounce relay). You can view a direct report for the IP in question at: http://www.uitb.deepskytech.com/show_ip_report.php?ip=194.109.24.25 The bounces contain enough information for you to identify the general source of the problem. You should also have enough information to contact us directly for any details you may need in identifying the specific problem that exists in your email server(s)/network. Once you have corrected the problem(s) , please notify us of this. We can then confirm that the problem(s) has been corrected and remove the block that is in place for your email server(s)/network. ------------------------------------------------------------ NOTE: the issues on file from this location are simple enough to correct. Once these issues have been corrected, please contact us with the following information: IP Address(es) of SMTP Server(s) Managed: Host names of SMTP Server(s): Full Name/Role: Company Name (if any): Voice Phone Contact: Email Address: Full Snail Mail Address: We will use this information to create an "Allow record" for the IP addresses managed as SMTP servers by this individual/role. The information within an Allow record is kept private within the UITB.com system. And, once an Allow record has been created for particular IP address(es), then any future issues we see originating from there will result in a notification email being dispatched instead of immediate blocking; this allows for the situation noted to be corrected before any blocking is put into place that may possibly affect users. Let me know if you have any questions on this or if we can help in any way. Cheers! ================================================================ Steven G. Willis sgwillis at deepskytech.com 866.224.3058 Deep Sky Technologies, Inc. http://www.deepskytech.com/ http://www.badchickens.com/ http://www.store-secure.com/ AIM-iChat: dstisgwillis ================================================================ All words are plastic. Word images begin to distort in the instance of utterance. Ideas imbedded in a language require that particular language for expression. This is the very essence of the meaning within the word "exotic". ================================================================ From sgwillis at deepskytech.com Mon May 2 17:45:25 2005 From: sgwillis at deepskytech.com (Steven G. Willis) Date: Mon, 2 May 2005 15:45:25 +0000 Subject: [Mailman-Developers] [ mailman-Bugs-871050 ] Uncought runner exception: Empty module name In-Reply-To: Message-ID: It hath once been written: >>UITB-Originating-Server: 194.109.24.25 (smtp-vbr5.xs4all.nl) > >The email (SMTP) server at 194.109.24.25 has been documented as: > >... Sorry, included the wrong address on that message. My apologies to all list members for my mistake. Cheers! ================================================================ Steven G. Willis sgwillis at deepskytech.com 866.224.3058 Deep Sky Technologies, Inc. http://www.deepskytech.com/ http://www.badchickens.com/ http://www.store-secure.com/ AIM-iChat: dstisgwillis ================================================================ Thankfully they created the word 'muffin' else I would be eating a cupcake for breakfast ================================================================ From stephen at xemacs.org Tue May 3 10:37:46 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 03 May 2005 17:37:46 +0900 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> (Chuq Von Rospach's message of "Sat, 30 Apr 2005 10:51:00 -0700") References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> Message-ID: <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Chuq" == Chuq Von Rospach writes: >> the 3rd party archiver.] I don't see why Gmane or the Mail >> Archive should have to obey special rules here. Chuq> because it's the list owners list, and they have the final Chuq> say on how its run. Not the users. If the users don't like Chuq> it, they can go start their own lists, not attempt to co-opt Chuq> policy on someone else's list. That's not the point here. The special rule I'm talking about is the one that says they must guess what (unpublished) policy is because they're somehow "different" from "ordinary" subscribers. The examples (Gmane and Mail Archive) are habitual good citizens. Sure, they _are_ different, in a relevant way---they exist to broaden distribution, including archiving. But I think that in the great majority of cases where random users can just sign up, that is a service to be encouraged. It's not a good idea to put the burden of proof on them, when either the list-owner can be more selective about membership, or they can use X-No-Archive. Hrm. Maybe a way to turn on X-No-Archive should be part of this patch? (Or does Mailman offer that already? I don't see it.) >> ... if Mailman is going to endorse services that way. I don't >> really think it's a good idea in principle, though. What >> happens if The Mail Archive goes away or goes proprietary? Chuq> then we disable the patch. Good trick, that. Mailman is free software; it will be months before the revised code propagates to all the major distros, let alone the small-time variants. How long would it take Apple to get a Software Update out? During that period, Mailman is offering a service that it can't support. Nor do I think Mailman's reaction would be particularly swift---isn't this the kind of thing that as a technical matter really should wait until the next scheduled release? Again, I'm not really arguing against the patch. It's the people who might be doing extra releases (Barry and Tokio, right?) or answering the FAQs (Brad and Mark, primus inter pares) who should decide if it belongs in the Mailman distribution. I do advocate some kind of public statement about the policy toward adding new facilities of this kind. One easy one would be "you write the patch, and show that you conform to certain rules such as 'patch defaults off' and 'service respects X-No-Archive as well as conforming to relevant RFCs', and we'll put it in to the next regular release that isn't already in feature freeze." Or maybe it's worth encouraging such services, and being more helpful about it. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From fil at rezo.net Tue May 3 10:45:54 2005 From: fil at rezo.net (Fil) Date: Tue, 3 May 2005 10:45:54 +0200 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <20050503084554.GC28586@rezo.net> I would see it that way, in the "Archiving" section of admin : Archiving on a foreign system : ------------------------------- prevent archiving on foreign systems yes [] no [x] (adds a X-NO-Archive: header) if no, send all mails to archive on the following address(es): [ ................ ] e.g. archiver at mail-archive.org, thingy at gmane.plop, and so on see http://mail.org/foreign_archives/ for more information With this (and proper wording), I think you get the best of the functionality without the "political" problems. -- Fil From brad at stop.mail-abuse.org Tue May 3 10:56:06 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 3 May 2005 10:56:06 +0200 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote: > Sure, they _are_ different, in a relevant way---they exist to broaden > distribution, including archiving. But I think that in the great > majority of cases where random users can just sign up, that is a > service to be encouraged. It's not a good idea to put the burden of > proof on them, when either the list-owner can be more selective about > membership, or they can use X-No-Archive. The problem here is that Mailman should not be adding an "X-No-Archive:" header to messages that it is processing. This is something that should be controlled from the perspective of the user, and Mailman should not be stepping on their toes. Moreover, if Mailman did add such a header, what would happen to the internal archiving system? Would Mailman ignore the header that it has added while honoring the same header that might have been put on the message by the user? As a list admin, I can see a strong desire to keep your own archive, but to want to prevent anyone else from maintaining an archive, at least not without your express approval. Unless, that is, you gateway to USENET news, in which case Google and others have news archives that you could not control and could not even be aware of in most cases. But then if you gateway to USENET news, you should be aware of this issue, and be prepared for what might happen. > Again, I'm not really arguing against the patch. It's the people who > might be doing extra releases (Barry and Tokio, right?) or answering > the FAQs (Brad and Mark, primus inter pares) who should decide if it > belongs in the Mailman distribution. IMO, the ultimate decision is up to Barry -- it's his project, and he gets to decide how things go. However, he is currently focusing on Mailman3 right now, and Tokio is the release engineer for Mailman2, and in the past Barry has been open to comments and suggestions from others. So, I imagine he might make his feelings known, but then leave the ultimate decision to Tokio, who would hopefully also take input from others. However, I don't see that Mark or I would necessarily have any more weight given to our comments during that discussion as a result of our work with the FAQ and answering the questions. I would hope that we would be heard along with the others commenting on the subject, and appropriate weight would be given to them by Barry and Tokio, but more based on their merits than on the work we do with the FAQ. There are plenty of other knowledgeable people on mailman-users and mailman-developers who don't (or haven't recently) done much of anything with the FAQ, and I would hope that their voices would be given as much weight relative to their experience as would ours. > I do advocate some kind of public statement about the policy toward > adding new facilities of this kind. One easy one would be "you write > the patch, and show that you conform to certain rules such as 'patch > defaults off' and 'service respects X-No-Archive as well as conforming > to relevant RFCs', and we'll put it in to the next regular release > that isn't already in feature freeze." I'm not so sure this is a good idea. At least, not so far as guaranteeing that it would be put in the next regular release. IMO, if the patch defaults to off, and the service conforms to the relevant RFCs and BCPs, then I think we should give it serious consideration, but I wouldn't want to guarantee anything more than serious consideration. > Or maybe it's worth encouraging such services, and being more helpful > about it. I would encourage more people to make patches, and to try to be more helpful about this process in general. But I wouldn't want to make any guarantees as to what would/would not get included -- everything should get the appropriate level of consideration, but no guarantees beyond that. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From larsi at gnus.org Tue May 3 12:47:38 2005 From: larsi at gnus.org (Lars Magne Ingebrigtsen) Date: Tue, 03 May 2005 12:47:38 +0200 Subject: [Mailman-Developers] Patch for Mail Archive mirroring References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: "Stephen J. Turnbull" writes: > ... if Mailman is going to endorse services that way. I don't really > think it's a good idea in principle, though. What happens if The Mail > Archive goes away or goes proprietary? What are people going to think > if The Mail Archive's maintainers hire Barry or Brad? Etc, etc. (Disclosure: I'm the other archiving service, Gmane.) I wonder if adding a layer of indirection here would help with these considerations. That is -- Mailman could have a box saying "archive using external archivers" (without saying which external archivers) that list admins could tick/untick that resulted in a message being sent to a meta-archival site. This meta-archival site would then have a list of external archivers that be notified about the mailing list. This meta-archive would be run by a third party, and would de-list any archivers that are naughty. -- (domestic pets only, the antidote for overdose, milk.) larsi at gnus.org * Lars Magne Ingebrigtsen From larsi at gnus.org Tue May 3 13:19:56 2005 From: larsi at gnus.org (Lars Magne Ingebrigtsen) Date: Tue, 03 May 2005 13:19:56 +0200 Subject: [Mailman-Developers] Patch for Mail Archive mirroring References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: Lars Magne Ingebrigtsen writes: > This meta-archival site would then have a list of external archivers > that be notified about the mailing list. (Like Jeff said, Gmane would probably not be one of these archivers, because we need more information than is usually available from Mailman. In particular, we need to know what the list is really about to classify it properly, and list descriptions are (more often than not, I think) "The devel list", which doesn't really help us much. And we like to have project URLs, so that we can point users to the web site of the project, and there's settings like address encryption on/off, etc, etc. So at present, only mail-archive.com (and possibly MARC) would be the only external archive(s) on the list of archivers, which might make this overkill.) -- (domestic pets only, the antidote for overdose, milk.) larsi at gnus.org * Lars Magne Ingebrigtsen From lists05 at equinephotoart.com Tue May 3 21:38:51 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Tue, 03 May 2005 12:38:51 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <20050503084554.GC28586@rezo.net> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> <20050503084554.GC28586@rezo.net> Message-ID: <4277D34B.7040301@equinephotoart.com> Fil wrote: >I would see it that way, in the "Archiving" section of admin : > > Archiving on a foreign system : > ------------------------------- > > prevent archiving on foreign systems yes [] no [x] > (adds a X-NO-Archive: header) > > if no, > send all mails to archive on the following address(es): > [ ................ ] > e.g. archiver at mail-archive.org, thingy at gmane.plop, and so on > see http://mail.org/foreign_archives/ for more information > > (Without stating an opinion on if it is a good idea in *this* case or not to add this functionality, I'd like to share an opinion about the nature of the selections.) The sequence of "prevent" "no" "if no" can be confusing. I can see list managers accidentally setting this wrong and then coming to -users asking for help. I think it would be less confusing to have it read like this: Archiving on a foreign system : ------------------------------- allow archiving on foreign systems NO [] YES[X] if NO mailman adds a X-NO-Archive: header if YES, send all mails to archives via the following address(es): [ ................ ] e.g. archiver at mail-archive.org, thingy at gmane.plop, and so on see http://mail.org/foreign_archives/ for more information jc From fil at rezo.net Tue May 3 21:48:57 2005 From: fil at rezo.net (Fil) Date: Tue, 3 May 2005 21:48:57 +0200 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <4277D34B.7040301@equinephotoart.com> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> <20050503084554.GC28586@rezo.net> <4277D34B.7040301@equinephotoart.com> Message-ID: <20050503194857.GR8647@rezo.net> > The sequence of "prevent" "no" "if no" can be confusing. You are not wrong! Indeed! I can't disagree :) -- Fil From carbonnb at sympatico.ca Thu May 5 03:37:26 2005 From: carbonnb at sympatico.ca (Bryan Carbonnell) Date: Wed, 04 May 2005 21:37:26 -0400 Subject: [Mailman-Developers] XHTML Compliant Web UI - 2.1.6 Patch In-Reply-To: Message-ID: On 24 Apr 2005 at 8:31, Bryan Carbonnell wrote: > I have just uploaded a patch that will make the web UI for MM 2.1.6rc1 > XHTML 1 strict compliant. This patch allows for some CSS formatting as > well. > > I have tried to make all the pages compliant, but I may have missed > some combinations of pages and options, so if you find some that > aren't compliant, please let me know which page isn't compliant and > under which circumstances it's not. > > It it patch 1160353 in the Sourceforge Mailman patch repository. > http://sourceforge.net/tracker/index.php?func=detail&aid=1160353&group > _id=103&atid=300103 > > If anyone has any feedback on it, I'd love to hear it,since this is my > first attempt at something like this. Now updated for MM 2.1.6rc3 It also makes the archives XHTML1.0 Strict compliant. -- Bryan Carbonnell - carbonnb at sympatico.ca Never let a computer see you hurry. From marshman at frozenbear.com Fri May 6 04:14:40 2005 From: marshman at frozenbear.com (=?ISO-8859-1?Q?Jeff=20Marshall?=) Date: 05 May 2005 19:14:40 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring Message-ID: <200505060217.j462HJr13895@glin.devaudio.com> I figured I would attempt a brief summary of major points brought up by the discussion. Concerns - proper documentation describing the feature and possibly Mailman's position on archiver tie-ins - make sure it defaults to off (it currently does) - we should look for opportunities to add safeguards - one possible safeguard - an option for admins to add the "X-No-Archive: yes" header - has pros and cons (cons: does it conflict with local pipermail archiving? possible conflict with user's X-No-Archive intentions?) Is it an endorsement? - people ranged from "seems like an endorsement" to "no more than mailman endorses the other software it works with" - I'm happy to do the work to make this feature work with other archiving services as well. Gmane looks like it is out. I will check with Hank at MARC. Overall - seems like most people think it is a positive patch (with the caveat that it defaults to "off") because it makes things easy for admins that choose to use it - in the end, it's up to Barry and Tokio. Hopefully one of them can jump in briefly and make the call, or ask me for some rework on the patch. Corrections or clarifications are welcome. Thanks to everyone for their consideration and response; people seemed to put a lot of energy into this. Much appreciated. Jeff Marshall marshman at frozenbear.com -----Original Message----- From: Brad Knowles Date: 5/3/05 1:56 am To: Stephen J. Turnbull Cc: mailman-developers at python.org, Chuq Von Rospach , Chuq Von Rospach Subj: Re: [Mailman-Developers] Patch for Mail Archive mirroring At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote: > Sure, they _are_ different, in a relevant way---they exist to broaden > distribution, including archiving. But I think that in the great > majority of cases where random users can just sign up, that is a > service to be encouraged. It's not a good idea to put the burden of > proof on them, when either the list-owner can be more selective about > membership, or they can use X-No-Archive. The problem here is that Mailman should not be adding an "X-No-Archive:" header to messages that it is processing. This is something that should be controlled from the perspective of the user, and Mailman should not be stepping on their toes. Moreover, if Mailman did add such a header, what would happen to the internal archiving system? Would Mailman ignore the header that it has added while honoring the same header that might have been put on the message by the user? As a list admin, I can see a strong desire to keep your own archive, but to want to prevent anyone else from maintaining an archive, at least not without your express approval. Unless, that is, you gateway to USENET news, in which case Google and others have news archives that you could not control and could not even be aware of in most cases. But then if you gateway to USENET news, you should be aware of this issue, and be prepared for what might happen. > Again, I'm not really arguing against the patch. It's the people who > might be doing extra releases (Barry and Tokio, right?) or answering > the FAQs (Brad and Mark, primus inter pares) who should decide if it > belongs in the Mailman distribution. IMO, the ultimate decision is up to Barry -- it's his project, and he gets to decide how things go. However, he is currently focusing on Mailman3 right now, and Tokio is the release engineer for Mailman2, and in the past Barry has been open to comments and suggestions from others. So, I imagine he might make his feelings known, but then leave the ultimate decision to Tokio, who would hopefully also take input from others. However, I don't see that Mark or I would necessarily have any more weight given to our comments during that discussion as a result of our work with the FAQ and answering the questions. I would hope that we would be heard along with the others commenting on the subject, and appropriate weight would be given to them by Barry and Tokio, but more based on their merits than on the work we do with the FAQ. There are plenty of other knowledgeable people on mailman-users and mailman-developers who don't (or haven't recently) done much of anything with the FAQ, and I would hope that their voices would be given as much weight relative to their experience as would ours. > I do advocate some kind of public statement about the policy toward > adding new facilities of this kind. One easy one would be "you write > the patch, and show that you conform to certain rules such as 'patch > defaults off' and 'service respects X-No-Archive as well as conforming > to relevant RFCs', and we'll put it in to the next regular release > that isn't already in feature freeze." I'm not so sure this is a good idea. At least, not so far as guaranteeing that it would be put in the next regular release. IMO, if the patch defaults to off, and the service conforms to the relevant RFCs and BCPs, then I think we should give it serious consideration, but I wouldn't want to guarantee anything more than serious consideration. > Or maybe it's worth encouraging such services, and being more helpful > about it. I would encourage more people to make patches, and to try to be more helpful about this process in general. But I wouldn't want to make any guarantees as to what would/would not get included -- everything should get the appropriate level of consideration, but no guarantees beyond that. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. _______________________________________________ Mailman-Developers mailing list Mailman-Developers at python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/marshman%40frozzenbear.com Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.http From bob at nleaudio.com Fri May 6 08:28:59 2005 From: bob at nleaudio.com (Bob Puff) Date: Fri, 6 May 2005 02:28:59 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <200505060217.j462HJr13895@glin.devaudio.com> References: <200505060217.j462HJr13895@glin.devaudio.com> Message-ID: <20050506062737.M4906@nleaudio.com> Personally, I'd much rather see the HT/Dig patch implemented before this one. That is IMHO more useful to the average mailman admin than this. Bob ---------- Original Message ----------- From: Jeff Marshall To: brad at stop.mail-abuse.org, stephen at xemacs.org Cc: mailman-developers at python.org, chuqui at plaidworks.com Sent: 05 May 2005 19:14:40 -0700 Subject: Re: [Mailman-Developers] Patch for Mail Archive mirroring > I figured I would attempt a brief summary of major points brought up > by the discussion. > > Concerns > - proper documentation describing the feature and possibly Mailman's > position on archiver tie-ins - make sure it defaults to off (it > currently does) - we should look for opportunities to add safeguards > - one possible safeguard - an option for admins to add the "X-No- > Archive: yes" header - has pros and cons (cons: does it conflict > with local pipermail archiving? possible conflict with user's X-No- > Archive intentions?) > > Is it an endorsement? > - people ranged from "seems like an endorsement" to "no more than > mailman endorses the other software it works with" - I'm happy to do > the work to make this feature work with other archiving services as > well. Gmane looks like it is out. I will check with Hank at MARC. > > Overall > - seems like most people think it is a positive patch (with the > caveat that it defaults to "off") because it makes things easy for > admins that choose to use it - in the end, it's up to Barry and > Tokio. Hopefully one of them can jump in briefly and make the call, > or ask me for some rework on the patch. > > Corrections or clarifications are welcome. > > Thanks to everyone for their consideration and response; people > seemed to put a lot of energy into this. Much appreciated. > > Jeff Marshall > marshman at frozenbear.com > > -----Original Message----- > From: Brad Knowles > Date: 5/3/05 1:56 am > To: Stephen J. Turnbull > Cc: mailman-developers at python.org, Chuq Von Rospach , Chuq Von > Rospach Subj: Re: [Mailman-Developers] Patch for Mail Archive mirroring > > At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote: > > > Sure, they _are_ different, in a relevant way---they exist to broaden > > distribution, including archiving. But I think that in the great > > majority of cases where random users can just sign up, that is a > > service to be encouraged. It's not a good idea to put the burden of > > proof on them, when either the list-owner can be more selective about > > membership, or they can use X-No-Archive. > > The problem here is that Mailman should not be adding an > "X-No-Archive:" header to messages that it is processing. This is > something that should be controlled from the perspective of the user, > and Mailman should not be stepping on their toes. > > Moreover, if Mailman did add such a header, what would happen to > the internal archiving system? Would Mailman ignore the header that > it has added while honoring the same header that might have been put > on the message by the user? > > As a list admin, I can see a strong desire to keep your own > archive, but to want to prevent anyone else from maintaining an > archive, at least not without your express approval. Unless, that > is, you gateway to USENET news, in which case Google and others have > news archives that you could not control and could not even be aware > of in most cases. But then if you gateway to USENET news, you > should be aware of this issue, and be prepared for what might happen. > > > Again, I'm not really arguing against the patch. It's the people who > > might be doing extra releases (Barry and Tokio, right?) or answering > > the FAQs (Brad and Mark, primus inter pares) who should decide if it > > belongs in the Mailman distribution. > > IMO, the ultimate decision is up to Barry -- it's his project, > and he gets to decide how things go. However, he is currently > focusing on Mailman3 right now, and Tokio is the release engineer > for Mailman2, and in the past Barry has been open to comments and > suggestions from others. So, I imagine he might make his feelings > known, but then leave the ultimate decision to Tokio, who would > hopefully also take input from others. > > However, I don't see that Mark or I would necessarily have any > more weight given to our comments during that discussion as a result > of our work with the FAQ and answering the questions. I would hope > that we would be heard along with the others commenting on the > subject, and appropriate weight would be given to them by Barry and > Tokio, but more based on their merits than on the work we do with > the FAQ. > > There are plenty of other knowledgeable people on mailman-users > and mailman-developers who don't (or haven't recently) done much of > anything with the FAQ, and I would hope that their voices would be > given as much weight relative to their experience as would ours. > > > I do advocate some kind of public statement about the policy toward > > adding new facilities of this kind. One easy one would be "you write > > the patch, and show that you conform to certain rules such as 'patch > > defaults off' and 'service respects X-No-Archive as well as conforming > > to relevant RFCs', and we'll put it in to the next regular release > > that isn't already in feature freeze." > > I'm not so sure this is a good idea. At least, not so far as > guaranteeing that it would be put in the next regular release. IMO, > if the patch defaults to off, and the service conforms to the > relevant RFCs and BCPs, then I think we should give it serious > consideration, but I wouldn't want to guarantee anything more than > serious consideration. > > > Or maybe it's worth encouraging such services, and being more helpful > > about it. > > I would encourage more people to make patches, and to try to be > more helpful about this process in general. But I wouldn't want to > make any guarantees as to what would/would not get included -- > everything should get the appropriate level of consideration, but no > guarantees beyond that. > > -- > Brad Knowles, > > "Those who would give up essential Liberty, to purchase a little > temporary Safety, deserve neither Liberty nor Safety." > > -- Benjamin Franklin (1706-1790), reply of the Pennsylvania > Assembly to the Governor, November 11, 1755 > > SAGE member since 1995. See for more info. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/marshman%40frozzenbear.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.http > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp ------- End of Original Message ------- From stephen at xemacs.org Fri May 6 11:39:34 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 06 May 2005 18:39:34 +0900 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <20050506062737.M4906@nleaudio.com> (Bob Puff's message of "Fri, 6 May 2005 02:28:59 -0400") References: <200505060217.j462HJr13895@glin.devaudio.com> <20050506062737.M4906@nleaudio.com> Message-ID: <87psw4y9pl.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Bob" == Bob Puff writes: Bob> Personally, I'd much rather see the HT/Dig patch implemented Bob> before this one. That is IMHO more useful to the average Bob> mailman admin than this. Jeff's patch is so simple you could prove its correctness mathematically. The impossible takes a little longer. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From stephen at xemacs.org Fri May 6 12:17:00 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 06 May 2005 19:17:00 +0900 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: (Brad Knowles's message of "Tue, 3 May 2005 10:56:06 +0200") References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <87ll6sy7z7.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Brad" == Brad Knowles writes: Brad> At 5:37 PM +0900 2005-05-03, Stephen J. Turnbull wrote: >> It's not a good idea to put the burden of proof on them, when >> either the list-owner can be more selective about membership, >> or they can use X-No-Archive. Brad> The problem here is that Mailman should not be adding Brad> an "X-No-Archive:" header to messages that it is processing. Brad> This is something that should be controlled from the Brad> perspective of the user, and Mailman should not be stepping Brad> on their toes. OK. I can't find a spec for the X-No-Archive header that looks "official", but the USEFOR draft for the "Archive" header does say "for use by the poster". Brad> Moreover, if Mailman did add such a header, what would Brad> happen to the internal archiving system? Would Mailman Brad> ignore the header that it has added while honoring the same Brad> header that might have been put on the message by the user? Exactly. You'd just put the "Add X-No-Archive header" handler in the pipeline after Mailman's archiver. The list admin already has control of Mailman's internal archiver. Brad> As a list admin, I can see a strong desire to keep Brad> your own archive, but to want to prevent anyone else from Brad> maintaining an archive, at least not without your express Brad> approval. I think the semantics are arguably OK here as long as Mailman passes through any existing X-No-Archive header (or Archive, when that gets out of draft status). The user has no right to expect to be archived elsewhere if the list master's policy is "we do our own archiving." But yes, Mailman should respect the RFCs (including drafts, for optional facilities it wants to use). Too bad. Maybe you could make it part of the user's configuration. Then the list master could default it to X-No-Archive: yes; individual users could turn it to no if they want to, including on a message by message basis. A stretch, I know, but it would be really horrible to have to have separate archiving control headers for the user and the list, and to have to establish a precedence, etc. >> I do advocate some kind of public statement about the policy >> toward adding new facilities of this kind. One easy one would >> be "you write the patch, and show that you conform to certain >> rules such as 'patch defaults off' and 'service respects >> X-No-Archive as well as conforming to relevant RFCs', and we'll >> put it in to the next regular release that isn't already in >> feature freeze." Brad> I'm not so sure this is a good idea. At least, not so Brad> far as guaranteeing that it would be put in the next regular Brad> release. I'm happy with your phrasing of "serious consideration." Nothing's guaranteed in a volunteer maintained project, of course. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From brad at stop.mail-abuse.org Fri May 6 14:22:38 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 6 May 2005 14:22:38 +0200 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <87ll6sy7z7.fsf@tleepslib.sk.tsukuba.ac.jp> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> <87ll6sy7z7.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: At 7:17 PM +0900 2005-05-06, Stephen J. Turnbull wrote: > Maybe you could make it part of the user's configuration. Then the > list master could default it to X-No-Archive: yes; individual users > could turn it to no if they want to, including on a message by message > basis. A stretch, I know, but it would be really horrible to have to > have separate archiving control headers for the user and the list, and > to have to establish a precedence, etc. I think the concept of having Mailman optionally add it's own "X-No-Archive:" header would greatly complicate the situation, and I would be opposed to spending a whole lot of time working on this unless someone else can provide us a pretty much complete feature-rich patch that allows for modifying where in the stream this process is done and where in the stream Mailman pays attention to this header itself, and on a per-user basis. Even then, I would be opposed to spending a whole lot of time contemplating the patch. The original patch is simple enough that I think we can argue the merits of trying to slip it in sooner rather than later. However, the more complex you make this concept and the more complex you make the patch, the more I would be unwilling to consider incorporating such a feature until the next major release of Mailman2. > I'm happy with your phrasing of "serious consideration." Nothing's > guaranteed in a volunteer maintained project, of course. Of course. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From lists05 at equinephotoart.com Fri May 6 17:25:36 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Fri, 06 May 2005 08:25:36 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> <87ll6sy7z7.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <427B8C70.20503@equinephotoart.com> Brad Knowles wrote: >At 7:17 PM +0900 2005-05-06, Stephen J. Turnbull wrote: > > > >> Maybe you could make it part of the user's configuration. Then the >> list master could default it to X-No-Archive: yes; individual users >> could turn it to no if they want to, including on a message by message >> basis. A stretch, I know, but it would be really horrible to have to >> have separate archiving control headers for the user and the list, and >> to have to establish a precedence, etc. >> >> Allowing users to set their archive preference in their list settings is a completely different feature. If someone wants to write a patch that does that, it should act on incoming email before mailman processes that mail for local archiving so that the local archive honors the user's setting. Then the list archive process would happen after the local archive is written. > > I think the concept of having Mailman optionally add it's own >"X-No-Archive:" header would greatly complicate the situation, and I >would be opposed to spending a whole lot of time working on this >unless someone else can provide us a pretty much complete >feature-rich patch that allows for modifying where in the stream this >process is done and where in the stream Mailman pays attention to >this header itself, and on a per-user basis. > > Personally, I don't see this as a big problem. If the header is inserted at a single specific place in the stream that is OK *as long as it's properly documented*. Then each list server admin or list owner can choose to turn this feature on or not, knowing exactly what it will do. IMHO, the correct place to insert this header is after mailman has processed the incoming message and archived it locally. That way the original sender's x-no-archive setting (set in the original incoming email or by the *other* x-no-archive patch that might someday be added) is correct for the local archive, and the outgoing mail is correct for the list's preference. jc From marshman at frozenbear.com Thu May 12 06:39:56 2005 From: marshman at frozenbear.com (=?ISO-8859-1?Q?Jeff=20Marshall?=) Date: 11 May 2005 21:39:56 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring Message-ID: <200505120443.j4C4hFr12542@glin.devaudio.com> I wrote: > I will check with Hank at MARC. One more followup. I emailed with Hank at MARC (marc.theaimsgroup.com). Hank really likes the idea and tried enhancing the patch to cover MARC as well. He ran into a few issues that caused him to abort the attempt ["...setting of the List-Archive: URL header. MARC (and I think Gmane too) sometimes takes liberty with list names, such as for a project foo, if they've a list "users" we add it as "foo-users" (as opposed to Mail Archive's equivalent "users at foo.org" which works to keep them unique). That also makes it difficult to make meaningful predictions for what the resulting URLs will be, or checking the subscription list, etc. "]. So for now Hank is passing on resolving those issues, although he's willing to put more effort into it if people want the MARC option. Jeff From tkikuchi at is.kochi-u.ac.jp Thu May 12 23:17:24 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri, 13 May 2005 06:17:24 +0900 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <200504292211.j3TMBbr29010@glin.devaudio.com> References: <200504292211.j3TMBbr29010@glin.devaudio.com> Message-ID: <4283C7E4.7090207@is.kochi-u.ac.jp> Hi folks, Jeff Marshall wrote: > I have submitted a patch to SourceForge for consideration. > > Feature: > - New third party archiving option that uses The Mail Archive. I've reading your discussions and kept silent but recently urged to say something here. You may think this timing is the last chance that this patch is included in the main cvs but there are many other patches which are waiting in the SF patch area and maintained by the respective original authors. Incluing in the main CVS means we, Barry and I, are resposible in maintenace of the feature and I am not moved toward accepting the resposibility. I'd say "no" for merging into CVS now. Of course, Barry may have different opinion. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Fri May 13 01:15:11 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 12 May 2005 19:15:11 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <1115939710.32262.46.camel@geddy.wooz.org> I've looked at the patch, so let me give my general impressions, and then try to answer some specific questions brought up in this thread. First, obviously this can't make it into 2.1.6, since that's imminent. The patch itself looks fine (i.e. no dotted T's or crossed I's :). But I would probably reject it anyway. In principle, I like more general solutions and hooks for extensibility than hard-coding in external dependencies like this. For example, Mailman already has variables for hooking in external archives, so you could potentially re-implement your patch against that API. The one thing you'd lose is the ability to select mail-archive on a per-list basis. Is that important? I suppose some virtual hosting installations might want to allow that, but how common would that be? Let's say that's an important requirement. What I'd like to see in that case is a way to specify multiple archivers, register these archivers with Mailman, and then give list owners the ability to select one or more of those registered archive methods. You could even generalize it so that the internal Pipermail archiver was just another one of those methods. /That/ would be a cool patch that I might support in a future version. On Sat, 2005-04-30 at 04:01, Stephen J. Turnbull wrote: > On the pro side, there is the point that this would make such > mirroring an opt-in on the listmaster's side, which is good. So it > might be worth Mailman thinking about under what conditions it would > be good to make such an endorsement, and adding anybody who satisfied > those conditions. Right. If we had the general framework I outlined above, we could be pretty democratic about it. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050512/99f60070/attachment.pgp From barry at python.org Fri May 13 01:17:31 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 12 May 2005 19:17:31 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <1115939851.32266.53.camel@geddy.wooz.org> On Tue, 2005-05-03 at 06:47, Lars Magne Ingebrigtsen wrote: > I wonder if adding a layer of indirection here would help with these > considerations. > > That is -- Mailman could have a box saying "archive using external > archivers" (without saying which external archivers) that list admins > could tick/untick that resulted in a message being sent to a > meta-archival site. This meta-archival site would then have a list of > external archivers that be notified about the mailing list. > > This meta-archive would be run by a third party, and would de-list > any archivers that are naughty. My idea of having a framework in Mailman wouldn't preclude this, and it would give list owners the option of picking a specific archiver (because of compliance with whatever policies they care about), or just let the meta-archiver choose. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050512/af56f7bb/attachment.pgp From barry at python.org Fri May 13 01:25:48 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 12 May 2005 19:25:48 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <42739EBB.5090205@equinephotoart.com> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <42739EBB.5090205@equinephotoart.com> Message-ID: <1115940348.32259.62.camel@geddy.wooz.org> On Sat, 2005-04-30 at 11:05, JC Dill wrote: > I personally don't see it as being a significant endorsement. AIUI, > it's a patch that allows 2 software programs to work well together. > Mailman already provides patches or directions to make mailman work well > with qmail and postfix, but I don't believe this constitutes an > "endorsement" of qmail and/or postfix. In a sense it does though, because we're making some kind of promise to keep those things working. Now, the reality is that without Your help, there's no way I could keep those promises. I know Mailman works with Postfix because that's what I use, but I certainly don't have the time or resources to test under all possible configurations. I still think that means that the Mailman community as a whole is endorsing the support of those external mail servers. > A simple patch philosophy that will address this and future patches: If > the patch is incorporated into the main mailman build then the default > state should be "off" so that the listmaster has to proactively turn the > feature "on" for their mailman list server. +1 > If the patch remains as an > add-on feature that has to be downloaded separately from the main build, > then the default state could be "on" (since downloading the patch > separately would be a clear indication that the listmaster desired to > implement this feature on their mailman list server). -1. Pro-actively enabling a feature shouldn't be that much more work than downloading it and getting it integrated. > IMHO, etc. Caveat: I'm not a developer so those of you who actually > write code and build/install the software (I just run it after someone > else installed it for me :-) have much more say on this than I do. So > if you hate my idea, speak up! Don't underestimate yourself JC! You're what we developers like to call "A User", and while your type can be pesky at times , without you we're just hacking in the wind (he says, refraining from a more graphic description :). Users who help contribute to the design, functionality, and usability of Mailman -- as you do -- are always welcome on this list! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050512/91e4a38d/attachment.pgp From barry at python.org Fri May 13 01:30:20 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 12 May 2005 19:30:20 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> Message-ID: <1115940620.32266.65.camel@geddy.wooz.org> On Sat, 2005-04-30 at 13:51, Chuq Von Rospach wrote: > > ... if Mailman is going to endorse services that way. I don't really > > think it's a good idea in principle, though. What happens if The Mail > > Archive goes away or goes proprietary? > > then we disable the patch. No biggie. As long as it's not mandatory, > I don't see a problem here. The only problem of course is that you have to assume there will be tens of thousands of deployed installations that will suddenly break. Holy crap, I can see the complaints now. ;) will-my-replybot-be-able-to-keep-up?-ly y'rs, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050512/4fff034c/attachment.pgp From barry at python.org Fri May 13 01:36:02 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 12 May 2005 19:36:02 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <1115940962.32259.71.camel@geddy.wooz.org> On Tue, 2005-05-03 at 04:37, Stephen J. Turnbull wrote: > Hrm. Maybe a way to turn on X-No-Archive should be part of this > patch? (Or does Mailman offer that already? I don't see it.) Not on the Mailman side. > Good trick, that. Mailman is free software; it will be months before > the revised code propagates to all the major distros Or years. It's bad enough I still get bug reports about Mailman 2.0, but there are sites still running Mailman 1.x. > , let alone the > small-time variants. How long would it take Apple to get a Software > Update out? During that period, Mailman is offering a service that it > can't support. Nor do I think Mailman's reaction would be > particularly swift---isn't this the kind of thing that as a technical > matter really should wait until the next scheduled release? > > Again, I'm not really arguing against the patch. It's the people who > might be doing extra releases (Barry and Tokio, right?) or answering > the FAQs (Brad and Mark, primus inter pares) who should decide if it > belongs in the Mailman distribution. > > I do advocate some kind of public statement about the policy toward > adding new facilities of this kind. One easy one would be "you write > the patch, and show that you conform to certain rules such as 'patch > defaults off' and 'service respects X-No-Archive as well as conforming > to relevant RFCs', and we'll put it in to the next regular release > that isn't already in feature freeze." > > Or maybe it's worth encouraging such services, and being more helpful > about it. I think I've stated my general philosophy in a previous message. If WizzyMTA came with a new plug-in, documentation, and some promise of support help (if only to answer questions on mailman-users), we'd probably add the module in the next release. If we had a similar plug-in architecture for multiple 3rd-party archivers, we'd facilitate the same kind of thing for that service. I'd be all for that. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050512/a355abce/attachment.pgp From chuqui at plaidworks.com Fri May 13 01:48:09 2005 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Thu, 12 May 2005 16:48:09 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <1115939710.32262.46.camel@geddy.wooz.org> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <1115939710.32262.46.camel@geddy.wooz.org> Message-ID: <83A1147E-FFE9-4146-94B7-C78429C03070@plaidworks.com> what I did with my system was make the archiver completely separate from Mailman -- to mailman , it's just another email address that the admin subscribes, or not. Does archiving need to be integrated into mailman in the first place? As opposed to, say, a place to specifiy the URL of the archives for display? and since we've never really had the time/energy/etc to maintain and enhance pipermail, maybe spliting the code out and retiring it is a good strategy. On May 12, 2005, at 4:15 PM, Barry Warsaw wrote: > Let's say that's an important requirement. What I'd like to see in > that > case is a way to specify multiple archivers, register these archivers > with Mailman, and then give list owners the ability to select one or > more of those registered archive methods. You could even > generalize it > so that the internal Pipermail archiver was just another one of those > methods. From marshman at frozenbear.com Fri May 13 02:43:27 2005 From: marshman at frozenbear.com (=?ISO-8859-1?Q?Jeff=20Marshall?=) Date: 12 May 2005 17:43:27 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring Message-ID: <200505130046.j4D0kqr16941@glin.devaudio.com> Barry wrote: > I think I've stated my general philosophy in a previous message. > If WizzyMTA came with a new plug-in, documentation, and some promise > of support help (if only to answer questions on mailman-users), we'd > probably add the module in the next release. If we had a similar plug-in > architecture for multiple 3rd-party archivers, we'd facilitate the same > kind of thing for that service. I'd be all for that. Thanks for your feedback. I'll be happy to dig into the current archive system and work on a plug-in architecture to support multiple external archivers. I originally thought the Archive component of Mailman was something intended only to support the local pipermail archive, but using that API like you mention sounds like it would work well. I'm guessing it'd be a fair amount of work to make the internal pipermail work with the plug-in approach just like the external archivers. At the very least, it would need a lot of testing to make sure it doesn't break existing installations. I'll get back with MARC and possibly GMane so I can try to make things as general as is reasonable. I'll try to run a proposed approach in front of the list before coding it (unless it's easy enough to demonstrate the proposal via code). I think the only concern is that I think admins *would* find value in per-list control of external archives. This is speculation, though. Jeff From dallas at dreamhost.com Fri May 13 02:57:33 2005 From: dallas at dreamhost.com (Dallas Bethune) Date: Thu, 12 May 2005 17:57:33 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <200505130046.j4D0kqr16941@glin.devaudio.com> References: <200505130046.j4D0kqr16941@glin.devaudio.com> Message-ID: <91CD4EAC-F3DF-4074-816C-D0AD2D8D26A2@dreamhost.com> On May 12, 2005, at 5:43 PM, Jeff Marshall wrote: > Barry wrote: > >> I think I've stated my general philosophy in a previous message. >> If WizzyMTA came with a new plug-in, documentation, and some promise >> of support help (if only to answer questions on mailman-users), we'd >> probably add the module in the next release. If we had a similar >> plug-in >> architecture for multiple 3rd-party archivers, we'd facilitate the >> same >> kind of thing for that service. I'd be all for that. >> > > > Thanks for your feedback. I'll be happy to dig into the current > archive system and work on a plug-in architecture to support > multiple external archivers. I originally thought the Archive > component of Mailman was something intended only to support the > local pipermail archive, but using that API like you mention sounds > like it would work well. I'm guessing it'd be a fair amount of > work to make the internal pipermail work with the plug-in approach > just like the external archivers. At the very least, it would need > a lot of testing to make sure it doesn't break existing installations. > > I'll get back with MARC and possibly GMane so I can try to make > things as general as is reasonable. I'll try to run a proposed > approach in front of the list before coding it (unless it's easy > enough to demonstrate the proposal via code). > > I think the only concern is that I think admins *would* find value > in per-list control of external archives. This is speculation, > though. As a webhosting company we would without a doubt find a lot of value in any per-list control. We already get quite a lot of requests for this or that customization that's not possible on a per list basis now. This particular feature would be great as many of our users are not happy with pipermail and it'd be nice to point them to a way to easily enable some other archiving solution. Right now, I just vaguely tell them how they might go about doing it themselves. Likewise, if we add support for some other archiver ourselves it'd be nice to not have to turn it on for all of the lists on the Mailman install at the same time. Moving lists between differently configured Mailman installs is an option, but this would be less work if it worked well. This has been an interesting discussion overall... Dallas From barry at python.org Fri May 13 02:57:41 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 12 May 2005 20:57:41 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <20050503084554.GC28586@rezo.net> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> <20050503084554.GC28586@rezo.net> Message-ID: <1115945860.20714.1.camel@geddy.wooz.org> On Tue, 2005-05-03 at 04:45, Fil wrote: > I would see it that way, in the "Archiving" section of admin : > > Archiving on a foreign system : > ------------------------------- > > prevent archiving on foreign systems yes [] no [x] > (adds a X-NO-Archive: header) You'd have to make clear that this would just be a hint to the foreign system, of course. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050512/485efb5a/attachment.pgp From barry at python.org Fri May 13 03:06:02 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 12 May 2005 21:06:02 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <83A1147E-FFE9-4146-94B7-C78429C03070@plaidworks.com> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <1115939710.32262.46.camel@geddy.wooz.org> <83A1147E-FFE9-4146-94B7-C78429C03070@plaidworks.com> Message-ID: <1115946362.20714.9.camel@geddy.wooz.org> On Thu, 2005-05-12 at 19:48, Chuq Von Rospach wrote: > Does archiving need to be integrated into > mailman in the first place? As opposed to, say, a place to specifiy > the URL of the archives for display? The key is that you have to know what value to insert into List-Archive. But it dovetails into a topic I've talked about before. I would love to have some way to calculate a unique archiving ID (more unique than Message-ID ) that two uncommunicative systems could use to calculate a url relative to List-Archive. Then Mailman could insert a header and/or footer text in the list copy that points to the message in the archive. > and since we've never really had the time/energy/etc to maintain and > enhance pipermail, maybe spliting the code out and retiring it is a > good strategy. I don't think so. Pipermail is fine for a large segment of the Mailman community. For them, having to do nothing to get an archive of your list has a lot of value. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050512/0d94d723/attachment.pgp From barry at python.org Fri May 13 03:18:44 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 12 May 2005 21:18:44 -0400 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <200505130046.j4D0kqr16941@glin.devaudio.com> References: <200505130046.j4D0kqr16941@glin.devaudio.com> Message-ID: <1115947124.20715.13.camel@geddy.wooz.org> On Thu, 2005-05-12 at 20:43, Jeff Marshall wrote: > I'll get back with MARC and possibly GMane so I can try to make things > as general as is reasonable. I'll try to run a proposed approach in > front of the list before coding it (unless it's easy enough to > demonstrate the proposal via code). Cool. > I think the only concern is that I think admins *would* find value in > per-list control of external archives. This is speculation, though. We can always take the simple approach first and see if people get motivated to request more. The nice thing about a site-wide only selection is that you don't have to expose any of this to the web u/i. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050512/32f7df1b/attachment.pgp From lists05 at equinephotoart.com Fri May 13 05:56:19 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Thu, 12 May 2005 20:56:19 -0700 Subject: [Mailman-Developers] [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <1115945860.20714.1.camel@geddy.wooz.org> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> <20050503084554.GC28586@rezo.net> <1115945860.20714.1.camel@geddy.wooz.org> Message-ID: <42842563.4010505@equinephotoart.com> Barry Warsaw wrote: >On Tue, 2005-05-03 at 04:45, Fil wrote: > > >>I would see it that way, in the "Archiving" section of admin : >> >> Archiving on a foreign system : >> ------------------------------- >> >> prevent archiving on foreign systems yes [] no [x] >> (adds a X-NO-Archive: header) >> >> > >You'd have to make clear that this would just be a hint to the foreign >system, of course. > Good point. It would probably be simpler and clearer to just say: Add "X-NO-Archive: Yes" header yes [] no [x] Do we need to explain what this header does (and doesn't) do, or could we assume that if the list owner doesn't know that they can google to find out? jc From barry at python.org Fri May 13 06:15:13 2005 From: barry at python.org (Barry Warsaw) Date: Fri, 13 May 2005 00:15:13 -0400 Subject: [Mailman-Developers] [Mailman-Developers] [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <42842563.4010505@equinephotoart.com> References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> <20050503084554.GC28586@rezo.net> <1115945860.20714.1.camel@geddy.wooz.org> <42842563.4010505@equinephotoart.com> Message-ID: <1115957713.20715.70.camel@geddy.wooz.org> On Thu, 2005-05-12 at 23:56, JC Dill wrote: > Do we need to explain what this header does (and doesn't) do, or could > we assume that if the list owner doesn't know that they can google to > find out? You could add more information in the option's details. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050513/a08bc820/attachment.pgp From msapiro at value.net Fri May 13 06:23:28 2005 From: msapiro at value.net (Mark Sapiro) Date: Thu, 12 May 2005 21:23:28 -0700 Subject: [Mailman-Developers] subject_prefix multiplication Message-ID: All of a sudden, within the last hour or so, subject_prefix on both mailman-users at python.org and mailman-developers at python.org is being added to replies even though it's already present resulting in doubling and tripling (so far not more) of the prefix. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Fri May 13 06:41:19 2005 From: barry at python.org (Barry Warsaw) Date: Fri, 13 May 2005 00:41:19 -0400 Subject: [Mailman-Developers] [Mailman-Developers] subject_prefix multiplication In-Reply-To: References: Message-ID: <1115959279.20712.83.camel@geddy.wooz.org> On Fri, 2005-05-13 at 00:23, Mark Sapiro wrote: > All of a sudden, within the last hour or so, subject_prefix on both > mailman-users at python.org and mailman-developers at python.org is being > added to replies even though it's already present resulting in > doubling and tripling (so far not more) of the prefix. Thanks for the quick heads up. I think I just fixed it. At least I /hope/ so, 'cause I'm going to bed. ;) will-test-a-few-follow-ups-to-be-sure-first-ly y'rs, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050513/6f6e7244/attachment.pgp From jwblist at olympus.net Fri May 13 07:24:17 2005 From: jwblist at olympus.net (John W. Baxter) Date: Thu, 12 May 2005 22:24:17 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <1115945860.20714.1.camel@geddy.wooz.org> Message-ID: On 5/12/05 5:57 PM, "Barry Warsaw" wrote: >> I would see it that way, in the "Archiving" section of admin : >> >> Archiving on a foreign system : >> ------------------------------- >> >> prevent archiving on foreign systems yes [] no [x] >> (adds a X-NO-Archive: header) > > You'd have to make clear that this would just be a hint to the foreign > system, of course. And change the naming. "Outside"? I can hear it now: "I ain't archiv'n my list with a bunch of furriners". :-) --John From stephen at xemacs.org Fri May 13 11:00:24 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 13 May 2005 18:00:24 +0900 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <1115946362.20714.9.camel@geddy.wooz.org> (Barry Warsaw's message of "Thu, 12 May 2005 21:06:02 -0400") References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <1115939710.32262.46.camel@geddy.wooz.org> <83A1147E-FFE9-4146-94B7-C78429C03070@plaidworks.com> <1115946362.20714.9.camel@geddy.wooz.org> Message-ID: <87u0l7lcuv.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "BAW" == Barry Warsaw writes: BAW> On Thu, 2005-05-12 at 19:48, Chuq Von Rospach wrote: >> Does archiving need to be integrated into mailman in the first >> place? As opposed to, say, a place to specifiy the URL of the >> archives for display? BAW> The key is that you have to know what value to insert into BAW> List-Archive. But you need that anyway---unless you use pipermail, Mailman can't know where your archives are until you tell it. So that doesn't argue against changing pipermail's interface to generic archive-by-mail, Mailman can still know where pipermail will put stuff. I see two problems with archive-by-mail, aside from "don't fix pipermail, which ain't broke". The first is that you have to be careful to set up that archive mail address to be secure, otherwise it's a back door for spam to get into your archive. This is going to be, uh, subtle for most of the users at least, I got bit. Even if we try to document it carefully I think this is FAQ-a-minute. The second was suggested by the "who owns X-No-Archive, anyway?" issue. If archiving is done by a special handler, it can have special logic to (attempt to) inhibit 3rd party archivers, it can respect X-No-Archive itself, and you can move it around in the pipeline if you need special effects. All of that is hard to do if it's hiding among the general memebership. NB, if the Archive handler supports the mail-to-archive protocol, then you don't have to worry about having an International Archiver Protocol with a World Archiver Organization to embargo archives who forget to obey X-No-Archive ... Mailman handles that. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From brad at stop.mail-abuse.org Fri May 13 11:05:19 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 13 May 2005 11:05:19 +0200 Subject: [Mailman-Developers] [Mailman-Users] subject_prefix multiplication In-Reply-To: <1115959279.20712.83.camel@geddy.wooz.org> References: <1115959279.20712.83.camel@geddy.wooz.org> Message-ID: At 12:41 AM -0400 2005-05-13, Barry Warsaw wrote: > Thanks for the quick heads up. I think I just fixed it. At least I > /hope/ so, 'cause I'm going to bed. ;) So far as I know, we had been running a plain-jane 2.1.6rc3 installation on this machine. Is the fix for the subject line duplication going to be included in 2.1.6rc4, or at least the final 2.1.6-REL? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From stephen at xemacs.org Fri May 13 11:25:18 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 13 May 2005 18:25:18 +0900 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <1115947124.20715.13.camel@geddy.wooz.org> (Barry Warsaw's message of "Thu, 12 May 2005 21:18:44 -0400") References: <200505130046.j4D0kqr16941@glin.devaudio.com> <1115947124.20715.13.camel@geddy.wooz.org> Message-ID: <87mzqzlbpd.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "BAW" == Barry Warsaw writes: BAW> The nice thing about a site-wide only selection is that you BAW> don't have to expose any of this to the web u/i. Uh, is that so "nice"? While I'm sure nobody has up to the minute stats lying around, my sense is that a lot of the traffic on mailman-users is from people using webhosting services. Cf Dallas's post for a webhoster's take. Dunno if you want to do anything nice for Cpanel, but wouldn't any features that reduced those FAQs would be worth considering? Note, I have no sense of what maintenance and support issues go with exposing formerly site-wide configs to listowners, so I can't take that into consideration---please forgive if this is a no-brainer. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From stephen at xemacs.org Fri May 13 13:15:40 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 13 May 2005 20:15:40 +0900 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <42842563.4010505@equinephotoart.com> (JC Dill's message of "Thu, 12 May 2005 20:56:19 -0700") References: <200504292211.j3TMBbr29010@glin.devaudio.com> <87pswcg0c7.fsf@tleepslib.sk.tsukuba.ac.jp> <3340FFD3-57BA-4CF7-923F-9CAA164F5A8A@plaidworks.com> <87u0lkbt7p.fsf@tleepslib.sk.tsukuba.ac.jp> <20050503084554.GC28586@rezo.net> <1115945860.20714.1.camel@geddy.wooz.org> <42842563.4010505@equinephotoart.com> Message-ID: <87zmuzjs0z.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "JC" == JC Dill writes: JC> Add "X-NO-Archive: Yes" header yes [] no [x] JC> Do we need to explain what this header does (and doesn't) do, JC> or could we assume that if the list owner doesn't know that JC> they can google to find out? It needs explanation. It's arguable that Mailman shouldn't add that header AFAIK, for one. So Mailman's rationale and caveats need to be presented. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From barry at python.org Fri May 13 14:05:13 2005 From: barry at python.org (Barry Warsaw) Date: Fri, 13 May 2005 08:05:13 -0400 Subject: [Mailman-Developers] [Mailman-Users] subject_prefix multiplication In-Reply-To: References: <1115959279.20712.83.camel@geddy.wooz.org> Message-ID: <1115985912.20963.36.camel@presto.wooz.org> On Fri, 2005-05-13 at 05:05, Brad Knowles wrote: > At 12:41 AM -0400 2005-05-13, Barry Warsaw wrote: > > > Thanks for the quick heads up. I think I just fixed it. At least I > > /hope/ so, 'cause I'm going to bed. ;) > > So far as I know, we had been running a plain-jane 2.1.6rc3 > installation on this machine. Is the fix for the subject line > duplication going to be included in 2.1.6rc4, or at least the final > 2.1.6-REL? Yes. And I emailed Tokio last night (well, a few hours ago which for me included the briefest of naps :) that I think we'll need one more release candidate. I'll probably spin that today, er, in a few hours. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050513/11e0fc72/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Fri May 13 14:14:42 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri, 13 May 2005 21:14:42 +0900 Subject: [Mailman-Developers] [Mailman-Users] subject_prefix multiplication In-Reply-To: <1115985912.20963.36.camel@presto.wooz.org> References: <1115959279.20712.83.camel@geddy.wooz.org> <1115985912.20963.36.camel@presto.wooz.org> Message-ID: <42849A32.7060003@is.kochi-u.ac.jp> Barry Warsaw wrote: > On Fri, 2005-05-13 at 05:05, Brad Knowles wrote: > >>At 12:41 AM -0400 2005-05-13, Barry Warsaw wrote: >> >> >>> Thanks for the quick heads up. I think I just fixed it. At least I >>> /hope/ so, 'cause I'm going to bed. ;) >> >> So far as I know, we had been running a plain-jane 2.1.6rc3 >>installation on this machine. Is the fix for the subject line >>duplication going to be included in 2.1.6rc4, or at least the final >>2.1.6-REL? > > > Yes. And I emailed Tokio last night (well, a few hours ago which for me > included the briefest of naps :) that I think we'll need one more > release candidate. I'll probably spin that today, er, in a few hours. > > -Barry I believe I could finally fix the bug and commited in CVS. IMHO, python re.escape() should escape special characters only -- I can't find '%' in special character list in the manual. -- Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Fri May 13 19:37:23 2005 From: barry at python.org (Barry Warsaw) Date: Fri, 13 May 2005 13:37:23 -0400 Subject: [Mailman-Developers] [Mailman-Users] subject_prefix multiplication In-Reply-To: <42849A32.7060003@is.kochi-u.ac.jp> References: <1115959279.20712.83.camel@geddy.wooz.org> <1115985912.20963.36.camel@presto.wooz.org> <42849A32.7060003@is.kochi-u.ac.jp> Message-ID: <1116005843.32405.78.camel@geddy.wooz.org> On Fri, 2005-05-13 at 08:14, Tokio Kikuchi wrote: > I believe I could finally fix the bug and commited in CVS. IMHO, python > re.escape() should escape special characters only -- I can't find '%' in > special character list in the manual. Cool. Sounds like a bug to me. I'll probably spin rc4 in about 7 hours. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050513/3173d686/attachment.pgp From jimmy at netatonce.se Sat May 14 15:11:17 2005 From: jimmy at netatonce.se (Jimmy Svensson) Date: Sat, 14 May 2005 15:11:17 +0200 Subject: [Mailman-Developers] Search members bug? Message-ID: <4285F8F5.6070300@netatonce.se> I'm using the latest release candidate of Mailman and have a problem with the search function. When the result from the search is more than could be viewed on one page the result is divided into several pages depending on the beginning character of the email address... but when I want to view the results from the search beginning with anything other than A (for example B) the search is forgotten and all members beginning with B is shown instead of the ones I searched for. The problem is that the links for the different characters only contain the get variable "letter" and not "findmember" which is the variable posted by the search form. Have anyone else had the same problem? Would be nice with a fix for this. /Jimmy Svensson From barry at python.org Sat May 14 16:46:18 2005 From: barry at python.org (Barry Warsaw) Date: Sat, 14 May 2005 10:46:18 -0400 Subject: [Mailman-Developers] Search members bug? In-Reply-To: <4285F8F5.6070300@netatonce.se> References: <4285F8F5.6070300@netatonce.se> Message-ID: <1116081977.20962.71.camel@presto.wooz.org> On Sat, 2005-05-14 at 09:11, Jimmy Svensson wrote: > I'm using the latest release candidate of Mailman and have a problem > with the search function. When the result from the search is more than > could be viewed on one page the result is divided into several pages > depending on the beginning character of the email address... but when I > want to view the results from the search beginning with anything other > than A (for example B) the search is forgotten and all members beginning > with B is shown instead of the ones I searched for. The problem is that > the links for the different characters only contain the get variable > "letter" and not "findmember" which is the variable posted by the search > form. > > Have anyone else had the same problem? Would be nice with a fix for this. JC Dill mentioned the same thing to me in private email. I looked at Mailman/Cgi/admin.py and it hasn't changed in a long time, so I'm wondering if this is just the way it worked or if something else broke "recently". Is this the first 2.1.6 release candidate you've tried, or have you been keeping up with the earlier development releases? When did you notice this breakage? If I have time this weekend, I'll see if I can look into it, but we're getting down to the wire with 2.1.6. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050514/c8fe2082/attachment.pgp From lists05 at equinephotoart.com Sat May 14 17:45:08 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Sat, 14 May 2005 08:45:08 -0700 Subject: [Mailman-Developers] Search members bug? In-Reply-To: <1116081977.20962.71.camel@presto.wooz.org> References: <4285F8F5.6070300@netatonce.se> <1116081977.20962.71.camel@presto.wooz.org> Message-ID: <42861D04.5050801@equinephotoart.com> Barry Warsaw wrote: >On Sat, 2005-05-14 at 09:11, Jimmy Svensson wrote: > > >>I'm using the latest release candidate of Mailman and have a problem >>with the search function. When the result from the search is more than >>could be viewed on one page the result is divided into several pages >>depending on the beginning character of the email address... but when I >>want to view the results from the search beginning with anything other >>than A (for example B) the search is forgotten and all members beginning >>with B is shown instead of the ones I searched for. The problem is that >>the links for the different characters only contain the get variable >>"letter" and not "findmember" which is the variable posted by the search >>form. >> >>Have anyone else had the same problem? Would be nice with a fix for this. >> >> > >JC Dill mentioned the same thing to me in private email. > Jimmy's bug report is different from mine. I was reporting the pagination - I hadn't seen letter-paginated search results for wild-card searches before. (I don't do them very often, so I don't know how long this has been the case.) Jimmy's bug is reporting something worse, not only are the results paginated but when you click on a letter to get the results starting with that letter, you don't GET the paginated results page for results starting with that letter. My report was about UI clumsiness (bad design), Jimmy's report is about something that is truly broken and not working as designed. Since the paginated results are broken, I suggest we try to fix both problems by generating the results on a single page (no pagination) or paginating by count (using the "maximum number of members per page" setting) rather than first letter. jc From msapiro at value.net Sat May 14 19:30:58 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat, 14 May 2005 10:30:58 -0700 Subject: [Mailman-Developers] Search members bug? In-Reply-To: <42861D04.5050801@equinephotoart.com> Message-ID: JC Dill wrote: > >Jimmy's bug report is different from mine. I was reporting the >pagination - I hadn't seen letter-paginated search results for wild-card >searches before. (I don't do them very often, so I don't know how long >this has been the case.) At least since 2.1.4 If the total number of hits is greater than admin_member_chunksize, results are paginated by letter. If you then click another letter, you get the full list for that letter, not the filtered list. You can then re-apply the find on that page and get the filtered list for that letter (only), but this is clearly not satisfactory. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Sat May 14 20:47:19 2005 From: barry at python.org (Barry Warsaw) Date: Sat, 14 May 2005 14:47:19 -0400 Subject: [Mailman-Developers] Search members bug? In-Reply-To: References: Message-ID: <1116096438.20963.86.camel@presto.wooz.org> On Sat, 2005-05-14 at 13:30, Mark Sapiro wrote: > At least since 2.1.4 I think unfortunately, we're going to have to postpone fixing this until after 2.1.6. We /really/ need to get this release out to fix the security issues. I'm going to cut another release candidate in a few minutes and barring any really severe breakage, this one will be the version we release (Tokio, we'll put off updating the GPL notices too). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050514/638b7f7c/attachment.pgp From lists05 at equinephotoart.com Sat May 14 21:01:00 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Sat, 14 May 2005 12:01:00 -0700 Subject: [Mailman-Developers] Search members bug? In-Reply-To: <1116096438.20963.86.camel@presto.wooz.org> References: <1116096438.20963.86.camel@presto.wooz.org> Message-ID: <42864AEC.8060707@equinephotoart.com> Barry Warsaw wrote: >On Sat, 2005-05-14 at 13:30, Mark Sapiro wrote: > > > >>At least since 2.1.4 >> >> > >I think unfortunately, we're going to have to postpone fixing this until >after 2.1.6. We /really/ need to get this release out to fix the >security issues. > OK. Can we document the search result work around in the release notes? jc From barry at python.org Sat May 14 21:46:10 2005 From: barry at python.org (Barry Warsaw) Date: Sat, 14 May 2005 15:46:10 -0400 Subject: [Mailman-Developers] Search members bug? In-Reply-To: <42864AEC.8060707@equinephotoart.com> References: <1116096438.20963.86.camel@presto.wooz.org> <42864AEC.8060707@equinephotoart.com> Message-ID: <1116099969.20964.94.camel@presto.wooz.org> On Sat, 2005-05-14 at 15:01, JC Dill wrote: > OK. Can we document the search result work around in the release notes? What's the workaround? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050514/8cf7af94/attachment.pgp From barry at python.org Sat May 14 22:50:54 2005 From: barry at python.org (Barry Warsaw) Date: Sat, 14 May 2005 16:50:54 -0400 Subject: [Mailman-Developers] Mailman 2.1.6 release candidate 4 Message-ID: <1116103854.20963.104.camel@presto.wooz.org> A few more last minute fixes and some language updates. Please let me know if you encounter any show stoppers. Barring any really critical bugs, this is going to be 2.1.6 final. -Barry https://sourceforge.net/project/shownotes.php?release_id=327367 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050514/a2eabf3e/attachment.pgp From jeff at jab.org Sat May 14 23:48:30 2005 From: jeff at jab.org (Jeff Breidenbach) Date: Sat, 14 May 2005 14:48:30 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <1115947124.20715.13.camel@geddy.wooz.org> (message from Barry Warsaw on Thu, 12 May 2005 21:18:44 -0400) References: <200505130046.j4D0kqr16941@glin.devaudio.com> <1115947124.20715.13.camel@geddy.wooz.org> Message-ID: Barry> In principle, I like more general solutions and hooks for Barry> extensibility than hard-coding in external dependencies like Barry> this. Like this? Since the Mailman UI is a bunch of HTML forms, put the GUI control for third party archiving on the internet. Configuration Categories * [General Options] * Passwords * Language options * Bounce processing * Membership Management... * Local archiving * Non-digest options * Third party archiving * Digest options * Mail<->News gateways List admin clicks on [Third party archiving], which is special hyperlink [1] that goes to a mailman controlled dynamic webpage, perhaps on or redirected through list.org. Third party archiving Archive the list publicly on The Mail Archive? [No] [Yes] Archive the list publicly on MARC? [No] [Yes] Set as primary archive? [None] [Mail-Archive] [MARC] [Submit Your Changes] When the user clicks on the submit button, the form POST goes back to the mailman GUI and sets the appropriate functionality. There are two main advantages to this approach. First, it provides a global deadman switch. Second, the feature gracefully degrades. The web page can can say "not implemented yet" or "feature disabled". It can hold manual instructions, honest to god tightly integrated GUI controls, or a combination of the above. Of course now the Mailman is kind of on the hook for keeping something up and running on the internet, which is kind of a pain. But as Lars said, this is something that archival services can help with. Cheers, Jeff [1] The hyperlink would be a little bit fancier than normal, and since it would need to embed some information about the location of the mailman installation. For example, if mailman was set up on foo.com, then $FORM_POST_URL would be the form submission location on foo.com, e.g.. http://foo.com/mailman/admin/list1/thirdpartyarchiving Third Party Archiving From jeff at jab.org Sat May 14 23:52:36 2005 From: jeff at jab.org (Jeff Breidenbach) Date: Sat, 14 May 2005 14:52:36 -0700 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: <1115947124.20715.13.camel@geddy.wooz.org> (message from Barry Warsaw on Thu, 12 May 2005 21:18:44 -0400) References: <200505130046.j4D0kqr16941@glin.devaudio.com> <1115947124.20715.13.camel@geddy.wooz.org> Message-ID: Dallas> As a webhosting company we would without a doubt find a lot of Dallas> value in any per-list control. We already get quite a lot of Dallas> requests for this or that customization that's not possible on Dallas> a per list basis now. This particular feature would be great Dallas> as many of our users are not happy with pipermail and it'd be Dallas> nice to point them to a way to easily enable some other Dallas> archiving solution. Dallas, would you consider applying the existing Sourceforge patch to your mailman installation? It is helpful to get feedback from real live users. John> And change the naming. "Outside"? I can hear it now: John> "I ain't archiv'n my list with a bunch of furriners". :-) How about "third party archiving" ? Brad> Unless, that is, you gateway to USENET news, in which case Google and Brad> others have news archives that you could not control and could Brad> not even be aware of in most cases. Google Groups honors "X-No-Archive: Yes" http://groups.google.com/googlegroups/posting_faq.html#prevent From brad at stop.mail-abuse.org Sat May 14 23:37:04 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat, 14 May 2005 23:37:04 +0200 Subject: [Mailman-Developers] Patch for Mail Archive mirroring In-Reply-To: References: <200505130046.j4D0kqr16941@glin.devaudio.com> <1115947124.20715.13.camel@geddy.wooz.org> Message-ID: At 2:52 PM -0700 2005-05-14, Jeff Breidenbach wrote: > Google Groups honors "X-No-Archive: Yes" Yes, but there are plenty of other gatewaying systems out there which may not. My point is that once the message leaves your control, there's not much you can do about what people do with it. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tkikuchi at is.kochi-u.ac.jp Sun May 15 05:46:12 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sun, 15 May 2005 12:46:12 +0900 Subject: [Mailman-Developers] Search members bug? In-Reply-To: <1116096438.20963.86.camel@presto.wooz.org> References: <1116096438.20963.86.camel@presto.wooz.org> Message-ID: <4286C604.3040804@is.kochi-u.ac.jp> Barry Warsaw wrote: > version we release (Tokio, we'll put off updating the GPL notices too). Agreed. And, sorry for the many typos I've committed. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From loisbert1 at aol.com Tue May 17 18:11:38 2005 From: loisbert1 at aol.com (loisbert1@aol.com) Date: Tue, 17 May 2005 12:11:38 -0400 Subject: [Mailman-Developers] (no subject) Message-ID: <8C729123D909C1B-B1C-34B35@mblk-r41.sysops.aol.com> Please get more off of this list server!!!!!!! NOW From barry at python.org Wed May 18 16:24:09 2005 From: barry at python.org (Barry Warsaw) Date: Wed, 18 May 2005 10:24:09 -0400 Subject: [Mailman-Developers] [Fwd: [ mailman-Bugs-1188133 ] CGI group id not properly tested] In-Reply-To: <5.1.0.14.2.20050518133521.00bdf0b0@127.0.0.1> References: <5.1.0.14.2.20050518133521.00bdf0b0@127.0.0.1> Message-ID: <1116426249.10675.1.camel@geddy.wooz.org> On Wed, 2005-05-18 at 09:49, Graham Klyne wrote: > This comment surprises me a little, as I am using postfix and I was > experiencing access-related problems. However, following my initial > installation, I did find that I had to change the file protection on the > alias files [*], otherwise I was unable to use Mailman to create new > mailing lists, so maybe that was my problem all along? (This being after > encountering the previous problem and applying the "patch".) Yes, you need to have both the aliases and the aliases.db file writable by group mailman, and group owned by mailman. However, additionally, the aliases.db file must be /user/ owned by mailman in order for Postfix to execute the scripts with the proper permissions. If that's not clear in the documentation (and enforced by check_perms) then you should file a bug report so we can make sure those issues are addressed. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050518/c49d9aef/attachment.pgp From mcn4 at leicester.ac.uk Thu May 19 12:58:31 2005 From: mcn4 at leicester.ac.uk (Matthew Newton) Date: Thu, 19 May 2005 11:58:31 +0100 Subject: [Mailman-Developers] Storing other data in the list object Message-ID: <20050519105831.GC18476@ultra.le.ac.uk> Hi, The Mailman system I'm putting together has lists automatically created/deleted depending on another database (i.e. the university database defines what lists exist, and who owns them, and Mailman should then match this). I need to be able to store information about when the list was created (this is used in the synchronization procedure). I could save this in another text file, but that is something else to go wrong / get out of synch. Therefore, is the following safe to do, (assuming I use a variable that is unlikely to be used by Mailman itself)? Is there a place I should be using instead of this (i.e. a dictionary in the object called "localdata")? m = MailList.MailList(listname, lock=1) m.uol_createddate = "something" m.Save() m.Unlock() Thanks! Matthew -- Matthew Newton UNIX and e-mail Systems Administrator, Network Support Section, Computer Centre, University of Leicester, Leicester LE1 7RH, United Kingdom From barry at python.org Thu May 19 15:17:48 2005 From: barry at python.org (Barry Warsaw) Date: Thu, 19 May 2005 09:17:48 -0400 Subject: [Mailman-Developers] Storing other data in the list object In-Reply-To: <20050519105831.GC18476@ultra.le.ac.uk> References: <20050519105831.GC18476@ultra.le.ac.uk> Message-ID: <1116508667.10062.3.camel@presto.wooz.org> On Thu, 2005-05-19 at 06:58, Matthew Newton wrote: > I need to be able to store information about when the list was created > (this is used in the synchronization procedure). I could save this in > another text file, but that is something else to go wrong / get out of > synch. Therefore, is the following safe to do, (assuming I use a > variable that is unlikely to be used by Mailman itself)? Is there a > place I should be using instead of this (i.e. a dictionary in the object > called "localdata")? > > m = MailList.MailList(listname, lock=1) > m.uol_createddate = "something" > m.Save() > m.Unlock() Yes, it is safe to do, if you pick the right attribute names. I suggest using something like m.x_my_special_thing as the name (i.e. I hereby guarantee that Mailman will not use names that start with 'x_'). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050519/2fb41efa/attachment.pgp From carl at fink.to Fri May 20 03:12:18 2005 From: carl at fink.to (Carl Fink) Date: Thu, 19 May 2005 21:12:18 -0400 Subject: [Mailman-Developers] Plugin architecture? If not, suggestions on extending functionality? Message-ID: <20050520011218.GA18069@nitpicking.com> Hi. I'm running mailing lists for a nonprofit organization. We'd like to create a customized newsletter. The idea is that subscribers would visit a configuration page, and check off the topics that they're interested in. Then, monthly or so, a customized newsletter would be generated for each subscriber and mailed out. Since I'm already administering a Mailman server, it struck me that extending Mailman was the way to go. I'm only slightly familiar with Python, but it would be my seventh or eighth language, so that doesn't intimidate me. What I'd like to do is write a plugin. However, I have been unable to find a description of a Mailman plugin API in dozens of web searches using multiple engines. I find *references* to such an API going back four years, but no actual documentation of one. So: does the current Mailman support plugins? If not, what do you, the Mailman developers, think of extending the package to support custom newsletters? Any suggestions on where to start? Thanks for reading. -- Carl Fink postmaster at iconsf.org I-Con System Administrator and Postmaster From msapiro at value.net Fri May 20 03:36:15 2005 From: msapiro at value.net (Mark Sapiro) Date: Thu, 19 May 2005 18:36:15 -0700 Subject: [Mailman-Developers] Plugin architecture? If not, suggestions on extending functionality? In-Reply-To: <20050520011218.GA18069@nitpicking.com> Message-ID: Carl Fink wrote: > >So: does the current Mailman support plugins? If not, what do you, the >Mailman developers, think of extending the package to support custom >newsletters? Any suggestions on where to start? It "sort of" supports plugins for list membership management, but not for message customization. What you are looking for is customer relationship/email campaign management software. Mailman is not intended to be used in that way, and trying to make it so is likely to be difficult and not very successful. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From Dale at Newfield.org Fri May 20 09:03:24 2005 From: Dale at Newfield.org (Dale Newfield) Date: Fri, 20 May 2005 00:03:24 -0700 Subject: [Mailman-Developers] Plugin architecture? If not, suggestions on extending functionality? In-Reply-To: <20050520011218.GA18069@nitpicking.com> References: <20050520011218.GA18069@nitpicking.com> Message-ID: <428D8BBC.2040501@Newfield.org> Carl Fink wrote: > What I'd like to do is write a plugin. However, I have been unable to > find a description of a Mailman plugin API While I agree with the previous poster that Mailman may not be the tool you're looking for, the answer to your question is: The place in mailman to look is at the pipeline module. What it sounds to me that you are describing is a pipeline step that does much more customization to the message at fan-out time. Look at the VERP stuff... -Dale From jean-philippe.giola at st.com Wed May 25 09:51:49 2005 From: jean-philippe.giola at st.com (Jean-Philippe GIOLA) Date: Wed, 25 May 2005 09:51:49 +0200 Subject: [Mailman-Developers] mbox archive Message-ID: <42942E95.1040804@st.com> Hi all! I want to know when the mbox archive is created for a list (in archives/private/listname.mbox/listname.mbox) /I have still ask this question in the mailman-users list but noboby has answer me... /reguards./ / -- Jean-Philippe Giola - 6577 From barry at python.org Wed May 25 13:06:15 2005 From: barry at python.org (Barry Warsaw) Date: Wed, 25 May 2005 07:06:15 -0400 Subject: [Mailman-Developers] mbox archive In-Reply-To: <42942E95.1040804@st.com> References: <42942E95.1040804@st.com> Message-ID: <1117019175.16104.644.camel@presto.wooz.org> On Wed, 2005-05-25 at 03:51, Jean-Philippe GIOLA wrote: > I want to know when the mbox archive is created for a list (in > archives/private/listname.mbox/listname.mbox) When the first message to the list is posted. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050525/07e5a6aa/attachment.pgp From bv at opera.com Wed May 25 15:08:57 2005 From: bv at opera.com (=?iso-8859-15?Q?Bj=F8rn_Vermo?=) Date: Wed, 25 May 2005 15:08:57 +0200 Subject: [Mailman-Developers] Suspending subscribers on vacation? Message-ID: It is a problem that some people think it is cool to automatically generate "out of office" messages when they are away, especially when they are subscribed to high-volume lists. Is there an easy way to have Mailman temporarily unsubscribe them when it receives one of those messages? -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From msapiro at value.net Wed May 25 15:32:25 2005 From: msapiro at value.net (Mark Sapiro) Date: Wed, 25 May 2005 06:32:25 -0700 Subject: [Mailman-Developers] mbox archive In-Reply-To: <42942E95.1040804@st.com> Message-ID: Jean-Philippe GIOLA wrote: > >I want to know when the mbox archive is created for a list (in >archives/private/listname.mbox/listname.mbox) > >/I have still ask this question in the mailman-users list but noboby has >answer me... I answered you. See http://mail.python.org/pipermail/mailman-users/2005-May/044824.html -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Mon May 30 22:07:34 2005 From: barry at python.org (Barry Warsaw) Date: Mon, 30 May 2005 16:07:34 -0400 Subject: [Mailman-Developers] Min requirements for running Mailman? In-Reply-To: <1094741310.29998.20.camel@angua.localnet> References: <9B66BBD37D5DD411B8CE00508B69700F05ADE362@pborolocal.rnib.org.uk> <1094740291.348.321.camel@finch.boston.redhat.com> <1094741310.29998.20.camel@angua.localnet> Message-ID: <1117483654.4385.118.camel@geddy.wooz.org> On Thu, 2004-09-09 at 10:48, Nigel Metheringham wrote: > Am I right in thinking that 2.1.5 does not have backward compatibility > with 2.0.x versions, so it is not possible to directly upgrade a 2.0.x > to 2.1.x? It should be possible, but it's not something I've tested in a very long tim.e > I was certainly unable to take lists to 2.1.5 when I tried recently on > full system upgrade - I ended up recreating the lists with significant > pain involved. Can you provide details? I consider it a bug that lists cannot be upgrade from 2.0.13 to 2.1.6. You might need to upgrade from 2.0.x where x < 13, to 2.0.13 first though. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050530/f57e9bb9/attachment.pgp From msapiro at value.net Mon May 30 22:54:38 2005 From: msapiro at value.net (Mark Sapiro) Date: Mon, 30 May 2005 13:54:38 -0700 Subject: [Mailman-Developers] Min requirements for running Mailman? In-Reply-To: <1117483654.4385.118.camel@geddy.wooz.org> Message-ID: Barry Warsaw wrote: > >On Thu, 2004-09-09 at 10:48, Nigel Metheringham wrote: > >> I was certainly unable to take lists to 2.1.5 when I tried recently on >> full system upgrade - I ended up recreating the lists with significant >> pain involved. > >Can you provide details? I consider it a bug that lists cannot be >upgrade from 2.0.13 to 2.1.6. You might need to upgrade from 2.0.x >where x < 13, to 2.0.13 first though. There have been reports on the mailman-users list of difficulties in moving/upgrading lists from older versions. After grappling with these issues in my own mind, I have concluded that the likely explanation is not that the new Mailman can't update the old list's config.db, but rather that the marshal format of the old lists config.db is not compatible with the Python on the new system. Does this seem reasonable, or am I off track here. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From Nigel.Metheringham at dev.intechnology.co.uk Mon May 30 23:22:46 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 30 May 2005 22:22:46 +0100 Subject: [Mailman-Developers] Min requirements for running Mailman? In-Reply-To: <1117483654.4385.118.camel@geddy.wooz.org> References: <9B66BBD37D5DD411B8CE00508B69700F05ADE362@pborolocal.rnib.org.uk> <1094740291.348.321.camel@finch.boston.redhat.com> <1094741310.29998.20.camel@angua.localnet> <1117483654.4385.118.camel@geddy.wooz.org> Message-ID: <1117488166.5353.4.camel@angua.localnet> On Mon, 2005-05-30 at 16:07 -0400, Barry Warsaw wrote: > On Thu, 2004-09-09 at 10:48, Nigel Metheringham wrote: One of us is in a timewarp here.... > > Am I right in thinking that 2.1.5 does not have backward compatibility > > with 2.0.x versions, so it is not possible to directly upgrade a 2.0.x > > to 2.1.x? > > It should be possible, but it's not something I've tested in a very long > tim.e > > > I was certainly unable to take lists to 2.1.5 when I tried recently on > > full system upgrade - I ended up recreating the lists with significant > > pain involved. > > Can you provide details? I consider it a bug that lists cannot be > upgrade from 2.0.13 to 2.1.6. You might need to upgrade from 2.0.x > where x < 13, to 2.0.13 first though. This is 9 months ago... so my memory is not as good as it should be. However if I remember rightly it was down to features that were added during the 2.1.x series with a related change in database format. You can do 2.0.13 -> 2.1.x where x <= 3 (from memory), but not direct to 2.1.5 [This is probably worth looking at because I see a significant number of sites still on 2.0.x unfortunately]. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From barry at python.org Tue May 31 15:02:10 2005 From: barry at python.org (Barry Warsaw) Date: Tue, 31 May 2005 09:02:10 -0400 Subject: [Mailman-Developers] RELEASED Mailman 2.1.6 Message-ID: <1117544530.4380.166.camel@geddy.wooz.org> On behalf of the development team, I'm pleased to announce the release of GNU Mailman 2.1.6. This is a significant release, which includes three important security patches, updated Chinese (zh_TW and zh_CN) support, better compatibility with Python 2.4, a few new features, and many bug fixes. Mailman is free software for managing email mailing lists and e-newsletters. This release fixes CAN-2005-0202, a reported vulnerability in path traversal in the private archive script. This release also provides an option for sites to produce more cryptographically secure auto-generated passwords, and it closes a potential cross-site scripting hole. Because of the security (and other) fixes, it is highly recommended that all sites upgrade to 2.1.6. For more information, please see: http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman On a personal note, I owe a debt of gratitude to Tokio Kikuchi, who served as release manager for 2.1.6, integrated countless patches, and coordinated the Chinese language updates for this release. Please join me in thanking him for helping out so much. For links to download the Mailman 2.1.6 source tarball, see: http://sourceforge.net/project/showfiles.php?group_id=103 Enjoy, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050531/635fab8e/attachment.pgp From barry at python.org Tue May 31 23:48:32 2005 From: barry at python.org (Barry Warsaw) Date: Tue, 31 May 2005 17:48:32 -0400 Subject: [Mailman-Developers] Min requirements for running Mailman? In-Reply-To: References: Message-ID: <1117576112.12683.15.camel@geddy.wooz.org> On Mon, 2005-05-30 at 16:54, Mark Sapiro wrote: > There have been reports on the mailman-users list of difficulties in > moving/upgrading lists from older versions. After grappling with these > issues in my own mind, I have concluded that the likely explanation is > not that the new Mailman can't update the old list's config.db, but > rather that the marshal format of the old lists config.db is not > compatible with the Python on the new system. > > Does this seem reasonable, or am I off track here. I think it's possible, but I'm not sure this is the real problem. OT1H, marshal is not guaranteed to be portable across Python versions (which is one reason we use pickle now). I searched through Python's NEWS and HISTORY files and while I did see a few changes to marshal mentioned, they aren't changes that I think would have affected Mailman's data files. OTOH, it's possible that changes did occur that are biting us. However, I just tried to store a dictionary that contained just strings, floats, and ints. Created the file under Python 2.1.3 and read it back with Python 2.4.1 and had no problems. That doesn't necessarily mean we're safe, but it makes it less likely that this is the problem. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050531/b9592b1c/attachment.pgp From barry at python.org Tue May 31 23:50:26 2005 From: barry at python.org (Barry Warsaw) Date: Tue, 31 May 2005 17:50:26 -0400 Subject: [Mailman-Developers] Min requirements for running Mailman? In-Reply-To: <1117488166.5353.4.camel@angua.localnet> References: <9B66BBD37D5DD411B8CE00508B69700F05ADE362@pborolocal.rnib.org.uk> <1094740291.348.321.camel@finch.boston.redhat.com> <1094741310.29998.20.camel@angua.localnet> <1117483654.4385.118.camel@geddy.wooz.org> <1117488166.5353.4.camel@angua.localnet> Message-ID: <1117576226.12684.18.camel@geddy.wooz.org> On Mon, 2005-05-30 at 17:22, Nigel Metheringham wrote: > This is 9 months ago... so my memory is not as good as it should be. The hazards of cleaning out a big inbox (on my part ;). > However if I remember rightly it was down to features that were added > during the 2.1.x series with a related change in database format. > > You can do 2.0.13 -> 2.1.x where x <= 3 (from memory), but not direct to > 2.1.5 Okay, I'll see if I can try this. > [This is probably worth looking at because I see a significant number of > sites still on 2.0.x unfortunately]. Yeah, it'll be that way forever. Thanks, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050531/acf3a29e/attachment.pgp