From gsstark at mit.edu Fri Apr 2 13:51:39 2004 From: gsstark at mit.edu (Greg Stark) Date: Fri Apr 2 13:51:45 2004 Subject: [Mailman-Developers] Happy Mailman Reminder Day Message-ID: <87d66qkybo.fsf@stark.xeocode.com> I forgot to wish all a happy Mailman Reminder Day yesterday. Do these reminders not bother everyone else? Getting a few dozen of these once a month used to really piss me off. I long since sent them to my spam folder but just on principle whoever decided these should be enabled by default ought to be first against the wall when the revolution comes. -------------- next part -------------- Skipped content of type multipart/digest-------------- next part -------------- -- greg From dj at donherring.com Fri Apr 2 14:40:59 2004 From: dj at donherring.com (Don Herring) Date: Fri Apr 2 14:40:50 2004 Subject: [Mailman-Developers] Changing the Domain Name Message-ID: I am trying to set up a list and have been able to get mailman to use the proper external domain name for the email address but not for the links to the unsubscribe page, admin page etc it includes in the emails. Mailman insist on using an internal name server.domain.com instead of the external name lists.domain.com (domain.com is used for example purposes only). Does anyone know how to change this setting? From fmouse at fmp.com Thu Apr 1 14:45:39 2004 From: fmouse at fmp.com (Lindsay Haisley) Date: Fri Apr 2 14:44:49 2004 Subject: [Mailman-Developers] Submitted courier-to-mailman script Message-ID: <1080848739.14861.6.camel@vishnu.fmp.com> I used the mailman patch-manager at sourceforge to upload a list submission handler, courier-to-mailman.py, to handle list submissions and control messages under Courier virtual domains. It's based on Bruce Perens' qmail-to-mailman script, but is updated for mailman v2 and modified to work with the Courier MTA. You may want to include it in the contrib directory of the mailman source distribution. -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | http://www.fmp.com | | From jack.bradach at oregonstate.edu Thu Apr 1 13:42:19 2004 From: jack.bradach at oregonstate.edu (Bradach, Jack) Date: Fri Apr 2 14:45:17 2004 Subject: [Mailman-Developers] Question about changing the "reply-to" address on the mailman list. Message-ID: <2B8B2BD3A0D58F41B0F28F215AF4901D763893@mtadams.nws.oregonstate.edu> Hello, I'm the list support person for my university, and I had a question about change I'm considering making to the "mailman" list on our site. We have monthly password reminders enabled by default and the message that gets sent out starts with "DO NOT REPLY TO THIS MESSAGE... Here's how to unsubscribe if you don't want to be on such and such list." The problem is that a large number of the people every month don't bother reading the mail and instead reply to mailman-owner with "unsubscribe," usually without leaving the original message intact, so I've got to go in and look at the headers and manually remove them from whatever list they were on. My plan is to set the "reply-to" address on mailman to be "DONOTREPLY@OREGONSTATE.EDU," so that people sending to the list will just have it uncerimoniously bounced back, hopefully forcing them to reread the message, or setting it to another list which auto-responds with "Read this this time." As far as I know, the only mail that gets sent from the mailman list itself are the monthly reminders and the notices it sends me when people attempt to subscribe to the list. Am I missing something that will break if I do this? Does anyone have a better solution? (Being able to set the address the reminders come from would be a cool feature, btw.) Thanks for the info. - Jack Bradach Jack.Bradach@oregonstate.edu Oregon State University jack|w on irc.freenode.net From fil at rezo.net Fri Apr 2 14:48:49 2004 From: fil at rezo.net (Fil) Date: Fri Apr 2 14:49:03 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: Message-ID: <20040402194848.GC30772@rezo.net> > Is there any way to setup mailman to stop distributing X-Confirm-Reading- > To requests sent by some list users? I would do it inside postfix header_checks filters, with a line like /^X-Confirm-Reading-To: / IGNORE If you're using some other MTA, or want this setting to be only for Mailman, I don't know. -- Fil From mike at UDel.Edu Fri Apr 2 14:51:42 2004 From: mike at UDel.Edu (Mike Porter) Date: Fri Apr 2 14:51:51 2004 Subject: [Mailman-Developers] Cloning listsZ In-Reply-To: <86r7w0fb16.fsf@kamino.rfc1149.org> References: <98771DD908470C49AF3B579BEEF1C199F780FF@njexchange.imany.com> <86r7w0fb16.fsf@kamino.rfc1149.org> Message-ID: Make the new list, then perhaps use config_list to dump the variables of the list to clone from, make changes, and then import into the new list, making the new list look a lot like the old list? - Mike Porter PGP Fingerprint: F4 AE E1 9F 67 F7 DA EA 2F D2 37 F3 99 ED D1 C2 On Thu, 11 Mar 2004, Arne Schwabe wrote: > Scott Hardy writes: > > > Does anyone know if it is possible to clone a list instead of manually > > creating each one from scratch? > > I think I will write a little python skript to achieve soon if there > is nothing like that. (where soon means < 1 month) > > Arne > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/mike%40udel.edu > From dgc at uchicago.edu Fri Apr 2 15:28:16 2004 From: dgc at uchicago.edu (David Champion) Date: Fri Apr 2 15:28:50 2004 Subject: [Mailman-Developers] Re: Cloning listsZ In-Reply-To: References: <98771DD908470C49AF3B579BEEF1C199F780FF@njexchange.imany.com> <86r7w0fb16.fsf@kamino.rfc1149.org> Message-ID: <20040402202816.GM14052@dust.uchicago.edu> * On 2004.04.02, in , * "Mike Porter" wrote: > Make the new list, then perhaps use config_list to dump the > variables of the list to clone from, make changes, and then import > into the new list, making the new list look a lot like the old > list? The last time I needed to do this, it was possible just to copy the contents of .../lists/[listname] to .../lists/[newlistname] -- config.db and all. I haven't played with an installation that has config_list, but making some basic assumptions, that seems workable, too. However you'll need the associated templates and digest index file and so on, too. And don't forget to copy the archives, if that applies. Users tend to get annoyed by that, but only after enough time has passed to make it harder to do right. -- -D. dgc@uchicago.edu NSIT University of Chicago From brad.knowles at skynet.be Fri Apr 2 15:01:54 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Apr 2 18:10:38 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: Message-ID: At 6:53 PM -0600 2004/03/21, Andrzej Kasperowicz wrote: > Is there any way to setup mailman to stop distributing X-Confirm-Reading- > To requests sent by some list users? Depending on your MTA, you could configure it to remove various types of headers on incoming messages. However, I'm not aware of any way to do this within Mailman. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From andyk at spunge.org Fri Apr 2 18:41:34 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Fri Apr 2 18:41:50 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: Message-ID: <406E164E.24075.26E5A05@localhost> > At 6:53 PM -0600 2004/03/21, Andrzej Kasperowicz wrote: > > > Is there any way to setup mailman to stop distributing X-Confirm-Reading- > > To requests sent by some list users? > > Depending on your MTA, you could configure it to remove various > types of headers on incoming messages. However, I'm not aware of any > way to do this within Mailman. Well, that's too bad. I've already given an example that in another mailing list program it is possible to do it: http://mail.python.org/pipermail/mailman-developers/2004-March/016713.html ak From jwblist at olympus.net Fri Apr 2 20:42:48 2004 From: jwblist at olympus.net (John W. Baxter) Date: Fri Apr 2 20:43:06 2004 Subject: [Mailman-Developers] message filters - how to define regex string which allowes any mail address In-Reply-To: <406999F4.7020901@itt.nu> Message-ID: On 3/30/2004 8:01, "lp" wrote: > If anyone knows the regex string that defines "any" mail address > reagrdless of what stands before and after "@", please give me an exact > example of the string. Well, the first edition of "Mastering Regular Expressions" by Jeffrey E. F. Friedl (spelled correctly) had such a regular expression in small print occupying a full page near the back. [He developed pieces of it in various parts of the book.] It had a bug, so there was a correct version at O'Reilly's site in the book's errata area. Unfortunately, the book is now in its second edition, and Mr. Friedl seems to have left the bug out of that regular expression, so it isn't in the current errata and I can't point it out to you. Check a bookstore with a good O'Reilly selection or a library...the book should be available in one or the other of those places so you can enjoy the RE. You probably don't want to use the regular expression. --John From brad.knowles at skynet.be Fri Apr 2 22:10:30 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri Apr 2 22:12:02 2004 Subject: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <406DB7B3.30627.BC9FC1@localhost> References: <406DB7B3.30627.BC9FC1@localhost> Message-ID: At 6:57 PM -0800 2004/04/02, Lloyd F. Tennison wrote: > What makes you think it is Mailman? It does not exist on any of my > lists, nor does it exist on the lists I receive from others - including > this list. (View this source.) Check you MTA. Maybe that is what is > doing it. If Mailman is doing it it is somewhere not mentioned in the > documentation and does not do it in all setups. The problem that the OP is complaining about is that some other member of the list posted a message containing that header, and Mailman did not strip it out. As a result, this header was passed unchanged to the recipients of the list, which could expose the privacy of the users who received the message but who are not publicly advertised as being members of the list (you can control whether or not your subscription is publicly visible). If the recipient MUA supported this header, then the original poster to the list could get responses back from a wide variety of people, with potentially damaging consequences. Imagine if the list were an online rape support group, and the person posting was a serial rapist, perhaps posing as someone else. They could easily get a list of potentially vulnerable targets which they could then go after, at least of the people who would be running the common MUA that recognizes this header, and are not computer savvy-enough to know how to turn this "feature" off. That would tend to make them even better potential targets, and those are the only ones a potential serial rapist would be likely to be interested in anyway. It was probably just a spammer going out of their way to gather more mailing addresses for the mill, but I think you must concede the potential security weakness here. In this case, the weakness is not the fault of Mailman. The weakness is the fault of the damn bloody stupid MUA and the criminally incompetent company that wrote it. However, since this is something that Mailman could potentially have protected against, people will expect that Mailman *must* do so, because we all know damn good and well that the unnamed company will never do anything useful when it comes to computer security. Myself, I can see this becoming a slippery slope, and I'm not sure we'd want to go down that route. On the other hand, I can understand why some mailing list admins might insist on this feature. I'm beginning to think that Mailman should strip all incoming headers down to the bare minimum (leave "From:", "Subject:", "Cc:", "Received:", and that's about it), at least by default. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From terri at zone12.com Sat Apr 3 02:24:18 2004 From: terri at zone12.com (Terri Oda) Date: Sat Apr 3 02:24:46 2004 Subject: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: <406DB7B3.30627.BC9FC1@localhost> Message-ID: > I'm beginning to think that Mailman should strip all incoming headers > down to the bare minimum (leave "From:", "Subject:", "Cc:", > "Received:", and that's about it), at least by default. At least making this an option would make quite a few people happy, I imagine, although a more configurable strip-these-headers/keep-these-headers might be better. From brad.knowles at skynet.be Sat Apr 3 04:46:15 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Apr 3 04:46:57 2004 Subject: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: <406DB7B3.30627.BC9FC1@localhost> Message-ID: At 2:24 AM -0500 2004/04/03, Terri Oda wrote: > At least making this an option would make quite a few people happy, I > imagine, although a more configurable strip-these-headers/ > keep-these-headers might be better. Okay, add a "strip-these-headers/keep-these-headers" option, but by default select "keep-these-headers", and pre-fill in the minimum. How's that? ;-) -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From andyk at spunge.org Sat Apr 3 08:01:20 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sat Apr 3 08:01:24 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: <406DB7B3.30627.BC9FC1@localhost> Message-ID: <406ED1C0.2171.32A0BE@localhost> > the common MUA that recognizes this header, and are not computer > savvy-enough to know how to turn this "feature" off. That would tend The person who complained about it to me, was able to turn it off, but he didn't want to do so, claiming that he needs it sometimes to inform people writing to him in private that he read their e-mails. He is using The Bat, and he set it that way, that it was poping up a window telling him that someone sent an e-mail with x-confirm-reading, and he should either accept it (send a confirming message) or deny it. He claimed that list-owners should configure their mailing list programs to remove that kind of headers, that it should be within their basic tasks to do when configuring a list. Well, I couldn't argue much with that. There should be indeed such a feature in Mailman like it is in ecartis: a form where could be set colon separated headers to be removed from outgoing messages: http://znik.wbc.lublin.pl/~ak/rozne/ecartis/freelists_config.gif Regerding MTA. I'm not the admin of the server, and I have no acccess to it. Besides, I don't think it would be a good thing to do it on MTA level (other people could complain...), it should be possible to do within Mailman by list-owners. ak From carbonnb at sympatico.ca Sat Apr 3 09:43:51 2004 From: carbonnb at sympatico.ca (Bryan Carbonnell) Date: Sat Apr 3 09:43:57 2004 Subject: (Fwd) Re: [Mailman-Users] Re: [Mailman-Developers] How to rem Message-ID: <406E8757.21122.2A68F0@localhost> OOPS, Should have gone to the list and not Brad directly. Sorry Brad. ------- Forwarded message follows ------- From: Bryan Carbonnell On 3 Apr 2004 at 11:46, Brad Knowles wrote: > At 2:24 AM -0500 2004/04/03, Terri Oda wrote: > > > At least making this an option would make quite a few people > > happy, I imagine, although a more configurable > > strip-these-headers/ keep-these-headers might be better. > > Okay, add a "strip-these-headers/keep-these-headers" option, but by > default select "keep-these-headers", and pre-fill in the minimum. Why not just have a list of UserDefined RegEx's of headers to strip? Kind of like the Spam Filtering Rules in Mailman. That way BArry won't get "Well why can you strip header x, but not header y?" If you go with keep these/strip these, I'd vote for keeping everything and let the admin HAVE to make the change for themselves. Don't the RFCs say not to mess with the headers if possible? Or something like that? -- Bryan Carbonnell - carbonnb@sympatico.ca Out of my mind. Back in five minutes. -- Bryan Carbonnell - carbonnb@sympatico.ca The man who claims to be the boss in his own home will lie about other things as well. From brad.knowles at skynet.be Sat Apr 3 14:45:23 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Apr 3 16:28:49 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <406ED1C0.2171.32A0BE@localhost> References: <406DB7B3.30627.BC9FC1@localhost> <406ED1C0.2171.32A0BE@localhost> Message-ID: At 3:01 PM +0200 2004/04/03, Andrzej Kasperowicz wrote: > He claimed that > list-owners should configure their mailing list programs to remove that > kind of headers, that it should be within their basic tasks to do when > configuring a list. I disagree. I've been running mailing lists for more than ten years. This is not a basic task for any mailing list administrator. This is an advanced issue that very few mailing list administrators (should) need to have to deal with. This is part of why very few mailing lists have the built-in ability to strip arbitrary headers. > Well, I couldn't argue much with that. I can. > There should > be indeed such a feature in Mailman like it is in ecartis: a form where > could be set colon separated headers to be removed from outgoing > messages: > http://znik.wbc.lublin.pl/~ak/rozne/ecartis/freelists_config.gif We are not going to take every single bloody feature of ecartis and re-implement that in Mailman. If you want ecartis, then use it. Otherwise, you're welcome to continue using Mailman. > Regerding MTA. I'm not the admin of the server, and I have no acccess to > it. Besides, I don't think it would be a good thing to do it on MTA level > (other people could complain...), it should be possible to do within > Mailman by list-owners. Indeed, many MTAs don't have this ability, either. This just isn't a standard feature that you will find in mail or mailing list systems. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From brad.knowles at skynet.be Sat Apr 3 14:51:50 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Apr 3 16:28:54 2004 Subject: (Fwd) Re: [Mailman-Users] Re: [Mailman-Developers] How to rem In-Reply-To: <406E8757.21122.2A68F0@localhost> References: <406E8757.21122.2A68F0@localhost> Message-ID: At 9:43 AM -0500 2004/04/03, Bryan Carbonnell wrote: > Why not just have a list of UserDefined RegEx's of headers to strip? Because most people don't properly understand regular expressions. Since you can do the same thing in a different way and have Mailman build the proper regular expressions based on user input, it seems pretty obvious what the correct solution is. > Kind of like the Spam Filtering Rules in Mailman. That way BArry > won't get "Well why can you strip header x, but not header y?" If you have a "keep-these-headers/strip-these-headers" option, then there shouldn't be any headers that either can't be stripped or kept, depending on your particular type of choice. > If you go with keep these/strip these, I'd vote for keeping > everything and let the admin HAVE to make the change for themselves. IMO, we should default to safety. > Don't the RFCs say not to mess with the headers if possible? Or > something like that? The RFCs regarding mail are intended primarily for MTAs and MUAs, not mailing list management systems. Moreover, they make it clear that you can add headers, but you can't change them, and under certain circumstances you can remove them. Since the MLM is a gateway system of sorts, there is more freedom with regards to what the authors are allowed to do. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From andyk at spunge.org Sat Apr 3 18:23:48 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sat Apr 3 18:23:54 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: <406ED1C0.2171.32A0BE@localhost> Message-ID: <406F63A4.21145.26C8272@localhost> > I disagree. I've been running mailing lists for more than ten > years. This is not a basic task for any mailing list administrator. > This is an advanced issue that very few mailing list administrators > (should) need to have to deal with. This is part of why very few > mailing lists have the built-in ability to strip arbitrary headers. I'd be glad if you could explain it to him, as he apparently was offended, because I didn't do it, and he's not a newbe in internet, I've seen him on-line for about 9-10 years. > We are not going to take every single bloody feature of ecartis Of course not, but what is wrong in taking every good, useful feature? > and re-implement that in Mailman. If you want ecartis, then use it. > Otherwise, you're welcome to continue using Mailman. Now, come on Brad! I've just presented to Mailman community 3 interesting IMHO featueres, which ecartis have, and Mailman haven't got, thus suggesting to implement them in Mailman, because I think Mailman would gain having those features implemented. What's wrong with that? If I requested those 3 features not telling you that I've seen them in ecartis, then all would be fine, you would be happy, right? You seem to be jelous of ecartis. Think positive Brad! Don't be angry at them that they have some good features that Mailman haven't got (and don't be angry at me that I ask for some of those features to be added in Mailman), just do something that Mailman have them instead of being jelous (no offence :)). :P ak From brad.knowles at skynet.be Sat Apr 3 19:21:09 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat Apr 3 19:29:13 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <406F63A4.21145.26C8272@localhost> References: <406ED1C0.2171.32A0BE@localhost> <406F63A4.21145.26C8272@localhost> Message-ID: At 1:23 AM +0200 2004/04/04, Andrzej Kasperowicz wrote: > I'd be glad if you could explain it to him, as he apparently was > offended, because I didn't do it, and he's not a newbe in internet, I've > seen him on-line for about 9-10 years. As I told you in private e-mail, I'm not interested in whatever he might have to say. I've been in this business long enough to know what the capabilities are of the various types of programs, and there's nothing he could possibly say that could change my mind. These are facts we're dealing with, and regardless of whatever his personal opinions are as to what he feels should be done to protect him from his own stupidity, he's not going to change the facts. >> We are not going to take every single bloody feature of ecartis > > Of course not, but what is wrong in taking every good, useful feature? We can take input from many sources, when it comes to ideas to incorporate into Mailman. I'm sure that Barry would be happy to accept any useful input you may have. However, keep in mind that Barry can always decide not to implement a particular recommended feature, and even those features that he does decide to implement will have to be prioritized. Moreover, the development effort that is available is extremely limited -- there are a whole host of compromises that have to be continually made, and no one ever gets everything they want, and most people probably don't even get many of the things they want. But asking someone to re-create a commercial product and then give that away for free, well that's quite a different matter. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From andyk at spunge.org Sun Apr 4 08:41:52 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sun Apr 4 08:41:58 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: <406F63A4.21145.26C8272@localhost> Message-ID: <40701EB0.31895.1AADDC@localhost> > As I told you in private e-mail, I'm not interested in whatever > he might have to say. I've been in this business long enough to know > what the capabilities are of the various types of programs, and > there's nothing he could possibly say that could change my mind. But there is a lot what you could say to change his mind... > We can take input from many sources, when it comes to ideas to > incorporate into Mailman. I'm sure that Barry would be happy to > accept any useful input you may have. However, keep in mind that > Barry can always decide not to implement a particular recommended > feature, and even those features that he does decide to implement > will have to be prioritized. I know, but I shouldn't be condemned for recommending such features. And it seems that I was just for daring to compare it to ecarits. > But asking someone to re-create a commercial product and then > give that away for free, well that's quite a different matter. I don't understand the above. From what the freelists say on the page: http://www.freelists.org/about.html "FreeLists runs a completely free service on completely Free software. The Linux operating system, the Apache webserver, and the Ecartis mailing manager are responsible for bringing FreeLists to you daily. Mhonarc and ht://dig work in conjunction to bring you the web-based archives. All of this software is Free software and we italicize that word over and over again to emphasize its importance. See the Free Software Foundation's website for more information." it seems that all the software they use is free. ak From brad.knowles at skynet.be Sun Apr 4 10:02:38 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Apr 4 10:09:15 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <40701EB0.31895.1AADDC@localhost> References: <406F63A4.21145.26C8272@localhost> <40701EB0.31895.1AADDC@localhost> Message-ID: At 2:41 PM +0200 2004/04/04, Andrzej Kasperowicz wrote: > I know, but I shouldn't be condemned for recommending such features. And > it seems that I was just for daring to compare it to ecarits. As I said, this is a slippery slope. Once you start down the path of "But program XYZZY does this, why can't you?!?", it becomes very difficult to get back to the real issue of what features truly are needed, for what reason, and what size of community would best be served by focusing on what work. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From claw at kanga.nu Sun Apr 4 10:58:35 2004 From: claw at kanga.nu (J C Lawrence) Date: Sun Apr 4 10:58:40 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: Message from Brad Knowles of "Sun, 04 Apr 2004 16:02:38 +0200." References: <406F63A4.21145.26C8272@localhost> <40701EB0.31895.1AADDC@localhost> Message-ID: <18779.1081090715@kanga.nu> On Sun, 4 Apr 2004 16:02:38 +0200 Brad Knowles wrote: > As I said, this is a slippery slope. Once you start down the path of > "But program XYZZY does this, why can't you?!?", it becomes very > difficult to get back to the real issue of what features truly are > needed, for what reason, and what size of community would best be > served by focusing on what work. Past an early point an easy distinguishing factor is: Are you interested in it enough to write a patch? Are you interested in it enough to maintain a patch? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From andyk at spunge.org Sun Apr 4 11:17:35 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sun Apr 4 11:17:37 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: References: <40701EB0.31895.1AADDC@localhost> Message-ID: <4070432F.12243.A93B4F@localhost> > At 2:41 PM +0200 2004/04/04, Andrzej Kasperowicz wrote: > > > I know, but I shouldn't be condemned for recommending such features. And > > it seems that I was just for daring to compare it to ecarits. > > As I said, this is a slippery slope. Once you start down the > path of "But program XYZZY does this, why can't you?!?", it becomes > very difficult to get back to the real issue of what features truly > are needed, for what reason, and what size of community would best be > served by focusing on what work. I don't agree. Those features are needed, which users want. It's not that important what inspired them. ak From andyk at spunge.org Sun Apr 4 11:32:55 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sun Apr 4 11:32:57 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <18779.1081090715@kanga.nu> References: Message from Brad Knowles of "Sun, 04 Apr 2004 16:02:38 +0200." Message-ID: <407046C7.10789.B746A3@localhost> > Past an early point an easy distinguishing factor is: > > Are you interested in it enough to write a patch? > > Are you interested in it enough to maintain a patch? To whom you address these questions? Why do you assume that everyone knows Python? I assist Mailman community as I can, i.e. by giving my advice and my ideas how things could be improved. ak From carbonnb at sympatico.ca Sun Apr 4 12:05:04 2004 From: carbonnb at sympatico.ca (Bryan Carbonnell) Date: Sun Apr 4 12:05:12 2004 Subject: (Fwd) Re: [Mailman-Users] Re: [Mailman-Developers] How to rem In-Reply-To: References: <406E8757.21122.2A68F0@localhost> Message-ID: <406FF9F0.27821.47E107@localhost> On 3 Apr 2004 at 21:51, Brad Knowles wrote: > At 9:43 AM -0500 2004/04/03, Bryan Carbonnell wrote: > > > Why not just have a list of UserDefined RegEx's of headers to > > strip? > > Because most people don't properly understand regular > expressions. Since you can do the same thing in a different way and > have Mailman build the proper regular expressions based on user input, > it seems pretty obvious what the correct solution is. Yes, it may be true that RegExs are foreign to most people (myself included to a certain degree), but wouldn't it make MM more flexible? And wouldn't it be easier for Barry to implement? > If you have a "keep-these-headers/strip-these-headers" option, > then there shouldn't be any headers that either can't be stripped or > kept, depending on your particular type of choice. Well, would the X-Habeas headers be added as an option to strip, or the next X-Habeas type header that comes along? Or... Do you see my point? If there are an absolutely fixed number of types of headers that could across, then I could see that going your way would work better, but since I can add any header to an outgoing mail that I want, with my e-mail client (like I did with this e-mail), then should the MM admins be given the opportunity to strip them with a RegEx? > > If you go with keep these/strip these, I'd vote for keeping > > everything and let the admin HAVE to make the change for > > themselves. > > IMO, we should default to safety. Wouldn't safety be to not mess with the mail while passing through MM? > > Don't the RFCs say not to mess with the headers if possible? Or > > something like that? > > The RFCs regarding mail are intended primarily for MTAs and MUAs, not > mailing list management systems. Moreover, they make it clear that > you can add headers, but you can't change them, and under certain > circumstances you can remove them. Since the MLM is a gateway system > of sorts, there is more freedom with regards to what the authors are > allowed to do. I understand that the RFC are for MTA and MUAs, but shouldn't MM follow them as well? As well as we can anyway? I'm not trying to argue, just trying to get thing straighened out in my mind. -- Bryan Carbonnell - carbonnb@sympatico.ca It was difficult to code. So it damn well better be difficult to use. From andyk at spunge.org Sun Apr 4 12:05:29 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sun Apr 4 12:05:33 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <40702E29.8070903@smxy.org> References: <407046C7.10789.B746A3@localhost> Message-ID: <40704E69.6515.D517F5@localhost> > > To whom you address these questions? > > Why do you assume that everyone knows Python? > > I assist Mailman community as I can, i.e. by giving my advice and my > > ideas how things could be improved. > > So you'd rather tell people what to do, rather than do it yourself, > because you might have to learn something? Hrmph. You must be kidding. Even in middleages people had various occupations. Do you want to move us all to a stoneage? At that time indeed most people could do everything. Well, not quite, men still couldn't give birth. :P ak From claw at kanga.nu Sun Apr 4 12:37:28 2004 From: claw at kanga.nu (J C Lawrence) Date: Sun Apr 4 12:37:34 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: Message from "Andrzej Kasperowicz" of "Sun, 04 Apr 2004 17:32:55 +0200." <407046C7.10789.B746A3@localhost> References: Message from Brad Knowles of "Sun, 04 Apr 2004 16:02:38 +0200." <407046C7.10789.B746A3@localhost> Message-ID: <20104.1081096648@kanga.nu> On Sun, 04 Apr 2004 17:32:55 +0200 Andrzej Kasperowicz wrote: >> Past an early point an easy distinguishing factor is: >> Are you interested in it enough to write a patch? >> Are you interested in it enough to maintain a patch? > To whom you address these questions? How about you? > Why do you assume that everyone knows Python? I don't. I assume that everyone can learn python should their interest/need for a particular feature be large enough. After all, that's what we had to do (learn Python etc), in order to get done what's been done so far. > I assist Mailman community as I can, i.e. by giving my advice and my > ideas how things could be improved. Excellent, and thank you, however code is far more valuable than ideas. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From andyk at spunge.org Sun Apr 4 12:44:33 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sun Apr 4 12:44:38 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <4070334A.8020700@smxy.org> References: <40704E69.6515.D517F5@localhost> Message-ID: <40705791.29902.F8D978@localhost> > If you want something done, and there isn't anyone who has the time, > skills or inclination to do it for you, then you either knuckle down and And how could I know that there isn't anyone, huh? > do it yourself, or forget about it. You don't keep hounding someone else > to do it. You are rude. Look what you've just written. You seem to have contempt for users of the program, and that's a very bad thing. Is the mailman for the users or the users for the mailman? There are developers, and users, users can make their wishlist, and developers could see what they can do. If someone can do a patch himself, that's good, but if someone cannot, then telling him to shut up, because he cannot do it himself is just rude and silly. ak From dev at anabasis.net Sun Apr 4 12:46:41 2004 From: dev at anabasis.net (Lawrence Weeks) Date: Sun Apr 4 12:46:44 2004 Subject: [Mailman-Developers] Excessive quote filtering [was Re: Copy some of the features from Freelists (ecartis) to the Mailman.] In-Reply-To: References: Message-ID: <20040404164641.GA29215@dm2.deskmedia.com> Once upon a time (Wed Mar 24), Andrzej Kasperowicz wrote: > Bad quoting is also often a problem, so it would be good if Mailman > could have similar solution to that used in freelists. I've not looked at ecartis/freelists, but I have had quote filtering on my mailing lists since the early 90s (originally in the Majordomo pipe stream), via a Perl filter script I wrote, called the Mommy filter. It's a real bear to keep up with. To support catching excessive quoting generated by the various mail clients, I have dozens of tests and cases. There is no elegant way to do it really. Then, you have idiotic subscribers messing with the quote markers, in particular the evil MS style bottom quoting, to circumvent the filters. There are some people out there who just HATE the concept of being told they cannot quote whatever the hell they want, despite doing so on somebody else's dime. My filter, tweaked over the last decade, does a pretty good job. However, it still requires tweaking based on what you see happening on the mailing list. It requires that feedback process to be effective. It requires a plain-text mailing list. Doing this with a HTML permitting list would be, um, complex. If somebody would like to take up placing this capability into Mailman, I'd be happy to share my (ugly) script if it would be of interest. I actually started a little bit of exploration into doing that myself, but decided that I'd rather to maintain my own filtering policy external to Mailman, so as to be able to respond to events on the lists rapidly. Larry -- Lawrence Weeks lweeks@anabasis.net Anabasis Consulting Ltd From andyk at spunge.org Sun Apr 4 12:54:55 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sun Apr 4 12:54:58 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <20104.1081096648@kanga.nu> References: Message from "Andrzej Kasperowicz" of "Sun, 04 Apr 2004 17:32:55 +0200." <407046C7.10789.B746A3@localhost> Message-ID: <407059FF.32414.1025895@localhost> > I don't. I assume that everyone can learn python should their > interest/need for a particular feature be large enough. After all, Bad assumption. Time is not from rubber, your advice might be good for computer science students, but might not be for others. I suggest you never say again to someone such unceremoniously just do it yourself. If someone could do it himself he would do it without asking for that on the list. > Excellent, and thank you, however code is far more valuable than ideas. You really think so? What code would you write without any ideas, huh? ak From chuqui at plaidworks.com Sun Apr 4 14:01:22 2004 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Sun Apr 4 13:02:06 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <40705791.29902.F8D978@localhost> References: <40704E69.6515.D517F5@localhost> <40705791.29902.F8D978@localhost> Message-ID: <14E3383C-8662-11D8-8B76-0003934516A8@plaidworks.com> Guys -- Can we please drop this? It's been beaten into the ground. I don't think the mailman development crew has shown itself well here, either, especially Brad, who seems to be grumpy beyond the needs of the discussion for some reason. I don't think we as a team managing an open source project look good right now, it wasn't handled particularly professionally, IMHO. and for the record, I tend to disagree with Brad -- I definitely see it as useful to be able to strip out headers that cause systems to auto-reply with a return receipt. but since those headers aren't really standardized, it's not as simply as flipping a switch. what I might do, stepping back a couple of steps and looking at it somewhat objectively, is to consider an option that simply strips all non-RFC headers from a message. But I'm rather surprised to see us blowing off someone's privacy concerns here in the heat of whatever grumpiness people brought to the discussion the last couple of days, and especially doing it as members of the Mailman team the way we did. All of the points made are relevant, the way they were made was, well, IMHO less than optimal. so maybe we should all shut up and let this cool off. Maybe reconsider the idea once the emotion's drained a bit. But right now, we're not doing anyone any good on anything. From claw at kanga.nu Sun Apr 4 13:03:35 2004 From: claw at kanga.nu (J C Lawrence) Date: Sun Apr 4 13:03:39 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: Message from "Andrzej Kasperowicz" of "Sun, 04 Apr 2004 18:54:55 +0200." <407059FF.32414.1025895@localhost> References: Message from "Andrzej Kasperowicz" of "Sun, 04 Apr 2004 17:32:55 +0200." <407046C7.10789.B746A3@localhost> <407059FF.32414.1025895@localhost> Message-ID: <21322.1081098215@kanga.nu> On Sun, 04 Apr 2004 18:54:55 +0200 Andrzej Kasperowicz wrote: >> I don't. I assume that everyone can learn python should their >> interest/need for a particular feature be large enough. After all, > Bad assumption. Time is not from rubber, your advice might be good for > computer science students, but might not be for others. No. The critical point is "large enough". If their need is large enough they either will themselves, or will arrange for someone else to as their proxy. > I suggest you never say again to someone such unceremoniously just do > it yourself. If someone could do it himself he would do it without > asking for that on the list. Frequently, near enough to invariably as to be easily mistaken for it, that is not the case. >> Excellent, and thank you, however code is far more valuable than >> ideas. > You really think so? What code would you write without any ideas, huh? Any decent engineer (or otherwise) can think of a thousand great ideas an hour. There isn't a particular shortage of such. There is a particular shortage of implementations of great ideas. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From terri at zone12.com Sun Apr 4 13:34:09 2004 From: terri at zone12.com (Terri Oda) Date: Sun Apr 4 13:34:47 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <14E3383C-8662-11D8-8B76-0003934516A8@plaidworks.com> References: <40704E69.6515.D517F5@localhost> <40705791.29902.F8D978@localhost> <14E3383C-8662-11D8-8B76-0003934516A8@plaidworks.com> Message-ID: <47F074AF-865E-11D8-9E22-000D934FBF38@zone12.com> On Apr 4, 2004, at 2:01 PM, Chuq Von Rospach wrote: > Can we please drop this? It's been beaten into the ground. I don't > think the mailman development crew has shown itself well here, either, > especially Brad, who seems to be grumpy beyond the needs of the > discussion for some reason. I don't think we as a team managing an > open source project look good right now, it wasn't handled > particularly professionally, IMHO. > > so maybe we should all shut up and let this cool off. Maybe reconsider > the idea once the emotion's drained a bit. But right now, we're not > doing anyone any good on anything. Thank you Chuq. That's pretty much what I was thinking. *I* think stripping headers could be a useful feature, and I can even see in my head how I'd go about putting that into the admin interface. But since I think writing more documentation is more useful, that's where my time's going to go. (Even though writing that code is more fun to me than writing admin documentation.) Now that the idea's out there (it has been put into the wiki, right?), it'll be implemented if someone interested has the time, inclination, and expertise, and it'll be accepted if the patch is appropriate. No point in trying to force people to volunteer their time if they're not ready yet, and no point in shoving the idea into the ground when it's clearly useful to someone, and might be useful to more people in the future. Who knows -- a few months from now, we may find out that flocks of people want it, and then more people will be willing to put the time into implementation. Or a few months from now, no one else will have wanted it in Mailman because they'll have found something else better suits their needs, and the idea will die. Terri From andyk at spunge.org Sun Apr 4 13:59:00 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sun Apr 4 13:59:06 2004 Subject: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <21322.1081098215@kanga.nu> References: Message from "Andrzej Kasperowicz" of "Sun, 04 Apr 2004 18:54:55 +0200." <407059FF.32414.1025895@localhost> Message-ID: <40706904.6202.13D0643@localhost> > No. The critical point is "large enough". If their need is large > enough they either will themselves, or will arrange for someone else to > as their proxy. I don't think so. If they ask for that on the list, that already means that their need is large enough. List-owners needn't to know any computer language, and in fact probably most of the list-owners do not know any, and you shouldn't expect that they will learn it just to implement a feature in mailman - that's an utopian expectation. > Frequently, near enough to invariably as to be easily mistaken for it, > that is not the case. People sometimes offer their code on the list (a few months ago a code to add the links in archive, and now the quotation filter). It's now the developers' task not to waste that generous offer and implement it in the mailman distribution. > Any decent engineer (or otherwise) can think of a thousand great ideas > an hour. There isn't a particular shortage of such. There is a No, they think that they have great ideas, really great ideas are rare. > particular shortage of implementations of great ideas. Sure, but still idea is first. Without an idea there would be no code. ak From andyk at spunge.org Sun Apr 4 15:04:18 2004 From: andyk at spunge.org (Andrzej Kasperowicz) Date: Sun Apr 4 15:04:21 2004 Subject: [Mailman-Developers] Global hide/unide list members Message-ID: <40707852.25282.178CF32@localhost> A list-owner: http://mail.python.org/pipermail/mailman-users/2004- March/035696.html asked me for help with retrieving a list of subscribers of his lists. What I found on his lists was this option ticked: "Conceal the member's address" in the "Default options for new members joining this list.". However, the problem now is that unmarking this option has influence only to new members who subscribe, but the old ones still have their addresses hidden, and I don't know how to unhide them globally - all at once (there are thousands of subscribers, so it'd be a time consuming task to do it manually for each subscriber). I don't think he has an access to shell to retrieve list members in another way. Is there any way to unhide them all at once? ak From gward at python.net Sun Apr 4 18:05:39 2004 From: gward at python.net (Greg Ward) Date: Sun Apr 4 18:05:48 2004 Subject: [Mailman-Developers] Typo fix in Mailman's README.EXIM Message-ID: <20040404220539.GA18583@cthulhu.gerg.ca> Hi Barry -- Daniel Zeiss spotted a typo in Mailman's README.EXIM (actually, he spotted it in the version at http://www.exim.org/howto/mailman21.html -- hence cc'ing webmaster@exim.org). Here's the fix: --- README.EXIM 20 Mar 2003 16:58:29 -0000 2.9 +++ README.EXIM 4 Apr 2004 21:54:52 -0000 @@ -247,13 +247,13 @@ # Accept bounces to lists even if callbacks or other checks would fail warn message = X-WhitelistedRCPT-nohdrfromcallback: Yes condition = \ - ${if and {{match{$local_part}{(.*)-bounces\+.*}} + ${if and {{match{$local_part}{(.*)-bounces\+.*}} \ {exists {MAILMAN_HOME/lists/$1/config.pck}}} \ {yes}{no}} {yes}{no}} accept condition = \ - ${if and {{match{$local_part}{(.*)-bounces\+.*}} + ${if and {{match{$local_part}{(.*)-bounces\+.*}} \ {exists {MAILMAN_HOME/lists/$1/config.pck}}} \ {yes}{no}} {yes}{no}} Suggested checkin comment: "Fix typo in SMTP Callback section (Daniel Zeiss )." To Nigel (or whoever's manning webmaster@exim.org these days): can you fix the HTML version please? Also I spotted a typo that has been corrected in the canonical version (README.EXIM in Mailman's CVS) -- s/epmty/empty/. Thanks. Greg -- Greg Ward http://www.gerg.ca/ There's nothing to see here. Move on; go about your business. From brad.knowles at skynet.be Sun Apr 4 18:08:34 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun Apr 4 18:40:09 2004 Subject: (Fwd) Re: [Mailman-Users] Re: [Mailman-Developers] How to rem In-Reply-To: <406FF9F0.27821.47E107@localhost> References: <406E8757.21122.2A68F0@localhost> <406FF9F0.27821.47E107@localhost> Message-ID: At 12:05 PM -0400 2004/04/04, Bryan Carbonnell wrote: > Yes, it may be true that RegExs are foreign to most people (myself > included to a certain degree), but wouldn't it make MM more flexible? There can be such a thing as "too flexible". After all, a C compiler and a Python interpreter are about as flexible as you can get -- so why don't you code your own features in them? > And wouldn't it be easier for Barry to implement? Maybe. However, we have to consider more than just the implementation cost -- there is also the support cost to consider. If it costs 10x or 100x as much to support the regex feature because it's too flexible and too confusing to too many people, then it's not worth the effort. > Do you see my point? If there are an absolutely fixed number of types > of headers that could across, then I could see that going your way > would work better, but since I can add any header to an outgoing mail > that I want, with my e-mail client (like I did with this e-mail), > then should the MM admins be given the opportunity to strip them with > a RegEx? Okay, so a Keep-These-Headers option being restricted to just the following: From: Subject: To: Cc: Date: Is not capable of stripping all possible headers that could potentially be generated? Sorry, I don't buy it. The only thing that using a regex would do for you that cannot easily be done with a strip-these-headers/keep-these-headers option is the case of multiple headers which share some subset of their name and for which you want the same action to be taken (e.g., strip all headers matching "^List.*:"). I'm just not sure that it would be worth the effort to get this relatively small additional functionality, given the potential additional support cost that would result. But only Barry could really answer this question. > Wouldn't safety be to not mess with the mail while passing through > MM? No, "safety" would be to strip everything that is not known to be safe, such as the minimal list of headers shown above. > I understand that the RFC are for MTA and MUAs, but shouldn't MM > follow them as well? As well as we can anyway? Where it makes sense, yes. But as I said before, a Mailing List Manager is effectively a type of gateway system, and while there are a small number of documents that describe what are considered to be Best Current Practices for MLMs, there are no Required or Recommended RFCs that are specifically aimed at them. As such, you need to apply a lot of interpretation when you're looking at RFCs that are written for MTAs or MUAs, and try to figure out which parts are applicable to MLMs and which ones are not. > I'm not trying to argue, just trying to get thing straighened out in > my mind. This is a point of deep discussion amongst the most experienced people in the field. You are not expected to fully understand all the nuances involved. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From carbonnb at sympatico.ca Sun Apr 4 19:26:12 2004 From: carbonnb at sympatico.ca (Bryan Carbonnell) Date: Sun Apr 4 19:26:29 2004 Subject: (Fwd) Re: [Mailman-Users] Re: [Mailman-Developers] How to rem In-Reply-To: References: <406FF9F0.27821.47E107@localhost> Message-ID: <40706154.29947.681BC2@localhost> On 5 Apr 2004 at 0:08, Brad Knowles wrote: > At 12:05 PM -0400 2004/04/04, Bryan Carbonnell wrote: > > And wouldn't it be easier for Barry to implement? > > Maybe. However, we have to consider more than just the > implementation cost -- there is also the support cost to consider. If > it costs 10x or 100x as much to support the regex feature because it's > too flexible and too confusing to too many people, then it's not worth > the effort. Fair enough. I never considered that. > > Do you see my point? If there are an absolutely fixed number of > > types of headers that could across, then I could see that going > > your way would work better, but since I can add any header to an > > outgoing mail that I want, with my e-mail client (like I did with > > this e-mail), then should the MM admins be given the opportunity to > > strip them with a RegEx? > > Okay, so a Keep-These-Headers option being restricted to just the > following: > > From: > Subject: > To: > Cc: > Date: > > Is not capable of stripping all possible headers that could > potentially be generated? Sorry, I don't buy it. I think that we are talking about 2 different things. Or at least I misunderstood what you were talking about. I was thinking from your description, From: would be selectable to keep or strip Subject: would be selectable to keep or strip To: would be selectable to keep or strip Cc: would be selectable to keep or strip Date: would be selectable to keep or strip etc. as SEPARATE individual choices to. Not as a group. Now that I understand your thinking, I think that this may be a very viable alternative. Maybe even less of a support issue. Maybe both what you are thinking and the RegEx would work well together. The keep/strip for those that want simple and RegEx for those that want the extra control. > I'm just not sure that it would be worth the effort to get this > relatively small additional functionality, given the potential > additional support cost that would result. Neither do I. Unfortunately I'm just learning Python, so I don't know who hard or how easy any of these suggestions are. > But only Barry could really answer this question. Absolutely. > No, "safety" would be to strip everything that is not known to be > safe, such as the minimal list of headers shown above. I can see that. I'm, personally, not convinced, but then I haven't been a mail admin as long as you have been. > > I'm not trying to argue, just trying to get thing straighened out > > in my mind. > > This is a point of deep discussion amongst the most experienced > people in the field. You are not expected to fully understand all the > nuances involved. I'm not worried about all the nuances involved. I was just trying to get what we, you and I were discussing, sorted out. And now I realize that we weren't quite talking about the same things. I was talking about controling individual headers, separately, and you are talking about controlling the "basic" headers as a group. Whose idea is better? Not my call, I'm glad to say. I guess we just need to wait and see what Barry has in store for us :) -- Bryan Carbonnell - carbonnb@sympatico.ca My reality check bounced. From Nigel.Metheringham at dev.InTechnology.co.uk Mon Apr 5 04:35:03 2004 From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham) Date: Mon Apr 5 04:37:56 2004 Subject: [Mailman-Developers] message filters - how to define regex string which allowes any mail address In-Reply-To: References: Message-ID: <1081154103.7655.3.camel@angua.localnet> On Sat, 2004-04-03 at 02:42, John W. Baxter wrote: > Well, the first edition of "Mastering Regular Expressions" by Jeffrey E. F. > Friedl (spelled correctly) had such a regular expression in small print > occupying a full page near the back. [He developed pieces of it in various > parts of the book.] It had a bug, so there was a correct version at > O'Reilly's site in the book's errata area. Theres also a copy of the regexp - or actually the perl generator for it - at:- http://public.yahoo.com/~jfriedl/regex/code.html Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From barry at python.org Mon Apr 5 10:14:26 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 5 10:14:50 2004 Subject: [Mailman-Developers] Re: Typo fix in Mailman's README.EXIM In-Reply-To: <20040404220539.GA18583@cthulhu.gerg.ca> References: <20040404220539.GA18583@cthulhu.gerg.ca> Message-ID: <1081174465.29721.14.camel@anthem.wooz.org> On Sun, 2004-04-04 at 18:05, Greg Ward wrote: > Hi Barry -- Daniel Zeiss spotted a typo in Mailman's > README.EXIM (actually, he spotted it in the version at > http://www.exim.org/howto/mailman21.html -- hence cc'ing > webmaster@exim.org). Thanks, fixed. Don't worry Daniel, as a general rule I don't include email addresses at all in checkin messages. -Barry From jam at athene.jamux.com Mon Apr 5 10:09:53 2004 From: jam at athene.jamux.com (John A. Martin) Date: Mon Apr 5 10:20:42 2004 Subject: [Mailman-Developers] Re: (Fwd) Re: [Mailman-Users] Re: How to rem References: <406E8757.21122.2A68F0@localhost> <406FF9F0.27821.47E107@localhost> Message-ID: <87oeq6zfbi.fsf@athene.jamux.com> >>>>> "Brad" == Brad Knowles >>>>> "Re: (Fwd) Re: [Mailman-Users] Re: How to rem" >>>>> Mon, 5 Apr 2004 00:08:34 +0200 Brad> Okay, so a Keep-These-Headers option being restricted Brad> to just the following: Brad> From: Brad> Subject: Brad> To: Brad> Cc: Brad> Date: IMHO facilitating such heavy handed usurpation of the standards that explicitly permit arbitrary header fields in mail messages is a bad idea. One legitimate use of arbitrary header fields is to convey routine information without cluttering the message body. There are for example at least three such header fields in this message apart From the well defined Content-Type field removal of which would cripple the PGP/MIME signature on this mail. There are other rfc2822 fields like Message-ID and Resent-* fields and more that should not be deleted. IMHO failure of a mailing list manager to comply with the MTA standards with respect to header munging is an extraordinary step that should require extraordinary justification. jam -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 154 bytes Desc: not available Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040405/2b9b47fc/attachment.bin From brad.knowles at skynet.be Mon Apr 5 12:33:44 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Mon Apr 5 12:41:11 2004 Subject: [Mailman-Developers] Re: (Fwd) Re: [Mailman-Users] Re: How to rem In-Reply-To: <87oeq6zfbi.fsf@athene.jamux.com> References: <406E8757.21122.2A68F0@localhost> <406FF9F0.27821.47E107@localhost> <87oeq6zfbi.fsf@athene.jamux.com> Message-ID: At 10:09 AM -0400 2004/04/05, John A. Martin wrote: > There are > for example at least three such header fields in this message apart > From the well defined Content-Type field removal of which would > cripple the PGP/MIME signature on this mail. Mailman is already doing MIME bodypart stripping, based on content-type values, etc.... It doesn't take much of a stretch of the imagination to take that same type of mechanism and apply it to the RFC2822 headers as well. > There are other rfc2822 > fields like Message-ID and Resent-* fields and more that should not be > deleted. Okay, add Message-ID to the list of standard headers that would typically be kept. > IMHO failure of a mailing list manager to comply with the MTA > standards with respect to header munging is an extraordinary step that > should require extraordinary justification. Is it such an extraordinary step? IMO, that's the real point under discussion. There are so many clueless users out there that insist that you protect them from their own stupidity, and they seem to go out of their way to use products from certain companies (who shall remain nameless) which likewise seem to go out of their way to do extremely stupid and dangerous things based on input from sources that are not proven to be trustworthy. This is part of the slippery slope I was talking about. At what point do you stop trying to fight the billions of lemmings that are running you over on a moment-by-moment basis, and you start trying to do something to protect yourself, your systems, and your users, against them? In a sense, this is also what spam and spam fighting is all about. More and more people are insisting on senders that must meet ever more stringent requirements, before the connection or message will be accepted. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From mch at cix.compulink.co.uk Thu Apr 8 09:54:00 2004 From: mch at cix.compulink.co.uk (Mike Holderness) Date: Thu Apr 8 09:54:10 2004 Subject: [Mailman-Developers] "Reply-to" addresses in archive Message-ID: I've just spotted that in the archives for a list with "Reply-to:list" many messages appear as coming from the list, some with no record of the sender. Is this a known bug? Or is there some admin setting I'm missing? I've looked hard and not found one... Mike From mch at cix.compulink.co.uk Thu Apr 8 10:52:00 2004 From: mch at cix.compulink.co.uk (Mike Holderness) Date: Thu Apr 8 10:52:41 2004 Subject: [Mailman-Developers] Truncated digest with MIME Message-ID: I have a problem. We have, I think, a problem. 1) Message is sent with a line exactly 76 characters long, ending with ".". User (a computerphobe) still has pretty email turned on, so something en route wraps the line at column 75, leaving a "." by itself on the next line. 2) For another digest user - who is reading email as plain text that means "here endeth the message". Rest of digest not visible. Potential for fouling up their email client when they reindex. I've asked all members of the list to switch to plain text emails. But it ain't gonna happen :( Can something be done to make mailman transparent to this? I can find one message about this in the archive, but no response: # From: Michael Schwendt # Subject: [Mailman-Developers] Mailman transparency # Date: Sat, 13 Sep 2003 06:24:03 -0700 2) Occasionally, a subscriber finds that a posted message has made it to the mailing-list only truncated. It turns out that the message contained a line with only a single dot by itself. Mailman cuts off the message body at that line before distributing the truncated message to all subscribers. It looks much like the dot is treated as SMTP message body delimiter but in a non-transparent way. The users should be protected from something like that. From subha at gotomedia.com Thu Apr 8 11:46:13 2004 From: subha at gotomedia.com (Subha Subramanian) Date: Thu Apr 8 11:46:22 2004 Subject: [Mailman-Developers] Placing the confirmation string in email body instead of the Subject Message-ID: <0D081BEC540DBD44B7E43752757CEC8E4EB385@webserver.gotomedia.com> Hi, How do I get mailman to parse the whole message to get the email commands?The email command only works if it is the first line of the email body. I am trying to change the subject of the confirmation email to make it user friendly. I changed the verify.txt to include the confirmation cookie and changed Utils.py to read the first 20 lines. It still doesnt work! What am I missing? -Subha From maligree at gmx.de Thu Apr 8 15:14:42 2004 From: maligree at gmx.de (Dave Kliczbor) Date: Thu Apr 8 15:14:45 2004 Subject: [Mailman-Developers] Wrong host_name when creating list via webinterface Message-ID: <200404082114.42657.maligree@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello out there... I just set up mailman on my Debian woody box, using the mailman 2.1.4-2.backports.org debian package from backports.org. Everything seems to be ok, except one tiny bit... If I create a new list via webinterface, the wrong hostname is used (namely 'domain.tld')-- if I create it via command line, the right hostname is used (namely 'lists.domain.tld'). Nothing concerning my mailing lists is associated with 'domain.tld', everything, including web traffic, has to use 'lists.domain.tld'. As a result, I put 'lists.domain.tld' everywhere I could find before even starting mailman the very first time. I dove a bit further in this issue, but all I could find was that the host_name config variable has been set inproperly when using the webinterface to create a list. I even used the deprecated DEFAULT_HOST_NAME variable in mm_cfg.py, but no result. I still have to manually set the host_name in the list option page after creating. I found only one post without answer in the last three months regarding such an issue on mailman-users, nothing found in mailman-developers (keywords I used: web, host) I tried posting first on mailman-users, but I got no answer (I suppose my question was a bit too technical :-). Even on the bug tracker I found nothing and now I'm at the end of my knowledge... (OK, if I learn python maybe I could solve the problem, but that's a little bit more time-consuming than I could afford...) My mm_cfg.py: - ---- DEFAULT_URL = 'https://lists.domain.tld/cgi-bin/mailman/' DEFAULT_EMAIL_HOST = 'lists.domain.tld' DEFAULT_URL_HOST = 'lists.domain.tld' IMAGE_LOGOS = '/images/mailman/' USE_ENVELOPE_SENDER = 0 DEFAULT_SEND_REMINDERS = 0 DEFAULT_HOST_NAME = 'lists.domain.tld' HOST_NAME = 'lists.domain.tld' MAILMAN_SITE_LIST = 'mailman' PRIVATE_ARCHIVE_URL = '/cgi-bin/mailman/private' DEFAULT_URL_PATTERN = 'https://%s/cgi-bin/mailman/' PUBLIC_ARCHIVE_URL = 'https://%(hostname)s/pipermail/%(listname)s' DEFAULT_SERVER_LANGUAGE = 'de' VIRTUAL_HOSTS.clear() add_virtualhost('lists.domain.tld') - ---- cya Dave KLiczbor - -- docs on mail serving and spam preventing in the courier mail suite: http://da.andaka.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdaSi9gy0Ccu0VlMRAuacAJ0V/tGPnt0l7w03OBZvfHvj4pwWKwCfVTA7 q7NyBI8yE4+BDTvS3x20048= =FmPe -----END PGP SIGNATURE----- From terri at zone12.com Thu Apr 8 15:35:02 2004 From: terri at zone12.com (Terri Oda) Date: Thu Apr 8 15:35:15 2004 Subject: [Mailman-Developers] "Reply-to" addresses in archive In-Reply-To: References: Message-ID: On Apr 8, 2004, at 9:54 AM, Mike Holderness wrote: > I've just spotted that in the archives for a list with > "Reply-to:list" many messages appear as coming from > the list, some with no record of the sender. > > Is this a known bug? What version of Mailman are you using? It was an issue I noticed with 2.0 archives, but I don't think I've ever seen it in 2.1. In one of the 2.0 versions, if I recall correctly, all the users email addresses were changed to the list address, so any user who didn't specify their name in their from line wound up appearing as just the list. I just left it like that because of the incidental anti-spam usefulness, but the patch (if I recall correctly) is fairly trivial. I just don't think I ever actually made one and submitted it. In 2.1, the mail-to links are changed to the list, but the actual email address is there, in munged format. Terri From terri at zone12.com Thu Apr 8 15:41:08 2004 From: terri at zone12.com (Terri Oda) Date: Thu Apr 8 15:41:14 2004 Subject: [Mailman-Developers] Wrong host_name when creating list via webinterface In-Reply-To: <200404082114.42657.maligree@gmx.de> References: <200404082114.42657.maligree@gmx.de> Message-ID: On Apr 8, 2004, at 3:14 PM, Dave Kliczbor wrote: > I just set up mailman on my Debian woody box, using the mailman > 2.1.4-2.backports.org debian package from backports.org. I haven't looked at more recent mailman packages, but I've been largely unimpressed with the debs I've seen in the past -- there's so much munging in there that sometimes it causes more problems than it "solves" through standardizing. Not sure why. I don't know how practical this is for you, but you might consider trying from source if you've got the time (It's fairly easy to do, and the instructions were pretty good the last time I checked). > I tried posting first on mailman-users, but I got no answer (I suppose > my question was a bit too technical :-). Even on the bug tracker I > found nothing and now I'm at the end of my knowledge... (OK, if I learn > python maybe I could solve the problem, but that's a little bit more > time-consuming than I could afford...) Have you submitted a bug? It could just be a bug. :) Anyhow, I'm afraid I don't actually know the answer to your question, but if you once again don't get an answer, I suggest you put the problem into the bug tracker. Then, someone will at least try to verify the bug so you'll have some help. Terri From fil at rezo.net Thu Apr 8 16:21:43 2004 From: fil at rezo.net (Fil) Date: Thu Apr 8 16:20:58 2004 Subject: [Mailman-Developers] Mailman + postfix + amavisd-new HOWTO Message-ID: <20040408202142.GB30121@rezo.net> Mailman + postfix + amavisd-new HOWTO ------------------------------------- by Fil 8/04/2004 - This is a first draft. Comments are welcome. This file is released under the GNU Free Documentation License (FDL, see below). INTRODUCTION: Installing the antispam/antivirus amavisd-new on a mailing-list server poses a serious performance issue: when the server sends out thousands of emails to the mailing-list subscribers, some of these subscribers return bounce messages, which can number in the hundreds and might clog the antivirus daemon if you're not careful. Here's how we do it on http://listes.rezo.net/ 1) Before all, make sure you run postfix v2.x, otherwise the FILTER feature will not be here. Configure postfix so that it accepts scanned messages from amavisd-new on localhost:10025 Add to /etc/postfix/master.cf the following lines: localhost:10025 inet n - n - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 2) Configure amavisd-new the usual way, so that it accepts incoming mail on localhost:10024 (or any other port you choose) and sends it back into the mail queue via localhost:10025; this is very standard, but I guess the settings is as follows, in /etc/amavis/amavis.log: $inet_socket_port = 10024; @inet_acl = qw( 127.0.0.1 ); $max_servers = 2; # two servers max at the same time 3) Define a smtp-amavis service on postfix, so that it can be invoked later: Add to /etc/postfix/master.cf: smtp-amavis unix - - n - 2 lmtp -o smtp_data_done_timeout=1200 Note here that the maximum number of processes running in parallel (2) is the same as in the amavisd-new configuration. You can increase both a bit if you experience delays in delivery because of amavis, but that's out of the scope of this HOWTO. 2 is fine for us, with a daily average of 10 emails to check per minute (and a powerful computer). 4) Test your filter by sending messages locally through SMTP:10024 5) Configure postfix to send all emails through the filter EXCEPT those messages that are only addressed to a list-bounces address : Create the address regexp in /etc/postfix/amavis_check (do 'man regexp_table' to get more information): !/-bounces@(my\.domain\.tld|other\.domain\.net)$/i FILTER smtp-amavis:[127.0.0.1]:10024 Modify /etc/postfix/main.cf to have the check_recipient_access use this regexp table: smtpd_recipient_restrictions = permit_mynetworks check_client_access hash:$config_directory/access reject_unauth_destination check_recipient_access regexp:$config_directory/amavis_check # other UCE checks here 6) You're done. Check your log files and enjoy an almost spam- and virus-free server. 7) Now you can focus on the viruses and politics that kill people in the real world, and read "Global Aids: Myths and Facts" by Alec Irwin and Joyce Millen, published by South End Press. REFERENCES: Amavisd-new: http://www.amavis.org/ Mailman: http://www.list.org/ postfix: http://www.postfix.org/ Copyright (c) 2004 PHILIPPE RIVIERE. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. From claw at kanga.nu Thu Apr 8 16:46:01 2004 From: claw at kanga.nu (J C Lawrence) Date: Thu Apr 8 16:46:07 2004 Subject: [Mailman-Developers] Wrong host_name when creating list via webinterface In-Reply-To: Message from Terri Oda of "Thu, 08 Apr 2004 15:41:08 EDT." References: <200404082114.42657.maligree@gmx.de> Message-ID: <13804.1081457161@kanga.nu> On Thu, 8 Apr 2004 15:41:08 -0400 Terri Oda wrote: > On Apr 8, 2004, at 3:14 PM, Dave Kliczbor wrote: >> I just set up mailman on my Debian woody box, using the mailman >> 2.1.4-2.backports.org debian package from backports.org. > I haven't looked at more recent mailman packages, but I've been > largely unimpressed with the debs I've seen in the past -- there's so > much munging in there that sometimes it causes more problems than it > "solves" through standardizing. Not sure why. Having run from the Debian packages for some years now without problem I'd counter this, and instead recommend just installing the appropriate mailman package from /testing. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From jonas at freesources.org Thu Apr 8 20:31:51 2004 From: jonas at freesources.org (Jonas Meurer) Date: Thu Apr 8 20:33:19 2004 Subject: [Mailman-Developers] external archiver Message-ID: <20040409003150.GH655@nazgul.mejo.net> hello, I try to configure mailman to use lurker as archiver, but the usage of External Archivers is not clear for me, and i didn't find any documentation about this topic except of a hint in mailmans faq wizard, which only describes the way of subscribing a archiving user to every list and set the right alias to the archiver for the mta. Since this requires procmail, which is quite steady at heavy load, i'dd like to use the PUBLIC_EXTERNAL_ARCHIVER and PRIVATE_EXTERNAL_ARCHIVER config options of mailman. After searching some pages and files, i got from Defaults.py, that these two options should be what I searched for. I understood them as options where you set a shell command where the message is passed to that should archive the message at the external archiver. If this is wrong, what's the intention of these two options? For my external archiver (lurker), i have the binary lurker-index, which needs the listname with option -l and expects the message at stdin. so i set the two options like following: PUBLIC_EXTERNAL_ARCHIVER = '/usr/bin/lurker-index -l `echo %(listname)s \ | tr "[:upper:]" "[:lower:]"` -m' PRIVATE_EXTERNAL_ARCHIVER = '/usr/bin/lurker-index -l `echo %(listname)s \ | tr "[:upper:]" "[:lower:]"` -m' this should do nothing else than running lurker-index with -l listname (changed to lowercase letters, since lurker only support lowercase listnames). so if the listname is either mylist or MyList, the command should be: /usr/bin/lurker-index -l `echo MyList | tr "[:upper:]" "[:lower:]"` -m which ends normally ends up in: /usr/bin/lurker-index -l mylist -m but regardless if I use the above listed option, or directly PUBLIC_EXTERNAL_ARCHIVER = '/usr/bin/lurker-index -l mylist -m' i get at /var/log/mailman/error: Apr 09 02:21:15 2004 (18207) external archiver non-zero exit status: 1 any suggestions what I might have forgotten? ah, i turned off multipart message filtering for not messing up lurker at initial tests: ARCHIVE_SCRUBBER = 0 sorry, i absolutely have no idea what I did wrong, and I CCed this message to -developers since there seems to be no documented common usage of the EXTERNAL_ARCHIVER options. Maybe the message isn't passed to the shell command on stding because other delivery method is expected, but i don't believe that. Additional, what exactly does this ARCHIVE_TO_MBOX option do? Defaults.py tells me: # 1 - archive to mbox to use an external archiving mechanism only does this mean that mailman archives to an mbox file and the external archiver is intended to use this file for archiving new messages? if yes, where can i find this mbox file? should the external archiver option then use the file for updating archive rather than getting the new message directly over standard input (stdin)? sorry if i'm confusing, please tell me in this case, but i have too much questions i'm not able to answer on my own, to get the whole big puzzle put together out of all the little pieces. bye jonas From jonas at freesources.org Fri Apr 9 07:44:49 2004 From: jonas at freesources.org (Jonas Meurer) Date: Fri Apr 9 07:46:20 2004 Subject: [Mailman-Developers] Re: [Mailman-Users] external archiver In-Reply-To: <20040409003150.GH655@nazgul.mejo.net> References: <20040409003150.GH655@nazgul.mejo.net> Message-ID: <20040409114448.GC650@nazgul.mejo.net> On 09/04/2004 To Mailman-Users wrote: > sorry, i absolutely have no idea what I did wrong, and I CCed this > message to -developers since there seems to be no documented common > usage of the EXTERNAL_ARCHIVER options. > Maybe the message isn't passed to the shell command on stdin because > other delivery method is expected, but i don't believe that. is there any documented common way of using the *_EXTERNAL_ARCHIVER options? Apart from the fact that the value has to be a shell command, I was not able to get any information about their usage. Does mailman give the message on stdin to the shell command, or is this command intended to use the mbox mailman also archives to or how should the external archiver get the message? > Additional, what exactly does this ARCHIVE_TO_MBOX option do? > Defaults.py tells me: > # 1 - archive to mbox to use an external archiving mechanism only > [...] > does this mean that mailman archives to an mbox file? > if yes, where can i find this mbox file? seems like this option defines whether mailman archives only to pipermail or mbox, both or none of these. The mbox file is stored at $ARCHIVE_PATH/private/mylist.mbox/mylist.mbox, is this correct? bye jonas From fil at rezo.net Fri Apr 9 07:53:16 2004 From: fil at rezo.net (Fil) Date: Fri Apr 9 07:52:26 2004 Subject: [Mailman-Developers] Re: [Mailman-Users] external archiver In-Reply-To: <20040409114448.GC650@nazgul.mejo.net> References: <20040409003150.GH655@nazgul.mejo.net> <20040409114448.GC650@nazgul.mejo.net> Message-ID: <20040409115316.GG19425@rezo.net> > pipermail or mbox, both or none of these. The mbox file is stored at > $ARCHIVE_PATH/private/mylist.mbox/mylist.mbox, is this correct? Yes ; and it's a pity that it's not stored in a Maildir format, which would ease many things, especially backups and web-scripts to tap the archives (the static mhonarc-like thing is really old-fashioned). -- Fil From terri at zone12.com Fri Apr 9 17:48:52 2004 From: terri at zone12.com (Terri Oda) Date: Fri Apr 9 17:49:01 2004 Subject: [Mailman-Developers] Mailman + postfix + amavisd-new HOWTO In-Reply-To: <20040408202142.GB30121@rezo.net> References: <20040408202142.GB30121@rezo.net> Message-ID: This'd be a great thing to have linked in the FAQ (as well as our documentation pages?). Would you be interested in doing this? You can add it yourself (the url is http://www.python.org/cgi-bin/faqw-mm.py and the password is Mailman) or, if you don't have time, I can add it (or a link to it) for you. Thanks for taking the time to put all this info in a nice compact form. Terri From fil at rezo.net Fri Apr 9 18:05:50 2004 From: fil at rezo.net (Fil) Date: Fri Apr 9 18:04:55 2004 Subject: [Mailman-Developers] Mailman + postfix + amavisd-new HOWTO In-Reply-To: References: <20040408202142.GB30121@rezo.net> Message-ID: <20040409220550.GA29874@rezo.net> > This'd be a great thing to have linked in the FAQ (as well as our Thanks. I've put in in section 6 (integration issues). There are still some things to check: for example, if you look carefully the regexp I use, it is too simple, as you can send viruses and spam to the address troll@domain.tld by abusing the + delimiter, such as in: troll+-bounces@domain.tld And I still have no clue if the number of amavis processes is right. Today I sent out 40000 emails, and the pipe was clogged for about 15 minutes. Will try next month with a bit more :-) If I understand correctly, this FAQ is editable by anyone? So feel free to update and annotate the file, but in that case please email me. -- Fil From roth at feep.net Mon Apr 12 01:38:48 2004 From: roth at feep.net (Mark D. Roth) Date: Mon Apr 12 10:14:20 2004 Subject: [Mailman-Developers] Avoiding setgid Binaries and Directories Message-ID: <20040412053848.GA29835@starbase.feep.net> I've just recently started playing around with Mailman, so I apologize in advance if this is an FAQ, or if I'm sending this to the wrong forum, etc. Any etiquette corrections would be greatly appeciated. :) I think I've found a way to install Mailman without the need for setgid files and directories, but I'd like to get a sanity check from people who are more familiar with the code than I am, just to make sure that there aren't any security implications in how I have things configured. Here's how I've set things up. Basicly, I solved the problem by using external mechanisms to ensure that the Mailman binaries are always executed as user and group mailman. For the CGI scripts, there is suEXEC. For the mail interface, there is the Procmail MTA handler, which was posted on SourceForge: http://sourceforge.net/tracker/index.php?func=detail&aid=723918&group_id=103&atid=300103 Because these external mechanisms take care of all of the uid/gid changing, I built Mailman with "--with-mail-gid=mailman --with-cgi-gid=mailman". Now here's the complication. I'm trying to build a distributable binary package of Mailman, and I'd like it to be usable in different environments. In particular, I'd like to use the same package in my environment, where I avoid the setgid bit as described above, as well as in other environments, which may still use the normal setgid approach. However, if I build with "--with-mail-gid=mailman --with-cgi-gid=mailman", then the package isn't really usable in other environments, since most mailers and web servers will not be invoking the binaries as group "mailman". I would prefer to build the package with something like "--with-mail-gid=mailnull --with-cgi-gid=httpd", which is more likely to be useful on other people's systems. To solve this problem, I propose that the wrapper code be modified to allow execution by MAILMAN_GROUP in addition to the "--with-mail-gid" and "--with-cgi-gid" values. My thought is that this shouldn't present a security risk, since the setregid() call wouldn't give the caller any permissions that it doesn't already have. In fact, there's no point in calling setregid() to begin with in this case, since it's already running as group MAILMAN_GROUP; the wrapper can simply exec the binary. So, my question is, are there any security issues I haven't thought of with respect to the configuration I'm using in my environment? If not, does anyone see any problem with modifying the wrapper code as I suggest? If this seems like a reasonable change, I'd be happy to submit a patch. Thanks in advance for your feedback! -- Mark D. Roth http://www.feep.net/~roth/ From lloyd_tennison at whoever.com Mon Apr 12 17:27:44 2004 From: lloyd_tennison at whoever.com (Lloyd F. Tennison) Date: Mon Apr 12 17:27:53 2004 Subject: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman In-Reply-To: References: Message-ID: <407AA760.28086.FE16383@localhost> I know this might be simplistic, and I cannot get it to work, but the Defaults.py say the following: # These variables controls how headers must be cleansed in order to be # accepted by your NNTP server. Some servers like INN reject messages # containing prohibited headers, or duplicate headers. The NNTP server may # reject the message for other reasons, but there's little that can be # programmatically done about that. See Mailman/Queue/NewsRunner.py # # First, these headers (case ignored) are removed from the original message. NNTP_REMOVE_HEADERS = ['nntp-posting-host', 'nntp-posting-date', 'x- trace', 'x-complaints-to', 'xref', 'date-received', 'posted', 'posting-version', 'relay-version', 'received'] # Next, these headers are left alone, unless there are duplicates in the # original message. Any second and subsequent headers are rewritten to the # second named header (case preserved). NNTP_REWRITE_DUPLICATE_HEADERS = [ ('to', 'X-Original-To'), ('cc', 'X-Original-Cc'), ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), ('mime-version', 'X-MIME-Version'), ] I was trying to use it to remove X-Mailer and X-Url codes, but as I read it this should also remove the original received header - which would be great for announce only lists. Since my IP is in the header my attacks on my personal machine get out of hand by pop-up spammers. Thanks. Lloyd F. Tennison lloyd_tennison@whoever.com No trees were harmed in the transmission of this message. However, a rather large number of electrons were temporarily inconvenienced. From jack.bradach at oregonstate.edu Mon Apr 12 18:50:17 2004 From: jack.bradach at oregonstate.edu (Bradach, Jack) Date: Mon Apr 12 18:52:50 2004 Subject: [Mailman-Developers] Mailman "Already Subscribed" behavior. Message-ID: <2B8B2BD3A0D58F41B0F28F215AF4901D7638B7@mtadams.nws.oregonstate.edu> Hello, I've noticed that Mailman's "You're already subscribed to this list" behavior isn't consistent between the web and email interfaces. Specifically, if you send a message to listname-join@domain.tld, it kicks you a brief "you are already subscribed to this list" message. However, if you subscribe from the web interface (and are already a member), it has a long message about how it could be a security violation (or nothing to worry about!). Any chance someone can change it kicks out the same message no matter how you try to double-subscribe? (Or even better, allow the site admin to change that message. It doesn't look like it's one of the messages that site admins can edit.) Thanks! Jack Bradach List Support list-support@orst.edu 541-737-3474 From lloyd_tennison at whoever.com Mon Apr 12 19:18:14 2004 From: lloyd_tennison at whoever.com (Lloyd F. Tennison) Date: Mon Apr 12 19:18:05 2004 Subject: [Mailman-Developers] images embedded in html: inline vs. attached Message-ID: <407AC146.27719.10468B7F@localhost> Why not just do the images as embedded from your website? I send out this type all the time and it works well.. As an added bonus you can see how many emails are opened by looking at the hits on the files from the web server. Just make sure you know how to do slices so that the images are easy to download and read. This also cuts the delivery time greatly - there are no files to send. Thanks. Lloyd F. Tennison lloyd_tennison@whoever.com No trees were harmed in the transmission of this message. However, a rather large number of electrons were temporarily inconvenienced. From John.Airey at rnib.org.uk Tue Apr 13 06:55:47 2004 From: John.Airey at rnib.org.uk (John.Airey@rnib.org.uk) Date: Tue Apr 13 06:56:02 2004 Subject: [Mailman-Developers] double dash or single dash to commence signatures? Message-ID: <9B66BBD37D5DD411B8CE00508B69700F05ADDEED@pborolocal.rnib.org.uk> I have noticed that mailman uses a double dash to end message commands. I was under the impression that a dash followed by a space (which we currently have in our disclaimer) was correct. This certainly works with majordomo, which is what we used to use until I became tired of the enormous amount of administration that it took just to set up one list. Does anyone on this list know which RFC states which is the correct one? If of course both are valid would you be able to patch mailman to allow "end","--" and "- "? -- John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey@rnib.org.uk Every person who has set out to disprove the resurrection of Jesus Christ has changed their mind after examining the evidence in detail. - DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk From philb at philb.us Tue Apr 13 20:18:34 2004 From: philb at philb.us (Phil Barnett) Date: Tue Apr 13 20:16:33 2004 Subject: [Mailman-Developers] double dash or single dash to commence signatures? In-Reply-To: <9B66BBD37D5DD411B8CE00508B69700F05ADDEED@pborolocal.rnib.org.uk> References: <9B66BBD37D5DD411B8CE00508B69700F05ADDEED@pborolocal.rnib.org.uk> Message-ID: <200404132018.37353.philb@philb.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 13 April 2004 6:55 am, John.Airey@rnib.org.uk wrote: > I have noticed that mailman uses a double dash to end message commands. I > was under the impression that a dash followed by a space (which we > currently have in our disclaimer) was correct. This certainly works with > majordomo, which is what we used to use until I became tired of the > enormous amount of administration that it took just to set up one list. > > Does anyone on this list know which RFC states which is the correct one? > > If of course both are valid would you be able to patch mailman to allow > "end","--" and "- "? The correct signature separator is (as below) dash-dash-space-linefeed Don't know if it was ever an RFC, but it does descend from usenet. - -- "The choices we make dictate the life we lead. To thine ownself be true." -- William Shakespeare KI4DPT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAfINaWMqSOYd58pwRAofkAJ4vssovA+OdsfcoTSHApqJyw2iKBwCfWJrs uuIFIEWbY+fnFYyd+zvnhUQ= =5EdA -----END PGP SIGNATURE----- From mamandel at ldc.upenn.edu Wed Apr 14 13:56:21 2004 From: mamandel at ldc.upenn.edu (Mark A. Mandel) Date: Wed Apr 14 13:56:25 2004 Subject: [Mailman-Developers] Re: double dash or single dash to commence signatures? In-Reply-To: References: Message-ID: #From: Phil Barnett # #On Tuesday 13 April 2004 6:55 am, John.Airey@rnib.org.uk wrote: #> I have noticed that mailman uses a double dash to end message commands. I #> was under the impression that a dash followed by a space (which we #> currently have in our disclaimer) was correct. This certainly works with #> majordomo, which is what we used to use until I became tired of the #> enormous amount of administration that it took just to set up one list. #> #> Does anyone on this list know which RFC states which is the correct one? #> #> If of course both are valid would you be able to patch mailman to allow #> "end","--" and "- "? # #The correct signature separator is (as below) # #dash-dash-space-linefeed # #Don't know if it was ever an RFC, but it does descend from usenet. Part of this confusion may be due to the fact that there is no such character as "dash" in ASCII. '-' is a minus sign or hyphen. (http://www.bbsinc.com/iso8859.html; http://www.w3.org/MarkUp/html3/latin1.html) English punctuation has at least three characters that look more or less like that. Editors argue back and forth over whether the en dash and the em dash are both needed, but at least the em dash -- or just dash, for short -- is logically very different from the hyphen. Hyphens link words, as in "state-of-the-art interface", or parts of words, as in could cause a con- stitutional crisis Dashes separate parts of sentences, as in the end of the paragraph before last. Rendering a dash in ASCII, descended from doing so on a typewriter, is best done with two hyphens, preferably with a space after and possibly before as well. If somebody saw "-- " and described it as "dash-space", and someone else implemented that description as "- ", we'd wind up with what we have. #"The choices we make dictate the life we lead. To thine ownself be true." -- #William Shakespeare "This above all: to thine own self be true, And it must follow, as the night the day, Thou canst not then be false to any man." William Shakespeare, Hamlet, Act I, scene 3. "The choices we make dictate the life we lead." 116 hits on Google, many of them linked with the above six words of Shakespeare (written as five). "Never argue with a pedant over nomenclature. It wastes your time and annoys the pedant." Lois McMaster Bujold, _Memory_ -- Dr. Whom, Consulting Linguist, Grammarian, Orthoepist, & Philological Busybody a.k.a. Mark A. Mandel From egeorge at gedochin.com Thu Apr 15 05:08:11 2004 From: egeorge at gedochin.com (egeorge@gedochin.com) Date: Thu Apr 15 05:08:19 2004 Subject: [Mailman-Developers] Can I Change the Name of a Mail List? Message-ID: <20040415020811.22102.h006.c007.wm@mail.gedochin.com.criticalpath.net> For simply testing the Mail List on my website, I created one with a non-relevant name. Having seen it working, can I change the name? Thanks _____________________________________________________________________ BatteryMax has a special price for Ghanaian clients. Visit http://gedochin.com/product_description/product1_1.html for details. Go to http://3webooks.com/ for online money-making secrets. _____________________________________________________________________ If replying directly, remove the spam trap from my address From somuchfun at atlantismail.com Thu Apr 15 06:18:16 2004 From: somuchfun at atlantismail.com (Somuchfun) Date: Thu Apr 15 06:18:44 2004 Subject: [Mailman-Developers] (no subject) Message-ID: A friend asked me for help about some mailman questions. He wrote an email to some of the people behind mailman but never got a reply. So I am posting these questions for him here on the list. Would be nice if someone could comment. thx -------------------------------------- 1. I have one mailman list with 50,000 members. I found numerous people who have been suspended due to bounces back in January but still are not purged. Does mailman not do a purge run from time to time? If not how can I purge these suspended members? 2. Using a dual xeon 1.8 server with 2GB of ram I still have the problem that the web interface is not responding when sending out a message. Looking at the cpu and memory stats it seems mailman grabs all resources and leaves the web interface unusable. This has gotten so bad that people complained that they cannot unsubscribe after receiving the message. 3. Is there any way to see how many of the total members shown on the membership page are suspended and for what reasons? 4. The bounce setting seems to be set by member and not for the whole list? Here is the scenario: I set the bounce setting to send after 2 bounces 3 attempts each 7 days apart. So I send the first message. Bounces come back. Then I change the bounce setting to 0 so all members who have bounces 2 times are suspended and purged right away. I send out the second time. And I see after that in the queue messages telling people that they have bounced 2 times and will receive 2! more notifications. This would mean they got the first bounce setting and not the last one. How can this be? ---------------------------------- From brad.knowles at skynet.be Thu Apr 15 07:14:22 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu Apr 15 07:15:29 2004 Subject: [Mailman-Developers] (no subject) In-Reply-To: References: Message-ID: At 3:18 AM -0700 2004/04/15, Somuchfun wrote: > 2. Using a dual xeon 1.8 server with 2GB of ram I still have the problem > that the web interface is not responding when sending out a message. Looking > at the cpu and memory stats it seems mailman grabs all resources and leaves > the web interface unusable. This has gotten so bad that people complained > that they cannot unsubscribe after receiving the message. This is a known performance issue with some large lists. I don't know what kind of disk subsystem you have, but if you can use a RAID 0+1 array with high-speed disks on an intelligent hardware controller with battery-backed write-back cache, and you enable certain filesystem features (depending on your OS), this may help significantly improve your performance. In my experience, most performance problems with large mailing lists and large mail systems come down to inadequate disk I/O capacity (operations per second, not read or write throughput), and doing this kind of thing is the best/most reliable way to get the kind of performance you're likely to need. You don't need CPU for this. Once you get a certain amount of RAM, adding more isn't likely to help you very much. What you really need is a robust and killer-fast disk I/O subsystem. See the archives for more information on this subject, and also Mailman FAQ entries , , , , and . Then, depending on whether you use Exim, Sendmail, Postfix, or Qmail, see , , , or , respectively. There's lots of good extra stuff mentioned at the top of , so even if you use an MTA other than Sendmail, I recommend that you check out this entry. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From staiger at staiger-service.de Fri Apr 16 04:52:12 2004 From: staiger at staiger-service.de (Sebastian Staiger) Date: Fri Apr 16 04:53:15 2004 Subject: [Mailman-Developers] General overview Message-ID: <407F9EBC.1070604@staiger-service.de> Hello, I'd like to contibute some features to mailman, but i find it quite difficult to get into the structure of it. Is there any documenttion where I can get a general overview of how the different classes interact? I thought of thomething like the "big picture" in the postfix documentation. If there is none, I could think of making one. Do you know if anybody is allready adding real virtual host support (i.e. same list names in different domains)? Has anyone yet implemented a list-membership management with ldap? Sebastian Staiger From jack.bradach at oregonstate.edu Tue Apr 20 12:49:58 2004 From: jack.bradach at oregonstate.edu (Bradach, Jack) Date: Tue Apr 20 12:50:04 2004 Subject: [Mailman-Developers] default setting for "header_filter_rules?" Message-ID: <2B8B2BD3A0D58F41B0F28F215AF4901D7638D3@mtadams.nws.oregonstate.edu> Can the setting "header_filter_rules" be set in mm_cfg.py so that all new lists created will have a default for it? Our site tags all inbound mail with spam-assassin's "X-Spam-Status: YES" and I want to make it reject all mail by default that matches it. The option bounce_matching_headers doesn't quite do what I want, since it (despite what the name suggests) holds the message for owner approval rather than bouncing it. Is there any reason it does that? :) Thanks! Jack Bradach List Support list-support@orst.edu 541-737-3474 From lloyd_tennison at whoever.com Wed Apr 21 04:18:21 2004 From: lloyd_tennison at whoever.com (Lloyd F. Tennison) Date: Wed Apr 21 04:18:36 2004 Subject: [Mailman-Developers] Cpanel is trying to work on a couple of Mailman Issues - but We Need Help Message-ID: <4085CBDD.3941.AB4062@localhost> We have the senior programmer at Cpanel trying to solve a couple of issues, * that no uncaught bounces exist with lists with over 20,000 (obviously wrong) with personalization on. * That Challenge/Verfiies disappear with personalization on, etc. The problem is, they say that do not have access to a Mailman install without Cpanel. If someone is willing to help us out with a non-Cpanel install on Mailman - so they can see how it is supposed to work, please let me know so that I can converse with them. (Also, if there are any other glaring issues - maybe they can look at them at the same time - but no promises.) Thanks. Lloyd F. Tennison lloyd_tennison@whoever.com No trees were harmed in the transmission of this message. However, a rather large number of electrons were temporarily inconvenienced. From jon at csh.rit.edu Thu Apr 22 16:21:13 2004 From: jon at csh.rit.edu (Jon Parise) Date: Thu Apr 22 16:21:24 2004 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman3 getstuff.sh, 3.4, 3.5 In-Reply-To: References: Message-ID: <20040422202112.GA4461@csh.rit.edu> On Thu, Apr 22, 2004 at 07:54:40AM -0700, bwarsaw@users.sourceforge.net wrote: > zconfig_version=ZConfig-2.2 > if [ ! -d $zconfig_version ] > then > - wget http://zope.org/Members/bwarsaw/MailmanDesignNotes/ZConfig-2.2.tar.bz2 > + wget http://zope.org/Members/fdrake/zconfig/ZConfig-2.2.tar.bz2 > tar jxf ${zconfig_version}.tar.bz2 Perhaps the 'wget' URL should also use $zconfig_version? -- Jon Parise (jon@csh.rit.edu) :: http://www.csh.rit.edu/~jon/ From ned at mac.com Thu Apr 22 22:31:45 2004 From: ned at mac.com (Ned Holbrook) Date: Thu Apr 22 22:32:09 2004 Subject: [Mailman-Developers] 2.1.2 permissions error Message-ID: Hello all, I'm installing Mailman 2.1.2 from the RedHat 9 source RPM and can't seem to access any of the web scripts. I've included various results below; does anyone have any suggestions as to how I might resolve this issue? Thanks, Ned --- [ned@sven bin]$ ls -l /var/log/mailman total 15 -rw-rw-r-- 1 mailman mailman 322 Apr 22 18:43 error -rw-rw-r-- 1 mailman mailman 1260 Apr 21 13:29 post -rw-rw-r-- 1 mailman mailman 7065 Apr 22 18:55 qrunner -rw-rw-r-- 1 mailman mailman 2063 Apr 22 18:55 smtp -rw-rw-r-- 1 mailman mailman 728 Apr 21 13:29 smtp-failure -rw-rw-r-- 1 root mailman 193 Apr 21 11:42 subscribe [ned@sven bin]$ pwd /var/mailman/bin [ned@sven bin]$ sudo ./check_perms No problems found [ned@sven bin]$ --- Bug in Mailman version 2.1.2 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 68, in run_main immediate=1) File "/var/mailman/Mailman/Logging/StampedLogger.py", line 52, in __init__ Logger.__init__(self, category, nofail, immediate) File "/var/mailman/Mailman/Logging/Logger.py", line 49, in __init__ self.__get_f() File "/var/mailman/Mailman/Logging/Logger.py", line 67, in __get_f 1) File "/usr/lib/python2.2/codecs.py", line 496, in open file = __builtin__.open(filename, mode, buffering) IOError: [Errno 13] Permission denied: '/var/log/mailman/error' Python information: VariableValue sys.version 2.2.3 (#1, Aug 8 2003, 08:44:02) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-13)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 Environment variables: VariableValue HTTP_COOKIE PHPSESSID=3466d0405189bbc9ac394ef34b4bea73 SCRIPT_FILENAME /var/mailman/cgi-bin/listinfo PYTHONPATH /var/mailman SERVER_SOFTWARE Apache/2 SERVER_ADMIN webmaster@spflrc.org SCRIPT_NAME /mailman/listinfo SERVER_SIGNATURE REQUEST_METHOD GET HTTP_HOST www.spflrc.org SERVER_PROTOCOL HTTP/1.1 QUERY_STRING REQUEST_URI /mailman/listinfo HTTP_ACCEPT */* HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/137 (KHTML, like Gecko) Safari/137 HTTP_CONNECTION keep-alive SERVER_NAME www.spflrc.org REMOTE_ADDR 17.213.14.246 REMOTE_PORT 54326 HTTP_ACCEPT_LANGUAGE en, ja;q=0.92, ja-jp;q=0.96, fr;q=0.88, de-de;q=0.85, de;q=0.81, es;q=0.77, it-it;q=0.73, it;q=0.69, nl-nl;q=0.65, nl;q=0.62, sv-se;q=0.58, sv;q=0.54, no-no;q=0.50, no;q=0.46, da-dk;q=0.42, da;q=0.38, fi-fi;q=0.35, fi;q=0.31 SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip, deflate;q=1.0, identity;q=0.5, *;q=0 SERVER_ADDR 66.220.29.254 DOCUMENT_ROOT /var/www/html From rommel at suse.de Fri Apr 23 05:19:08 2004 From: rommel at suse.de (Heiko Rommel) Date: Fri Apr 23 05:17:10 2004 Subject: [Mailman-Developers] moving mm_cfg.py Message-ID: Hello, since the site configuration file mm_cfg.py - typically located in /usr/lib/mailman/Mailman/mm_cfg.py or /usr/local/mailman/Mailman/mm_cfg.py - is a configuration file, I would like to move it to a configuration or state directory like /etc or /var to be LSB conform. Is there some easy support for this in Mailman ? -- Heiko Rommel rommel@suse.de SUSE Linux AG, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 741 77 55 From lloyd_tennison at whoever.com Fri Apr 23 05:29:16 2004 From: lloyd_tennison at whoever.com (lloyd_tennison@whoever.com) Date: Fri Apr 23 05:29:02 2004 Subject: [Mailman-Developers] Re: [ mailman-Bugs-940497 ] substitute poster's address but keep name Message-ID: What client ----- Original Message --------------- >Return-Path: >Received: from spf6.us4.outblaze.com (205.158.62.33) by mta4.wss.scd.yahoo.com (7.0.016) > id 408811160004A6AD for lloyd@danandben.com; Thu, 22 Apr 2004 21:47:55 -0700 >Received: from mail.python.org (mail.python.org [12.155.117.29]) > by spf6.us4.outblaze.com (Postfix) with ESMTP id 4C491539A7 > for ; Fri, 23 Apr 2004 04:43:34 +0000 (GMT) >Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org) > by mail.python.org with esmtp (Exim 4.22) > id 1BGsbS-0004aP-VI; Fri, 23 Apr 2004 00:47:54 -0400 >Received: from sc8-sf-sshgate.sourceforge.net ([66.35.250.220]) > by mail.python.org with esmtp (Exim 4.22) id 1BGsbQ-0004VZ-Ac > for mailman-coders@python.org; Fri, 23 Apr 2004 00:47:52 -0400 >Received: from sc8-sf-web4-b.sourceforge.net ([10.3.1.24] > helo=sc8-sf-web4.sourceforge.net) > by sc8-sf-sshgate.sourceforge.net with esmtp (Exim 3.36 #1 (Debian)) > id 1BGsbP-000831-00; Thu, 22 Apr 2004 21:47:51 -0700 >Received: from nobody by sc8-sf-web4.sourceforge.net with local (Exim 3.36 #1 > (Debian)) id 1BGsbP-0003Eh-00; Thu, 22 Apr 2004 21:47:51 -0700 >To: noreply@sourceforge.net >From: "SourceForge.net" >Mime-Version: 1.0 >Content-Type: text/plain; charset="ISO-8859-1" >Message-Id: >Date: Thu, 22 Apr 2004 21:47:51 -0700 >X-Spam-Status: OK (lists-mailman 0.000) >Cc: >Subject: [ mailman-Bugs-940497 ] substitute poster's address but keep name >X-BeenThere: mailman-coders@python.org >X-Mailman-Version: 2.1.5b1 >Precedence: list >Reply-To: mailman-developers@python.org >List-Id: Mailman list for bug and patch messages >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: mailman-coders-bounces@python.org >Errors-To: mailman-coders-bounces@python.org > >Bugs item #940497, was opened at 2004-04-23 04:47 >Message generated for change (Tracker Item Submitted) made by Item Submitter >You can respond by visiting: >https://sourceforge.net/tracker/?func=detail&atid=100103&aid=940497&group_id=103 > >Category: security/privacy >Group: 2.1 (stable) >Status: Open >Resolution: None >Priority: 5 >Submitted By: Pierre Abbat (phma) >Assigned to: Nobody/Anonymous (nobody) >Summary: substitute poster's address but keep name > >Initial Comment: >I was on a list that uses the feature in which the poster's >From: header is replaced with the list address to prevent >spammers from harvesting addresses. Unfortunately, this >makes it impossible, in the second pane of my mail client, to >see who said what. I suggest substituting only the address, >leaving the name intact. For example: >From: Ellie Vator >To: foo@bar.baz >should become >From: Ellie Vator >To: foo@bar.baz >and >From: l.e.vator@otis.com (Ellie Vator) >should become >From: foo@bar.baz (Ellie Vator) >.. > >---------------------------------------------------------------------- > >You can respond by visiting: >https://sourceforge.net/tracker/?func=detail&atid=100103&aid=940497&group_id=103 > >_______________________________________________ >Mailman-coders mailing list >Mailman-coders@python.org >http://mail.python.org/mailman/listinfo/mailman-coders From lloyd_tennison at whoever.com Fri Apr 23 21:10:07 2004 From: lloyd_tennison at whoever.com (Lloyd F. Tennison) Date: Sat Apr 24 07:20:53 2004 Subject: [Mailman-Developers] Getting caught by SPAM Filters because of Mailman handoff Message-ID: <40895BFF.31678.1B0D8A1@localhost> Companies are now starting to block Mailman lists (among others) because of the way the headers are sent out stating the hand-off to the server: Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org) by mail.python.org with esmtp (Exim 4.22) id 1BH7Kx-0001vz-7S; Fri, 23 Apr 2004 16:31:51 -0400 Anything with that format - they are marking as "probable SPAM" Any thoughts on how to zap? Also, as I mine is an announce only list - it would be nice to be able to zap the other received from headers and show the message as coming directly from the server. One webmail program does it - but it cannot send HTML. Received: from localhost.localdomain ([127.0.0.1] helo=mail.python.org) by mail.python.org with esmtp (Exim 4.22) id 1BH7Kx-0001vz-7S; Fri, 23 Apr 2004 16:31:51 -0400 Received: from mydomain.com ([111.111.11.111]) by mail.python.org with esmtp (Exim 4.22) id 1BH7Ko-0001tP-Ph for mailman-users@python.org; Fri, 23 Apr 2004 16:31:42 -0400 BTW - usim exim as MTA. Thanks. Lloyd F. Tennison lloyd_tennison@whoever.com No trees were harmed in the transmission of this message. However, a rather large number of electrons were temporarily inconvenienced. From r.barrett at ftel.co.uk Sat Apr 24 13:16:55 2004 From: r.barrett at ftel.co.uk (Richard Barrett) Date: Sat Apr 24 13:29:52 2004 Subject: [Mailman-Developers] Re: [Mailman-Users] Getting caught by SPAM Filters because of Mailman handoff In-Reply-To: <40895BFF.31678.1B0D8A1@localhost> References: <40895BFF.31678.1B0D8A1@localhost> Message-ID: <2FB99A22-9613-11D8-92AB-000A957C9A50@ftel.co.uk> On 24 Apr 2004, at 02:10, Lloyd F. Tennison wrote: > Companies are now starting to block Mailman lists (among others) > because of the way the headers are sent out stating the hand-off to > the server: > > Received: from localhost.localdomain ([127.0.0.1] > helo=mail.python.org) > by mail.python.org with esmtp (Exim 4.22) > id 1BH7Kx-0001vz-7S; Fri, 23 Apr 2004 16:31:51 > -0400 > > > Anything with that format - they are marking as "probable SPAM" > > Any thoughts on how to zap? > Although I run the outgoing MTA and Mailman on the same machine, my Mailman SMTP configuration tells it not to address the MTA using localhost (127.0.0.1) but by the FQDN and IP number which appears in our globally published MX record for that server. Thus the Received: header added by the outbound MTA at this juncture refers to reception form a host (itself) which is resolvable via DNS to an MX record by MTAs which subsequently handle the message. In that respect, it is thus fairly indistinguishable from other Received: headers that precede and follow it. Would this be avoid triggering the approach in anti-spam measures you refer to? > Also, as I mine is an announce only list - it would be nice to be able > to zap the other received from headers and show the message as > coming directly from the server. One webmail program does it - but > it cannot send HTML. > > Received: from localhost.localdomain ([127.0.0.1] > helo=mail.python.org) > by mail.python.org with esmtp (Exim 4.22) > id 1BH7Kx-0001vz-7S; Fri, 23 Apr 2004 16:31:51 > -0400 > Received: from mydomain.com ([111.111.11.111]) > by mail.python.org with esmtp (Exim 4.22) id > 1BH7Ko-0001tP-Ph > for mailman-users@python.org; Fri, 23 Apr 2004 > 16:31:42 -0400 > > > BTW - usim exim as MTA. > > > > Thanks. > > Lloyd F. Tennison > lloyd_tennison@whoever.com > > No trees were harmed in the transmission of this > message. > However, a rather large number of electrons were > temporarily > inconvenienced. From lloyd_tennison at whoever.com Sat Apr 24 14:00:11 2004 From: lloyd_tennison at whoever.com (Lloyd F. Tennison) Date: Sat Apr 24 14:00:14 2004 Subject: [Mailman-Developers] Re: [Mailman-Users] Getting caught by SPAM Filters because of Mailman handoff In-Reply-To: <2FB99A22-9613-11D8-92AB-000A957C9A50@ftel.co.uk> References: <40895BFF.31678.1B0D8A1@localhost> Message-ID: <408A48BB.6968.54D9741@localhost> How did you change the configuration to accomplish that, please. Copies to: mailman-users@python.org, mailman-developers@python.org From: Richard Barrett Subject: Re: [Mailman-Users] Getting caught by SPAM Filters because of Mailman handoff Date sent: Sat, 24 Apr 2004 18:16:55 +0100 To: lloyd_tennison@whoever.com > On 24 Apr 2004, at 02:10, Lloyd F. Tennison wrote: > > > Companies are now starting to block Mailman lists (among others) > > because of the way the headers are sent out stating the hand-off to > > the server: > > > > Received: from localhost.localdomain ([127.0.0.1] > > helo=mail.python.org) > > by mail.python.org with esmtp (Exim 4.22) > > id 1BH7Kx-0001vz-7S; Fri, 23 Apr 2004 16:31:51 > > -0400 > > > > > > Anything with that format - they are marking as "probable SPAM" > > > > Any thoughts on how to zap? > > > > Although I run the outgoing MTA and Mailman on the same machine, my > Mailman SMTP configuration tells it not to address the MTA using > localhost (127.0.0.1) but by the FQDN and IP number which appears in > our globally published MX record for that server. Thus the Received: > header added by the outbound MTA at this juncture refers to reception > form a host (itself) which is resolvable via DNS to an MX record by > MTAs which subsequently handle the message. In that respect, it is thus > fairly indistinguishable from other Received: headers that precede and > follow it. > > Would this be avoid triggering the approach in anti-spam measures you > refer to? > > > Also, as I mine is an announce only list - it would be nice to be able > > to zap the other received from headers and show the message as > > coming directly from the server. One webmail program does it - but > > it cannot send HTML. > > > > Received: from localhost.localdomain ([127.0.0.1] > > helo=mail.python.org) > > by mail.python.org with esmtp (Exim 4.22) > > id 1BH7Kx-0001vz-7S; Fri, 23 Apr 2004 16:31:51 > > -0400 > > Received: from mydomain.com ([111.111.11.111]) > > by mail.python.org with esmtp (Exim 4.22) id > > 1BH7Ko-0001tP-Ph > > for mailman-users@python.org; Fri, 23 Apr 2004 > > 16:31:42 -0400 > > > > > > BTW - usim exim as MTA. > > > > > > > > Thanks. > > > > Lloyd F. Tennison > > lloyd_tennison@whoever.com > > > > No trees were harmed in the transmission of this > > message. > > However, a rather large number of electrons were > > temporarily > > inconvenienced. > Thanks. Lloyd F. Tennison lloyd_tennison@whoever.com No trees were harmed in the transmission of this message. However, a rather large number of electrons were temporarily inconvenienced. From barry at python.org Sat Apr 24 23:47:34 2004 From: barry at python.org (Barry Warsaw) Date: Sat Apr 24 23:47:50 2004 Subject: [Mailman-Developers] Mailman 2.1.5 release candidate 2 Message-ID: <1082864853.29380.35.camel@anthem.wooz.org> I've just uploaded Mailman 2.1.5 release candidate 2 (no, you never saw rc1 :). Since there are some fairly significant changes with this version, I felt it was necessary to put out a release candidate to hopefully prompt some additional testing. If you're able to test the new version, that would be great, but please note that: * The file format for on-disk messages in the qrunners has changed. Until now, each queued message was represented by two files, a .msg and a .pck file. With this version, all information is kept in the .pck file. This improves stability and performance. The upgrade script will attempt to convert all your existing .msg/.pck files to the single .pck file, but there may still be lurking problems with this conversion. * The pending database has been changed from a global pickle file living in $prefix/data, to a unique pickle file per mailing list. The upgrade script attempts to determine which list each pending request belongs to, but it isn't always possible to know, so while it does the best it can, there may still be lurking problems with this conversion. If you upgrade you should do so only on a quiet system. I recommend shutting down Mailman, your MTA, and your web server before doing the upgrade. Please note any problems you have with the conversion scripts (you may want to make backups first ;). My thanks for not letting the above discourage you from testing the new version. :) I think the improvements in 2.1.5 are worth it, and based on experiences running python.org, the new version should be quite stable once installed. I plan to release 2.1.5 final sometime next weekend. -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/20040424/e7485342/attachment.bin From bill at celestial.com Fri Apr 2 14:56:15 2004 From: bill at celestial.com (Bill Campbell) Date: Sat Apr 24 23:51:54 2004 Subject: [Mailman-Developers] Virus sent to lists "from" my domain - add password for mods In-Reply-To: <00a901c40abe$2e47add0$6401a8c0@desktop> References: <00a901c40abe$2e47add0$6401a8c0@desktop> Message-ID: <20040402195611.GA13709@alexis.mi.celestial.com> On Mon, Mar 15, 2004, Arthur Gibbs wrote: >Using Mailman 2.1.3, we have had problems with virus-generated messages with >spoofed senders getting through to a one-way list. > >The only 'solution' I have found is to to disallow any non-moderated users >or administrators. This forces all messages, even from list admins, to be >moderated. > >Under Privacy options: [Recipient filters], we set "Ceiling on acceptable >number of recipients for a posting" to 1. > >And also turned on 'Emergency moderation of all list traffic is enabled' in >General Options. > >However this is not ideal. Back in the dark ages I used Majodomo. As >primtive as that program was, these virus messages would not be getting >through. Reason? The moderated users had to include a password with each >post. Could that password type feature be added? > >A virus might forge the 'form' and the envelope. But it is aweful hard to >forge a good password that also matches that from. > >Any thoughts? Enable Spamassassin, and assign a very high value to MICROSOFT_EXECUTABLE and MIME_SUSPECT_NAME. Bill -- INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ ``Never chastise a Windows user...just smile at them kindly as you would a disadvantaged child.'' WBM From kesilfie at africaonline.com.gh Wed Apr 14 08:03:26 2004 From: kesilfie at africaonline.com.gh (Geo Essilfie) Date: Sat Apr 24 23:56:11 2004 Subject: [Mailman-Developers] Can I Change the Name of a Mail List? Message-ID: <002401c422c6$58d46500$88c055d4@ge02> For simply testing the Mail List on my website, I created one with a non-relevant name. Having seen it working, can I change the name? Thanks _____________________________________________________________________ BatteryMax has a special price for Ghanaian clients. Visit http://gedochin.com/product_description/product1_1.html for details. Go to http://3webooks.com/ for online money-making secrets. _____________________________________________________________________ If replying directly, remove the spam trap from my address From lloyd_tennison at whoever.com Fri Apr 2 21:57:46 2004 From: lloyd_tennison at whoever.com (Lloyd F. Tennison) Date: Sat Apr 24 23:56:45 2004 Subject: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? In-Reply-To: <406E164E.24075.26E5A05@localhost> References: Message-ID: <406DB7B3.30627.BC9FC1@localhost> What makes you think it is Mailman? It does not exist on any of my lists, nor does it exist on the lists I receive from others - including this list. (View this source.) Check you MTA. Maybe that is what is doing it. If Mailman is doing it it is somewhere not mentioned in the documentation and does not do it in all setups. From: "Andrzej Kasperowicz" To: Brad Knowles , mailman-users@python.org, mailman-developers@python.org Date sent: Sat, 03 Apr 2004 01:41:34 +0200 Priority: normal Copies to: Subject: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman? > > At 6:53 PM -0600 2004/03/21, Andrzej Kasperowicz wrote: > > > > > Is there any way to setup mailman to stop distributing X-Confirm-Reading- > > > To requests sent by some list users? > > > > Depending on your MTA, you could configure it to remove various > > types of headers on incoming messages. However, I'm not aware of any > > way to do this within Mailman. > > Well, that's too bad. I've already given an example that in another > mailing list program it is possible to do it: > http://mail.python.org/pipermail/mailman-developers/2004-March/016713.html > > > ak > > ------------------------------------------------------ > Mailman-Users mailing list > Mailman-Users@python.org > http://mail.python.org/mailman/listinfo/mailman-users > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Thanks. Lloyd F. Tennison lloyd_tennison@whoever.com No trees were harmed in the transmission of this message. However, a rather large number of electrons were temporarily inconvenienced. From mtech at duane.com Wed Apr 7 20:58:57 2004 From: mtech at duane.com (mtech@duane.com) Date: Sat Apr 24 23:57:17 2004 Subject: [Mailman-Developers] Re: [Mailman3-dev] Mailman Design In-Reply-To: from "Aaron Schaap" at Apr 05, 2004 01:52:16 PM Message-ID: <20040408010504.68A2BE242BB@ns1.duane.com> Aaron Schaap wrote > > >> By "design" do you mean the web u/i for Mailman? If so, +1 and yep, >> this is the place to be. > >Yes, I mean u/i. I still feel that it would be a good thing to provide a simple, html based user interface that had these items on the left side of the listinfo page to navigate through the different options rather than the blast of text that now happens. [subscribe] {archives} {list options} {members} {post} Is this something that could be added in Mailman 2.1.5 or 2.2 ? >> We need to rethink how (or even if) the u/i will be editable through the >> web. There are all kinds of security and xss issues that need to be >> addressed if we allow this. I tend to think it fails the 80/20 rule -- >> it makes the system more complex for a feature that few use. > >I agree it's not the best to have everything editable. However, that said, >if we do quite a bit of it in CSS, with everything nicely structured and >semantic - people should be able to do quite a bit with the CSS file as far >as look and layout. > >Example: CSS Zen Garden >http://csszengarden.com/ > >This was a project in which designers had to come up with various designs >for the same site. The only catch was that they couldn't touch the HTML and >could only change the CSS to make their designs come alive. > >Using this method, I think we can offer people a huge amount of flexibility >by allowing them to change one single CSS file. > >This is however, just one idea and much more conversation is needed. > >------------------------- >Aaron Schaap >Elevator Up - Internet Consulting & Development >Phone: 616-566-1423 >Web: www.elevatorup.com >Email: aaron.schaap@elevatorup.com > > > >_______________________________________________ >Mailman3-Dev mailing list >Mailman3-Dev@python.org >Unsubscribe: http://mail.python.org/mailman/options/mailman3-dev/mtech%40duane.com > From SHardy at imany.com Fri Apr 2 15:08:24 2004 From: SHardy at imany.com (Scott Hardy) Date: Sat Apr 24 23:57:54 2004 Subject: [Mailman-Developers] Blocking auto reply e-mails Message-ID: <386B53F05331C141921F33C92D2CB6A5028D19CC@EXCHANGE> Does anyone know how to block things like "out of office" replies from hitting the list? Thanks - Scott From ricardo at rixhq.nu Sun Apr 25 05:25:29 2004 From: ricardo at rixhq.nu (Ricardo) Date: Sun Apr 25 05:25:37 2004 Subject: [Mailman-Developers] not metoo not working? Message-ID: <408B8409.90807@rixhq.nu> Hi, I have a few subscribers who use the "not metoo" setting in mailman... but apparently since a few upgrades (i'm now running 2.1.4), it doesn't work anymore: they *do* get their own posts. I tried it myself and I can confirm that if I set my subscription to "not metoo", I get my own post anyway (yes my email adddress is exactly the same as the one i'm subscribed with). Anybody here who experiences the same problem with 2.1.4? or do I need to start digging in the code? :) TIA, Ricardo. From slave at codegrunt.com Sun Apr 25 16:23:40 2004 From: slave at codegrunt.com (Ron Brogden) Date: Sun Apr 25 16:23:44 2004 Subject: [Mailman-Developers] restoring templates 2.1.4 (FAQ probably) Message-ID: <200404251323.40708.slave@codegrunt.com> Howdy. I did my best to find this in all of the FAQs, online docs, INSTALL and UPGRADE readmes (which are somewhat out of date) and had no luck. I just upgraded to 2.14 of Mailman which of course stomped on my nice archive templates which linked to my swish-e searching amongst other things. I've tried editing things in /usr/local/mailman/templates/ but so far these have not taken effect so I am missing something or pipermail is not looking where I think it is looking. Last time I had to mess with the templates was a long way back so I have forgotten what was required exactly. Since the docs don't help and changing stuff like "archidxhead.html" seems to have no effect, I am asking here. =) An expletive or two in my direction followed by directions to where this is documented would be appreciated. Cheers From barry at python.org Mon Apr 26 09:49:09 2004 From: barry at python.org (Barry Warsaw) Date: Mon Apr 26 09:49:28 2004 Subject: [Mailman-Developers] Re: Mailman 2.1.5 release candidate 2 In-Reply-To: <1082864853.29380.35.camel@anthem.wooz.org> References: <1082864853.29380.35.camel@anthem.wooz.org> Message-ID: <1082987348.17933.32.camel@anthem.wooz.org> On Sat, 2004-04-24 at 23:47, Barry Warsaw wrote: > I've just uploaded Mailman 2.1.5 release candidate 2 (no, you never saw > rc1 :). There was something wrong with the tarball, so I just uploaded a new version (along with a new signature and an updated md5sum in the release notes). If you grabbed the 2.1.5c2 tarball before just now, please try again. -Barry From maierg at fs.tum.de Mon Apr 26 13:49:12 2004 From: maierg at fs.tum.de (Gregor Maier) Date: Mon Apr 26 13:49:15 2004 Subject: [Mailman-Developers] Mails shunt: LookupError: unknown encoding: X-UNKNOWN Message-ID: <20040426194912.4d25352f.maierg@fs.tum.de> Hello, I have an "interesting" on some mailinglist. All mails to this list get shunted with the error message: LookupError: unknown encoding: X-UNKNOWN This only happens when digestable is set to true. The funny thing about this, that I cannot figure out when this error occurs. It is only reproduceable on some lists. - Not all lists with the digestable=1 have this phenomen, in fact only a few have it - The problem is indepented from the mailer I use. Other lists work fine with all tested mailers - The listowner told me that he didn't change the digestable option when mails stopped arriving at the list (he just changed the archive from public to private). - The list worked fine for some month before it "stopped working" at the beginning of april - Updating mailman to 2.1.4 and several restarts didn't help - There were no lockfiles that could have caused this problem - Skimming the code in Scrubber.py und Message.py didn't help me. - My current "hotfix" is to disable the digest option on the affected lists. But this cannot be the solution forever.... My setup is a gentoo-linux box with mailman-2.1.4 and python-2.3.3 I have absolutely no clue how this problem was introduced to my system an why it is just limited to some list. There is a (quite old) bugreport about this problem from another guy: http://sourceforge.net/tracker/index.php?func=detail&aid=803729&group_id=103&atid=100103 but there's now hint there were the problem lies. I hope you give a hint were to look for the source of this problem. Mainly I just want to understand what's going on here. Here's the excerpt from my error log: Apr 26 18:27:05 2004 (17449) Uncaught runner exception: unknown encoding: X-UNKNOWN Apr 26 18:27:05 2004 (17449) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 160, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 91, in process send_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 306, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 265, in process url = save_attachment(mlist, part, dir) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 361, in save_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/local/mailman/pythonlib/email/Message.py", line 714, in get_filename return unicode(newvalue[2], newvalue[0] or 'us-ascii') LookupError: unknown encoding: X-UNKNOWN Apr 26 18:27:05 2004 (17449) SHUNTING: 1082996756.746207+e85fdb8b141ccd2a8f0757824f62fbff58 da2ce4 -- Gregor Maier Fachschaft Mathe/Phys/Info Computerreferat From qralston+ml.mailman-developers at andrew.cmu.edu Tue Apr 27 20:23:59 2004 From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston) Date: Tue Apr 27 20:24:07 2004 Subject: removing arbitrary headers [Mailman-Developers] [Mailman-Users] In-Reply-To: <14E3383C-8662-11D8-8B76-0003934516A8@plaidworks.com> References: <40704E69.6515.D517F5@localhost> <40705791.29902.F8D978@localhost> <14E3383C-8662-11D8-8B76-0003934516A8@plaidworks.com> Message-ID: <26260000.1083111839@pcmy.sei.cmu.edu> On 2004-04-04 at 11:01:22-07 Chuq Von Rospach wrote: > I definitely see it as useful to be able to strip out headers that > cause systems to auto-reply with a return receipt. IMHO, this statement can be shortened to "I definitely think it would be useful to strip out arbitrary headers." Case in point: we use SpamAssassin to analyze and tag incoming email (meaning, email received from external sites). All scanned messages receive an "X-Spam-Status" header; messages which scored as probable spam also receive an "X-Spam-Level" header. This permits mailing list owners to add this bounce_matching_headers rule: x-spam-level: \. But we'd like to have these headers removed when the message is distributed to the members of the list. While I can strip those headers at the MTA level (the combination of sendmail + MIMEDefang is a wonderful thing), it can be tricky to do it correctly. I think it would be cleaner to strip them from within Mailman. If, at some point in the future, I feel that my Python skills are up to the task, I'll probably take a crack at implementing something like this. But until then (or until someone else beats me to it), I think it's definitely a good idea. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From anarcat at anarcat.ath.cx Wed Apr 28 12:46:54 2004 From: anarcat at anarcat.ath.cx (The Anarcat) Date: Wed Apr 28 12:47:07 2004 Subject: [Mailman-Developers] True Virtual Hosting With Mailman Hack Message-ID: <20040428164653.GA83269@shall.anarcat.ath.cx> [sourceforge seems to be down, so I post this here] Hi there, We developped a reliable solution for running lists with the same name on different domains on the same Mailman installation. I implemented that on top of the Mailman 2.1.1-5.1 Debian stable package. All that is needed is to patch 2 files (bin/newlist, Mailman/MailList.py) in the mailman install, and here is the patch: http://bugs.koumbit.net/file_download.php?file_id=3&type=bug There's only one caveat right now: Mailman/Cgi/create.py might need to get patched too, but I haven't got around looking at it yet, and it "just works", for now. I don't know what's the current status of virtual hosting support on Mailman, but this patch is a simple hack that should bring joy in the homes of all Mailman admins around the world. :) I got my inspiration and part of the code from: http://mithrandr.moria.org/blog/139.html All it does is to add the domain to the internal_name() of a list. The real_name is kept as is, and the getListAddress() does the Right Thing. This makes Mailman generate aliases like: list-example.com: "|/var/lib/mailman/mail/mailman post list-example.com" Care will have to be taken on the MTA side to map those list-example.com to list@example.com. We are using alternc.org to manage our server, so we are using LDAP, so everything went pretty smoothly. :) But I guess it will require some magic on the Postfix side or something... Cheers, A. PS: for those wanting to see more, you can come to our Wiki: http://koumbit.net/wiki/VirtualMailman You'll probably have a little trouble finding your way if you don't read french though. :) Babelfish might help, haven't tried. ----- End forwarded message ----- From barry at python.org Fri Apr 30 14:35:54 2004 From: barry at python.org (Barry Warsaw) Date: Fri Apr 30 14:36:25 2004 Subject: [Mailman-Developers] not metoo not working? In-Reply-To: <408B8409.90807@rixhq.nu> References: <408B8409.90807@rixhq.nu> Message-ID: <1083350154.3975.5.camel@anthem.wooz.org> On Sun, 2004-04-25 at 05:25, Ricardo wrote: > I have a few subscribers who use the "not metoo" setting in mailman... > but apparently since a few upgrades (i'm now running 2.1.4), it doesn't > work anymore: they *do* get their own posts. I tried it myself and I can > confirm that if I set my subscription to "not metoo", I get my own post > anyway (yes my email adddress is exactly the same as the one i'm > subscribed with). > Anybody here who experiences the same problem with 2.1.4? > or do I need to start digging in the code? :) Works for me w/2.1.5c2. -Barry