Mailman 3 May 2007 - Mailman-coders

[ mailman-Bugs-1712034 ] Pipermail uses MIME CTEs in HTTP
by SourceForge.net 04 May '07

04 May '07

Bugs item #1712034, was opened at 2007-05-03 07:39 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1712034&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: Pipermail Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: Pipermail uses MIME CTEs in HTTP Initial Comment: CTE = Content-Transfer-Encoding = BASE64 or QP John Papapanos writes: > Here is a URL where I created a list for testing > mailman. > > https://mail.bioacademy.gr/pipermail/testlist2/2007-May/thread.html Wow! That's amazingly broken. What's I'm pretty sure is happening is that the archive contains raw message content in a MIME QP or transfer-encoding, which cannot be decoded because the Content-Transfer-Encoding header has been stripped (AFAIK it's actually prohibited in HTTP, cf RFC 2616 section 19.5). (I'm not 100% sure because I don't have access to the physical archive, only via https.) The reason that the Greek text-only comes out OK is that your browser (John and I are both using Firefox) interprets the { notation in the message body as SGML entities, which are Unicode. Presumably the reason that such content is in there in the first place is that either pipermail doesn't parse the mail (unlikely) or it reencodes use flatten or something like that. I'll look more carefully at the code later, maybe provide a patch, but don't bet on it. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-05-04 13:36 Message: Logged In: YES user_id=1123998 Originator: NO It turns out that John was using Mailman 2.1.5. When he upgraded to 2.1.9, these problems disappeared. See <http://mail.python.org/pipermail/mailman-users/2007-May/056942.html> I'm not certain, but I think this issue was fixed by changes in SVN rev. 7660 of Scrubber.py (Mailman 2.1.7). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1712034&group_…

1 0

[ mailman-Patches-1220144 ] allow specifying another list in accept_these_nonmembers
by SourceForge.net 04 May '07

04 May '07

Patches item #1220144, was opened at 2005-06-14 06:29 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1220144&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: list administration Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 6 Private: No Submitted By: Jim Tittsler (jtittsler) Assigned to: Tokio Kikuchi (tkikuchi) Summary: allow specifying another list in accept_these_nonmembers Initial Comment: Add the capability to logically include the addresses all of the members of another list in the same Mailman installation to accept_these_nonmembers. '@listname' checks the poster's address against the membership of listname. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2007-05-04 07:33 Message: Logged In: YES user_id=67709 Originator: NO Because '@' is mandatory in mailman 2.2 listname, I think that '`listname@domain`' is more preferable. Use of '`' is meaning 'evaluate this list member'. I also think we can merge this patch (along with the sibling list patch #1347962) in the next mailman 2.1.10 because release of 2.2 is delayed considerably. Thoughts ? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-12-01 20:30 Message: Logged In: YES user_id=1123998 Originator: NO The patch also applies without change to Mailman 2.1.9. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-07-17 23:09 Message: Logged In: YES user_id=1123998 The 2.1.6 patch also applies without change to Mailman 2.1.7 and 2.1.8. Even though there are minor changes in the patched modules, the patched line numbers and the patch data are unchanged. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-11-18 02:37 Message: Logged In: YES user_id=67709 Marking as an Mailman 2.2 new feature candidate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1220144&group_…

1 0

[ mailman-Patches-1415956 ] Sitewide headers/footers & XHTML Compliant Web UI
by SourceForge.net 04 May '07

04 May '07

Patches item #1415956, was opened at 2006-01-26 22:23 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1415956&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 UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bryan Carbonnell (carbonnb) Assigned to: Nobody/Anonymous (nobody) Summary: Sitewide headers/footers & XHTML Compliant Web UI Initial Comment: This patch was borne out of a request I received to make the Mailman UI fit the look of the web site. This patch allows you to set a site wide header and footer. This allows you to pretty much make the MM UI look like any other site. While I was at it I also made the web UI XHTML compliant. Once you patch your source and install it, all you need to do is edit the html files in the templates/en directory. Most of the pages will get the header and footers from the site-header.html and site-footer.html files, but some of the HTML files already contain theor own header/footer so you will need ot edit some of these files as well. Since this also adds XHTML compliance, this superceeds patch #116035 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-05-03 20:52 Message: Logged In: YES user_id=11375 Originator: NO The patch looks pretty good, though I'll suggest some refinements and some decisions need to be made. Net effects of the patch: Adds XHTML compliance. Adds site-header.html/site-footer.html to the templates/en directory and usage of CSS instead of <font> tags. Still uses tables for page layout. Adds CSS_FILE to mm_cfg.py. Requires addition of a /css/ directory to the web tree. Possible issues: Many I18N strings change, but only by folding HTML markup to lowercase. A bunch of search-and-replacing should be able to update all the language-specific templates. Need to decide upon class naming scheme; the scheme used isn't consistent (mm_web_adminitem_color in one case, mmErrorBackground in another). Could retarget it to use the <div id="mailman"> suggestion and '#mailman error' selectors. Possible bug: AddSpanStyle, AddDivStyle: won't generate <div>,<span> if no 'css_class' is provided. Presumably all current callers get this right; should the class work properly if there's an error, though? Compatibility issues: The patch removes the colour settings (WEB_HEADER_COLOR, WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) -- how to handle backward compatibility? That would require substituting into the .css file, or adding a 'style' attribute. WEB_HEADER_COLOR -- mmHeader WEB_ERROR_COLOR -- replaced by mmErrorBackground CSS class WEB_ADMINITEM_COLOR -- replaced by mmRight/mmLeft/mm_web_adminitem_color/ mmAdminItem Features not present that I thought of: * allow adding an embedded stylesheet * allow adding JavaScript links or text to the <head> * adding an onLoad to the body (perhaps not necessary -- can it be done in a <script> tag using DOM Events?) ---------------------------------------------------------------------- Comment By: Bryan Carbonnell (carbonnb) Date: 2006-01-28 23:07 Message: Logged In: YES user_id=449953 Updated both patches to remove some of my site specific HTML coding. ---------------------------------------------------------------------- Comment By: Bryan Carbonnell (carbonnb) Date: 2006-01-26 22:31 Message: Logged In: YES user_id=449953 I am also uploading a second version of this patch. This second version will add the sitewide headers/footer to source that has been patched with the ht://dig integration patches. At the time I posted this, the official ht://dig integration patches were not released, but the MM2.1.6 patches appear to work with MM 2.1.7, so they are what were used. to apply this patch use this command from your mailman source directory: patch -p1 <full/path/to/headfoot-htdig-2.1.7-0.1.patch ---------------------------------------------------------------------- Comment By: Bryan Carbonnell (carbonnb) Date: 2006-01-26 22:27 Message: Logged In: YES user_id=449953 I have only tested this with the english pages. I'm not sure how to deal with i18n yet, but I'm reading and I will update this patch as soon as I figure out how to deal with it. To apply this patch for MM2.1.7, you will need to apply patch #1405790 (Mailman 2.1.7 multiple patch) first. to apply this patch use this command from your mailman source directory: patch -p1 <full/path/to/headfoot-2.1.7-0.1.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1415956&group_…

1 0

[ mailman-Patches-1688957 ] fix concurrency problem in 2.2
by SourceForge.net 04 May '07

04 May '07

Patches item #1688957, was opened at 2007-03-27 08:15 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1688957&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 UI Group: Mailman 2.2 / 3.0 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: fix concurrency problem in 2.2 Initial Comment: The problem is described in a mailman-dev post. http://www.mail-archive.com/mailman-developers@python.org/msg10203.html Fix this by introducing reload mechanism in the interface to SQLAlchemy. I use session.refresh() to do this but because this function looks like to break locks, attempt is made to save the lock status and lock again after refresh. I'm not sure this is the right way to fix the problem but it is working (for now). ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2007-05-04 00:44 Message: Logged In: YES user_id=67709 Originator: YES Fix in a different way by Barry, thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1688957&group_…

1 0

[ mailman-Bugs-1712034 ] Pipermail uses MIME CTEs in HTTP
by SourceForge.net 03 May '07

03 May '07

Bugs item #1712034, was opened at 2007-05-03 23:39 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=1712034&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: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: Pipermail uses MIME CTEs in HTTP Initial Comment: CTE = Content-Transfer-Encoding = BASE64 or QP John Papapanos writes: > Here is a URL where I created a list for testing > mailman. > > https://mail.bioacademy.gr/pipermail/testlist2/2007-May/thread.html Wow! That's amazingly broken. What's I'm pretty sure is happening is that the archive contains raw message content in a MIME QP or transfer-encoding, which cannot be decoded because the Content-Transfer-Encoding header has been stripped (AFAIK it's actually prohibited in HTTP, cf RFC 2616 section 19.5). (I'm not 100% sure because I don't have access to the physical archive, only via https.) The reason that the Greek text-only comes out OK is that your browser (John and I are both using Firefox) interprets the { notation in the message body as SGML entities, which are Unicode. Presumably the reason that such content is in there in the first place is that either pipermail doesn't parse the mail (unlikely) or it reencodes use flatten or something like that. I'll look more carefully at the code later, maybe provide a patch, but don't bet on it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1712034&group_…

1 0

[ mailman-Bugs-1711470 ] Problem with accept_these_nonmembers
by SourceForge.net 02 May '07

02 May '07

Bugs item #1711470, was opened at 2007-05-02 14:54 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=1711470&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 Private: No Submitted By: Barry S. Finkel (barry_s_finkel) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with accept_these_nonmembers Initial Comment: I posted this to mailman-users May 01, 2007, and Mark Sapiro replied with a detailed diagnosis. I create new Mailman (2.1.9) lists via copying template files. One of my template files has: accept_these_nonmembers = ['user1(a)example.com', 'user2(a)example.com', 'user3(a)example.com (Joe Bleaux)', 'user4(a)example.com'] (I have split the line for easier readibility.) When I create a new list via /usr/sbin/newlist $listname config_list -i $1.config $listname I get no complaints, and the administrator web interface shows the four addresses with the parenthesized name after the third address. I have not tested whether any of these addresses can post to the new list. But when I want to add another address to the list (or remove an address) via the admin web interface, I get an error messsage about an incorrect address. When I remove the parenthesized name, the error message is not produced. If the parenthesized name is not valid, I would expect an error message during the config_list command execution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1711470&group_…

1 0

Mailman-coders May 2007