Mailman 3 February 1999 - Mailman-Developers

(no subject)
by Balazs Nagy 21 Feb '99

21 Feb '99

Hiyas, There any ideas about mail archive handling by email? I mean sending FAQ and other files automatically or the possibility of getting them. Regards: Balazs -- #!/usr/bin/perl -export-a-crypto-system-sig -http://dcs.ex.ac.uk/~aba/rsa print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

1 0

Re: [Mailman-Users] Messages silently disappearing
by Barry A. Warsaw 20 Feb '99

20 Feb '99

Thanks to Wes Morriston for giving me access to his Linux machine, I have diagnosed the problem he and Edward Marshall were having. I don't have a better solution than the one Wes came up with, so I'm posting this followup here to see if anybody has any ideas. The problem in a nutshell: on some Linux boxes, the effective group id is not preserved across a popen() call. Here's essentially the chain when a message is posted to a list: 1. The mail wrapper is invoked by the MDA. Mailman's wrapper is a setgid C program, that should change the egid to `mailman', then exec scripts/post. 2. scripts/post also has egid `mailman' and it goes about the business of checking that the message can be posted. Eventually, it is going to popen() scripts/deliver and start pumping it data. scripts/deliver in turn popens scripts/contact_transport, but it doesn't matter because by then the damage is done. Now, on both my Solaris 2.6 box and my RH5.1 box, scripts/deliver will inherit the egid of the invoking process, i.e. gid `mailman'. So by setting ~mailman/data to be g+w and group owned by mailman, everything's cool. However on Wes' SuSE machine, scripts/deliver runs with its egid reset to the real gid. This breaks mailman because the real gid isn't `mailman' and thus the process does not have permission to write into the ~mailman/data directory. Because the process is owned by daemon, Wes' solution of chown'ing ~mailman/data to daemon got this working again. I'm at a loss as to what the right solution is. Wes', while it works, doesn't seem ultimately right. But I have no idea how to force the egid of scripts/deliver to `mailman'. I don't believe you can have setgid scripts on Linux (I tried this, and no it did not work). Another solution would be to wrap scripts/deliver and probably scripts/contact_transport in C setgid wrappers, but that seems like a PITA. Is there some Linux option that we can exploit to allow this? Does anybody else have any better ideas? I am attaching a tarball of code that you can use to test whether your machine has the problem. To run this, compile wrapper.c, then chgrp it to some other group and chmod it to g+s. Also make sure wrapper-2.py is executable. Now run wrapper. If you see that wrapper, wrapper-1 and wrapper-2 all have the same egid, then you're okay. If wrapper-2 reverts to the real gid, then you'll get nailed by this. I'm guessing that because Stevens [APitUE] suggests that what we're doing may open up a security hole, some versions of Linux disallow this by reverting the egid on a popen(). -Barry

2 1

MailMan Bug :(
by Csanaki Csaba 19 Feb '99

19 Feb '99

Bug in Mailman version 1.0b8 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 (innermost last): File "/home/mailman/scripts/driver", line 85, in run_main logger = StampedLogger('error', File "/home/mailman/Mailman/Logging/StampedLogger.py", line 48, in __init__ Logger.__init__(self, category, nofail, immediate) File "/home/mailman/Mailman/Logging/Logger.py", line 40, in __init__ self.__get_f() File "/home/mailman/Mailman/Logging/Logger.py", line 63, in __get_f reraise() File "/home/mailman/Mailman/Logging/Logger.py", line 55, in __get_f f = self.__fp = open(self.__filename, 'a+') IOError: (13, 'Permission denied') ---- I installed mailman, but this don't work :( Prew --------------------------------------------------- mailto:prew@prew2.matav.hu http://prew2.matav.hu ICQ:6384302

4 3

Can anyone get MailMan running under Kernel w/ secure_linux patched?
by Alex Yu 19 Feb '99

19 Feb '99

Hello, I have problem w/ Mailman under Kernel 3.0.36 w/ secure_linux (ftp://ftp.false.com/pub/secure). I compiled the kernel with these options, Non-executable user stack area Restricted links in /tmp Restricted pipes in /tmp Restricted /proc So when I tried to update options on the web, I got error message as listed below. Can anyone fix? ---[START]------[START]---Bug in Mailman version 1.0b8 Traceback: Traceback (innermost last): File "/usr/local/mailman/scripts/driver", line 112, in run_main main() File "/usr/local/mailman/Mailman/Cgi/admin.py", line 170, in main ChangeOptions(lst, category, cgi_data, doc) File "/usr/local/mailman/Mailman/Cgi/admin.py", line 849, in ChangeOptions lst.Save() File "/usr/local/mailman/Mailman/MailList.py", line 683, in Save file = aside_new(fname, fname_last, reopen=1) File "/usr/local/mailman/Mailman/MailList.py", line 1211, in aside_new os.link(old_name, new_name) OSError: [Errno 1] Operation not permitted ---[end]--- -- best regards, alex.Yu

3 2

Re: [Mailman-Users] Messages silently disappearing
by Barry A. Warsaw 19 Feb '99

19 Feb '99

>>>>> "HM" == Harald Meland <Harald.Meland(a)usit.uio.no> writes: HM> I can't really see that there is any viable[1] alternative to HM> putting HM> setregid(getegid(), -1); HM> somewhere in common.c:run_script() [wrapped with appropriate HM> autoconfisms, of course]. HM> As long as there are systems not preserving the effective GID HM> when they ought to (IMHO), we'll have to hope that using the HM> real GID will work better. And, I don't think that setting HM> the real GID to the effective GID will cause trouble on other HM> systems. Thanks Harald, this sounds reasonable. I'm not sure what to do if autoconf detects that the system is missing a setregid() though. Right now it just doesn't get called. I suppose I'll also document all this in the FAQ. I tested this on Wes' machine with my example code, and it looks at least like the popen() process is getting the necessary gid. I did not test it with a live Mailman setup. Folks (especially Wes and Edward, and anybody else who was noticing these problems), could you please wait for my next check-in and then grab the CVS snapshot. Reset the ownership on ~mailman/data and do a re-install to see if my changes fix your problems. If you can't access the CVS repository, let me know and I'll do a beta9 release. -Barry

1 0

Re: [Mailman-Developers] Re: [Mailman-Users] Messages silently disappearing
by Harald Meland 19 Feb '99

19 Feb '99

[Barry A. Warsaw] > Thanks to Wes Morriston for giving me access to his Linux machine, I > have diagnosed the problem he and Edward Marshall were having. I > don't have a better solution than the one Wes came up with, so I'm > posting this followup here to see if anybody has any ideas. > > The problem in a nutshell: on some Linux boxes, the effective group id > is not preserved across a popen() call. [...] > I'm at a loss as to what the right solution is. I can't really see that there is any viable[1] alternative to putting setregid(getegid(), -1); somewhere in common.c:run_script() [wrapped with appropriate autoconfisms, of course]. As long as there are systems not preserving the effective GID when they ought to (IMHO), we'll have to hope that using the real GID will work better. And, I don't think that setting the real GID to the effective GID will cause trouble on other systems. [1] Starting everything via setgid C wrappers isn't viable (to me). Forcing (possibly non-privileged) Mailman users to chgrp their directories to groups they very likely aren't members of isn't viable (for them). -- Harald

1 0

Help with run_queue problem?
by Liam Kirsher 16 Feb '99

16 Feb '99

Hi, Can anyone help with this? I'm getting the following error when run_queue is executed, whether by cron or from the command line. Everything else seems to be working fine. Thanks in advance, Liam ------------------------------------------------------ Your "cron" job on ns1 /usr/local/bin/python /usr/local/etc/mailman/cron/run_queue produced the following output: Traceback (innermost last): File "/usr/local/etc/mailman/cron/run_queue", line 31, in ? OutgoingQueue.processQueue() File "/usr/local/etc/mailman/Mailman/OutgoingQueue.py", line 119, in processQu eue recip,sender,text = marshal.load(f) EOFError: EOF read where object expected -- <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-> Liam Kirsher VOICE: 415-456-6822 Numenet, Inc. FAX: 415-453-7876 775 E. Blithedale Ave. #176 EMAIL: liam(a)numenet.com Mill Valley, CA 94941 PGP: http://www.numenet.com/~liam/pgp_public_key.txt

1 0

Problems with '+' addressing
by Christopher Lindsey 12 Feb '99

12 Feb '99

I have several people subscribing to my lists with plus addressing (i.e. lindsey+mhonarc(a)ncsa.uiuc.edu (in fact, I'm subscribed to this list in the same way)). This breaks the "Restrict Posting to List Members" option for these accounts... What I'm trying to do is check for the existence of a '+' in each address in the list of subscribers, and if present, trim it and everything to the right off before checking for a match. Unfortunately, it appears that FindMatchingAddresses (called from MailList.FindUser) is just passed a dictionary of list members. Implementing the kind of check that I'd like would significantly slow down checking for matches because it couldn't just use the poster's address as a key anymore. So what's the best way to do this? Do a foreach on each key and check for a match? Like I said, it's slower, but it sure opens up a lot of possibilities. You could then do things like add regular expressions to the list of accepted posters... /.*\.example\.com/ would allow postings from anyone in a given domain (not something I would recommend), /george(a)example\.(org|com|net)/ would pull three lines together into one, etc. Not terribly useful, but what if you were to incorporate '+' addressing checks through regexes too then? Create a macro like :USER: and :DOMAIN: that would be used in the regex (colons are used since they can't be part of an address according to RFC 822)... Then you would have a regex like /:USER:\+[^@]*@:DOMAIN:/ :USER: and :DOMAIN: would be derived from the current poster, and each entry within the list of subscribers would be compared against the resulting regular expression (one at a time). I think that something like the '+' addressing check would be best served internally within Mailman (via a checkbox or whatever), but once the engine is in place it's a lot more extensible. Comments? I'm willing to mess with this (although I can't guarantee any great speed -- I just started messing with Python a couple of days ago). Chris

1 0

Stale mailman-checkins archive
by Benjamin B. Thomas 11 Feb '99

11 Feb '99

Has anyone noticed that the last archived message to the mailman-checkins list (http://www.python.org/pipermail/mailman-checkins/) is from November? (BTW: The project looks really nice! I'm considering switching over from my current majordomo + (wilma/glimpse) + custom hacked news2mail<->mail2news gateway when I get through with some other other pressing projects.) Cheers, benjy 1975 Cahaba Valley Road (205) 988-5925 Indian Springs, AL 35124 benjy(a)alum.mit.edu

2 1

[Fwd: Re: [Mailman-Users] NameError : recipients]
by Greg Stein 11 Feb '99

11 Feb '99

Greg Stein wrote: > > Scott A. McIntyre wrote: > > > > Thanks to Harald, I figured out my WANTED vs GOT and ended up letting > > mailman run with the GID it GOT and that seems to be much closer to > > being happy. However, now, whenever I post, I get the following in the > > error log: > > > > Feb 10 14:48:56 1999 post: Traceback (innermost last): > > post: File "/usr/people/mailman/scripts/post", line 65, in ? > > post: current_list.Post(msg) > > post: File "/usr/people/mailman/Mailman/MailList.py", line 1143, in > > Post > > post: recipients.remove(members) > > post: NameError : recipients > > This is a bug in Mailman 1.0b8. It has incorrect code for processing > "Don't Receive Own Posts". Turn that off, and it should work okay. I moved a block of lines in MailList.py down below the construction of the recipients list. It also appeared there was a bug in there that attempted to remove "members" rather than "sender". The final code looks like: # Try to get the address the list thinks this sender is sender = self.FindUser(msg.GetSender()) if sender: if self.GetUserOption(sender, mm_cfg.DontReceiveOwnPosts): dont_send_to_sender = 1 if self.GetUserOption(sender, mm_cfg.AcknowlegePosts): ack_post = 1 # Deliver the mail. members = self.GetDeliveryMembers() recipients = [] for m in members: if not self.GetUserOption(m, mm_cfg.DisableDelivery): recipients.append(m) if dont_send_to_sender: try: recipients.remove(sender) # # sender not in list (case sensitive username problem?) # except ValueError: self.LogMsg("error", "couldn't remove %s from recipient list: %s", sender, str(members)) self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) Cheers, -g -- Greg Stein, http://www.lyra.org/

1 0