Mailman 3 June 2006 - Mailman-coders

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net 19 Aug '22

19 Aug '22

Patches item #657951, was opened at 2002-12-23 14:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-18 18:43 Message: Logged In: YES user_id=12800 Andrew, to get the url for the archived message use mlist.GetBaseArchiveURL(), which knows about private vs. public archives, the host name and the list name. From there you should be able to tack on just the part of the path under "archives/private/listname". See Mailman/Handlers/Scrubber.py for an example. Only other minor comment: NUM_ARTICLES can probably go in Defaults.py.in ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 16:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-17 20:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 15:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 14:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 14:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 14:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…

2 1

[ mailman-Patches-871062 ] A MemberAdaptor for LDAP-based membership
by SourceForge.net 30 Jun '06

30 Jun '06

Patches item #871062, was opened at 2004-01-05 18:09 Message generated for change (Comment added) made by viktu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=871062&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: K. A. Krueger (fubarobfusco) Assigned to: Nobody/Anonymous (nobody) Summary: A MemberAdaptor for LDAP-based membership Initial Comment: This is a module, LDAPMemberships, which extends MemberAdaptor to support membership lists based on a search in an enterprise LDAP directory. With this module, you can make mailing lists which, rather than having a list of member addresses stored in the list, query your LDAP server for member addresses whenever necessary. For instance, if you wish to have a mailing list of all the Vice Presidents in your company, you can express this as an LDAP search: "(title=Vice President*)" and create a mailing list which performs this search and delivers mail to the resulting user accounts when a message is sent to it. This way, rather than manually adding new Vice Presidents to the mailing list, you can simply have Human Resources update the LDAP records, and the change will immediately take effect for the mailing list. Mailman lists with LDAP-based membership can still have moderators, list policies, and the other usual features of Mailman lists. There are a few missing features; notably: 1. There is no bounce processing. 2. There are no per-user preferences. 3. The Web interface still allows you to try setting user preferences, but if you do you will get a stack thrown at you. (Only the "readable" interface of MemberAdaptor is implemented.) 4. The LDAP settings of a list (e.g. LDAP server and search string) are only administrable by editing its "extend.py" file, not over the Web. 5. There is no digest mode. To use this module, you must have the "ldap" Python module installed (aka "python-ldap"). Then just put LDAPMemberships.py in the "Mailman" directory (~mailman/Mailman), create a new list, and write an "extend.py" file in the list directory like so: ##### from Mailman.LDAPMemberships import LDAPMemberships def extend(list): ldap = LDAPMemberships(list) ldap.ldapsearch = "(title=Vice President*)" # members search string ldap.ldapserver = "ldap.example.net" # your enterprise LDAP server ldap.ldapbasedn = "dc=Example dc=net" # your LDAP base DN ldap.ldapbinddn = '' # a bind DN which can read people's 'mail' field ldap.ldappasswd = '' # the password for the bind DN list._memberadaptor = ldap ##### This module has been tested at my site and is in production on a Mailman 2.1.2 installation. ---------------------------------------------------------------------- Comment By: Viktu Pons (viktu) Date: 2006-06-30 11:00 Message: Logged In: YES user_id=1530492 Hi all, I'm having troubles with this memberadaptor, which I can't resolve as I have no idea of python :( The fact is that sometimes it works, sometimes not. If the query returns few values (this is 50,60) it works fine, but when I have to select a huge amount of addresses (say 3000) it gives up giving errors such "Can't contact LDAP server". Then it puts the message in the shunt folder, and sometimes unshunting several times it sends the email, and sometimes you lose it forever and can't find where it went. Any ideas? Anyone having the same problem? Thanks a lot! ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2005-02-01 18:02 Message: Logged In: YES user_id=944208 I've just uploaded version 0.4 of LDAPMemberships.py. This includes the patch by the_olo to support multiple values in 'mail', and also fixes a bug reported by Mark Sapiro involving importing defaults from the wrong module. ---------------------------------------------------------------------- Comment By: martin whinnery (mawhin) Date: 2004-08-25 17:39 Message: Logged In: YES user_id=90418 I've hacked your work about to get it to handle lists based on group membership instead. You may find it worthwhile. http://webserver.offal.homelinux.org/LDAPMemberAdaptor/V3.0/LDAPMemberAdapt… This version's nasty, but you'll get the idea. Wanna roll it into yours? Mart ---------------------------------------------------------------------- Comment By: Aleksander Adamowski (the_olo) Date: 2004-04-05 15:47 Message: Logged In: YES user_id=244001 I suggest this patch to allow senders use any source address they might have set in LDAP (the 'mail' attribute can have multiple values!) --- LDAPMemberships.py.orig 2004-04-01 12:31:54.000000000 +0200 +++ LDAPMemberships.py 2004-04-05 15:40:03.000000000 +0200 @@ -115,7 +115,9 @@ # mail is unique mail = attrs['mail'][0].strip() self.__members.append(mail) - self.__member_map[mail] = mail + # mail can have multiple values + for secondarymail in attrs['mail']: + self.__member_map[secondarymail.strip()] = mail if attrs.has_key('mailalternateaddress'): malts = attrs['mailalternateaddress'] for malt in malts: ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2004-03-31 05:59 Message: Logged In: YES user_id=944208 Well, Mailman does a lot more than just keep track of who's subscribed -- for instance, restricted posters, list moderation, archiving. LDAPMemberships is not meant to be useful for Internet mailing lists with people signing up for them, but rather for institutional or enterprise lists. These have a lot of the same requirements (moderation etc.) as Internet lists, but don't need subscription/unsubscription -- since employees are usually required to be on them. My workplace is using this (well, actually a later version than the one I've uploaded here) as a replacement for an LDAP mailing-list feature in Netscape SuiteSpot now that we have migrated away from that system. We -also- use LDAP-based aliases (in Postfix, not Sendmail, actually) -- but for some things we need the moderation and other facilities that Mailman has. For instance, we have an announcements list that goes to all regular employees. A simple alias would allow anyone to send stuff to it, and certain senior scientists would love to send big PDFs to everyone. A Mailman list with LDAPMemberships can have sender restrictions so that only our IT Director and our mail systems admin can approve posts to it. Archiving is also quite useful for announcements lists. ---------------------------------------------------------------------- Comment By: Chris Drumgoole (cdrum) Date: 2004-03-31 05:38 Message: Logged In: YES user_id=429400 why use this when you can just use Sendmail's LDAP -> Alias functions? No need for a mailing list program like mailman.. right? ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2004-01-26 21:35 Message: Logged In: YES user_id=944208 Yet another new version (0.3) of LDAPMemberships.py. This one fixes some ambiguities with LDAP record handling, particularly for users with multiple "cn" values, and those who send mail as their "mailalternateaddress" field address rather than their "mail" field. If anyone is actually using this, please email me and let me know :) ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2004-01-20 17:53 Message: Logged In: YES user_id=944208 I've uploaded a new version (0.2) of LDAPMemberships.py. This one is some ungodly number of times faster, as it does not do redundant LDAP queries in a single load. ---------------------------------------------------------------------- Comment By: K. A. Krueger (fubarobfusco) Date: 2004-01-05 18:18 Message: Logged In: YES user_id=944208 Er. SF ate the indentation on my "extend.py" example in the patch description. All of the lines after "def extend(list):" are meant to be indented once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=871062&group_i…

1 0

[ mailman-Bugs-1507248 ] no delivery to lists "wrong" footer characters
by SourceForge.net 23 Jun '06

23 Jun '06

Bugs item #1507248, was opened at 2006-06-16 05:14 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ulrik Haugen (ulrik_haugen) >Assigned to: Mark Sapiro (msapiro) Summary: no delivery to lists "wrong" footer characters Initial Comment: Mailman 2.1.8: I recently had a problem with list administrators changing the footer to something containing characters that do not fit the default language for the list. (Actually it was the result of an upgrade but it can be reproduced more easily this way.) This resulted in letters to these lists going to the archive but not beeing distributed to list members. After some investigation i discovered that they were instead getting sent to the shunt directory with the following error message in logs/error: Jun 15 16:40:26 2006 (11718) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) Traceback (most recent call last): File "/service/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/service/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/service/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/SMTPDirect.py", line 132, in process Decorate.process(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/Decorate.py", line 99, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) SHUNTING: 1150382425.6505611+4f10f0ef8067c96952336a07919d018adc6a9979 I think this is a very bad idea as it results in the list administrator complaining to me as site administrator about letters not being delivered instead of (for instance) the list members complaing to the list administrator about unreadable characters in the footer. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-23 13:18 Message: Logged In: YES user_id=1123998 This is now fixed in Subversion both in the trunk and the Release_2_1-maint branch. The fix strips (ignores) header/footer characters outside the character set of the list's language. ---------------------------------------------------------------------- Comment By: Ulrik Haugen (ulrik_haugen) Date: 2006-06-17 15:49 Message: Logged In: YES user_id=636029 If I understand correctly the solutions you outline are: 1) Have mailman strip the characters outside the list character set from any header/footer and "attach" the remainder to the message as before. 2) Attach the header/footer as separate parts if they contain characters outside the list character set but mark these parts as beeing encoded with the list character set. If so, I'd certainly prefer the first approach, stripping the header/footer over delivering incorrectly marked messages. One other option might be to skip the header/footer entirely if it can't be attached correctly. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-16 09:03 Message: Logged In: YES user_id=1123998 I think you are correct. I'm not sure about the fix though. Current code in Decorate.py is (sorry for wrapped lines): # TK: Try to keep the message plain by converting the header/ # footer/oldpayload into unicode and encode with mcset/lcset. # Try to decode qp/base64 also. uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: oldpayload = unicode(msg.get_payload(decode=True), mcset) frontsep = endsep = u'' I see two approaches to fix this. The first is to change uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) to uheader = unicode(header, lcset, 'ignore') ufooter = unicode(footer, lcset, 'ignore') This will cause the rogue characters to be ignored. The second approach is to move the uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: inside the try as try: uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) The result of this will be to add the header and/or footer in separate MIME parts in this case. I also thought of using 'replace' instead of 'ignore' in the first approach, but this will likely result in a UnicodeError in encode() later on and ultimately have the same result as the second approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_…

1 0

[ mailman-Bugs-1511226 ] Bug in cs translation
by SourceForge.net 23 Jun '06

23 Jun '06

Bugs item #1511226, was opened at 2006-06-23 12:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1511226&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ladislav Vaiz (ziav) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in cs translation Initial Comment: Please apply patch sent as attachment. It fixed month name bug in Czech transation. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1511226&group_…

1 0

[ mailman-Bugs-1054944 ] Default templates set bgcolors
by SourceForge.net 22 Jun '06

22 Jun '06

Bugs item #1054944, was opened at 2004-10-27 01:58 Message generated for change (Comment added) made by hramrach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1054944&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: MJ Ray (slef) Assigned to: Nobody/Anonymous (nobody) Summary: Default templates set bgcolors Initial Comment: Many of the templates for the CGI and for the archives set background colours but do not set text colours. This leads to readers who don't use dark-on-light default colours getting very hard-to-read pages. Mailman is not following Web Content Accessibility Guideline 2.2 I attach a patch which fixes templates/en in a minimal way. I hope that's OK. If not, please direct me. ---------------------------------------------------------------------- Comment By: Michal Suchanek (hramrach) Date: 2006-06-22 17:18 Message: Logged In: YES user_id=404997 What's the status of this? There are many broken installations of MailMan out there where the subscription page is unreadable. It is still broken in 2.1.7 (I doubt the site admins actively break this). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1054944&group_…

1 0

[ mailman-Feature Requests-874329 ] Next/Previous Month links in archives
by SourceForge.net 19 Jun '06

19 Jun '06

Feature Requests item #874329, was opened at 2004-01-10 03:45 Message generated for change (Comment added) made by mamandel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=874329&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nathan Gray (n8gray) Assigned to: Nobody/Anonymous (nobody) Summary: Next/Previous Month links in archives Initial Comment: Mailman has really improved my life with its wonderful archive generation, but there's one oversight in the interface. There should be "Next Month" and "Previous Month" links in the thread/date view of the archives. It's pretty annoying to have to manually type the month name in the URL or go back to the list-info, then to the archive list, then to the month in question. ---------------------------------------------------------------------- Comment By: Mark A. Mandel (mamandel) Date: 2006-06-19 16:47 Message: Logged In: YES user_id=915526 I second the motion. I'm not a sysadmin, I'm a researcher, and perforce a research administrator. At times I have been maintaining 6-8 lists for different but related groups, and searching back and forth through several of those lists for a discussion that took place something like a year ago is just maddening, simply because there's no way to jump to the next archive set (next or previous month). You have to go up several pages -- BACK won't do it, because the previous page was the previous post that you read. And then you've got a page full of these lines -- October 2003: [ Thread ] [ Subject ] [ Author ] [ Date ] [ Gzip'd Text 19 KB ] -- and if you happen to have been skipping around before zeroing in on the year or the quarter you want, there's no visual clue even to where you were. That's the kind of thing you ought to be able to keep in mind easily, but late in a tiring day it's just one more pain. Your alternative, of course, is to go into the address line and replace "2003-October" with "2003-November". This is probably a little more galling for me than for most list administrators because I have difficulty with long terms of typing and mousing, and prefer to do as much as I can with speech recognition. [This text prepared with Dragon NaturallySpeaking.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=874329&group_i…

1 0

[ mailman-Bugs-1507248 ] no delivery to lists "wrong" footer characters
by SourceForge.net 17 Jun '06

17 Jun '06

Bugs item #1507248, was opened at 2006-06-16 14:14 Message generated for change (Comment added) made by ulrik_haugen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ulrik Haugen (ulrik_haugen) Assigned to: Nobody/Anonymous (nobody) Summary: no delivery to lists "wrong" footer characters Initial Comment: Mailman 2.1.8: I recently had a problem with list administrators changing the footer to something containing characters that do not fit the default language for the list. (Actually it was the result of an upgrade but it can be reproduced more easily this way.) This resulted in letters to these lists going to the archive but not beeing distributed to list members. After some investigation i discovered that they were instead getting sent to the shunt directory with the following error message in logs/error: Jun 15 16:40:26 2006 (11718) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) Traceback (most recent call last): File "/service/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/service/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/service/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/SMTPDirect.py", line 132, in process Decorate.process(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/Decorate.py", line 99, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) SHUNTING: 1150382425.6505611+4f10f0ef8067c96952336a07919d018adc6a9979 I think this is a very bad idea as it results in the list administrator complaining to me as site administrator about letters not being delivered instead of (for instance) the list members complaing to the list administrator about unreadable characters in the footer. ---------------------------------------------------------------------- >Comment By: Ulrik Haugen (ulrik_haugen) Date: 2006-06-18 00:49 Message: Logged In: YES user_id=636029 If I understand correctly the solutions you outline are: 1) Have mailman strip the characters outside the list character set from any header/footer and "attach" the remainder to the message as before. 2) Attach the header/footer as separate parts if they contain characters outside the list character set but mark these parts as beeing encoded with the list character set. If so, I'd certainly prefer the first approach, stripping the header/footer over delivering incorrectly marked messages. One other option might be to skip the header/footer entirely if it can't be attached correctly. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-16 18:03 Message: Logged In: YES user_id=1123998 I think you are correct. I'm not sure about the fix though. Current code in Decorate.py is (sorry for wrapped lines): # TK: Try to keep the message plain by converting the header/ # footer/oldpayload into unicode and encode with mcset/lcset. # Try to decode qp/base64 also. uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: oldpayload = unicode(msg.get_payload(decode=True), mcset) frontsep = endsep = u'' I see two approaches to fix this. The first is to change uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) to uheader = unicode(header, lcset, 'ignore') ufooter = unicode(footer, lcset, 'ignore') This will cause the rogue characters to be ignored. The second approach is to move the uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: inside the try as try: uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) The result of this will be to add the header and/or footer in separate MIME parts in this case. I also thought of using 'replace' instead of 'ignore' in the first approach, but this will likely result in a UnicodeError in encode() later on and ultimately have the same result as the second approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_…

1 0

[ mailman-Patches-1507615 ] Updated courier-to-mailman.py
by SourceForge.net 17 Jun '06

17 Jun '06

Patches item #1507615, was opened at 2006-06-17 02:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1507615&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Knowles (shub) Assigned to: Nobody/Anonymous (nobody) Summary: Updated courier-to-mailman.py Initial Comment: Submitted to me by Lindsay Haisley <fmouse(a)fmp.com>, who took the qmail-to-mailman.py script in the contrib/ directory, and modified it to suit for use with the Courier MTA. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1507615&group_…

1 0

[ mailman-Bugs-1507248 ] no delivery to lists "wrong" footer characters
by SourceForge.net 16 Jun '06

16 Jun '06

Bugs item #1507248, was opened at 2006-06-16 05:14 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ulrik Haugen (ulrik_haugen) Assigned to: Nobody/Anonymous (nobody) Summary: no delivery to lists "wrong" footer characters Initial Comment: Mailman 2.1.8: I recently had a problem with list administrators changing the footer to something containing characters that do not fit the default language for the list. (Actually it was the result of an upgrade but it can be reproduced more easily this way.) This resulted in letters to these lists going to the archive but not beeing distributed to list members. After some investigation i discovered that they were instead getting sent to the shunt directory with the following error message in logs/error: Jun 15 16:40:26 2006 (11718) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) Traceback (most recent call last): File "/service/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/service/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/service/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/SMTPDirect.py", line 132, in process Decorate.process(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/Decorate.py", line 99, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) SHUNTING: 1150382425.6505611+4f10f0ef8067c96952336a07919d018adc6a9979 I think this is a very bad idea as it results in the list administrator complaining to me as site administrator about letters not being delivered instead of (for instance) the list members complaing to the list administrator about unreadable characters in the footer. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-16 09:03 Message: Logged In: YES user_id=1123998 I think you are correct. I'm not sure about the fix though. Current code in Decorate.py is (sorry for wrapped lines): # TK: Try to keep the message plain by converting the header/ # footer/oldpayload into unicode and encode with mcset/lcset. # Try to decode qp/base64 also. uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: oldpayload = unicode(msg.get_payload(decode=True), mcset) frontsep = endsep = u'' I see two approaches to fix this. The first is to change uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) to uheader = unicode(header, lcset, 'ignore') ufooter = unicode(footer, lcset, 'ignore') This will cause the rogue characters to be ignored. The second approach is to move the uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) try: inside the try as try: uheader = unicode(header, lcset) ufooter = unicode(footer, lcset) The result of this will be to add the header and/or footer in separate MIME parts in this case. I also thought of using 'replace' instead of 'ignore' in the first approach, but this will likely result in a UnicodeError in encode() later on and ultimately have the same result as the second approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_…

1 0

[ mailman-Bugs-1507248 ] no delivery to lists "wrong" footer characters
by SourceForge.net 16 Jun '06

16 Jun '06

Bugs item #1507248, was opened at 2006-06-16 14:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ulrik Haugen (ulrik_haugen) Assigned to: Nobody/Anonymous (nobody) Summary: no delivery to lists "wrong" footer characters Initial Comment: Mailman 2.1.8: I recently had a problem with list administrators changing the footer to something containing characters that do not fit the default language for the list. (Actually it was the result of an upgrade but it can be reproduced more easily this way.) This resulted in letters to these lists going to the archive but not beeing distributed to list members. After some investigation i discovered that they were instead getting sent to the shunt directory with the following error message in logs/error: Jun 15 16:40:26 2006 (11718) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) Traceback (most recent call last): File "/service/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/service/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/service/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/SMTPDirect.py", line 132, in process Decorate.process(mlist, msg, msgdata) File "/service/mailman/Mailman/Handlers/Decorate.py", line 99, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128) Jun 15 16:40:26 2006 (11718) SHUNTING: 1150382425.6505611+4f10f0ef8067c96952336a07919d018adc6a9979 I think this is a very bad idea as it results in the list administrator complaining to me as site administrator about letters not being delivered instead of (for instance) the list members complaing to the list administrator about unreadable characters in the footer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1507248&group_…

1 0