Mailman-Developers March 2007

mailman-developers@python.org

8 participants
8 discussions

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8184] trunk/mailman/Mailman

by Tokio Kikuchi

Hi Barry, bwarsaw(a)users.sourceforge.net wrote: > Revision: 8184 > http://svn.sourceforge.net/mailman/?rev=8184&view=rev > Author: bwarsaw > Date: 2007-03-29 22:09:36 -0700 (Thu, 29 Mar 2007) > > Log Message: > ----------- > api_lock(): When locking the MailList object, tell the SQLAlchemy session to > expire the object. This way, when the MailList attributes are next accessed, > the ORM will reload them from the database, getting any new values possibly > set in other processes. > > This works better than trying to use always_refresh=True on the mapper, or > trying to do a reload() because both of those approaches blow away locks. I'm > not sure why this, but I suspect that it's because the identity map is handing > us back a different object, rather than invalidating the object's attributes. > > Modified Paths: > -------------- > trunk/mailman/Mailman/database/dbcontext.py > trunk/mailman/Mailman/testing/test_handlers.py > > Modified: trunk/mailman/Mailman/database/dbcontext.py > =================================================================== > --- trunk/mailman/Mailman/database/dbcontext.py 2007-03-27 06:35:12 UTC (rev 8183) > +++ trunk/mailman/Mailman/database/dbcontext.py 2007-03-30 05:09:36 UTC (rev 8184) > @@ -129,6 +129,7 @@ > > # Higher level interface > def api_lock(self, mlist): > + self.session.expire(mlist) > # Don't try to re-lock a list > if mlist.fqdn_listname in self._mlist_txns: > return > Wow! Fix is so simple. I've done a test with this using two terminals: terminal A terminal B $ bin/withlist test $ bin/withlist test >>> m.description u'' >>> m.Lock() >>> m.description = 'test' >>> m.Save() >>> m.Load() >>> m.description u'' >>> m.Unlock() >>> m.Lock() >>> m.description u'test' Mere Load() can't refresh the list attributes but needs Lock() to get them. A few problem remains like decorating the message where OutgoingRunner is used. This runner don't update the database so it doesn't use Lock() but only Load(). We should fix them to use Lock() (and Unlock()) to reload data. -- Tokio Kikuchi, tkikuchi(a)is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

14 years, 1 month

How can I reload mlist data from SA database

by Tokio Kikuchi

Hi Barry, Since we at Japanese universities are in Spring vacation, I started testing 2.2 code on my PC. What is curious about the LMTP/HTTP interfaces with SQLAlchemy based database is that changes commited in LMTP/HTTP sessions cannot be reflected on the other sessions. If I subscribe an address via HTTP then it cannot be unsubscribed from LMTP and vise versa, until I restart the runners. Perhaps we need a reload mechanism but I don't know how to implement it. Other than that, I think I've checked with i18n plain text message deliveries for both regular and digest. Still to go are mime multipart messages and archives. I've also added a comment on Testing Mailman 2.2 wiki page how to test run the 2.2 code. Cheers, -- Tokio Kikuchi, tkikuchi(a)is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

14 years, 1 month

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8181] trunk/mailman/Mailman

by Barry Warsaw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tokio, Thanks for the patches, and especially the test cases! I have a couple of questions for you. I noticed that current trunk is failing three tests: test_no_multipart_mixed_charset test_scrub_image test_scrub_text Can you check to see if those are failing for you? Also I was wondering about the latest change to passwords.py: On Mar 24, 2007, at 10:57 PM, tkikuchi(a)users.sourceforge.net wrote: > Modified: trunk/mailman/Mailman/passwords.py > =================================================================== > --- trunk/mailman/Mailman/passwords.py 2007-03-24 06:01:35 UTC (rev > 8180) > +++ trunk/mailman/Mailman/passwords.py 2007-03-25 02:57:18 UTC (rev > 8181) > @@ -240,6 +240,9 @@ > scheme = scheme_parts[0].lower() > scheme_enum = _SCHEMES_BY_TAG.get(scheme, _DEFAULT_SCHEME) > scheme_class = _SCHEMES_BY_ENUM[scheme_enum] > + if isinstance(rest_group, unicode): > + # decode() fails. (challenge is from database) > + rest_group = str(rest_group) > return scheme_class.check_response(rest_group, response, > *scheme_parts[1:]) Earlier, I was using s.encode('utf-8') to ensure that we had an 8-bit string for the hash function. I'm wondering if you prefer str() over .encode('utf-8') here and if so, what the reason is? Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRghtRXEjvBPtnXfVAQJAXQP/enWB9iOvVDJ6B+k3ggN32EjszSH4XvKU lY9A6gomMIdE+gIivNtbBx6ziv6w2AvYkV2fBC3sc5ooyZGQesjl5gpeZ53AwCyF HF9bVQuW72L9TxvWIYOO+wnADr97YyYSU/rNHT7GPua5Z+1SnwF5FQknFtpVFZdO yqzwK5b5C5E= =moCg -----END PGP SIGNATURE-----

14 years, 1 month

Problem with format=flowed patch

by Mark Sapiro

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=detail&atid=100103&aid=1495122&group_…>. 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. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

14 years, 1 month

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8169] trunk/mailman/Mailman/OldStyleMemberships.py

by Barry Warsaw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 20, 2007, at 7:13 PM, msapiro(a)users.sourceforge.net wrote: > Revision: 8169 > http://svn.sourceforge.net/mailman/?rev=8169&view=rev > Author: msapiro > Date: 2007-03-20 16:13:26 -0700 (Tue, 20 Mar 2007) > > Log Message: > ----------- > - Fixed a bug in OldStyleMemberships.addNewMember that allowed > adding an address > with upper case in the domain if the local part was all lower case. > - Changed the semantics of OldStyleMemberships.changeMemberAddress > os that > in the case of a straightforward address change, i.e. nodelete = 0, > delivery status and time are preserved if BYUSER or BYADMIN. > > Modified Paths: > -------------- > trunk/mailman/Mailman/OldStyleMemberships.py Thanks for fixing this Mark. For the change on the trunk, do you think we can get test cases in there for these two bugs? (Probably test_membership.py is a good place to add them.) Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRgE7S3EjvBPtnXfVAQLpSgP/XO+95FBO1yabTt5/L+76JLM3xX0PyqvP Xc2Wob4tJUdFBq9ibP8OXnfFXR3eZxjVEdMTMHMwJ6L96y53sbBgnwyVALh+A3T7 oK/Isqlw8ThITN8UgQB2tTYekaA4O5Ay5lNxW0Pyhd1v8pangK9NO6Q/2ZkdJtQI fsTT0nJXNJE= =TnNK -----END PGP SIGNATURE-----

14 years, 1 month

[Fwd: A work based on your nmzproc]

by Lindsay Haisley

This link may be of interest to the Mailman dev team. -------- Forwarded Message -------- From: Kiss Gabor (Bitman) <kissg(a)ssg.ki.iif.hu> To: fmouse(a)fmp.com Subject: A work based on your nmzproc Date: Mon, 19 Mar 2007 13:17:35 +0100 (CET) Hi Lindsay, Maybe you are interested in this document. http://bakacsin.ki.iif.hu/~kissg/project/mailman+namazu/ Regards Gabor

14 years, 1 month

Advanced Reply-To-Munging

by Sven Anderson

Hi all, here's finally my next proposal for a less broken but yet very useful reply-to-munging: - Motivation Non-technical users (generally) love defaults. They don't wanna have to choose between three different kind of reply buttons. And no-way they want to change their MUA they just got painfully used to (or even their mail address, as most of them are using webmail providers), just because of a stupid mailing list. So there's a user base who are mostly using webmailers and Outlook, and who just want to press "Reply" as they usually do, no matter if there is even a "Reply-To-All" button right next to it. Although this is a big pain for us geeks, I think a great software like Mailman should offer options (not default behavior) to serve such a user base. That's why I think, that Mailman should offer an option to set the default behavior of the standard reply button. The question what the default behavior of the reply button should be has to be discussed in each lists user base, Mailman should offer the choice. Many list admins are very thankful, if they don't have to educate their users. - Proposed solution There is no RFC-way to set the default address for replies. The Reply-To header _replaces_ the From address in replies, which is something else than setting a default. That's why setting the Reply-To completely hides the From address (regarding replies) and therefore abusing it as a default breaks the reply-to-all function for instance, as it doesn't include the From address neither (which is correct, as long as the Reply-To address is an _replacement_ for the From address). Since there is no other way but to abuse the Reply-To header to control the default reply behavior, reply-to-munging has to take care of the From address too. There are four possible default reply targets that I consider as useful and should be offered at least as a list-wide option. (If individual mails are sent out, like with VERP, a per-user option is the best of course.) 1. Author 2. List 3. All recipients and author 4. Explicit address And this is, what I propose that Mailman should do in these cases: ad 1) Author is the "default default target" ;-). So no munging needed at all, no problems. ad 2) If Reply-To is already set, it is removed. Reply-To is set to the lists address. The old Reply-To or - if not existing - the From address is checked if it is a list member. If not, it is added as a "fake Cc" to the Cc header, in order to make the reply-to-all function work. ad 3) If Reply-To is already set, it is removed. Reply-To is set to: - the lists address, - all addresses in To/Cc headers, that are no list members, and - the old Reply-To or - if not existing - the From address, if not a list member ad 4) If Reply-To is already set, it is removed. Reply-To is set to the explicit address. The old Reply-To or - if not existing - the From address is checked if it is a list member. If not, it is added as a "fake Cc" to the Cc header, in order to make the reply-to-all function work. Of course, with option 2-4 you still lose the reply-to-author function, but at least for 2 and 4 in exchange for a new function, which a standard MUA with just a reply and reply-to-all button doesn't offer. Example: Me and two colleagues are the management board of a local radio station. We use Mailman as a "Deluxe-Alias" for both communication among us and as Alias for people who want to contact us. So a lot of mails on this list come from non-members. In these cases I either want to answer only to the list (my colleagues) or to the author and the list, but _never_ to the author alone. So it's obvious that in this case we would like to have the reply button going to the list, and reply-to-all going to all (including the author, what at the moment doesn't work). We want the default going to the list, not only because of our MUAs (Thunderbird, Mutt, Webmailer) only Mutt supports reply-to-list, but also because we want the default reply to be the least dangerous, which in our case is the list. Funnily enough, the mutt user wants the most, that the normal reply is going to the list. ;-) I hope I could make clear my ideas and point of view. Cheers, Sven

14 years, 2 months

Feature request: Reply-To Munging etc.

by Sven Anderson

Hi, as many of you probably would agree, whether you munge the Reply-To headers or not, both ways are not perfect. Just today I had a hard time again, as I'm not happy with both options, and finally came up with some ideas how the situation could be improved, about which I would like to read your comments: 1) Receiver clean-up (if Reply-To munging is NOT used) One of the problems not using Reply-To munging is, that by using the reply-to-all function of MUAs the list of receivers tends to accumulate. As in open lists the users cannot know, if an address is part of the list, they cannot just delete them without risking to drop people from the discussion. So what about an option to clean-up the receivers list in Mailman, that is Mailman removes all To/CC addresses which are members of the list? 2) Add non-member-senders to Reply-To (if Reply-To munging IS used) One of the annoying things using Reply-To munging in open lists is, that you cannot easily include external authors in replies, whether you are using reply-to or reply-to-all in your MUA. It would be nice, if the sender could be added to the Reply-To addresses in the case, that the sender is not a member of the list, so that replies automatically go to the list AND the author. (Of course, this should be done only, if the sender didn't set his own Reply-To header already.) 3) Add sender to Reply-To (if Reply-To munging IS used) As an variation to the proposal 2) it also would be nice to have the sender in general be added to the Reply-To header. That would make replies behave similar as the reply-to-all in case of no Reply-To munging. This makes it easier to reply only to the author, and not the whole list, by just deleting the list address while replying. Because you can also have address accumulation in that case, if users use the reply-to-all function, you could combine this option with the "receiver clean-up" option from proposal 1). As proposal 3) doesn't need to know the member status of addresses, you can also easily implement it in the MTA, therefore it is the least important one. What do you think about that? (With some help I can also try to implement this on my own, if there are chances to include it into the official Mailman.) Cheers, Sven

14 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers March 2007