[Mailman-Users] [Mailman-Developers] Mailman and Box
Moving to mailman-users, be a better place to post a request for experience. Please respect cross-posting restrictions. If you're just reporting experience, reply-to is set to Mailman-Users which is appropriate (at least, IIRC the Mailman Users/Developers lists don't mess with preexisting Reply-To). If you have patched Mailman to make it work better in this kind of application, you *may* wish to move the conversation back to Mailman Developers to propose inclusin in a future version of Mailman. (If you just want to say "hey I have a patch", I would leave that on -Users, FWIW YMMV.) bill.co...@unh.edu writes: > We will be retiring our Blackboard system (an e-learning portal) > which offered users 'organizations'; basically a combination of > group sharing of documents and collaboration via email. > > I can't begin to duplicate all of the functionality of this part > of Blackboard, but I figured if I could link our school's Box > cloud storage with our new Mailman v2 installation, that would go > a long ways to provide a similar service. > > The idea is that for every Mailman list created, a new Box shared > folder would also be created and associated with that list. The > list owner and subscriber information would live in Mailman. A > nightly reconciliation job would maintain the > list-owner/folder-owner roster and subscriber list between the > two systems. Subscribers to the list would be granted, as a > whole, either reader or contributor access to the Box folder > (whatever the owner chooses). The list-owner would be able to do > things like put the associated Box folder's URL into the list's > message footer. > > Box provides a RESTful API, so I think I just might be able to > pull this off. > > My question is, is there anybody else already doing this or > something similar? -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] Mailman 3 status
[resend w/proper address] On Jul 13, 2015, at 10:47 AM, Stephen J. Turnbull wrote: - Performance measurements. There are theoretical reasons to believe that under certain circumstances a large Mailman 3 under heavy use *might* suffer bottlenecks, but we just don't know yet. Note that the message delivery subsystem, while modernized and ported to Python 3, is largely inherited from Mailman 2, which means that reliability and performance *of message delivery* should be about the same. Over in mailman-developers we've had some discussion about performance of the REST server, which by default gets vended by Python 3's stdlib wsgiref module and probably would be improved by a better wsgi application server such as gunicorn. Follow ups to -developers on that topic please. The information provided above is accurate to the best of my ability, but it has not been checked by the responsible developers. It is provided in hope of may be of use to those considering installation of Mailman 3. If you're still on the fence after reading this post, please do get more accurate information from the responsible developers on the Mailman Developers list. You did good, Steve! :) Cheers, -Barry -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] Error while installing Mailman
On 03/05/2015 08:08 AM, Rakesh Verma wrote: i did the same but i am still getting the error, can i manually add the user to /etc/passwd??? Please keep threads on the list unless sending personal, private or security information. What happened when you did the useradd command? There are two issues with the manual: 1) useradd -c''GNU Mailman'' -s /no/shell -d /no/home -g mailman mailman should be either useradd -cGNU Mailman -s /no/shell -d /no/home -g mailman mailman or useradd -c'GNU Mailman' -s /no/shell -d /no/home -g mailman mailman 2) you need to be root or use sudo Also, if you don't actually know how to add a user to your system, you may not have enough sysadmin experience to successfully install mailman. The installation manual tries to be complete, but it assumes a certain level of background knowledge. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] [Mailman-Developers] Fwd: [sympa-users] thoughts re. DMARC impacts
Reply-To set to Mailman-Users. Although actual work on an RFC probably would be done by a developer, there's no reason to exclude site admins and list owners, and the impact of DMARC is surely apparent to developers, admins, and owners alike, as well as to our subscribers. Victoriano Giralt writes: This has recently circulated in the sympa-users lists. As a proud member of both communities I think that the synergy Miles proposes could really have some impact. Thank you for posting. Mailman as an organization (through me, the more or less official delegate to the DMARC Working Group - below, just the WG) is well aware of Miles' proposal. In short, I'm opposed to it in current form, both personally and on behalf of Mailman. That said, I welcome discussion and advocacy of his point of view, and if the Mailman community goes there, we can either delegate more people to advocate it or I can do my best to present the Mailman consensus as well as my own view (assuming it doesn't change in response to further advocacy :-). The rest is tl;dr, I suppose, but it is a complete and I hope fair summary of discussion of these proposals on the dm...@ieft.org list: http://www.ietf.org/mail-archive/web/dmarc/ Subject: [sympa-users] thoughts re. DMARC impacts Date: Mon, 27 Oct 2014 20:45:32 -0400 From: Miles Fidelman mfidel...@meetinghouse.net Many of us just had to deal with the impacts of DMARC on our lists. In the aftermath, I've been participating on the dmarc-ietf email list - trying to discuss ways to fix DMARC to better coexist with lists and other 3rd-party services (like send this article to). Unfortunately, it seems like the discussion is bogged down in two regards: - the ietf-dmarc working group is charted to enhance DMARC - dealing with its impacts is not really the focus - folks want a general purpose solution This is false. The charter is public: http://tools.ietf.org/wg/dmarc/charters In fact, Miles' proposal, and several similar ones, have received a lot of attention from the WG. Nobody has claimed it's out of WG scope or tried to shut down discussion on that basis, although it's off current focus. It's true that two specific participants are strong proponents of general purpose solutions, but they are special interests (a party of 2, or perhaps 2 parties of 1 ;-). The people who are the backbone of the WG have on average two *decades* of experience in creating email-related and other Internet standards, and they are quite happy to consider incremental improvements, two of which (the *-dkim-* Internet Drafts) are cited below. Currently, the WG's focus is on figuring out just what those impacts are, it's true, and that is a general purpose task. Nevertheless, many members of the WG are open to off-focus work as individuals, and the WG wiki is open as a forum for presenting off-focus ideas to be addressed ad hoc by individuals or by the WG in the future. http://tools.ietf.org/wg/dmarc/trac/wiki Personally, I'd like to see a short-term solution to make our lives easier, as list managers - sort of the way that NAT has been dealing with IPv4 address exhaustion, while we wait for IPv6 to happen. This is an excellent analogy. NAT has caused almost as many problems as it solved, especially in the security area. Miles' proposal would be the same IMO. I've been thinking along the lines of an update to RFC2369 - the 16-year-old document defines the List-* headers. Say by adding a couple of headers along the lines of: List-Original-Author: the original author List-Original-Reply-To: the original message's Reply-To These two have trivial generalizations which apply to some of the other third-party issues created by DMARC. Specifically, just drop the List- prefix. This generalization *will* occur -- those users will perceive the utility to themselves, and just start using it. The misnaming may not cause problems, but why invite them when we don't have to? By either name (or slight variations, such as Original-From and X-Original-From -- the latter has long been used by GMail for internal purposes, apparently), this proposal has the following design issues that must be resolved: 1. It changes the semantics of the From field defined by RFC 5322. According to RFC 5322, From is the definitive field indicating the author of the message content in a sense made somewhat precise in that RFC and other email RFCs. This proposal would add a very general except when it isn't clause to that definition, requiring updates to every MUA in use. It may affect many other RFCs as well -- specifically but not limited to all email authentication RFCs that propose to address the phishing problem. 2. Advocates of such headers are sharply divided on proposed semantics. Some (Google, Scott Kitterman on the WG ML) consider that the semantics should be restricted to the Reply-To function, and otherwise be
[Mailman-Users] [Mailman-Developers] Changes coming to the GNU Mailman wiki
Barry Warsaw writes: Thus I am here to announce the imminent switch of our wiki to a new Moin server. Hurray! Huge, huge thanks go to Paul Boddie for the incredible amount of work he's put into the conversion process. Yes indeed! It's been a huge project, taking what, about a year and a half (IIRC it was discussed at PyCon Sprints in 2013)! Thanks again Paul! Steve -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] Mailman 2.1.18 final release
On Tue, May 6, 2014 at 1:37 PM, Mark Sapiro m...@msapiro.net wrote: A critical incompatibility between the Mailman 2.1.18 final release and Python versions older than 2.6.5 or thereabouts affecting the DMARC Wrap Message action was discovered and fixed. This incompatibility also existed in the 2.1.16 and 2.1.17 releases. Thus, I have released Mailman 2.1.18-1 with a fix for this incompatibility. Please use 2.1.18-1 and not 2.1.18. Thank you Mark, and thank you for the huge effort in getting the Mailman 2.18.x release out the door. I know everyone thinks this, I just felt it needed to be stated. -Jim P. -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] DMARC and Mail Lists open space at Pycon
* Mark Sapiro m...@msapiro.net: On April 11, 2014 3:18:13 PM EDT, Mark Sapiro m...@msapiro.net wrote: On 04/11/2014 05:25 AM, Mark Sapiro wrote: Tentatively rescheduled to 17:00 EDT (21:00 GMT) on Friday, 11 Apr in room 525. I will attempt to post realtime summaries on #mailman. Due to various scheduling issues, this will be rescheduled for Saturday evening (Montreal time). Details to follow. Please email me if you're thinking of attending. So far I know it's me, Florian Fuchs, and Barry Warsaw, but we need DMARC folks too. We are currently scheduled for 19:00 EDT (23:00 GMT), today, 12 Apr in room 525. It looks like it may just be Barry, Florian and me making dinner plans, but if you're interested and here please come. Yikes! That's 1:00 a.m. my time. Can't guarantee I will still be up then. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] MM3 Test Hangs
On Wed, Feb 26, 2014 at 3:13 AM, Nicolas Karageuzian nico...@karageuzian.com wrote: I encountered db lock using sqlite with mailman3 and tools. Switching to postgres avoid the db locking states. Maybe you should explore that way. I'll try that. Hyperkitty moved to github so the lp ref is quite out of date for this resource. I thought so--that't why I was asking for definitive, easy-to-find links on the wiki. Thanks, Nicolas. -Tom -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] MM3 Test Hangs
On Feb 26, 2014, at 02:45 PM, Stephen J. Turnbull wrote: I have no idea what to do next, This is clearly a bug, although I think it's relatively recent, so it might be worth seeing if earlier revisions avoid the problem. Yes, I can reproduce it. The interesting thing is that the test is in rest/docs/membership.rst so these are multiprocess related bugs. Typically when this happens (and it will only be with the default SQLite database, as observed by others), it's a bug in the test, not necessarily a bug in the core. Tests which involve multiple processes, as the REST tests do (i.e. the foreground testing process and a background runner process) have to be careful to release the database lock when they expect background processes to access the database. Releasing the lock means calling .commit() or .abort() at the appropriate time. The thing to keep in mind is that with Storm, even doing an operation that results in a database query opens a transaction and thus acquires the lock. In the context of membership.rst, what this probably means is that somewhere in the doctest there's a database query with a missing explicit .commit() or .abort() before the background REST runner process executes. Tracing through the doctest to find out exactly where it hangs usually helps isolate where the missing commit/abort should go. Of course, it's possible that there's a missing commit/abort in the core, but I rather doubt it, since that's pretty well tied into the REST runner's HTTP transaction machinery, and other REST tests don't exhibit the hang. Tom, if you're up for debugging it, that would be great. If not, no worries. The test suite hangs for me, so I'll find some time this weekend to take a look. -Barry -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] Kernel update breaks Mailman!!
On Feb 20, 2014, at 12:07 PM, Lindsay Haisley wrote: I'm running Mailman 2.1.15 on a Ubuntu server, feeding into Courier MTA, running Python 2.7.3. I track security updates and install them promptly when they're issued by Ubuntu. Yesterday I updated the Linux kernel from 3.2.0-58-generic (x86_64) to 3.2.0-59-generic and Mailman quit working. List posts made it through to the archives, and were apparently queued within Mailman, but wouldn't go out. The mail server was working OK for non-list email. Today I backed out the kernel update and posts to lists sent yesterday and today are going out without problems. I'm really quite surprised about this. From the kernel version numbers, I'm guessing you're running Ubuntu 12.04 LTS? I have my personal Mailman server running on that OS, and just performed a kernel update. I'm about to reboot it into the new kernel, so I'll send a test message out and see if it works. Very odd that a kernel update alone would cause the problem. Can you send mail normally (i.e. outside of Mailman) and connect to your port 25? I guess the one difference between our setups is that I use Postfix. -Barry -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] Mailman 2.1.15 final released.
On Fri, Jun 15, 2012 at 8:04 PM, Mark Sapiro m...@msapiro.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am happy to announce the final release of Mailman 2.1.15. This release is identical to the 2.1.15rc1 release except for the version number and the inclusion of a missing part of the HTML installation manual. Python 2.4 is the minimum supported, but Python 2.6 is recommended. This release should work with Python 2.7, but has not been tested with that version. I have tested it with Python 2.7 and I have not encountered any problems. I have been running a live site on Python 2.7 with 2.1.14, 2.1.15rc and now I am installing 2.1.15. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] Mailman 2.1.15 final released.
Mark Sapiro wrote: I am happy to announce the final release of Mailman 2.1.15. This release is identical to the 2.1.15rc1 release except for the version number and the inclusion of a missing part of the HTML installation manual. Thanks for this as ever, quality release. I upgraded in a very short space of time, all working well. Andrew. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] Mailman 2.1.15rc1 released
On Wed, May 16, 2012 at 8:57 AM, Mark Sapiro m...@msapiro.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am happy to announce the first release candidate for Mailman 2.1.15. Python 2.4 is the minimum supported, but Python 2.6 is recommended. This release should work with Python 2.7, but has not been tested with that version. This release includes minor security enhancements, new features and bug fixes. See the Changelog at https://launchpad.net/mailman/2.1/2.1.15rc1 for more details. Do I still need these patches for 2.1.15: htdig-patch indexing-patch I can't seem to find them though:( -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
On Mar 26, 2012, at 04:11 PM, Andrea Crotti wrote: Great news Barry, but just one thing, I checked now on list.org and the GNU Mailman website and there is no mention of this release.. is that on purpose? Not really. The server moved recently and my keys hadn't been installed. Looks like they still aren't, so let me ping the admins. -Barry signature.asc Description: PGP signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
On Sat, Mar 24, 2012 at 3:00 AM, Barry Warsaw ba...@list.org wrote: Hello Mailman enthusiasts! I'm also ecstatic to announce the first alpha release of Postorius, our new official name for the Django-based Mailman 3 web user interface. The name was suggested by core developer Florian Fuchs in honor of a bass hero of both of ours, Jaco Pastorius. Postorius 1.0 alpha 1 is code named Space Farm. I can't wait for Gene Simmons and Tal Wilkenfeld! :-) -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] RELEASED: GNU Mailman 3.0 beta 1 and Postorius 1.0 alpha 1
On Mar 23, 2012, at 9:00 PM, Barry Warsaw ba...@list.org wrote: Use the key, unlock the door See what your fate might have in store... Everybody walk the dinosaur! Seriously though, this is amazing news! Thanks to everyone who helped work on this. I can't wait to give it a try! Cheers, Justin -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] [Mailman-Announce] Mailman security patch.
On Sep 09, 2010, at 06:46 AM, Mark Sapiro wrote: The patch is attached. Since it only affects the web CGIs, it can be applied and will be effective without restarting Mailman, although since it includes a patch to Utils.py which is imported by the qrunners, a restart of Mailman is advisable as soon as convenient after applying the patch. Thanks Mark! -Barry signature.asc Description: PGP signature -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] [Mailman-Developers] openID enabled mailman
On Jun 13, 2009, at 1:25 PM, Brad Knowles wrote: Mailman is the wrong place to put an OpenID provider. That needs to go somewhere else, and then you can put in code that allows Mailman to be an OpenID Relyer. Well put, and I could not agree more. What would be very helpful would be adding the necessary support to Mailman 2.2 and 3 so that it can be a relying party, and perhaps we can finally deprecate or kill off the stupid user passwords. -Barry PGP.sig Description: This is a digitally signed message part -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] [Mailman-Developers] openID enabled mailman
Malveeka Tewari writes: 2. Sign in with existing openID login for your subscription *1. Enable/Disable openID login for your subscription* *account* For enabling and diabling the openID feature, the users login their subscribed accounts as they do now for changing any of the subcription options. On this page if they enable the openID feature, they recieve an automated reply with their openID identifier. The password for the openID identifier is the same as that for the subscription accounts. If they change their subscription passwords, their openID password gets changed too. I don't understand what you're trying to do. The whole point of open ID is delegating authorization to a third party. If you want, you can provide that service as well, but once you've enabled OpenID, you shouldn't need a password for Mailman. In fact, the Mailman password should be disabled, as it is certainly less secure than OpenID at this point in time. I want to know if there's already an openID enabled version of mailman available The OpenID project has OpenID-enabled Mailman lists, but according to Brad Knowles in the process of adapting Mailman to OpenID they broke a lot of other features, and integrating their changes is non-trivial. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] openID enabled mailman
Hi Stephen Thanks for your reply. W want to implement the OpenID Provider for the mailman set up we are running on our servers. The idea is to use OpenID with mailman to provide single sign on for our other user accounts like our wiki etc. Our focus is on providing Single Sign On but we do not want to delegate authentication to a third party. Hence we want to implement OpenID provider for our Mailman service. and OpenID relying party for our wiki etc. Now for the OpenID provider we may choose to have new passwords or use the mailman passwords. For ease of users, we want to use the mailman passwords for the OpenID provider. I hope I have conveyed what I am trying to do. I will be thankful for any suggestions Thanks Malveeka On Sat, Jun 13, 2009 at 12:03 PM, Stephen J. Turnbull step...@xemacs.orgwrote: Malveeka Tewari writes: 2. Sign in with existing openID login for your subscription *1. Enable/Disable openID login for your subscription* *account* For enabling and diabling the openID feature, the users login their subscribed accounts as they do now for changing any of the subcription options. On this page if they enable the openID feature, they recieve an automated reply with their openID identifier. The password for the openID identifier is the same as that for the subscription accounts. If they change their subscription passwords, their openID password gets changed too. I don't understand what you're trying to do. The whole point of open ID is delegating authorization to a third party. If you want, you can provide that service as well, but once you've enabled OpenID, you shouldn't need a password for Mailman. In fact, the Mailman password should be disabled, as it is certainly less secure than OpenID at this point in time. I want to know if there's already an openID enabled version of mailman available The OpenID project has OpenID-enabled Mailman lists, but according to Brad Knowles in the process of adapting Mailman to OpenID they broke a lot of other features, and integrating their changes is non-trivial. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] openID enabled mailman
Malveeka Tewari writes: Our focus is on providing Single Sign On but we do not want to delegate authentication to a third party. Hence we want to implement OpenID provider for our Mailman service. I don't think this is a good idea. Mailman is designed to deliver single messages to multiple parties, which it does very well, and to manage member lists, which it does tolerably well for many purposes. It is not designed to keep secrets. You may not now particularly care, but it could be very annoying later if you decide you want more security and need to switch your system. Better to put your provider in a separate place from Mailman, and have Mailman rely on and trust only your provider. You could do them on the same host if necessary but in the long run you might want to have the provider on a dedicated host, depending on how serious you become about security. and OpenID relying partyOD for our wiki etc. Now for the OpenID provider we may choose to have new passwords or use the mailman passwords. For ease of users, we want to use the mailman passwords for the OpenID provider. Again, Mailman is not very secure. In the default configuration, passwords are mailed out in cleartext over non-secure channels (and even so-called secure mail is pretty tricky -- it's much easier to secure a web application). The passwords are also stored in the clear. This means that if you want to set up OpenID for existing users by transferring their passwords, it should be possible (I don't know how offhand, though). I don't recommend that, either. Normally, people don't care that much as there's not much damage that can be done via a mailing list, except spamming, and most lists have additional defenses against that. But you plan to rely on these passwords to secure multiple services, making the value of cracking one that much higher. I would ask my own users to set new passwords in this situation. Of course, all these issues depend on a lot of factors. You may have better security than the default for the Internet in place, or much more careful users, etc. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] USE_ENVELOPE_SENDER
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 9, 2009, at 5:43 AM, Ian Eiloart wrote: I'm not sure whether I do use it, but I think I should. Most of our list users are in our own domain. That domain certainly is less spoofable in the envelope, because we don't accept mail from our domain unless it's been through our servers. We don't get spam with sussex.ac.uk in the envelope sender domain. With SPF records now widely published, including by several large free email service providers, it's certainly within the power of sites to validate the envelope sender address of much of their inbound email. Losing this facility now would be a great shame. I certainly don't see how having the option can do much harm. It might be worth adding code to support BATV, if it isn't there already. MM3 does not yet support this. So, I've landed a branch that gets rid of the MM3 equivalent to USE_ENVELOPE_SENDER, but it will still be possible to consider the MAIL FROM or Sender addresses in preference to From, if you wanted to. I've implemented a site admin definable header lookup scheme so you can define the order that headers are considered. By default it's From:, MAIL FROM, Reply-To, Sender. This is a global order just like U_E_S was. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEUEARECAAYFAkmR6p4ACgkQ2YZpQepbvXHMTgCWKRprqGSj2x2uMUvzVff+GwPa FACgsLbElDIgzCYExy/rsm92g/HG9wQ= =A0Ue -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] USE_ENVELOPE_SENDER
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 9, 2009, at 5:47 AM, Ian Eiloart wrote: I agree that the use of USE_ENVELOPE_SENDER as an anti-spoof is outdated, particularly because it doesn't even come into play for the member/nonmember decision. Strike three. :) Our LMTP code is intended to make this decision before the message headers are even seen. Perhaps that makes the whole USE_ENVELOPE_SENDER option redundant. I think so too. How's that coming along? Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmR640ACgkQ2YZpQepbvXGjOgCeKZyrV9XlzokN1X05OJ/gmNMf trgAoItdNYDwKHwMH10r5S6bfwdI3lZq =VnvI -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] Mailman Developers Guide?
It took me a long time to figure out that Mailman's 'virgin' directory was for messages that Mailman created itself. Is stuff like this documented somewhere? Is there a developer's guide to Mailman out there? -- We're just a Bunch Of Regular Guys, a collective group that's trying to understand and assimilate technology. We feel that resistance to new ideas and technology is unwise and ultimately futile. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Mailman Developers Guide?
Kelly Jones wrote: It took me a long time to figure out that Mailman's 'virgin' directory was for messages that Mailman created itself. Is stuff like this documented somewhere? Is there a developer's guide to Mailman out there? UTSL There's really nothing beyond that. Mailman 3 will be better. -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] Demo import of bugs/patches/rfes to Launchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 19, 2008, at 9:25 PM, Mark Sapiro wrote: I've played with it a little bit, and I think it will be fine. One of the obvious advantages is the tighter integration with bazaar (I guess any would be tighter than what we have :) :) I think it's fine to convert. I wonder if it is possible in the conversion to map SF users to LP users where there is a correspondence, e.g. instead of mapping SF msapiro to LP Msapiro-users, map to LP Mark Sapiro. Or if there is a way after the fact to say Msapiro-users is me. I'll double check, but I believe the way this is handled is that new users are created for each of the SF user names, and we (or the individual user) can request that those users be merged into your official LP user id. If there are no objections, I'll chat with the folks doing the import and let them know that we're ready to switch over. We'll schedule a flag day and make the announcement before actually switching over. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkizyyoACgkQ2YZpQepbvXEnzACfVUh8LIPtbEwAu4VEWp1mmUwC IqwAn2ORhWyAuNBdVJUBl+ZWaeAyJ9HY =tGzi -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] Demo import of bugs/patches/rfes to Launchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: I'm happy to announce a demo import from SourceForge's bug tracker, patches tracker, and feature request tracker into Launchpad, and I invite you to play with the new issue tracker so that we can decide whether or not to complete this step of project hosting migration. The url is https://bugs.demo.launchpad.net/mailman/+bugs snip I don't have a timeframe for converting, or deciding to convert. Much depends on your feedback (and especially Mark's) and the readiness of the LP administrators to do the production import. I think if we like it, we could make the switch fairly quickly. I've played with it a little bit, and I think it will be fine. One of the obvious advantages is the tighter integration with bazaar (I guess any would be tighter than what we have :) I think it's fine to convert. I wonder if it is possible in the conversion to map SF users to LP users where there is a correspondence, e.g. instead of mapping SF msapiro to LP Msapiro-users, map to LP Mark Sapiro. Or if there is a way after the fact to say Msapiro-users is me. - -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIq3KjVVuXXpU7hpMRAnq5AKCkaNrP8e23TjfFjhAyjAK+4PPTIACg1W7I LG6GwR2D9MC6fajycbq8KKc= =fvIu -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] GNU Mailman Site Redesign
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've done a bit more work with the site redesign, and updated the working content I had. The latest version is here: http://terri.zone12.com/mm-website/ So, that's using some red/pink from the logo as link colours as someone suggested to me. It looks fine to me on this macbook, but I'm at the Ottawa Linux Symposium and don't have my usual array of desktops to test from, so someone please let me know if it's unreadable. (I've cc'ed mailman-users to get more eyes.) Here's one wit the same idea, using darker reds: http://terri.zone12.com/mm-website/?css=mailman-dark And the original two, both beige and gray are here: http://terri.zone12.com/mm-website/?css=mailman-orig http://terri.zone12.com/mm-website/?css=mailman-alt More suggestions welcome! Terri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIh2PpnB1cG1wafMARAth3AJ9S3tMKRa7L6GkAE3RM5M5QOclC+gCdHocX mDAbF8GrYVygAg6uzfUmooE= =fz4P -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] GNU Mailman Site Redesign
Terri Oda wrote: The latest version is here: http://terri.zone12.com/mm-website/ So, that's using some red/pink from the logo as link colours as someone suggested to me. I really don't want anyone over-riding my own choices for link colors. More suggestions welcome! Did you want to mention the official Mailman group on LinkedIn? Of course, I can't figure out how to give you a link that will take you to their page for the group as opposed to the home page that I defined for the group (namely www.list.org), but that may be something we can resolve. -- Brad Knowles [EMAIL PROTECTED] Member of the Python.org Postmaster Team Co-Moderator of the mailman-users and mailman-developers mailing lists -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] GNU Mailman Site Redesign
On 23-Jul-08, at 1:22 PM, Brad Knowles wrote: The latest version is here: http://terri.zone12.com/mm-website/ So, that's using some red/pink from the logo as link colours as someone suggested to me. I really don't want anyone over-riding my own choices for link colors. The original version I had used the standard link colours (ie - it didn't set them), and comments ranged from just general malaise about the colour scheme of the links to several people who asserted it was nearly unreadable on their setups. So I'll take the comment under advisement, but I suspect you're going to be in the minority. Since I've since changed the original css, here's the current stuff with no link colours specified (so they default to your browser settings): http://terri.zone12.com/mm-website/?css=mailman-nolink Did you want to mention the official Mailman group on LinkedIn? Of course, I can't figure out how to give you a link that will take you to their page for the group as opposed to the home page that I defined for the group (namely www.list.org), but that may be something we can resolve. Seems like a good fit for the Participate page! I've put it just under the wiki entry. Also, if I can convince launchpad and my laptop to get along, I'll share the code for this. It's currently generating the pages using a little python script. Although honestly, given that there's only 7 pages here, I think we might as well generate them once and just serve up the straight HTML. Terri -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] GNU Mailman Site Redesign
Terri Oda wrote: The original version I had used the standard link colours (ie - it didn't set them), and comments ranged from just general malaise about the colour scheme of the links to several people who asserted it was nearly unreadable on their setups. That implies their client is misconfigured and that should be their problem and not ours. Right? So I'll take the comment under advisement, but I suspect you're going to be in the minority. I would urge caution about paying too much attention to a vocal minority, to the potential detriment of the majority who aren't complaining. Now, if this was being driven by 508 compliance for accessibility and there simply were no other viable options, it would be more difficult for me to have grounds for a complaint. But so far I haven't heard terms like that. Since I've since changed the original css, here's the current stuff with no link colours specified (so they default to your browser settings): http://terri.zone12.com/mm-website/?css=mailman-nolink IMO, that looks much better. Did you want to mention the official Mailman group on LinkedIn? Of course, I can't figure out how to give you a link that will take you to their page for the group as opposed to the home page that I defined for the group (namely www.list.org), but that may be something we can resolve. Seems like a good fit for the Participate page! I've put it just under the wiki entry. Cool. Thanks! -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] GNU Mailman Site Redesign
Brad Knowles writes: That implies their client is misconfigured and that should be their problem and not ours. Right? Actually, all existing clients are pretty much broken, since they don't allow you to enforce your own CSS. But I guess they figure that nearly all existing users are broken, 'cause they can't write their own CSS :-( Grrr. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] [Mailman-Developers] Mailman 2.1.10 has been released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 21, 2008, at 3:50 PM, Mark Sapiro wrote: I am happy to announce the release of Mailman 2.1.10. Congratulations Mark! Long live Mailman 2.2. :) I will update the web sites. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgNFc0ACgkQ2YZpQepbvXEQ0wCePrsNZ1cyXStsBpjMHR94o20H HoEAn3Fv8D3WC3NCSkkjg9qIS5I5CzzP =1UG9 -END PGP SIGNATURE- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Mailman 2.1.10 has been released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 21, 2008, at 9:30 PM, Mark Sapiro wrote: You could set up a cron to run every hour or some other interval to efectively do rm $var_prefix/qfiles/shunt/*.psv The problem with that is there can occasionally be queue entries preserved for other conditions which are hopefully much rarer, but you might actually want to look at those. I think the best solution is to turn off the preservation of unparseable messages, and add an mm_cfg.py setting to turn it on. I can work up a patch. We should probably have some kind of shunt queue culler cron script in place, either that archives and deletes those files, or just expires them after a certain amount of time. What to people generally do with their shunt files? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgNUlsACgkQ2YZpQepbvXFI8gCgpF+Z1ROdfrEQa4ACrUnDBkJT DWIAn0qyRtYt4/1UCCpKSmImyLAWhkZO =WmVk -END PGP SIGNATURE- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Mailman 2.1.10 has been released
On 4/21/08, Barry Warsaw wrote: We should probably have some kind of shunt queue culler cron script in place, either that archives and deletes those files, or just expires them after a certain amount of time. That's easy enough to do with cron and find. You tell me what you want, and I'll be glad to set that up. What to people generally do with their shunt files? Leave them untouched for months or years? ;-) -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] [Mailman-i18n] Hebrew Mailman Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 23, 2007, at 11:04 AM, Dov Zamir wrote: I am resending this email, as well as to the other mailing lists, since I have received zero feedback since sending the original over two weeks ago. Should I assume there is no interest in this translation, and just keep it for my own sites? Dov, I'm sorry. It's definitely been on my list of things to do, but I just haven't had time yet. We will definitely get it in for a Mailman 2.1.10 release. Thanks, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRizjT3EjvBPtnXfVAQJ1BQP/akGQ0hxsT3Kl9p+xfuhOtQV7HUSnXQdr boA4uvfGtB1mN/yRC3YQklDPaklSgLowx+WMKxNcloxWkVgWoT8ywi/8a4uLm5II 2OdHIBUT6iqagO3H+qeGQVmaK/MNCZWBRklzcbPyfD5+GDp2aG0arbTVvBJcSzGI 6kugxxXSg4o= =nGX/ -END PGP SIGNATURE- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] [Fwd: TypeError: us-asciiwith python2.4 and mailman 2.1.8-1 (debian)]
Tokio Kikuchi wrote: Hi developers, This particular problem is caused by a bug in email 4.0.1 package which was fixed in the most recent subversion repository. http://svn.python.org/view/python/trunk/Lib/email/message.py?rev=54333r1=50840r2=54333 Maybe it's time to think of next bug fix release of mailman 2.1.10 as soon as the email 4.0.2(?) is out. But Mailman 2.1.x ships with and should be installed with the email 2.5.x branch, so unless this bug was also introduced and subsequently fixed in that branch as well, it shouldn't affect a properly installed Mailman. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] [Fwd: TypeError: us-asciiwith python2.4 and mailman 2.1.8-1 (debian)]
Mark Sapiro wrote: Tokio Kikuchi wrote: Hi developers, This particular problem is caused by a bug in email 4.0.1 package which was fixed in the most recent subversion repository. http://svn.python.org/view/python/trunk/Lib/email/message.py?rev=54333r1=50840r2=54333 Maybe it's time to think of next bug fix release of mailman 2.1.10 as soon as the email 4.0.2(?) is out. But Mailman 2.1.x ships with and should be installed with the email 2.5.x branch, so unless this bug was also introduced and subsequently fixed in that branch as well, it shouldn't affect a properly installed Mailman. Oh yes, you're right, Mark. I was too much involved in mailman 2.2 which will be shipped with email 4.0.x. Perhaps, we should make warning against package distributers that 'misc' directory (pythonlib) in the mailman source tree can't be omitted. BTW, I'm looking forward to see email 4.0.2 out. ;-) -- Tokio Kikuchi, [EMAIL PROTECTED] http://weather.is.kochi-u.ac.jp/ -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] [Fwd: TypeError: us-ascii with python2.4 and mailman 2.1.8-1 (debian)]
On Tue, 2007-04-10 at 17:29 -0700, Mark Sapiro wrote: Tokio Kikuchi wrote: Hi developers, This particular problem is caused by a bug in email 4.0.1 package which was fixed in the most recent subversion repository. http://svn.python.org/view/python/trunk/Lib/email/message.py?rev=54333r1=50840r2=54333 Maybe it's time to think of next bug fix release of mailman 2.1.10 as soon as the email 4.0.2(?) is out. But Mailman 2.1.x ships with and should be installed with the email 2.5.x branch, so unless this bug was also introduced and subsequently fixed in that branch as well, it shouldn't affect a properly installed Mailman. M'kay. I've fixed the shunting issue and upgraded to mailman 2.1.9-7 (debian) so hopefully things will be smooth from now on. Thanks for all the rapid responses. -- Justin Warren [EMAIL PROTECTED] seafelt.com: Making sense of a sea of data. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Problem with format=flowed patch
Hi Mark,
I was working this patch on the trunk.
I think the indent level of this part in Scrubber.py should be
if charset is None:
charset = part.get_content_charset(lcset)
+format = part.get_param('format')
+delsp = part.get_param('delsp')
Sorry if I misunderstand.
Mark Sapiro wrote:
I have been working on a fix for the problem of Mailman's dropping
format=flowed from Content-Type: headers. There is a bug report and a
patch at
https://sourceforge.net/tracker/?func=detailatid=100103aid=1495122group_id=103.
The patch to Scrubber.py has just been revised (revised patch is
attached to the above tracker item).
Scrubber would throw an exception when processing a message with no
text/plain part. If you are using a prior version of this patch,
please get the current version to avoid this problem.
--
Tokio Kikuchi, [EMAIL PROTECTED]
http://weather.is.kochi-u.ac.jp/
--
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/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Problem with format=flowed patch
Tokio Kikuchi wrote:
I think the indent level of this part in Scrubber.py should be
if charset is None:
charset = part.get_content_charset(lcset)
+format = part.get_param('format')
+delsp = part.get_param('delsp')
Tokio,
Thanks for looking at this.
I don't think your suggestion is correct. What I am trying to do is get
the format= and delsp= parameters from only the first text/plain part
in the message. Often, this will be the only part in which case it
doesn't matter.
Consider however a message with a format=flowed text/plain 'body' and a
subsequent attached text/plain part perhaps without format=flowed. We
want to remember the format parameter from the first 'body' part and
not override it from the second text/plain part.
I recognize that there can always be a pathological case where it might
be more appropriate to get the parameters from a subsequent part, but
I think in general, the first text/plain part is the safest.
--
Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Problem with format=flowed patch
Mark Sapiro wrote: I don't think your suggestion is correct. What I am trying to do is get the format= and delsp= parameters from only the first text/plain part in the message. Often, this will be the only part in which case it doesn't matter. Sorry that I misunderstood. It was a little bit too early in the morning to start working. ;-) (6AM Japan) I've almost done with this 'format=flowed' patch and others for Scrubber.py and Decorate.py for the trunk. I'll commit them after adding some more test codes. -- Tokio Kikuchi, [EMAIL PROTECTED] http://weather.is.kochi-u.ac.jp/ -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] My new job
Congratulations, Barry! I'm very happy to hear that you can spend more time on Mailman. I also learned by quick search that Canonical is founded by this nice guy. :) http://en.wikipedia.org/wiki/Mark_Shuttleworth Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone, I just wanted to drop a quick note to let you know that I have started working for Canonical, the folks who distribute Ubuntu Linux and develop the Launchpad service for distributed open source development. I'm quite excited to be working for Canonical. They are a Python and Zope shop, very open source friendly, and based on Linux, so I'm working in an environment that's both familiar and fun. They're also a distributed company, without traditional offices, but with many folks working all over the world. They're also hiring wink, wink. :) While this is good for Barry (and hopefully good for Canonical :), I know you're thinking, what does this mean for Mailman? Well, I'm glad you asked! Part of my official duties will be to integrate Mailman with Launchpad so as to enable more powerful communication patterns among members of a distributed development team. While I won't be spending /all/ of my time on Mailman, it will be getting some official love. I hope that this will help move the current development branch closer to a release some time later this year. Other than that, not much will really change. Mailman is and will always be released under the GPL, and it will continue to be a GNU project. If you have any questions or concerns, please send them directly to me. I will attempt to answer them as best I can, and if there are common themes, I'll post updates here. Thanks for your support and keep on delivering with Mailman! - -Barry Here are some related links: http://www.canonical.com http://www.ubuntu.com http://launchpad.net P.S. I'll be at PyCon this year so if you're coming too, please say hi! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRcUTb3EjvBPtnXfVAQIQKgP/XFVeeDBn6QVXkE9oK1YJxyrLZZET5GxT TAvTJgfndkcWPuUpbC5D6hcpDNa6sfIgJnR3enoW7MgKpOAtIXTuXqPpNiFMBVT2 qUhlDHhwYzdJWWyzI/oXGRvt0lMqqA69Iu7A6DAKrgksBB128V/mYxTfv8BPmF4W uASb/9MkmAQ= =h+IQ -END PGP SIGNATURE- -- Tokio Kikuchi, [EMAIL PROTECTED] http://weather.is.kochi-u.ac.jp/ -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
On Sep 28, 2006, at 12:34 AM, Barry Warsaw wrote: In summary my preferences would be: Mailman 2.1.x supported on Python 2.3, 2.4, and 2.5. Drop support for Python 2.1 and 2.2. We've done this accidentally in Mailman 2.1.9, so let's make it official. Mailman 2.2 supported on Python 2.4 and 2.5. +1 Barry - thanks for the advice I just wanted to report that Tiger (10.4.7 : ppc), Python 2.5 (from the OS X installer), and Mailman 2.1.9 works perfectly. Install went without a hitch. Stumbled a little, setting up virtual domains, but, I've been down that road before, so I knew what to fix. Jeff -- Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? Mac OS X: Are you guys coming, or what? -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 28, 2006, at 2:13 PM, Stubbs Jeff wrote: Barry - thanks for the advice I just wanted to report that Tiger (10.4.7 : ppc), Python 2.5 (from the OS X installer), and Mailman 2.1.9 works perfectly. Install went without a hitch. Stumbled a little, setting up virtual domains, but, I've been down that road before, so I knew what to fix. Excellent, thanks for the feedback Jeff! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRRwYCnEjvBPtnXfVAQIsQAQAqlgmUL/iZuOa+Fxy0e8b/BCkrKOqvujX fHzLs3nvozDXVu2+FZ6bPOJ89nVdSchIJiUjpVfUvQxmSu3NKy8Dn6szfIgg1zuT Bk/2gkl8jMPlgh6aknxSkaNKMUJut8P74z/pjbfbBYgdm36AS9K5v1aLBvVhIx5E sB8vEZ4HP04= =vN/W -END PGP SIGNATURE- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
On 9/28/06 1:13 PM, Stubbs Jeff at [EMAIL PROTECTED] wrote: Barry - thanks for the advice I just wanted to report that Tiger (10.4.7 : ppc), Python 2.5 (from the OS X installer), and Mailman 2.1.9 works perfectly. Install went without a hitch. Stumbled a little, setting up virtual domains, but, I've been down that road before, so I knew what to fix. This all made me curious. I'm just a user of Mailman on Mac OS X - no development of any sort by me - so I'm good with 2.1.9 and Python 2.3.5 on 10.4.7 - but this topic made me look at the Python 2.5 package at python.org. I finally figured out that the MacOS X python installer installs a new version in /usr/local/bin (as well as other places) separate from the Tiger provided version in /usr/bin. But how would you get mailman to use the user installed version? mailmanctl has #! /usr/bin/python at the top which will send it to the Tiger provided version. Of course you could modify mailmanctl but that would be subject to being overwritten when a new version of mailman is installed. Or is that the way it would need to be done? For me, it's all academic at least until mailman 2.2 comes along. Maybe Leopard will come with a later version of python. But I am curious and this sort of exercise does help me understand how the various pieces fit together. -- Larry Stone [EMAIL PROTECTED] http://www.stonejongleux.com/ -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 28, 2006, at 8:45 PM, Larry Stone wrote: This all made me curious. I'm just a user of Mailman on Mac OS X - no development of any sort by me - so I'm good with 2.1.9 and Python 2.3.5 on 10.4.7 - but this topic made me look at the Python 2.5 package at python.org. I finally figured out that the MacOS X python installer installs a new version in /usr/local/bin (as well as other places) separate from the Tiger provided version in /usr/bin. But how would you get mailman to use the user installed version? mailmanctl has #! /usr/bin/python at the top which will send it to the Tiger provided version. Of course you could modify mailmanctl but that would be subject to being overwritten when a new version of mailman is installed. Or is that the way it would need to be done? I'm assuming you built Mailman from source. If so, run configure with --with-python=/usr/local/bin/python or put that python on your $PATH first, and Mailman will use that one. If you look at the source, you'll see that the #! line is actually @PYTHON@ which gets substituted by configure at build time. I forget exactly why, but the standard #! /usr/bin/env python invocation caused problems for people, so now we hardcode it via configure. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRRyCCnEjvBPtnXfVAQKYxAP+Ibg1hUcx6nE/7/hH8g6sbJ/m82+ApBl9 WkSNuR3e01gyLm0ogIu3npk0pQeflVrmsvjqSCP6iBw81gaO+oeo7zkrIyFag7Ck bqMCPIBkSDzblEUrueyTPhBvlpDlP4+vaaQSHe/EGDYSz+r/nzY/PJR6PU+lLgn4 c3SF+iHwsWU= =FnoT -END PGP SIGNATURE- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
On 9/28/06 9:16 PM, Barry Warsaw at [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 28, 2006, at 8:45 PM, Larry Stone wrote: This all made me curious. I'm just a user of Mailman on Mac OS X - no development of any sort by me - so I'm good with 2.1.9 and Python 2.3.5 on 10.4.7 - but this topic made me look at the Python 2.5 package at python.org. I finally figured out that the MacOS X python installer installs a new version in /usr/local/bin (as well as other places) separate from the Tiger provided version in /usr/bin. But how would you get mailman to use the user installed version? mailmanctl has #! /usr/bin/python at the top which will send it to the Tiger provided version. Of course you could modify mailmanctl but that would be subject to being overwritten when a new version of mailman is installed. Or is that the way it would need to be done? I'm assuming you built Mailman from source. If so, run configure with --with-python=/usr/local/bin/python or put that python on your $PATH first, and Mailman will use that one. Yes, from source (I'm on MacOS X client, not server, so no pre-installed brain-dead mailman! :-) ) If you look at the source, you'll see that the #! line is actually @PYTHON@ which gets substituted by configure at build time. I forget exactly why, but the standard #! /usr/bin/env python invocation caused problems for people, so now we hardcode it via configure. Thanks. Someone else pointed out the --with-python to me privately. I wasn't sure what you meant about $PATH at first since of course my $PATH doesn't mean anything when mailman is started at system startup but now I see it's the value of $PATH when configure is run that you mean as configure finds the first python $PATH takes it to and uses that. As I said, not really an issue for me right now but this has made a huge difference in my understanding of how the whole mailman build process works so quite valuable in that sense. So, that leads to the question, is there any reason to install python 2.5 while running 2.1.9 or are we fine with 2.3.5 if we aren't doing anything else that would benefit from 2.5? -- Larry Stone [EMAIL PROTECTED] http://www.stonejongleux.com/ -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 28, 2006, at 11:03 PM, Larry Stone wrote: On 9/28/06 9:16 PM, Barry Warsaw at [EMAIL PROTECTED] wrote: So, that leads to the question, is there any reason to install python 2.5 while running 2.1.9 or are we fine with 2.3.5 if we aren't doing anything else that would benefit from 2.5? If it ain't broke... :) You're probably fine with 2.3.5. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRRyg9nEjvBPtnXfVAQLEhgP/dGuGbr+fzIzaw7/GZbZFtbXW3DfUUbed luVI4Rhm4fgBjFbqh35d1fu12/qpIPbLWv4TKFVVV522obDJaXnY9o2sxF7H/bkF rUrXIEIVOe5usd1jq1btZlrgHrsZUOwZ64MBaGekXOhjp4XS/zTsSgex1clGeQSp ZBvXFiNSKYs= =ec3Q -END PGP SIGNATURE- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
In summary my preferences would be: Mailman 2.1.x supported on Python 2.3, 2.4, and 2.5. Drop support for Python 2.1 and 2.2. We've done this accidentally in Mailman 2.1.9, so let's make it official. Mailman 2.2 supported on Python 2.4 and 2.5. +1 -- Tokio Kikuchi, [EMAIL PROTECTED] http://weather.is.kochi-u.ac.jp/ -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 27, 2006, at 9:32 PM, [EMAIL PROTECTED] wrote: Mailman 2.1.x supported on Python 2.3, 2.4, and 2.5. Drop support for Python 2.1 and 2.2. We've done this accidentally in Mailman 2.1.9, so let's make it official. Would it be possible to maintain a rough list of Python-2.3-and-later features that are required for current Mailman as the requirements are added? That would at least give folks who think they need an older Python some idea of what would be involved in adapting their Python installation to Mailman needs. Mark Sapiro wrote this message describing the unintended breakage in Mailman 2.1.9: http://mail.python.org/pipermail/mailman-users/2006-September/ 053290.html So the big difference between 2.1 and 2.2 was the unification of classes and types, which also changed the built-in factory functions like int() and str() to be types instead of functions. No one should use Python 2.2 for anything really. It was a fairly radical release and many of the new features didn't stabilize until Python 2.3. The main reason I want to drop Python 2.1 and 2.2 is that I simply can't build them on OS X any more, so I can't effectively test them. I'm not sure if Tokio and Mark are in the same boat though. I can't build Python 2.3 either, but at least there, I don't have to (thanks Apple!). As for Mailman 2.2, there are lots and lots of features I want to use from Python 2.4. Built-in sets, generators, PEP 292 $-strings (pioneered in Mailman), decorators, and the subprocess module to name a few. Of the new-in-Python 2.5 features I'd use but can live without, probably conditional expressions absolute imports, and the with statement are the most interesting. Oh, and the built-in sqlite3 package wink. http://www.python.org/doc/2.3/whatsnew/whatsnew23.html http://www.python.org/doc/2.4/whatsnew/whatsnew24.html http://www.python.org/doc/2.5/whatsnew/whatsnew25.html - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRRsx7nEjvBPtnXfVAQI3SgP/b3jeJti1AVveujcH1gwfwcwtG1LpU23X ECNQP2wybm6xwIhIl2Hjop58A6CjrauAZvWtF2YspMHeg6l/NnZ7DcCzc1VbKZQT cAhmsrHOh+MK5tIdLaOkQtl4T8D8i8tmtLrTDO+Wh6rhfG/oVhDa2IbNrdUZ59LQ yDvB1Nc+1m0= =yYt8 -END PGP SIGNATURE- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] OS X Mailman Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 27, 2006, at 8:29 PM, Tokio Kikuchi wrote: In summary my preferences would be: Mailman 2.1.x supported on Python 2.3, 2.4, and 2.5. Drop support for Python 2.1 and 2.2. We've done this accidentally in Mailman 2.1.9, so let's make it official. Mailman 2.2 supported on Python 2.4 and 2.5. +1 Cool, it's official then. :) http://wiki.list.org/x/8Q http://wiki.list.org/x/IQ - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRRtQxHEjvBPtnXfVAQLtcAQAlc7v5W0a6uUJgdvn8C0QC9crWKt1yqzJ U7Mylo33yFiUyXzbI1qkos6AJaAVij2q/elWdRj2+8sUOfBMdHI4NKpZQDcrFe2A wzzPZTG7HfTyckFMfOb0TYFqkzonlKAbBZTuqrTqagLh79k5FUFE8mPuqITpOiZ4 k4c3H4qU+2k= =4SI6 -END PGP SIGNATURE- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Anyone have a pickle / mbox to spare?
On 7/23/06, emf [EMAIL PROTECTED] wrote: It would sincerely help me if I could test my UI against actual mailman pickles to make sure I can deal with vagaries of configuration, etc. I'd be happy to provide a script to randomize all users passwords before you sent it over, but would prefer that the email addresses stay valid. I don't need generated archive files; just list pickles and mbox files, if you've been generating them. I've got a 213MB mbox, and associated pickle although it's a public list. Just let me know where to send it. -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting What a great ride! -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
William == William D Tallman [EMAIL PROTECTED] writes: William On Wed, May 03, 2006 at 11:11:22PM +0900, Stephen William J. Turnbull wrote: I don't think that is the way that RFC writers in general think. William Yes, so I gather. :-) William Which means that people really should learn to use email William systems intelligently, with the MUA of choice as the William means of control. I firmly believe that, but unfortunately there are lots of MUAs that don't really permit intelligent use. Many people inherit an MUA either from their OS or maybe their brother-in-law, and do not have the desire or resources to change MUAs or even learn to use the one they've got effectively. There are a number of ways to look at this, but what the people who write RFCs have come to insist is that you be strict with yourself (always follow the rules and best practices), while being lenient with others. You can think of this as simply aikido on the Internet (== self-defense), or some kind of generosity to those less clued than oneself, but the rule works well whyever you follow it. :-) So a good mail client will initialize the address of a reply to the Reply-To, but provide a way for the user to override. The RFC only specifies the former, though, and only as a suggestion. Exactly how to handle this problem is a user interface issue, and the RFC remains silent on such issues. William Implication here is that 'user' is a real human being, William not a software agent. In this particular case, user refers to user of a good mail client, presumably human (but it could easily be an Emacs Lisp program or an expect script ... ok, ok, that's not easy, that's heroic ... but it could be heroicly!) However, most of RFC 2822 doesn't refer to how the headers should be treated by a mail client, just to what they mean. That meaning could be useful to a human, or a mailing list server, or whatever. William RFC2822, section 3.6.6 discusses re-sending fields as William intended for use by a re-sending 'user'. It also William specifies that these fields are for informational William purposes only, and MUST NOT be used to actively William manipulate the message. Automatically. There's nothing that says that you can't write a mail client that has an bounce followup feature which looks for sender, resent-sender and so on, and adds them to the To header, as well as formatting the body with a summary of the progress of the message by using Date and Resent-Date headers. William So an email list server cannot act as a re-sender, IIUC. I don't see why not. I think you're overinterpreting the RFCs. Certainly, in this case human user is a leading interpretation. But if the actions described could be executed by a program, then there's no good reason not to interpret user as possibly being a program, unless the RFC explicitly says so. William The alternative is that the server actually initiates a William new message as a 'forwarding' agent. I don't think either of the meanings of forward suggested in RFC 2822 section 3.6.6 apply here. (New message with old message as body clearly applies to digests, but I think we're more interested in non-digest delivery in this thread.) [William gives an example] William That means that the server must (MUST?) identify itself William in the originator fields. No, I think that's wrong. If the server wants to claim responsibility for injecting the message into the mail system, then it should put itself in the Sender field. This absolves the original Sender of all responsibility for misformatting of the message, misdirection to wrong addresses, etc, etc. If the server doesn't change the body at all, and only adds new headers, then I think it should not do this. In the grey areas like Mailman, it's unclear. However, suppose Mailman is configured to leave the headers alone, and to leave the body alone, forwarding verbatim to the addresses on the mailing list (except for adding its List- headers, etc). I would argue that since Mailman doesn't automatically forward, but instead checks for spam, whether you're subscribed or not, whether the subscriber is already an addressee in the message, etc., it makes decisions about what to send where, and is therefore a user in the sense of section 3.6.6. Mailman SHOULD add Resent- headers, because if delivery gets screwed up, bugs in its logic should be considered a candidate cause. Ie, those headers mean that Mailman accepts partial responsibility for misdirecting the reinjection of the message into the mail transport system. For example, suppose Mailman hiccups and reinjects the same post twice. It would be useful to check whether the Resent-Message-Ids differ. If they do, you know for sure it was Mailman. If they don't, it doesn't prove it wasn't Mailman, but you do know that the phase where the error occurred was fairly late in
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Tue, May 09, 2006 at 12:33:29AM +0900, Stephen J. Turnbull wrote: William == William D Tallman [EMAIL PROTECTED] writes: snip Well damn!!! I am genuinely impressed and appreciative of this response! Have it saved off in a separate file to study. Mr. Turnbull has my sincere thanks for his effort here, and I hope that others may have found it as valuable as did I. On reflection, I stand instructed in several respects (not just about failing to discount what my own MTA added to the headers :D ), but specifically in the distinction between illegal and non-conforming. I should well have known better than that, having some knowledge of programming (C), and being a long-time detractor of message windows produced by a popular operating system to the effect that one has performed an ILLEGAL operation (emphasis mine). I may never actually put Mailman into service, but the project is both interesting and instructive, in no small part in consequence of the traffic on this list. Again, my thanks to Mr. Turnbull. Thanks for reading, Bill Tallman -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
William == William D Tallman [EMAIL PROTECTED] writes: William How does the RFC, or the writers thereof, define user? They don't. IMHO (there are those more expert than I on this list) anything that is normally expected to touch the headers or body of a message is a user for the purpose of RFC 2822. What is excluded is the mail transport system (MTAs) which are specified in RFC 2821. There is also a distinction between originators and others. Certain headers (From, Subject, Date, etc) are specified as for the use of the originator. Other headers are generally specified in terms of their semantics alone, and not according to who may use them. William An automated system is the tool of some deliberate William intent, implying (necessarily?) the will of a user, I William would think. I don't think that is the way that RFC writers in general think. Although there is a desire for RFC 2822 headers to be intelligible to humans, and many are very useful in day-to-day work, RFCs are in the end about machine-to-machine communication. Thus the focus is on syntax so that machines can parse them without knowing what they mean, and of semantics that allow machines to make a good guess at what the humans are going to want. For example, if there is a Reply-To header, the From header should be ignored, and the Reply-To address used in composing the addressee list for a reply. However, one of the examples used IIRC is where the author of the original message is traveling and uses his own address as From (that's the identity the recipient recognizes) but Reply-To to direct the response to his host, whose email address he is borrowing. Now, a human who replies a week later will know that the boss is back home and want to reply to From but the mail client can't know that. So a good mail client will initialize the address of a reply to the Reply-To, but provide a way for the user to override. The RFC only specifies the former, though, and only as a suggestion. Exactly how to handle this problem is a user interface issue, and the RFC remains silent on such issues. William Or is this relevant? Yes. Sometimes such definitions are made explicitly. I don't think they exist in this case, but it's a very good idea to ask. * Disclaimer: this is the way I think about these things, and I've found it useful in understanding what RFCs do and don't say. Others will surely have different opinions. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Wed, May 03, 2006 at 11:11:22PM +0900, Stephen J. Turnbull wrote: William == William D Tallman [EMAIL PROTECTED] writes: William How does the RFC, or the writers thereof, define user? They don't. IMHO (there are those more expert than I on this list) anything that is normally expected to touch the headers or body of a message is a user for the purpose of RFC 2822. What is excluded is the mail transport system (MTAs) which are specified in RFC 2821. Okay. There is also a distinction between originators and others. Certain headers (From, Subject, Date, etc) are specified as for the use of the originator. Other headers are generally specified in terms of their semantics alone, and not according to who may use them. Okay. William An automated system is the tool of some deliberate William intent, implying (necessarily?) the will of a user, I William would think. I don't think that is the way that RFC writers in general think. Yes, so I gather. Although there is a desire for RFC 2822 headers to be intelligible to humans, and many are very useful in day-to-day work, RFCs are in the end about machine-to-machine communication. Thus the focus is on syntax so that machines can parse them without knowing what they mean, and of semantics that allow machines to make a good guess at what the humans are going to want. Okay, that follows. For example, if there is a Reply-To header, the From header should be ignored, and the Reply-To address used in composing the addressee list for a reply. However, one of the examples used IIRC is where the author of the original message is traveling and uses his own address as From (that's the identity the recipient recognizes) but Reply-To to direct the response to his host, whose email address he is borrowing. Now, a human who replies a week later will know that the boss is back home and want to reply to From but the mail client can't know that. Which means that people really should learn to use email systems intelligently, with the MUA of choice as the means of control. So a good mail client will initialize the address of a reply to the Reply-To, but provide a way for the user to override. The RFC only specifies the former, though, and only as a suggestion. Exactly how to handle this problem is a user interface issue, and the RFC remains silent on such issues. Implication here is that 'user' is a real human being, not a software agent. RFC2822, section 3.6.6 discusses re-sending fields as intended for use by a re-sending 'user'. It also specifies that these fields are for informational purposes only, and MUST NOT be used to actively manipulate the message. As a re-sender does not alter the originating fields, software presumably cannot automagically use that information to ID the source of the message, which remains the purview of the originating fields. So an email list server cannot act as a re-sender, IIUC. The alternative is that the server actually initiates a new message as a 'forwarding' agent. That means that the server must (MUST?) identify itself in the originator fields. The address of the author of the message goes in the From: field, and the address of the forwarder (the email list's originating mailbox) goes in the Sender: field, with information on responses in the Reply-To: field. As the author is not the email list server, the address of the server's mailer MUST be by itself in the Sender: field. All as per section 3.6.5. Additionally, one would think that the server is a 'forwarder' because the message it sends out is not identical to the message it receives: it adds footers, etc. IIUC, that is. Which apparently I do not, having read through the headers of a message from this list. There is no Sender: field. The first field is apparently an unstructured field with no identifier with the canonical following colon. It contains the sender (mailman-users-bounces...) and the date, presumably of sending. The second field is Return-Path: with an 'addr-spec'. The originator fields are untouched. Which means that the list server is neither a re-sender or a forwarder, I gather, and that means I don't understanding any of this at all! Or is it that the server really is a re-sender in disguise and my MUA (MDA, actually: Procmail) is forced to process this message to its final destination in my mail system illegally? As I'm (recreationally) in the process of setting up and understanding a wee Mailman server on my own system, I'd really like to understand all this, but looks like I've got a ways to go. William Or is this relevant? Yes. Sometimes such definitions are made explicitly. I don't think they exist in this case, but it's a very good idea to ask. Okay, thanks for this response! And thanks again for reading, Bill Tallman -- Mailman-Users mailing list Mailman-Users@python.org
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Mon, 2006-05-01 at 18:16 -0700, Mark Sapiro wrote: Neal Groothuis wrote: Mailman is not the originator of the message, so it should not be tampering with the From: or Sender: fields at all. This is arguably not true. Mailman may add a list header and/or list footer to the body of the message as well as potentially filtering or scrubbing various MIME parts. The message sent by Mailman can be significantly different from the one originally received. The copy that Mailman sends is almost always modified in some way, and given the ambiguities in the standards, I think it's defensible to say that Mailman is the originator of the messages received by list members. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Mon, 2006-05-01 at 13:27 -0500, Neal Groothuis wrote: I'd like to work up an unofficial diff to Mailman 2.1 for people like Stephen who are willing to give it a try on a live site. I'm not sure this is even necessary. Ezmlm doesn't touch the Sender: header at all, Majordomo sets it to the owner of the list, and (AFAICT) Listserv sets it to the list itself. This would seem to me to indicate that incidences of mail being returned inappropriately to the sender are infrequent, at worst. As I said, I think it's defensible to claim Mailman is the originator, but practicality beats purity, and I do think a list manager falls into a gray area here. Having said all that, you might be right, in that we really don't need to do much except remove the addition of the Sender: header in bulkdeliver(). -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Fri, 2006-04-28 at 19:12 -0500, Brad Knowles wrote: I think we need to gather a lot more information about the likely outcome from this change, and I think the best way to achieve this is through giving admins (either site admins or list admins) the ability to set an option and choose whether or not they want to see what happens. I agree that we need a lot more data, but I'm not sure making this an option is the best way to gather that data. Besides, if we do it that way, it'll be Mailman 2.3 (or whatever 3.0 wink) before we make the change. I'd like to work up an unofficial diff to Mailman 2.1 for people like Stephen who are willing to give it a try on a live site. We just have to agree as to what that change should be! -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Sun, 2006-04-30 at 00:00 +0900, Stephen J. Turnbull wrote: Sender doesn't instruct *conformant* MTAs at all, does it? AFAIK the only thing that a RFC 2821-conforming MTA looks at is the Return-Path header, and it's supposed to remove that. So this is purely a matter of pragmatic self-defense against broken MTAs that do bounce to Sender. Correct, and what we're trying to figure out is whether we need that self-defense any longer. The change to test this may be as simple as commenting out msg['Sender'] = envsender in bulkdeliver() inside SMTPDirect.py (a little more complicated if you want to do it just for one domain though -- you'd want to test for something like if 'xemacs.org' in mlist.host_name) Agreed. For a number of reasons, I think this information can be useful. As I mentioned elsewhere, the Resent-Message-Id field can be used to supply a UUID that we can trust (eg, for constructing canonical archive URLs). Unlike the Received headers, these are readable by humans who aren't wall-eyed, helpful in tracing delays, for example. It's an intersting idea. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
I'd like to work up an unofficial diff to Mailman 2.1 for people like Stephen who are willing to give it a try on a live site. I'm not sure this is even necessary. Ezmlm doesn't touch the Sender: header at all, Majordomo sets it to the owner of the list, and (AFAICT) Listserv sets it to the list itself. This would seem to me to indicate that incidences of mail being returned inappropriately to the sender are infrequent, at worst. The important question would seem to be what's appropriate? From RFC 2822, 3.6.2: The originator fields indicate the mailbox(es) of the source of the message. Given this, the definition of the Sender and From headers, and the example given in this section, it seems that Outlook's interpretation of the fields (SENDER on behalf of FROM) is reasonable. Mailman is not the originator of the message, so it should not be tampering with the From: or Sender: fields at all. It might be appropriate for Mailman to add Resent-* headers, depending on how one reads RFC 2822, 3.6.6. I personally don't think it's necessary or useful, since list servers add their own List-* headers, per RFC 2369. The Resent-* headers seem to exist for individuals resending messages, not automated systems. This is supported by the RFC: Resent fields are used to identify a message as having been reintroduced into the transport system by a user. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Watching this with interest; a newbie learns... On Mon, May 01, 2006 at 01:27:40PM -0500, Neal Groothuis wrote: snip It might be appropriate for Mailman to add Resent-* headers, depending on how one reads RFC 2822, 3.6.6. I personally don't think it's necessary or useful, since list servers add their own List-* headers, per RFC 2369. The Resent-* headers seem to exist for individuals resending messages, not automated systems. This is supported by the RFC: Resent fields are used to identify a message as having been reintroduced into the transport system by a user. How does the RFC, or the writers thereof, define user? An automated system is the tool of some deliberate intent, implying (necessarily?) the will of a user, I would think. Or is this relevant? Thanks for reading. Bill Tallman -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Neal Groothuis wrote: Mailman is not the originator of the message, so it should not be tampering with the From: or Sender: fields at all. This is arguably not true. Mailman may add a list header and/or list footer to the body of the message as well as potentially filtering or scrubbing various MIME parts. The message sent by Mailman can be significantly different from the one originally received. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Yes, and it still happens. Apparently, AOL has some filter based on a FROM: address matching a specific list, and bounces it with an SPF error, which it clearly is not. Bob -- Original Message --- From: Barry Warsaw [EMAIL PROTECTED] Have you tried turning on full personalization so that every recipient gets their own copy? -Barry --- End of Original Message --- -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Brad == Brad Knowles [EMAIL PROTECTED] writes: At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote: Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational headers, so I don't see how adding them will instruct a receiving MTA usefully. Sender doesn't instruct *conformant* MTAs at all, does it? AFAIK the only thing that a RFC 2821-conforming MTA looks at is the Return-Path header, and it's supposed to remove that. So this is purely a matter of pragmatic self-defense against broken MTAs that do bounce to Sender. Brad Siunce the RFC doesn't specifically talk about relay Brad agents as separate from users, I think we could argue Brad that Mailman would qualify as a user in this context. Brad Therefore, the Resent-* headers seem to be most appropriate. Agreed. For a number of reasons, I think this information can be useful. As I mentioned elsewhere, the Resent-Message-Id field can be used to supply a UUID that we can trust (eg, for constructing canonical archive URLs). Unlike the Received headers, these are readable by humans who aren't wall-eyed, helpful in tracing delays, for example. Brad If we need something that will be noticed by other MTAs Brad beyond the envelope sender and the Return-Path: Brad Errors-To: headers, then we're going to have to carefully Brad think about this. What's an Errors-To header? I can't find it in the usual suspects. But I don't see any particular need for thought. Conforming Internet MTAs don't look at message headers, period. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
At 12:00 AM +0900 2006-04-30, Stephen J. Turnbull wrote: Brad If we need something that will be noticed by other MTAs Brad beyond the envelope sender and the Return-Path: Brad Errors-To: headers, then we're going to have to carefully Brad think about this. What's an Errors-To header? I can't find it in the usual suspects. That's the oldest technique for handling bounces. It has been deprecated for a while, but I would be inclined to continue to at least provide the appropriate information. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On 4/29/06 8:00 AM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Sender doesn't instruct *conformant* MTAs at all, does it? AFAIK the only thing that a RFC 2821-conforming MTA looks at is the Return-Path header, and it's supposed to remove that. There is no Return-Path: header during transmission of a message. The Return-Path header is added in the process of delivery. There is a return path, stated in the MAIL FROM:[EMAIL PROTECTED] SMTP command. (That command *can* have more stuff related to authentication.) The return path is what should be used as the address of a bounce if a mail system foolishly accepts a message and then creates a bounce. Notice that if an MTA rejects a message (or one or more of the recipients of the message), it is not bouncing or creating a bounce. It is issuing an error response...the MTA (or MUA in the case of message submission) that was trying to send creates a bounce message if appropriate (for message submission, the MUA notifies the user--or pretends to: Microsoft by default hides the notification remarkably well). While multi-line text associated with the rejection code is provided for, MUAs are very poor about showing it if a submission is rejected--some show only the first line; some only the last line. Even some MTAs improve the text of the rejection. --John -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote: If the previous value of the Sender: field is being lost, then that should be corrected. At the very least, the value should be saved in an Old-Sender: or Previous-Sender: or some other suitable renamed sender field. Probably Original-Sender: -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On 4/28/06 6:06 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote: If the previous value of the Sender: field is being lost, then that should be corrected. At the very least, the value should be saved in an Old-Sender: or Previous-Sender: or some other suitable renamed sender field. Probably Original-Sender: Probably, indeed. But what happens if that header was already taken in the process that brought the message to mailman for distribution to the list? (As usual, I have only questions, not answers.) --John -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
John W. Baxter wrote: Probably, indeed. But what happens if that header was already taken in the process that brought the message to mailman for distribution to the list? As I noted in my previous response, I believe that the correct field (if Mailman were to add a Sender: header) to add would be Resent-Sender. Please see RFC 2822, section 3.6.6. The Resent-Sender field may be multivalued, so this isn't a problem. However, Mailman should not be modifying the Sender: field at all. Original-Sender is a header used when gatewaying X.400 messages into RFC 822 messages for use in JNT mail networks. It would not be appropriate for use here. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Don't forget to consider things like SPF, which I think uses the sender field. Whatever is used for SPF _must_ be the domain of the mailman box, or you're gonna run into a pack of trouble. ...Trouble similar to a current problem I am having with AOL: they are bouncing all email with the FROM: address of a specific AOL user, when mailman delivers the messages to -any- aol or cs.com address. Its a very bad problem, because AOL is saying its a SPF problem, when it clearly isn't (as other aol people can post to the list and receive their posts), and all the aol users are being automatically unsubscribed from lists that this guy posts on. But I digress... Bob Neal Groothuis wrote: It does not appear that Mailman modifies the Sender: field to comply with RFC 2822. The list-bounces address is not the mailbox of the agent responsible for transmitting the message, as required in section 3.6.2. The mailbox of the agent responsible for the transmission of the message would be the list-owner address. Mailman's use the Sender: field does not seem to be in line with the intent of the RFC, nor with current usage of the field. snip -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Dallas Bethune wrote: For our uses just changing that list-bounces address to something less ominous looking would help. It definitely looks to me as if something needs to be done. I think perhaps offering 3 options either to the list admin on a per-list basis with a site default or just a site option. I lean towards per-list although it's more work to add to the GUI. The options I see are 1) current behavior with perhaps the addition of putting the original Sender: in another header. 2) like 1) only use list address instead of list-bounces. 3) don't touch Sender: at all. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
Now that I have a few minutes to breath ;) I'll try to summarize my thoughts on this, and then perhaps go back later and follow up to specific points later in the thread. I'm sympathetic to ripping out the Sender: field munging. It was always primarily a workaround for buggy MTAs. If the majority of MTAs out there now Do The Right Thing, then of course we want to be RFC compliant. Outlook's behavior has always been a wart but so far, the benefits have outweighed the costs. If the benefits are minimal now, then it should go. The question that must be answered is: if we no longer munge Sender: header, what are the right headers to set to increase the likelihood that bounces will go where we want them to? I don't care about the minority of still-deployed buggy MTAs that may send bounces to the wrong place as long as we can be reasonably assured they won't send them to /some/ wrong places. For example, I think it would be bad if they started spamming list owners with bounces, very bad if they spammed the original message authors, and worse if they spammed the mailing list with bounces. We have almost none of that now and if we removed the Sender: header and saw a huge increase in this bad behavior, then the benefits of munging the header go way up. Of course, we might not know until we start deploying, which would be too late. I encourage those of you who want to get rid of Sender: munging to modify your Mailman 2.1 code now and see what happens. :) Of course, you'll let us know how that goes! My recommendation would be to record the results in the wiki. I agree that the RFCs are a bit murky in this area, but it's relatively clear that the RFC 2822 'secretary' example illustrates the intent of Sender:. Our list owners are not the agents transmitting the messages, so listname-owner should clearly not go in Sender:. We really want to increase the chances that Mailman will process all bounces. As I mention above, we absolutely can't be a vector for spamming people with bounces they can't do anything about. If some buggy MTAs throw bounces away though, tough luck for their users. There should be enough compliant MTAs out there that the added cost of keeping bogus addresses on a list because we never saw their bounces should be low. I don't really like list or site options for this kind of thing. For one thing, we already have too many options and adding list options complicates the U/I and cognitive load for list admins who usually really don't want to be bothered with this nonsense. We should be reducing the options a list admin has to worry about, not increasing them. This is not really appropriate for a site admin either because that's too coarse of a decision. A Mailman site talks to a huge array of MTAs and MUAs, so I don't think you could make a good choice. If anything, should we determine that Sender: munging has to stay, it should be a user option because only the user knows whether their MUA will present them with an ugly message display. A user could decide to turn off Sender: munging, but I suspect it's still more than the typical user will want to deal with. And of course per-user options get into all the personalization vs. performance issues. Is listname-bounces confusing? Yes, and I wouldn't be opposed to changing this, although I'm not sure what we'd use. listname-processor? Well, let's hope we can just get rid of Sender: munging instead. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote: As I noted in my previous response, I believe that the correct field (if Mailman were to add a Sender: header) to add would be Resent-Sender. Please see RFC 2822, section 3.6.6. Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational headers, so I don't see how adding them will instruct a receiving MTA usefully. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
On Fri, 2006-04-28 at 14:08 -0400, Bob [EMAIL PROTECTED] wrote: ...Trouble similar to a current problem I am having with AOL: they are bouncing all email with the FROM: address of a specific AOL user, when mailman delivers the messages to -any- aol or cs.com address. Have you tried turning on full personalization so that every recipient gets their own copy? -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote: On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote: As I noted in my previous response, I believe that the correct field (if Mailman were to add a Sender: header) to add would be Resent-Sender. Please see RFC 2822, section 3.6.6. Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational headers, so I don't see how adding them will instruct a receiving MTA usefully. Siunce the RFC doesn't specifically talk about relay agents as separate from users, I think we could argue that Mailman would qualify as a user in this context. Therefore, the Resent-* headers seem to be most appropriate. But you are correct that these are purely informational and will be completely ignored by any MTA. If we need something that will be noticed by other MTAs beyond the envelope sender and the Return-Path: Errors-To: headers, then we're going to have to carefully think about this. I am still opposed to blindly making this change and letting the community find out what happens. I think we need to gather a lot more information about the likely outcome from this change, and I think the best way to achieve this is through giving admins (either site admins or list admins) the ability to set an option and choose whether or not they want to see what happens. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Permission of data/bounce-events-?????.pck
imacat wrote: I noted that in the source of mailman 2.1.7 there are 2 lines in bin/mailmanctl: line 421-422 # Clear our file mode creation umask os.umask(0) Is this intended? Is it the reason why data/bounce-events-?.pck are world-writable? There doesn't appear to be a good reason. This has been changed for Mailman 2.1.8 so that the 'default' umask will be 007 and also the specific creation of the bounce-events queue file will have no permission for 'other'. The changes to bin/mailmanctl and Mailman/Queue/BounceRunner.py have been committed to CVS and can be seen (soon) at http://cvs.sourceforge.net/viewcvs.py/mailman/mailman/. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Problems with uuencoded attachments
On Jan 14, 2006, at 9:59 PM, Tokio Kikuchi wrote:
Mark Sapiro wrote:
File /usr/lib/python2.3/uu.py, line 139, in decode
sys.stderr.write(Warning: %s\n % str(v))
File /usr/lib/mailman/Mailman/Logging/MultiLogger.py, line 45,
in write
_logexc(logger, msg)
File /usr/lib/mailman/Mailman/Logging/Utils.py, line 22, in
_logexc
sys.__stderr__.write('Logging error: %s\n' % logger)
IOError: [Errno 32] Broken pipe
I think this could be fixed by changing
/usr/lib/mailman/pythonlib/email/Message.py, line 223 from
uu.decode(StringIO(payload+'\n'), sfp)
to
uu.decode(StringIO(payload+'\n'), sfp,
quiet=True)
There should be other chances that Python builtin modules spew
warnings to sys.stderr. How about this patch for Logging/Utils.py
to write these messages into syslog facility.
The only problem is that currently Mailman does not use the syslog
module, and I'm uncomfortable with adding it for this one situation
(are there others?). We should definitely be passing the quiet flag
to uu.decode(), but OTOH maybe we should also be testing whether
sys.__stderr__ is detached and then redirecting that to logs/errors?
-Barry
--
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/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Problems with uuencoded attachments
Barry Warsaw wrote:
On Jan 14, 2006, at 9:59 PM, Tokio Kikuchi wrote:
Mark Sapiro wrote:
File /usr/lib/python2.3/uu.py, line 139, in decode
sys.stderr.write(Warning: %s\n % str(v))
File /usr/lib/mailman/Mailman/Logging/MultiLogger.py, line 45,
in write
_logexc(logger, msg)
File /usr/lib/mailman/Mailman/Logging/Utils.py, line 22, in
_logexc
sys.__stderr__.write('Logging error: %s\n' % logger)
IOError: [Errno 32] Broken pipe
I think this could be fixed by changing
/usr/lib/mailman/pythonlib/email/Message.py, line 223 from
uu.decode(StringIO(payload+'\n'), sfp)
to
uu.decode(StringIO(payload+'\n'), sfp,
quiet=True)
There should be other chances that Python builtin modules spew
warnings to sys.stderr. How about this patch for Logging/Utils.py
to write these messages into syslog facility.
The only problem is that currently Mailman does not use the syslog
module, and I'm uncomfortable with adding it for this one situation
(are there others?). We should definitely be passing the quiet flag
to uu.decode(), but OTOH maybe we should also be testing whether
sys.__stderr__ is detached and then redirecting that to logs/errors?
In usual mailman qrunner execs, stderr is logged into logs/errors. It
is the additional tee_to_real_stderr in LogStdErr() setting which wants
to print the error into real stderr.
Isn't it safe to put the tee_to_real_stderr value 0 in bin/qrunner script ?
--
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/
--
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/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Problems with uuencoded attachments
On Mon, 2006-01-16 at 09:25 +0900, Tokio Kikuchi wrote: In usual mailman qrunner execs, stderr is logged into logs/errors. It is the additional tee_to_real_stderr in LogStdErr() setting which wants to print the error into real stderr. Isn't it safe to put the tee_to_real_stderr value 0 in bin/qrunner script ? Ideally, tee_to_real_stderr would be !AS_SUBPROC (i.e. tee when not running qrunner under mailmanctl). That would have to be done in main() after processing the command line arguments. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Problems with uuencoded attachments
Barry Warsaw wrote:
On Mon, 2006-01-16 at 09:25 +0900, Tokio Kikuchi wrote:
In usual mailman qrunner execs, stderr is logged into logs/errors. It
is the additional tee_to_real_stderr in LogStdErr() setting which wants
to print the error into real stderr.
Isn't it safe to put the tee_to_real_stderr value 0 in bin/qrunner script ?
Ideally, tee_to_real_stderr would be !AS_SUBPROC (i.e. tee when not
running qrunner under mailmanctl). That would have to be done in main()
after processing the command line arguments.
Yeah, I noticed that too and played around. How about this patch.
I assumed running qrunner independently is for debugging purpose and
quit redirecting stderr into logs/error.
--
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/
Index: qrunner
===
RCS file: /cvsroot/mailman/mailman/bin/qrunner,v
retrieving revision 2.9.2.1
diff -u -r2.9.2.1 qrunner
--- qrunner 27 Aug 2005 01:40:16 - 2.9.2.1
+++ qrunner 16 Jan 2006 01:58:49 -
@@ -66,6 +66,9 @@
runner is required unless -l or -h is given, and it must be one of the names
displayed by the -l switch.
+
+Note also that this script should be started up from mailmanctl as a normal
+operation. It is only useful for debugging if it is run separately.
import sys
@@ -84,8 +87,6 @@
# Flag which says whether we're running under mailmanctl or not.
AS_SUBPROC = 0
-LogStdErr('error', 'qrunner', manual_reprime=0)
-
def usage(code, msg=''):
@@ -212,6 +213,10 @@
if len(runners) == 0:
usage(1, _('No runner name given.'))
+# Before we startup qrunners, we redirect the stderr to mailman syslog.
+if AS_SUBPROC:
+LogStdErr('error', 'qrunner', manual_reprime=0, tee_to_real_stderr=0)
+
# Fast track for one infinite runner
if len(runners) == 1 and not once:
qrunner = make_qrunner(*runners[0])
--
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/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] filename too long error - stopping list
On Fri, 2005-12-23 at 09:22 +0900, Tokio Kikuchi wrote: May be we should set this default in Defaults.py.in in the next release of 2.1.7. Thoughts? It's probably a good idea, but also as Stephen says, it might be a good idea to shorten the filename (keeping the extension) even when this value is left as False. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Low level bug: (solved)
On Thu, 2005-07-28 at 11:52, Mark Sapiro wrote: The real issue here seems to be that the import from mm_cfg done in the driver script is inadequately protected. The driver script print_traceback definition contains try: from Mailman.mm_cfg import VERSION except ImportError: VERSION = 'lt;undeterminedgt;' This is fine if there is an ImportError exception, but since mm_cfg.py is edited by users, it is possible (likely) that there will be a SyntaxError error exception here, and something more meaningful than the Mailman experienced a very low level failure and could not even generate a useful traceback for you. message could be reported. Bare excepts are evil, but maybe it's warranted in this situation. All we really care about is the VERSION variable you're right that users can easily put all manner of nastiness in there. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] subject_prefix multiplication
At 12:41 AM -0400 2005-05-13, Barry Warsaw wrote: Thanks for the quick heads up. I think I just fixed it. At least I /hope/ so, 'cause I'm going to bed. ;) So far as I know, we had been running a plain-jane 2.1.6rc3 installation on this machine. Is the fix for the subject line duplication going to be included in 2.1.6rc4, or at least the final 2.1.6-REL? -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] subject_prefix multiplication
On Fri, 2005-05-13 at 05:05, Brad Knowles wrote: At 12:41 AM -0400 2005-05-13, Barry Warsaw wrote: Thanks for the quick heads up. I think I just fixed it. At least I /hope/ so, 'cause I'm going to bed. ;) So far as I know, we had been running a plain-jane 2.1.6rc3 installation on this machine. Is the fix for the subject line duplication going to be included in 2.1.6rc4, or at least the final 2.1.6-REL? Yes. And I emailed Tokio last night (well, a few hours ago which for me included the briefest of naps :) that I think we'll need one more release candidate. I'll probably spin that today, er, in a few hours. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] subject_prefix multiplication
Barry Warsaw wrote: On Fri, 2005-05-13 at 05:05, Brad Knowles wrote: At 12:41 AM -0400 2005-05-13, Barry Warsaw wrote: Thanks for the quick heads up. I think I just fixed it. At least I /hope/ so, 'cause I'm going to bed. ;) So far as I know, we had been running a plain-jane 2.1.6rc3 installation on this machine. Is the fix for the subject line duplication going to be included in 2.1.6rc4, or at least the final 2.1.6-REL? Yes. And I emailed Tokio last night (well, a few hours ago which for me included the briefest of naps :) that I think we'll need one more release candidate. I'll probably spin that today, er, in a few hours. -Barry I believe I could finally fix the bug and commited in CVS. IMHO, python re.escape() should escape special characters only -- I can't find '%' in special character list in the manual. -- Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] subject_prefix multiplication
On Fri, 2005-05-13 at 08:14, Tokio Kikuchi wrote: I believe I could finally fix the bug and commited in CVS. IMHO, python re.escape() should escape special characters only -- I can't find '%' in special character list in the manual. Cool. Sounds like a bug to me. I'll probably spin rc4 in about 7 hours. -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] subject_prefix multiplication
On Fri, 2005-05-13 at 00:23, Mark Sapiro wrote: All of a sudden, within the last hour or so, subject_prefix on both mailman-users@python.org and mailman-developers@python.org is being added to replies even though it's already present resulting in doubling and tripling (so far not more) of the prefix. Thanks for the quick heads up. I think I just fixed it. At least I /hope/ so, 'cause I'm going to bed. ;) will-test-a-few-follow-ups-to-be-sure-first-ly y'rs, -Barry signature.asc Description: This is a digitally signed message part -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Mailman Developers
Hi all, Our company is looking for Mailman developers to help us to setup our Forums project. We are based in Thailand so anyone who knows somebody in the region that can help us is most appreciated. Thanks in advance. John _ John Kromodimedjo ICT Programme Officer Health and Development Networks Chiang Mai, Thailand -- Mailman-Users mailing list [EMAIL PROTECTED] 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/ This message was sent to: [EMAIL PROTECTED] Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
