Mailman 3 March 2000 - Mailman-Developers

Re: [Mailman-Developers] Betas coming soon
by Dan Mick 23 Mar '00

23 Mar '00

> [1] To closest way I can think of[2]: put it on screen, . . . > [2] And I shudder to think ;-) Hey, nesting footnotes is illegal. Somebody arrest that guy. ;)

1 0

Sender: header in 2.0beta1
by Gergely Madarasz 23 Mar '00

23 Mar '00

Hello, Previous versions always put Sender: <listname>-admin@<domain> in all mails sent out to the list... it seems that with the new sendmail delivery module it has some issues... with exim the mailman user has to be listed in the trusted_users option for this to work, if it is not listed, the Sender: header becomes mailman@<domain> -- Madarasz Gergely gorgo(a)caesar.elte.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/

5 11

Re: [Mailman-Developers] Sender: header in 2.0beta1
by Nigel Metheringham 23 Mar '00

23 Mar '00

gorgo(a)caesar.elte.hu said: > I've got it working... now smtplib can be told to use '/path/to/ > sendmail -bs' instead of connecting to localhost:25, and talk smtp > there (no addresses in the shell, perhaps a bit better error > handling). There is still a problem though... the Sender header gets > rewritten this way too... but now it becomes nobody@<domain>, I > haven't got the faintest clue why this happens, no process should run > as nobody here... The MTA should still know the UID its invoked under - exim will have the same Sender: problems as a straight CLI, and so the invoking user will still need to be trusted (or your MTA's equivalent). Also any loading issues from command line invocation still apply to an "mta -bs" invocation - although its probable that I am simply overly paranoid about this. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

2 1

Betas coming soon
by Barry A. Warsaw 22 Mar '00

22 Mar '00

Folks, Okay, I think I solved the last major hurdle before I can start releasing the new betas. Mailman should now lazily update it's old pending requests "database" to the new style external requests.db file. Wasn't as hard as I thought it would be. You will still have to be careful when upgrading from 1.1/1.0 to the new version. Please read/debug my recommendations in the UPGRADING file for details (after I check it in). While I'm pretty sure upgrading will work, I really need feedback from you beta testers. For now, I'd say you should be careful upgrading any operational site, but on the other hand I want to encourage you to test this stuff as much as possible. All feedback is welcome. Now, my questions. 1) Notice I haven't said "upgrade to 1.2" because I'm going to call the new release 2.0. While there aren't that many outwardly visible differences, there are enough architectural and schema changes, that I believe a 2.0 label is warranted. Plus, I want to give a stronger indication that the changes may be, er, significant. This means that if I really screw up 2.0, I can get a few 2.x bug patches out in quick succession. This also means that the i18n'd Mailman will likely be called 3.0. What's in a number anyway? :) 1) I've thought about being really parental about the upgrade, by essentially forcing people to read the UPGRADING file before "make" will succeed. I think I have a trick that will work, but I'm not sure it's a good idea. On the one hand it /might/ (only might) save lazy or novice upgraders some headaches by forcing them to read the manual first. One the other hand, it'll be really annoying either to those who are doing a fresh install, or who are upgrading but know what they're doing. So, do you think it would be a good idea to force everyone to read UPGRADING before "make" succeeds? Watch for the final round of checkins some time (hopefully) this week. After that I'll spin the 2.0beta1 tarball. I'm pretty sure the current CVS snapshot is very close, modulo updating the docs. I still need to get through the email backlog (sigh) and the Jitterbug database, but I can do that while the betas are out on the street. Cheers, -Barry

4 3

PairList error (fwd)
by sigma＠pair.com 22 Mar '00

22 Mar '00

In the last week or so, we've been seeing the following error and traceback on several pages, including our main listinfo page at http://www.pairlist.net/mailman/listinfo/ I've searched and found nothing about this error. Can someone point me in the right direction, hopefully? Thanks, Kevin Martin sigma(a)pair.com ----- Forwarded message ----- Bug in Mailman version 1.2 (experimental) 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 "/usr/mailman/scripts/driver", line 112, in run_main main() File "/usr/mailman/Mailman/Cgi/admin.py", line 67, in main mlist = MailList.MailList(listname) File "/usr/mailman/Mailman/MailList.py", line 69, in __init__ self.Load() File "/usr/mailman/Mailman/MailList.py", line 839, in Load raise Errors.MMBadListError, ('Failed to unmarshal config info: ' TypeError: __add__ nor __radd__ defined for these operands Environment variables: Variable Value DOCUMENT_ROOT /usr/www SERVER_ADDR 216.92.1.92 HTTP_ACCEPT_ENCODING gzip SERVER_PORT 80 PATH_TRANSLATED /usr/www/isc-agent-newsletter GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_LANGUAGE en,zh-CN SERVER_NAME www.pairlist.net HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.7 [en] (WinNT; U) HTTP_ACCEPT_CHARSET iso-8859-1,*,utf-8 HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* REQUEST_URI /mailman/admin/isc-agent-newsletter PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin QUERY_STRING SCRIPT_FILENAME /usr/mailman/cgi-bin/admin PATH_INFO /isc-agent-newsletter HTTP_HOST www.pairlist.net REQUEST_METHOD GET SERVER_SIGNATURE SCRIPT_NAME /mailman/admin SERVER_ADMIN webmaster(a)pairlist.net SERVER_SOFTWARE Apache/1.3.9 (Unix) PYTHONPATH /usr/mailman SERVER_PROTOCOL HTTP/1.0 REMOTE_PORT 1047

1 0

mailman 2.0beta1 problem: Mail delivery failed: returning message to sender (fwd)
by Gergely Madarasz 22 Mar '00

22 Mar '00

Hello, I've just upgraded my test machine to 2.0beta1 ... I sent a test message to the list, it was delivered correctly to its members and then I got the error message attached below. Anyway it seems quite strange to me... first, why does scripts/post write anything to stdout, second, why does it write "starting" twice ? The logs/post file has the following: Mar 22 19:02:22 2000 (6870) post to test from gorgo(a)sztaki.hu, size=444, success Additionally in logs/error I have the following: Mar 22 19:02:22 2000 post(6870): starting Mar 22 19:02:22 2000 post(6870): ending -- Madarasz Gergely gorgo(a)sztaki.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ ---------- Forwarded message ---------- Date: Wed, 22 Mar 2000 19:02:23 +0100 From: Mail Delivery System <Mailer-Daemon(a)thunderchild.aszi.sztaki.hu> To: gorgo(a)sztaki.hu Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: test(a)thunderchild.aszi.sztaki.hu: generated |/var/lib/mailman/mail/wrapper post test The following text was generated during the delivery attempt: ------ |/var/lib/mailman/mail/wrapper post test ------ starting ending starting ------ This is a copy of the message, including all the headers. ------ Return-path: <gorgo(a)sztaki.hu> Received: from lutra.sztaki.hu [193.225.86.1] by thunderchild.aszi.sztaki.hu with esmtp (Exim 3.12 #1 (Debian)) id 12XpSX-0001ml-00; Wed, 22 Mar 2000 19:02:21 +0100 Received: from localhost by sztaki.hu (PMDF V5.2-32 #42635) with ESMTP id <0FRU004014RXGU(a)sztaki.hu> for test(a)thunderchild.aszi.sztaki.hu; Wed, 22 Mar 2000 19:02:21 +0100 (MET) Date: Wed, 22 Mar 2000 19:02:21 +0100 (MET) From: Gergely Madarasz <gorgo(a)sztaki.hu> Subject: proba To: test(a)thunderchild.aszi.sztaki.hu Message-id: <Pine.GSO.4.10.10003221902010.19257-100000(a)lutra.sztaki.hu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII humm -- Madarasz Gergely gorgo(a)sztaki.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/

2 1

beta & smtp
by Ricardo Kustner 22 Mar '00

22 Mar '00

I just upgraded the cvs version i had installed (which is a snapshot from almost a month ago i think) and when i tried to approve 11 posts, I got a mailman error... something about a connection refused (see below)... maybe mailman is trying more connections than postfix allows... but the weird thing is that i never had this problem before, so this has to do with some recent stmp changes. I'll investigate postfix & mailman further to see if i can figure out what exactly is going wrong... Ricardo. admin(32515): mlist.HandleRequest(request_id, v, comment) admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 124, in HandleRequest admin(32515): self.__handlepost(data, value, comment) admin(32515): File "/usr/local/mailman/Mailman/ListAdmin.py", line 174, in __handlepost admin(32515): self.Post(msg) admin(32515): File "/usr/local/mailman/Mailman/MailList.py", line 1293, in Post admin(32515): Mailman.Handlers.HandlerAPI.DeliverToList(self, msg) admin(32515): File "/usr/local/mailman/Mailman/Handlers/HandlerAPI.py", line 55, in DeliverToList admin(32515): func(mlist, msg) admin(32515): File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 41, in process admin(32515): conn = smtplib.SMTP(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 182, in __init__ admin(32515): (code, msg) = self.connect(host, port) admin(32515): File "/usr/local/mailman/Mailman/pythonlib/smtplib.py", line 216, in connect admin(32515): self.sock.connect(host, port) admin(32515): error: (111, 'Connection refused') -- Ricardo. --

4 6

Re: [Mailman-Developers] Mailman keying on Sender: Field
by J C Lawrence 22 Mar '00

22 Mar '00

On Wed, 22 Mar 2000 08:11:11 -0600 Roberto Ullfig <rullfig(a)uchicago.edu> wrote: > I noticed that Mailman keys on the Sender: field when you email in > a subscription request. Is this really necessary? Is it possible > to reconfigure Mailman to key on the From: field instead? Is this > more or less desirable? Since confirmations are always in place it > seems to me that there's enough protection as it is without using > the Sender: field. There's a documented value you can edit in mm_cfg.py to change this. -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

Re: [Mailman-Users] confidentiality features
by Barry A. Warsaw 22 Mar '00

22 Mar '00

Please trim followups to mailman-developers(a)python.org... >>>>> "mjinks" == <mjinks(a)bsd.uchicago.edu> writes: mjinks> First of all, in testing it appears that although the mjinks> "From:" header is stripped, the "X-Sender:" still comes mjinks> through, as does the sender's IP address. We're in a mjinks> university, so back-tracing an IP address to a nearby mjinks> individual is not that tough, and could certainly be seen mjinks> as a gap for confidentiality. Could X-Sender and IP also mjinks> be stripped? Have I missed some detail? Mailman doesn't know about X-Sender, so it doesn't by default strip those. You'd probably also have to grok through Received: headers and others to truly anonymize the message. mjinks> On the other hand, this user wants to be able to peek mjinks> behind the curtain in those cases where confidentiality mjinks> needs to be violated -- for example if a poster to the mjinks> list claims to be suicidal or otherwise seems dangerous. mjinks> I showed the user that he'd see the real return address if mjinks> we set the list to be moderated, but he didn't like that mjinks> idea. Any clues? Can identifying information be made mjinks> available, say, to the list owner only? Here's the approach I would explore, using the 2.0 code base. Write a message handler module (see Mailman/Handlers/* for examples), calling it Anonymize.py. Put this in the pipeline such that every message passes through it before it's delivered to the archiver, or usenet, or the list. In this module, you'd strip or munge all the headers you want. To support lifting the curtain, you can store (securely, on the file system) whatever information gleaned out of the message is necessary to link the poster with the email message. You might even key both off of a randomly generated ID, which you'd poke into the outgoing message. Now that I think about it, it wouldn't be too hard to extend this idea into a general framework for email anonymizing. Given an MTA that can handle highly dynamic updates to it's alias database, you're "randomly generated ID" above would be used to create a Reply-To: address pointing back to your anonymizing service. Your add-on stuff would handle delivering back to the original user based on the random address. Oooh, what a neat idea! Let me know if you decide to play around with this. It'd be really cool to add some more anonymizing features in a future version. -Barry

1 0

Mailman keying on Sender: Field
by Roberto Ullfig 22 Mar '00

22 Mar '00

I noticed that Mailman keys on the Sender: field when you email in a subscription request. Is this really necessary? Is it possible to reconfigure Mailman to key on the From: field instead? Is this more or less desirable? Since confirmations are always in place it seems to me that there's enough protection as it is without using the Sender: field. -- Roberto Ullfig : rullfig(a)uchicago.edu Systems Administrator Networking Services and Information Technologies University of Chicago

3 3