Re: [Mailman-Users] Re: remove this?
> The bottom line is, like the original poster of this thread, I > want these headers to go away. Unfortunately, I haven't been able > to find where they are coming from. If someone could simply tell > me what I need to hack in order to get rid of these headers, I > would be grateful. http://nleaudio.com/bnotes/mailman.htm Bob -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
> "BW" == Bill Warner <[EMAIL PROTECTED]> writes: >> But, Mailman could do a better job of conforming to RFC 2369. >> E.g. it could suppress List-Post: for read-only lists, BW> Or, as Chuq mentioned use the List-Post: NO syntax. That's what I meant to say. :) >> Whether that means adding for Mailman 2.1 a list-specific >> configuration option (-1) or a site-wide configuration variable >> (-0), I'm not sure. BW> Thank-you, Barry, for reconsidering this issue. Please cast BW> my vote for a per-list option for the reasons outline in my BW> message to JC. Noted. Thanks. -Barry -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Duplicate emails sent out
Well then I would have to say the duplicates are being created at my end. At 22:58 8/05/01 -0700, Chuq Von Rospach wrote: >On 5/8/01 10:57 PM, "David Casamento" <[EMAIL PROTECTED]> wrote: > > > So from what I can tell, my mailing list server is sending out all the > dups. > >But that doesn't tell you where they're coming from. Who's creating the >duplicates? You? Or someone else? Until you figure that you, you won't >really solve this problem. > > > >-- >Mailman-Users maillist - [EMAIL PROTECTED] >http://mail.python.org/mailman/listinfo/mailman-users -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] Changing Mailman settings globally for groups of users
Hi, Apologies if this is in the archives (how do you search for Mailman specific topics?), but I would like to enable the "hide" option for all subscribers to a particular list. Is there a way to do that from the CLI? -- Juha The malformed orange Fails to satisfy the eye: Segmentation fault. -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
On Wed, 09 May 2001 15:33:47 -0500 Bill Warner <[EMAIL PROTECTED]> wrote: > At 12:15 AM 5/9/01 -0700, J C Lawrence wrote: >> Actually I buy and agree with both arguments, I just consider >> them misplaced in this case. They work very well elsewhere. > I think they are appropriate here too. It just seems to me that > an adamant stance against configurability is actually more harmful > to the stated goal of promoting wider acceptance of 2369 than > allowing a per-list configuration would be. You may be right. I look at it a little differently on the basis that source is available, and that lsit admins, should they so need to, can patch their source locally, and can find the relevant instructions and patches in the archives should they so need to. Unlike a closed source product the door is not slammed or locked shut, there's just a lack of a neon sign telling you where the door is. > Here's why I say that: > (a) Most mailman-owners will run with the defaults anyway, so all > of their messages will still be 2369ized. One of the advantages of the above you-have-to-manually-patch-your-source approach is that most will fail to maintain the patch across upgrades, and thus even if the patch is variously adopted, it will self-select against itself over time. > (b) Those of us that have problems in this area can 2369ize our > lists one, or a few, at a time, where appropriate, and bring our > users along at a rate that we can manage. Since only we can > determine what that rate is, only we can make that decision for > ourselves. Agreed. Use of a good MTA ala Exim can also help here (you can put in delivery time filters to strip the appropriate headers to do whatever to the message(s)). The question has never been about _IF_ you could do it, just about _HOW_. > So, bottom line, I agree that 2369 compliance is good for Mailman > and a worthy goal for all mailman-owners. A per-list > configuration option would make it easier for me, and based on > what I've read in the archive, others, to migrate towards full > 2369 compliance, and therefore more likely that we'll do it. That > sounds like a good thing to me. For reasons previously discussed, I'm not so keen. Tho I do agree that Mailman does not to properly support the concept of an announce-only list, and should reflect that in the List headers. > Anyway, , that's how the picture looks from where I sit. >> Trade offs. The high road. Those that leave are typically >> (experience) better off gone, and (experience) their replacements >> are much more valuable and numerous. > I don't disagree with anything you said here about FAQs, user > education, or customer/list member relations. I think you are > right on all counts. The problem is, that at this particular > moment in time, I simply cannot afford (in time or $$) to take the > high road without just a little bit of help to make doing so a > little bit easier. If I have to deal with this issue on an all or > nothing basis, it's going to be nothing. It is possible that Mailman is not the right MLM for your needs. > In any case, Barry has said he'll consider the 2369 configuration > issue for 2.1, and that's good enough for me! Given the current state of affairs, I would mildly encourage (translation: I won't argue against it) the following: Arbitrary-person-who-is-not-Barry writes a patch to support 2369 configurability and submits it at SourceForge. Minimal effort is excercised not to break the patch across Mailman versions. Anybody who really thinks they need it can grab the patch and head out on their own as/if needed. Its the old, "This is unsupported but you can do it" trick. >> > We now return you to your regularly scheduled program about how >> to > get Mailman to run on the Linux flavor-of-the-day... >> >> Yea gods save us. > Doesn't seem likely. ;-) -- J C Lawrence [EMAIL PROTECTED] -(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] problems with the config.db permissions
> > check_perms should be finding all this; you need to find out what's going > > wrong with check_perms. > > I tested with changing permissions/ownerships around on a few things > to see what check_perms would and would not catch, and found an > something interesting: Check_perms wants to set the gid to 'mail' > and /not/ mailman. But mailman itself spits out errors with this gid > setting. The only way I can see this happening is if Defaults.py or mm_cfg.py has the wrong entry for MAILMAN_GID. from Mailman import mm_cfg from Mailman.mm_cfg import MAILMAN_UID, MAILMAN_GID try: MAILMAN_GRPNAME = grp.getgrgid(MAILMAN_GID)[0] except KeyError: MAILMAN_GRPNAME = '' % MAILMAN_GID -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] problems with the config.db permissions
On Wed, 9 May 2001, Dan Mick wrote: > Doublecheck your version of check_perms; the code is there, and it > works, in 2.0.5. Are you running check_perms from the installed > bin/ directory as the instructions and about a billion posts on this > list say? Yes. I did. > check_perms should be finding all this; you need to find out what's going > wrong with check_perms. I tested with changing permissions/ownerships around on a few things to see what check_perms would and would not catch, and found an something interesting: Check_perms wants to set the gid to 'mail' and /not/ mailman. But mailman itself spits out errors with this gid setting. I have no idea why it worked so far up to this point, or very possibly it never did but the list was not tested to the complete functionality up to this point by the low traffic of my lists. Rather than fight with reinstalling mailman or some other extreme bit of work, I just put mailman in the group 'mail' and now things seem to be running smoothly again. Good grief what a headache this whole fiasco has been, my apologies for the upset. Tib -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] problems with the config.db permissions
Tib ([EMAIL PROTECTED]) said something that sounded like: > [root@unica mailman]# ls -lR lists/|grep config.db Are the directories set-gid? This will help in some cases where things are not ran through a set-gid program. Make sure that they are set to be 2775 (drwxrwsr-x). Ciao, -- Pug Bainter|AMD, Inc. System Engineer, MTS | Mail Stop 625 [EMAIL PROTECTED] | [EMAIL PROTECTED] | 5900 E. Ben White Blvd Phone: (512) 602-0364| Fax: (512) 602-6970 | Austin, TX 78741 Note: The views may not reflect my employers, or even my own for that matter. -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] problems with the config.db permissions
> Check_perms fails to find it, and it's turning into a major problem. Doublecheck your version of check_perms; the code is there, and it works, in 2.0.5. Are you running check_perms from the installed bin/ directory as the instructions and about a billion posts on this list say? > What (exactly) writes and rewrites the config.db file and what are the actual > permissions it's supposed to have? It should be owned by the user who writes it (which might be a lot of places). It should be group mailman, because the directory that it's in should be group mailman, and have the "group-id bit" set so that other file creations in that directory are also done by group mailman, and also because all the programs that write it are themselves sgid-mailman. In the case where you're updating things from the web page, the web server run the CGI program, probably in your case as user "nobody"; the CGI program validates the group it has been run as, and then sets its GID to mailman before continuing. That means all files it creates will be group mailman. check_perms should be finding all this; you need to find out what's going wrong with check_perms. > From ealier reference it sounded as though > it should be owned by nobody (since the webserver > modifies/creates/backs-up/etc) and the group should be mailman. Ok - I can deal > with this - but after manually setting the ownership to be just that - this is > what I get after waiting a while and checking again: > > [root@unica mailman]# ls -lR lists/|grep config.db > -rw-rw1 nobody mailman 9759 May 9 14:14 config.db > -rw-rw1 nobody mailman 9759 May 9 14:14 config.db.last > -rw-rw1 nobody mailman 16876 May 9 15:27 config.db > -rw-rw1 nobody mailman 16876 May 9 15:26 config.db.last > -rw-rw1 nobody mailman 2865 May 3 04:03 config.db > -rw-rw1 nobody mailman 2865 May 3 04:03 config.db.last > -rw-rw1 nobody mailman 3775 May 9 12:00 config.db > -rw-rw1 nobody mailman 3775 May 8 17:00 config.db.last > -rw-rw1 nobody mailman 5123 May 9 14:08 config.db > -rw-rw1 nobody mailman 5123 May 9 14:08 config.db.last > -rw-rw1 nobody mailman 3149 May 9 12:00 config.db > -rw-rw1 nobody mailman 3149 May 8 17:00 config.db.last > > [root@unica mailman]# ls -lR lists/|grep config.db > -rw-rw1 mailman mail 9759 May 9 17:00 config.db > -rw-rw1 nobody mailman 9759 May 9 14:14 config.db.last > -rw-rw1 mailman mail16876 May 9 17:00 config.db > -rw-rw1 nobody mailman 16876 May 9 15:27 config.db.last > -rw-rw1 nobody mailman 2865 May 3 04:03 config.db > -rw-rw1 nobody mailman 2865 May 3 04:03 config.db.last > -rw-rw1 mailman mail 3775 May 9 17:00 config.db > -rw-rw1 nobody mailman 3775 May 9 12:00 config.db.last > -rw-rw1 mailman mail 5123 May 9 17:00 config.db > -rw-rw1 nobody mailman 5123 May 9 14:08 config.db.last > -rw-rw1 mailman mail 3149 May 9 17:00 config.db > -rw-rw1 nobody mailman 3149 May 9 12:00 config.db.last > > As you can see - the ones that get modified have their permissions changed to > 'mailman:mail' and I've seen further changes where it becomes 'nobody:mail' and > then mailman starts spitting errors out right and left and the lists just queue > up messages and don't do anything anymore. Could someone please explain in > detail exactly how it's /supposed/ to happen in a good situation? > > > Tib > > > -- > Mailman-Users maillist - [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/mailman-users -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] problems with the config.db permissions
Check_perms fails to find it, and it's turning into a major problem. What (exactly) writes and rewrites the config.db file and what are the actual permissions it's supposed to have? From ealier reference it sounded as though it should be owned by nobody (since the webserver modifies/creates/backs-up/etc) and the group should be mailman. Ok - I can deal with this - but after manually setting the ownership to be just that - this is what I get after waiting a while and checking again: [root@unica mailman]# ls -lR lists/|grep config.db -rw-rw1 nobody mailman 9759 May 9 14:14 config.db -rw-rw1 nobody mailman 9759 May 9 14:14 config.db.last -rw-rw1 nobody mailman 16876 May 9 15:27 config.db -rw-rw1 nobody mailman 16876 May 9 15:26 config.db.last -rw-rw1 nobody mailman 2865 May 3 04:03 config.db -rw-rw1 nobody mailman 2865 May 3 04:03 config.db.last -rw-rw1 nobody mailman 3775 May 9 12:00 config.db -rw-rw1 nobody mailman 3775 May 8 17:00 config.db.last -rw-rw1 nobody mailman 5123 May 9 14:08 config.db -rw-rw1 nobody mailman 5123 May 9 14:08 config.db.last -rw-rw1 nobody mailman 3149 May 9 12:00 config.db -rw-rw1 nobody mailman 3149 May 8 17:00 config.db.last [root@unica mailman]# ls -lR lists/|grep config.db -rw-rw1 mailman mail 9759 May 9 17:00 config.db -rw-rw1 nobody mailman 9759 May 9 14:14 config.db.last -rw-rw1 mailman mail16876 May 9 17:00 config.db -rw-rw1 nobody mailman 16876 May 9 15:27 config.db.last -rw-rw1 nobody mailman 2865 May 3 04:03 config.db -rw-rw1 nobody mailman 2865 May 3 04:03 config.db.last -rw-rw1 mailman mail 3775 May 9 17:00 config.db -rw-rw1 nobody mailman 3775 May 9 12:00 config.db.last -rw-rw1 mailman mail 5123 May 9 17:00 config.db -rw-rw1 nobody mailman 5123 May 9 14:08 config.db.last -rw-rw1 mailman mail 3149 May 9 17:00 config.db -rw-rw1 nobody mailman 3149 May 9 12:00 config.db.last As you can see - the ones that get modified have their permissions changed to 'mailman:mail' and I've seen further changes where it becomes 'nobody:mail' and then mailman starts spitting errors out right and left and the lists just queue up messages and don't do anything anymore. Could someone please explain in detail exactly how it's /supposed/ to happen in a good situation? Tib -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] argh!! more problems
I'm afraid it doesn't - here's an example: [root@unica mailman]# ls -lR lists/|grep config.db -rw-rw1 nobody mail 9759 May 9 14:14 config.db -rw-rw1 nobody mail 9759 May 9 14:14 config.db.last -rw-rw1 mailman mail16876 May 9 15:27 config.db -rw-rw1 mailman mail16876 May 9 15:26 config.db.last -rw-rw1 mailman mail 2865 May 3 04:03 config.db -rw-rw1 mailman mail 2865 May 3 04:03 config.db.last -rw-rw1 mailman mail 3775 May 9 12:00 config.db -rw-rw1 mailman mail 3775 May 8 17:00 config.db.last -rw-rw1 mailman mail 5123 May 9 14:08 config.db -rw-rw1 mailman mail 5123 May 9 14:08 config.db.last -rw-rw1 mailman mail 3149 May 9 12:00 config.db -rw-rw1 mailman mail 3149 May 8 17:00 config.db.last [root@unica mailman]# ./bin/check_perms /home/mailman/archives/private/notopic/index.html bad gid (has: mailman, expected mail) /home/mailman/archives/private/distrib/index.html bad gid (has: mailman, expected mail) Problems found: 2 It sounds as though the check_perms script would have found all of these in error.. ? Tib On Wed, 9 May 2001, Dan Mick wrote: > Apparently you didn't read what I said. > > > -rw-rw1 nobody mail16875 May 8 18:16 > > /home/mailman/lists/thelist/config.db > > is not group mailman. That would be the problem, and I have to believe > that check_perms would find it, too. > > > > The web server writes it. This is not a problem, because it's owned > > > by group mailman, and write permissions are granted to group mailman. > > > -- > Mailman-Users maillist - [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/mailman-users > -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] argh!! more problems
Apparently you didn't read what I said. > -rw-rw1 nobody mail16875 May 8 18:16 > /home/mailman/lists/thelist/config.db is not group mailman. That would be the problem, and I have to believe that check_perms would find it, too. > > The web server writes it. This is not a problem, because it's owned > > by group mailman, and write permissions are granted to group mailman. -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
On 5/9/01 1:33 PM, "Bill Warner" <[EMAIL PROTECTED]> wrote: > OTOH, a strident "hack it or take a hike" anti-configuration stance (some > of the messages in the archive are downright hostile) actually makes it > harder for me, and others, to migrate towards full 2369 compliance, which > means it ain't gonna happen anytime soon. Why? It creates dialog, which fosters education. If we hadn't had this discussion, but instead had a configuration option, would you have even asked or researched? Probably not. By taking a hard line (and yes, sometimes it's gotten snarky, but usually, someone snarks at the code maintainers first. Usually...) it forces people to at least listen to the rationale before making the decision... > I'll simply hack the 2369 > headers out by the roots and that will be the end of it as far as I'm > concerned. And that, I submit, undermines the goal of rapid widespread > compliance. > > Anyway, , that's how the picture looks from where I sit. Heck, you'd have done that anyway -- but now you know why they're there and why we want them there, and you're doing it anyway. That's a net positive towards adoption, because at least you're making an informed (if, IMHO, wrong) choice. That's better than the option of making it in ignorance. -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
At 01:29 PM 5/9/01 -0400, Barry A. Warsaw wrote: >On the larger question of the List-* headers, there's no doubt that >the situation will not change for the 2.0.x maintenance branch. If >you want to get rid of the headers, hack the source. Fair enough. >But, Mailman could do a better job of conforming to RFC 2369. E.g. it >could suppress List-Post: for read-only lists, Or, as Chuq mentioned use the List-Post: NO syntax. >I still believe that Mailman is doing The Right Thing by supporting >RFC 2369. When the MUA vendors catch up, end users will benefit. Agreed. >Whether that means adding for Mailman 2.1 a >list-specific configuration option (-1) or a site-wide configuration >variable (-0), I'm not sure. Thank-you, Barry, for reconsidering this issue. Please cast my vote for a per-list option for the reasons outline in my message to JC. --Bill -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
At 12:15 AM 5/9/01 -0700, J C Lawrence wrote: >There is a critical difference. X does allow you and even makes it >very easy to do damned near anything you want, encluding being >incredibly stupid and making bad decisions. In a general light, >this is not a Bad Thing. One critical aspect however is that should >you do one of those stupid things you only break/damage yourself >(person running the broken app). A perfect example is X server >grabs. But, grabbing is so much fun! > > Unfortunately, if you don't buy the "mechanism, not policy" > > approach then you probably won't buy this argument either. > >Actually I buy and agree with both arguments, I just consider them >misplaced in this case. They work very well elsewhere. I think they are appropriate here too. It just seems to me that an adamant stance against configurability is actually more harmful to the stated goal of promoting wider acceptance of 2369 than allowing a per-list configuration would be. Here's why I say that: (a) Most mailman-owners will run with the defaults anyway, so all of their messages will still be 2369ized. (b) Those of us that have problems in this area can 2369ize our lists one, or a few, at a time, where appropriate, and bring our users along at a rate that we can manage. Since only we can determine what that rate is, only we can make that decision for ourselves. So, bottom line, I agree that 2369 compliance is good for Mailman and a worthy goal for all mailman-owners. A per-list configuration option would make it easier for me, and based on what I've read in the archive, others, to migrate towards full 2369 compliance, and therefore more likely that we'll do it. That sounds like a good thing to me. OTOH, a strident "hack it or take a hike" anti-configuration stance (some of the messages in the archive are downright hostile) actually makes it harder for me, and others, to migrate towards full 2369 compliance, which means it ain't gonna happen anytime soon. I'll simply hack the 2369 headers out by the roots and that will be the end of it as far as I'm concerned. And that, I submit, undermines the goal of rapid widespread compliance. Anyway, , that's how the picture looks from where I sit. >Trade offs. The high road. Those that leave are typically >(experience) better off gone, and (experience) their replacements >are much more valuable and numerous. I don't disagree with anything you said here about FAQs, user education, or customer/list member relations. I think you are right on all counts. The problem is, that at this particular moment in time, I simply cannot afford (in time or $$) to take the high road without just a little bit of help to make doing so a little bit easier. If I have to deal with this issue on an all or nothing basis, it's going to be nothing. In any case, Barry has said he'll consider the 2369 configuration issue for 2.1, and that's good enough for me! I ask for nothing more. > > We now return you to your regularly scheduled program about how to > > get Mailman to run on the Linux flavor-of-the-day... > >Yea gods save us. Doesn't seem likely. ;-) --Bill -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
At 11:32 PM 5/8/01 -0700, Chuq Von Rospach wrote: >I disagree. Policy decisions should be made by people who can make them in >an informed way, not out of ignorance. X windows lets its users do REALLY >STUPID AND DESTRUCTIVE things, simply because they want to. "because they >want to" isn't a good enough answer, Sure it is. It's what gives X the flexibility and power to do useful things which were not, or even could not, be anticipated by the developers in advance. Really, I appreciate your concern but you don't have to protect me from myself. >or else we ought to just give everyone >root access on a computer, and if they want to "rm -rf /", well, we should >let them. Sure, why not? What are you going to do, hide the rm man pages? Disable "-rf" unless they get permission from you? If it's their system, and they've decided they want to "rm -rf /", well then by golly I'll be happy to help. I don't see why anyone should appoint themselves to be the rm police, or the List-* police. >And in this specific case, there's a larger issue as well -- if sites turn >this stuff off widely, it discourages their adoption into the clients, >which screws over the overall adoption. The problem with this argument, as I see it (and have expounded in more detail in my message to JC), is that your attitude will actually make it more likely for sites, like mine, to kill these headers site-wide until they are no longer a problem instead of doing it selectively and working towards compliance with 2369. --Bill -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] Off-Topic: WebMail recommendations?
Sorry for the off-topic post, but at least I confessed my sin in advance! Since this group really seems to know its stuff, I'd like to ask for recommendations for a webmail server that will run on the same RHL7 machine as my Mailman installations. I'm hosting several low-traffic domains for non-profits and other groups...all important to the people involved, but no world-class performance requirements. Open source is preferrable, both for cost and customization, but some cost is acceptable if needed. So far I've looked at: BrowserExpress: Not open source, but reasonably priced. Incredibly easy to install, but pretty basic functionality. It works. Squirrel Mail: Open source and feature rich, but I don't want to fight my way through a MySQL->PHP->Apache->SquirrelMail installation path just to get webmail running. "Web E-Mail": Another open source package. Looks very basic and a bit rough, and they admit that it's not the most secure. Just based on their web site, I don't think it's where I want to be. Any other recommendations? Thanks much, Dave Melton -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
To help out those of you who like me think we should have the option of
removing the headers, here is my CookHeaders.py which removes all
headers that Mailman adds to outgoing mail. This is the crude way of
doing it, but my users are happier now and I have fewer complaints.
Myself and another gentleman had the same discussions you are having
with some people months ago and you will not change their minds.
If you use the code just copy the original CookHeaders.py to a new file
name to save it and replace it with the modified code.
This code is provided as is, it has not warranty that it will work or do what
you want. You use it at your own risk.
good luck,
Tom Hillson
--
#$base/Mailman/Handlers/CookHeaders.py
# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
"""Cook a message's Subject header.
"""
import string
import re
import urlparse
from Mailman import mm_cfg
def process(mlist, msg, msgdata):
# Mark the message as dirty so that its text will be forced to disk next
# time it's queued.
msgdata['_dirty'] = 1
# Set the "X-Ack: no" header if noack flag is set.
if msgdata.get('noack'):
msg['X-Ack'] = 'no'
# Because we're going to modify various important headers in the email
# message, we want to save some of the information in the msgdata
# dictionary for later. Specifically, the sender header will get waxed,
# but we need it for the Acknowledge module later.
msgdata['original_sender'] = msg.GetSender()
subject = msg.getheader('subject')
adminaddr = mlist.GetAdminEmail()
fasttrack = msgdata.get('fasttrack')
if not msgdata.get('isdigest') and not fasttrack:
# Add the subject prefix unless the message is a digest or is being
# fast tracked (e.g. internally crafted, delivered to a single user
# such as the list admin). We assume all digests have an appropriate
# subject header added by the ToDigest module.
prefix = mlist.subject_prefix
# we purposefully leave no space b/w prefix and subject!
if not subject:
msg['Subject'] = prefix + '(no subject)'
elif prefix and not re.search(re.escape(prefix), subject, re.I):
msg['Subject'] = prefix + subject
#
# get rid of duplicate headers
del msg['sender']
del msg['errors-to']
msg['Sender'] = msgdata.get('errorsto', adminaddr)
msg['Errors-To'] = msgdata.get('errorsto', adminaddr)
#
# Mark message so we know we've been here
# msg.headers.append('X-BeenThere: %s\n' % mlist.GetListEmail())
#
# Add Precedence: and other useful headers. None of these are standard
# and finding information on some of them are fairly difficult. Some are
# just common practice, and we'll add more here as they become necessary
#
# http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html
#
# None of these headers are added if they already exist
# if not msg.get('x-mailman-version'):
# msg['X-Mailman-Version'] = mm_cfg.VERSION
# Semi-controversial: some don't want this included at all, others
# want the value to be ^List'.
if not msg.get('precedence'):
msg['Precedence'] = 'bulk'
#
# Reply-To: munging. Do not do this if the message is "fast tracked",
# meaning it is internally crafted and delivered to a specific user.
# Yuck, I hate this feature but enough people want it that we should
# support it as an option.
if not fasttrack:
xreplyto = None
# Set Reply-To: header to point back to this list
if mlist.reply_goes_to_list == 1:
xreplyto = msg.get('reply-to')
msg['Reply-To'] = mlist.GetListEmail()
# Set Reply-To: an explicit address
elif mlist.reply_goes_to_list == 2:
xreplyto = msg.get('reply-to')
msg['Reply-To'] = mlist.reply_to_address
# Give the recipient some ability to un-munge things.
if xreplyto:
msg['X-Reply-To'] = xreplyto
#
# Add list-specific headers as defined in RFC 2369, but only if the
# message is being crafted for a specific li
Re: [Mailman-Users] Re: remove this?
At 2001-05-09 13:29 -0400, Barry A. Warsaw wrote: >Mike, thanks for the Eudora suggestions. I'm going to create a >README.USERAGENT file that collects this wisdom, and I'm going to add >a FAQ entry pointing people to this file. If anybody else has >suggestions on settings for other MUAs please send them along. Barry, Thanks, but I can't take credit for them. Someone else posted the Eudora instructions in a message on a similar thread. I used them to create a FAQ for my list users. https://sourceforge.net/docman/display_doc.php?docid=1465&group_id=13751 >But, Mailman could do a better job of conforming to RFC 2369. E.g. it >could suppress List-Post: for read-only lists, and it could get rid of >the obsolete List-Id: header. I'll work on this for Mailman 2.1. > >I still believe that Mailman is doing The Right Thing by supporting >RFC 2369. When the MUA vendors catch up, end users will benefit. I agree. :) >That said, we may have to invoke the 9th Zen of Python: Practicality >beats Purity[1]. Whether that means adding for Mailman 2.1 a >list-specific configuration option (-1) or a site-wide configuration >variable (-0), I'm not sure. I just wanted to say that while I still >agree with Chuq and JC that this RFC is important to support, I'm not >totally deaf to the cries of dismay from those of you who have to >expend real dollars to deal with users on non-conformant MUAs. I'm sure whatever you decide to do will be fine. -- Mike Noyes <[EMAIL PROTECTED]> http://leaf.sourceforge.net/ -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
Mike, thanks for the Eudora suggestions. I'm going to create a README.USERAGENT file that collects this wisdom, and I'm going to add a FAQ entry pointing people to this file. If anybody else has suggestions on settings for other MUAs please send them along. On the larger question of the List-* headers, there's no doubt that the situation will not change for the 2.0.x maintenance branch. If you want to get rid of the headers, hack the source. But, Mailman could do a better job of conforming to RFC 2369. E.g. it could suppress List-Post: for read-only lists, and it could get rid of the obsolete List-Id: header. I'll work on this for Mailman 2.1. I still believe that Mailman is doing The Right Thing by supporting RFC 2369. When the MUA vendors catch up, end users will benefit. That said, we may have to invoke the 9th Zen of Python: Practicality beats Purity[1]. Whether that means adding for Mailman 2.1 a list-specific configuration option (-1) or a site-wide configuration variable (-0), I'm not sure. I just wanted to say that while I still agree with Chuq and JC that this RFC is important to support, I'm not totally deaf to the cries of dismay from those of you who have to expend real dollars to deal with users on non-conformant MUAs. waffling-ly y'rs, -Barry [1] http://www.python.org/doc/Humor.html#zen -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] user list
for starters, is there an archive available of this [EMAIL PROTECTED] list so can look thru? trying to find out where to locate the file that holds the subscriber's addresses on the server. does mailman take well to having scripts edit the users instead of the conventional subscribe or admin bulk subscribe methods? (if this is possible at all). lance. -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Attributes List
On Wed, 9 May 2001, Jason Maderios wrote: > Are all the available attributes listed anywhere? I would like to add > the username and password to the footer of every email sent out. I know > about the security implications but this is for a short term > "Announcement" list. You can't. The MLM doesn't build a separate copy for each recipient, so it can't be customized this way. -- ROGER B.A. KLORESE [EMAIL PROTECTED] PO Box 14309San Francisco, CA 94114 "There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] Re: remove this?
>Same with hacking list-*. The general consensus among those of us who've put >time into understanding this issue is that it's a very good thing for the >long-term development of mail list technologies. Short term, it's at best a >minor irritant, and that's only to people with cruddy mail clients (consider >it an incentive to upgrade to soemthing decent). For what it's worth, I use Eudora and rather like that it displays headers that it doesn't recognize. Sure it scares the lusers, but I love that it tries to inform me when it sees something "weird". They were simple enough to turn off in any case. Of course it will be nicer when it supports the RFC... - H -- Harold Paulson Sierra Web Design [EMAIL PROTECTED] http://www.sierraweb.com VOICE: 775.833.9500 FAX: 810.314.1517 -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] Re: [Mailman-Users] purge pending submittion from command line?
Attached is a script that i wrote a week or two ago to do exactly that. you might need to edit the top line to reflect the location of python on your system. I had the script sitting in ~mailman/bin on my system and it worked quite happily. If you want to run it in cron, schedule it to run just before mailman sends out administrative reminders to the moderator/owner of the list. That way there is little chance of the moderators getting mails about pending requests. Regards Donal On Tue, 08 May 2001 21:06:36 +0900 ISO-2022-JP wrote: > > Is there any way to manually process the pending request from > > command line? > > Delete the relevant files from ~mailman/data/ > > -- > J C Lawrence [EMAIL PROTECTED] > -(*) http://www.kanga.nu/~claw/ > The pressure to survive and rhetoric may make strange bedfellows > > --- #! /usr/local/bin/python # # Written by Donal Hunt # April 23rd 2001 # # argv[1] should be the name of the list. """Clear pending administrative requests for a list Usage: clear_requests listname Where: listname The name of the Mailman list you want to clear pending requests from. It must already exist. """ import sys import os import string import getopt import paths from Mailman import mm_cfg from Mailman import Utils from Mailman import MailList from Mailman import Errors from Mailman import Message from Mailman.Logging.Syslog import syslog def usage(status, msg=''): if msg: print msg print __doc__ % globals() sys.exit(status) def main(): try: ml = MailList.MailList(sys.argv[1]) except Errors.MMListError, e: usage(1, 'No such list: %s (%s)' % (listname, e)) try: print 'No of Requests Pending: %s ' % ml.NumRequestsPending() print 'No of postings awaiting approval: %s ' % ml.GetHeldMessageIds() print 'No of subsciptions awaiting approval: %s ' % ml.GetSubscriptionIds() for i in ml.GetHeldMessageIds(): ml.HandleRequest(i, 3) for i in ml.GetSubscriptionIds(): ml.HandleRequest(i, 2, 'No subscription allowed - please mail %s' % ml.owner[0] ) print 'No of Requests Pending: %s ' % ml.NumRequestsPending() ml.Save() finally: ml.Unlock() main()
[Mailman-Users] Attributes List
Gang, Are all the available attributes listed anywhere? I would like to add the username and password to the footer of every email sent out. I know about the security implications but this is for a short term "Announcement" list. TIA, Jason Maderios -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Call for suggestions
At 06:02 PM 5/8/2001 -0600, Ashley M. Kirchner wrote: >Chuq Von Rospach wrote: > >> Trying to keep the subscriber databases in sync across machines is going to >> be problematic. > >Tow things I can think off of the top of my head, one being the easiest >(maybe). > > a) NFS Not designed for it. Chuq has posted some other thoughts, but if you're going the route of sharing disk between machines, you need a filesystem designed for it: NFS works okay at using network storage, but not when the individual files are to be actively shared between several machines. Here's where you go look at something like GFS, just to pick one example out of the air. Mats -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] 2.0.5 issues persist on RH70 (corrected)
On Tue, 8 May 2001, Pug Bainter wrote: | Joe Morris ([EMAIL PROTECTED]) said something that sounded like: | > 4. Rerun check_perms and it finds 11 problems all related to files that | > are not set-gid. Why did it return differently this time after I set the | > owner of all files to mailman?!? | Because for security purposes the OS removes the set-gid bit after a | chown or chgrp. So, I guess it's OK to leave root as the owner of the structure? ___ Joe Morrishttp://www.ibiblio.org/morris Web Systems Manager, ATNhttp://help.unc.edu UNC-Chapel Hill http://www.unc.edu -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
On May 9, 2001 at 09:51, Nigel Metheringham wrote: >will not in general support them... and currently the only MUA I know >of that does use them is exmh (and that has a couple of wrinkles I Pine, at least since 4.21, supports List-*. >We probably also ought to use the List-* headers as part of the loop >detection... and long term deprecate the X-beenthere - however judging >by the number of mailman 1.x installs around and the amount of people >with procmail filtering on that its likely to be a painful process. I already procmailise -- I mean, filter -- on List-Id. >this is not made easy - ie not a web config item, and if we do use >List-* as part of the loop detection remember that people using it may >screw themselves royally. If its a configurable my tendancy would be Good! >to put it in mm_cfg.py and ideally reset it on each upgrade. That'd be nice. -- Satya. http://satya.virtualave.net/> US-bound grad students! For pre-apps, see http://quickapps.cjb.net/> Reactor error -- core dumped. -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] Looping unexplained
Hi there... We are running a mailman site with 6 Lists. All the lists bar the Rouge one are working like a dream. The rogue list is sending out a sent message multiple times, with the amount of times ranging from 2 to 100 odd times. There is no difference in setup of the lists, and I have even created a list with a number of personal accounts to try and recreate the situation but the lists just work. I was wondering if anyone else has got/had a similar problem , and if so HoW CAN I FIX IT :-> Any help would be gr8 Thanx in advance and Regards -- --- Bryan Gruneberg Raxel Communications - Linux Developer / Consultant Tel : +27 11 8036004 Cell: +27 83 3087752 -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Re: remove this?
[EMAIL PROTECTED] said: > If and when MUAs make automated use of these headers as suggested by > the RFC, then it may be a good idea. But until then, I simply can't > afford the added tech support burden to teach every user how to make > this kind of config change to their particular client. It's hard > enough to keep their basic setting in order! ;-) Chicken & Egg or Egg & Chicken. Someone has to start. Until there is evidence that list headers are being used, MUA authors will not in general support them... and currently the only MUA I know of that does use them is exmh (and that has a couple of wrinkles I could do without). We probably also ought to use the List-* headers as part of the loop detection... and long term deprecate the X-beenthere - however judging by the number of mailman 1.x installs around and the amount of people with procmail filtering on that its likely to be a painful process. We do need to document the use of the headers and potentially have a means for disabling them... however I would very strongly suggest that this is not made easy - ie not a web config item, and if we do use List-* as part of the loop detection remember that people using it may screw themselves royally. If its a configurable my tendancy would be to put it in mm_cfg.py and ideally reset it on each upgrade. BTW for people wishing to strip these then it may be better to do this in MTA filtering - exim can handle this easily. I am strongly resisting the temptation to comment on the buns thread. Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ Phone: +44 1423 85 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
