Mailman 3 July 2006 - Mailman-coders

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

Aug. 19, 2022

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-1532081 ] with long lists, findmember option got forgotten
by SourceForge.net July 31, 2006

July 31, 2006

Patches item #1532081, was opened at 2006-08-01 01:04 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=1532081&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 Submitted By: RISKO Gergely (errge) Assigned to: Nobody/Anonymous (nobody) Summary: with long lists, findmember option got forgotten Initial Comment: After the admin do a filtering on members, the generated first letter based URLs don't inherit the filter regex. This patch fixes that bug. Reported in debian as #359721. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1532081&group_…

1 0

[ mailman-Feature Requests-403066 ] Auto Approval of subscriptions for certain domains
by SourceForge.net July 31, 2006

July 31, 2006

Feature Requests item #403066, was opened at 2001-01-01 09:27 Message generated for change (Comment added) made by jimpop You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=403066&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: Closed Resolution: Accepted Priority: 3 Submitted By: Mark Tearle (mtearle) Assigned to: Mark Sapiro (msapiro) Summary: Auto Approval of subscriptions for certain domains Initial Comment: A patch to enable automatic approval for certain domains, eg people in the example.com are automatically approved all others have to wait for the moderator ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2006-07-31 18:13 Message: Logged In: YES user_id=3142 New feature request for this patch, seeking feedback. Most of my lists automatically moderate new subscribers, in addition some require admin approval for subsciption, except for domains listed in subscribe_auto_approval. A nice addition to this patch would be to not moderate subscribers whose domains are listed in subscribe_auto_approval. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-03-25 22:21 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2006-03-12 22:12 Message: Logged In: YES user_id=3142 I've successfully applied this against a v2.1.8 system and it works well. Thanks!! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-11 13:36 Message: Logged In: YES user_id=1123998 The attached patch is against a 2.1.8a1 installed base (installed because it patches Defaults.py and not Defaults.py.in). It is a modification and extension of the original patch. It implements a new list attribute 'subscribe_auto_approval' which is a list of email addresses and regular expressions matching email addresses whose subscriptions are exempt from admin approval. It implements the original intent if one just uses regexps that match domains. This will go in Mailman 2.2, but it would be nice to get some feedback from people who are interested in this feature and are willing to try the patch. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-11 08:31 Message: Logged In: YES user_id=34209 Is this still necessary with Mailman 2.1, which has more 'automatic' options (as well as 'memberadaptors') ? In any case, the patch is likely heavily out of date by now, I'm moving this to Feature Requests for now. Feel free to respond if you (still) have a need. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=403066&group_i…

1 0

[ mailman-Bugs-1531675 ] ARCHIVE_TO_MBOX=1 broken
by SourceForge.net July 31, 2006

July 31, 2006

Bugs item #1531675, was opened at 2006-07-31 11:23 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=1531675&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: configuring/installing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ross Golder (rossigee) Assigned to: Nobody/Anonymous (nobody) Summary: ARCHIVE_TO_MBOX=1 broken Initial Comment: While looking into an archiving problem on mail.gnome.org, where we use our own external archiver (ARCHIVE_TO_MBOX was set to 1), Owen Taylor discovered the following bug causing it to ignore this setting: >From /usr/lib/mailman/Mailman/Defaults.py: # ARCHIVE_TO_MBOX #-1 - do not do any archiving # 0 - do not archive to mbox, use builtin mailman html archiving only # 1 - archive to mbox to use an external archiving mechanism only # 2 - archive to both mbox and builtin mailman html archiving - # use this to make both external archiving mechanism work and # mailman's builtin html archiving. the flat mail file can be # useful for searching, external archivers, etc. ARCHIVE_TO_MBOX = 2 Now, while that's not particularly clear, I can certainly see why one might assume that we wanted a setting, of '1', but if you look at the code we see: if mm_cfg.ARCHIVE_TO_MBOX in (1, 2): self.__archive_to_mbox(msg) if mm_cfg.ARCHIVE_TO_MBOX == 1: # Archive to mbox only. return txt = str(msg) # should we use the internal or external archiver? [...] So, ARCHIVE_TO_MBOX=1 skips both the internal *and* external archivers, and archives only to the MBOX files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1531675&group_…

1 0

[ mailman-Feature Requests-1530164 ] Accept senders from another list(s)
by SourceForge.net July 28, 2006

July 28, 2006

Feature Requests item #1530164, was opened at 2006-07-27 23:47 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1530164&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: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Williamson (kb5mu) Assigned to: Nobody/Anonymous (nobody) Summary: Accept senders from another list(s) Initial Comment: I'd like to specify that List A is to accept postings from List B and List C. Example: List A is an open discussion group, and List B is a senior manager's group. The managers might not subscribe to the discussion (for lack of time) but they need to be able to post announcements. Indirect reference to another list would be better than the existing facility to add individual addresses to the approved list. When a manager comes or goes or changes email address, his access to List A would automatically follow his status on List B, without administrator action. Indirect reference to another list is better than asking the managers to subscribe to List A but disable mail delivery, because they won't remember to update their List A subscriptions. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-07-28 08:22 Message: Logged In: YES user_id=1123998 See patch 1220144 at https://sourceforge.net/tracker/index.php?func=detail&aid=1220144&group_id=… I think this does what you want. It is a candidate for inclusion in Mailman 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1530164&group_…

1 0

[ mailman-Feature Requests-1530164 ] Accept senders from another list(s)
by SourceForge.net July 28, 2006

July 28, 2006

Feature Requests item #1530164, was opened at 2006-07-27 23:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1530164&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: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Williamson (kb5mu) Assigned to: Nobody/Anonymous (nobody) Summary: Accept senders from another list(s) Initial Comment: I'd like to specify that List A is to accept postings from List B and List C. Example: List A is an open discussion group, and List B is a senior manager's group. The managers might not subscribe to the discussion (for lack of time) but they need to be able to post announcements. Indirect reference to another list would be better than the existing facility to add individual addresses to the approved list. When a manager comes or goes or changes email address, his access to List A would automatically follow his status on List B, without administrator action. Indirect reference to another list is better than asking the managers to subscribe to List A but disable mail delivery, because they won't remember to update their List A subscriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1530164&group_…

1 0

[ mailman-Feature Requests-1527758 ] Send rejection text to moderated messages
by SourceForge.net July 24, 2006

July 24, 2006

Feature Requests item #1527758, was opened at 2006-07-24 09:25 Message generated for change (Comment added) made by derekrprice You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1527758&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: None Status: Open Resolution: None Priority: 5 Submitted By: Derek Robert Price (derekrprice) Assigned to: Nobody/Anonymous (nobody) Summary: Send rejection text to moderated messages Initial Comment: Per this report http://savannah.gnu.org/support/?func=detailitem&item_id=105465 , it would be nice if a default rejection text could be sent to moderated messages. For instance, most posters to CVS's commit email list are held for moderation, and I would like them to be sent the following notice when the moderator rejects their postings: This list is intended to receive automated commit messages from the CVS repository and is therefore otherwise read-only. Please send user discussion, including help requests, to info-cvs(a)gnu.org and development discussion, including bug reports and patch submissions, to bug-cvs(a)gnu.org. Unfortunately, there does not appear to be an easy way to do this via the list setup. I would be just as happy if the a default "held for moderation" message could be set. Both would be especially nice. ---------------------------------------------------------------------- >Comment By: Derek Robert Price (derekrprice) Date: 2006-07-24 09:32 Message: Logged In: YES user_id=793288 Incidentally, as noted by Sylvain Beucler in the linked savannah.gnu.org support incident, there is already a comment in Handlers/Moderate.py to the effect that the held for moderation message should be configurable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1527758&group_…

1 0

[ mailman-Feature Requests-1527758 ] Send rejection text to moderated messages
by SourceForge.net July 24, 2006

July 24, 2006

Feature Requests item #1527758, was opened at 2006-07-24 09:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1527758&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: None Status: Open Resolution: None Priority: 5 Submitted By: Derek Robert Price (derekrprice) Assigned to: Nobody/Anonymous (nobody) Summary: Send rejection text to moderated messages Initial Comment: Per this report http://savannah.gnu.org/support/?func=detailitem&item_id=105465 , it would be nice if a default rejection text could be sent to moderated messages. For instance, most posters to CVS's commit email list are held for moderation, and I would like them to be sent the following notice when the moderator rejects their postings: This list is intended to receive automated commit messages from the CVS repository and is therefore otherwise read-only. Please send user discussion, including help requests, to info-cvs(a)gnu.org and development discussion, including bug reports and patch submissions, to bug-cvs(a)gnu.org. Unfortunately, there does not appear to be an easy way to do this via the list setup. I would be just as happy if the a default "held for moderation" message could be set. Both would be especially nice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1527758&group_…

1 0

[ mailman-Patches-1527537 ] prevent and log subscription spamflood (2.1.8)
by SourceForge.net July 24, 2006

July 24, 2006

Patches item #1527537, was opened at 2006-07-24 11:06 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=1527537&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: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Paul Wise (pabs3) Assigned to: Nobody/Anonymous (nobody) Summary: prevent and log subscription spamflood (2.1.8) Initial Comment: The attached patch for mailman 2.1.8 causes mailman to ignore subscriptions that already exist in pending.pck and request.pck. This prevents people from mass-spamming either the list admin or random email addresses (depending on the configuration of the list). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1527537&group_…

1 0

[ mailman-Patches-1220144 ] allow specifying another list in accept_these_nonmembers
by SourceForge.net July 17, 2006

July 17, 2006

Patches item #1220144, was opened at 2005-06-13 23:29 Message generated for change (Comment added) made by msapiro 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 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: Mark Sapiro (msapiro) Date: 2006-07-17 16: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-17 18: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-Bugs-1469962 ] Attachments with ' just hang
by SourceForge.net July 17, 2006

July 17, 2006

Bugs item #1469962, was opened at 2006-04-13 10:36 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&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: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-07-16 20:28 Message: Logged In: YES user_id=1123998 The thing I missed in trying to duplicate is the fact that the exception is thrown in decode_rfc2231(). Thus, the problem only occurs with a RFC2231 encoded header, i.e., one with a long filename split into pieces as filename*0="first part of name containing ' character" filename*1="second part of name - etc." The underlying problem is in the Python email library in email/Utils.py. See http://mail.python.org/pipermail/email-sig/2006-July/000293.html for a more complete description and a potential fix. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-14 10:39 Message: Logged In: YES user_id=1123998 I am unable to duplicate this error with various versions of Python's email library. I am using an attachment with the header Content-Disposition: attachment; filename="cal'dar.doc" If the one that fails in your case is different from this in any significant way, please post it. ---------------------------------------------------------------------- Comment By: cpkevin (xprt5) Date: 2006-04-14 06:07 Message: Logged In: YES user_id=1501592 Here is the latest traceback Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack Apr 11 23:04:22 2006 (60899) Traceback (most recent call last): File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 92, in process send_digests(mlist, mboxfp) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 133, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 315, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Scrubber.py", line 299, in process url = save_attachment(mlist, part, dir) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Scrubber.py", line 411, in save_attachment filename = Utils.oneline(msg.get_filename(''), lcset) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 724, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 607, in get_param for k, v in self._get_params_preserve(failobj, header): File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 554, in _get_params_preserve params = Utils.decode_params(params) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Utils.py", line 337, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Utils.py", line 284, in decode_rfc2231 charset, language, s = parts ValueError: need more than 2 values to unpack Apr 11 23:04:22 2006 (60899) SHUNTING: 1144789462.1552839+7ff91a627d48daa19efc8509d86eb3ec869fc909 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 20:34 Message: Logged In: YES user_id=1123998 I'm not sure if this is a 2.1.6 bug or a cPanel bug, but it seems to be fine in 2.1.7 since I have now received copies of this bug report, its two updates, the 149967 report and its update (a total of 5 messages) from the mailman-coders(a)python.org Mailman 2.1.7 list, and they all have subject [ mailman-Bugs-1469962 ] Attachments with ' just hang (or the same with 1469967). I.e., the same messages you receive directly from sourceforge.net are also posted to mailman-coders(a)python.org. In any case, if you want to post the full traceback from the error, either here or directly to me, I will try to determine the problem and suggest a fix for 2.1.6. ---------------------------------------------------------------------- Comment By: cpkevin (xprt5) Date: 2006-04-13 19:22 Message: Logged In: YES user_id=1501592 Mailman version is 2.1.6 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 18:36 Message: Logged In: YES user_id=1123998 What Mailman/Python version is this? Also see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_…

1 0

[ mailman-Patches-1520343 ] FIX: Inputs are imcompletely escaped & saved (2.1 & 2.2)
by SourceForge.net July 11, 2006

July 11, 2006

Patches item #1520343, was opened at 2006-07-11 13:34 Message generated for change (Settings changed) made by ikedasoji You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&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: Open Resolution: None Priority: 7 Submitted By: ikedasoji (ikedasoji) >Assigned to: Tokio Kikuchi (tkikuchi) >Summary: FIX: Inputs are imcompletely escaped & saved (2.1 & 2.2) Initial Comment: Inputs on admin pages are imcompletely escaped, then the escaped values are saved (excpet 'info' property). This expedient solution have caused following problems: o Input including `"' breaks HTML formatting. o `<' is not allowed in admin/user option value (it is replaced with '<' in many contexts). o 'info' in admin page might break HTML formatting with some sort of tags (e.g. '</textarea>'). This patch solve these problems. Always unescaped value is saved (except '<script>' in 'info') and escaped only when it is displayed as HTML. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&group_…

1 0

[ mailman-Patches-1520343 ] Inputs are imcompletely escaped & saved (2.1 & 2.2)
by SourceForge.net July 11, 2006

July 11, 2006

Patches item #1520343, was opened at 2006-07-11 13:34 Message generated for change (Settings changed) made by ikedasoji You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&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: Open Resolution: None >Priority: 7 Submitted By: ikedasoji (ikedasoji) Assigned to: Nobody/Anonymous (nobody) Summary: Inputs are imcompletely escaped & saved (2.1 & 2.2) Initial Comment: Inputs on admin pages are imcompletely escaped, then the escaped values are saved (excpet 'info' property). This expedient solution have caused following problems: o Input including `"' breaks HTML formatting. o `<' is not allowed in admin/user option value (it is replaced with '<' in many contexts). o 'info' in admin page might break HTML formatting with some sort of tags (e.g. '</textarea>'). This patch solve these problems. Always unescaped value is saved (except '<script>' in 'info') and escaped only when it is displayed as HTML. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&group_…

1 0

[ mailman-Patches-1520343 ] Inputs are imcompletely escaped & saved (2.1 & 2.2)
by SourceForge.net July 11, 2006

July 11, 2006

Patches item #1520343, was opened at 2006-07-11 13:34 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=1520343&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: Open Resolution: None Priority: 5 Submitted By: ikedasoji (ikedasoji) Assigned to: Nobody/Anonymous (nobody) Summary: Inputs are imcompletely escaped & saved (2.1 & 2.2) Initial Comment: Inputs on admin pages are imcompletely escaped, then the escaped values are saved (excpet 'info' property). This expedient solution have caused following problems: o Input including `"' breaks HTML formatting. o `<' is not allowed in admin/user option value (it is replaced with '<' in many contexts). o 'info' in admin page might break HTML formatting with some sort of tags (e.g. '</textarea>'). This patch solve these problems. Always unescaped value is saved (except '<script>' in 'info') and escaped only when it is displayed as HTML. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1520343&group_…

1 0

[ mailman-Bugs-1519881 ] lost messages risk with contrib/mm-handler
by SourceForge.net July 10, 2006

July 10, 2006

Bugs item #1519881, was opened at 2006-07-10 10:53 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=1519881&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: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: lost messages risk with contrib/mm-handler Initial Comment: As far as I am aware, this bug is present in all versions of the contributed sendmail mailer contrib/mm-handler The Perl code in subversion /trunk/mailman/contrib/mm-handler contains the following fragment: $wrapper = new FileHandle "|$MMWRAPPER $cmd $list"; if (!defined($wrapper)) { ## Defer? print STDERR "$0: cannot exec ", "\"$MMWRAPPER $cmd $list\": deferring\n"; exit (-1); } # Don't need these without the "n" flag on the mailer def.... #$date = &mboxdate(time); #$wrapper->print ("From $sender $date\n"); # ...because we use these instead. $from_ = <STDIN>; $wrapper->print ($from_); $wrapper->print ("X-Mailman-Handler: $VERSION\n"); while (<STDIN>) { $wrapper->print ($_); } close($wrapper); This is the code that actually hands off the message from sendmail to the mailman wrapper. I note that it still has the problem which the original author, David Champion <dgc(a)uchicago.edu>, was made aware some years ago. The Perl code fails to check the value returned by the close($wrapper). As the FileHandle being closed is a pipe, the close operation returns the status value returned by the Mailman wrapper at the far end of the pipe. This value should be checked. Not checking this status value means that if the mailman wrapper fails to successfully enqueue the message for any reason this is not detected by the sendmail mailer. Meanwhile, the mailer blithely tells sendmail that the message was successfully delivered. The likely consequence is that the message will be silently lost. Adding a test after: close($wrapper); such as: close($wrapper); die "Mailman delivery wrapper failed" if $?; nods in the direction of correcting the problem. I leave aside suggestions that more appropriate, mail related, return code values might sensibly be used by this sendmail mailer, amongst other things. btw: this risk is not theoretical. Some years ago it caused the only loss of messages by our Mailman system that we have experienced. We initially fixed, then replaced with a python implementation and finally ceased all use of this type of sendmail mailer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1519881&group_…

1 0

[ mailman-Feature Requests-1469343 ] Per-user Reply-To mungling for sent mails
by SourceForge.net July 10, 2006

July 10, 2006

Feature Requests item #1469343, was opened at 2006-04-12 15:16 Message generated for change (Comment added) made by cras You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&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: None Status: Open Resolution: None Priority: 5 Submitted By: Timo Sirainen (cras) Assigned to: Nobody/Anonymous (nobody) Summary: Per-user Reply-To mungling for sent mails Initial Comment: This feature request isn't the same as the existing ones about per-user reply-to mungling (eg. 788314). I like the ability for users to be able to select if they want to get both private and list replies (highly useful in big traffic lists) or only list replies (if you're going to read all the mails in the list anyway). Now this is already possible assuming that everyone hits Reply-to-all, which I think is what most people do. However for those who want only the list replies, they need to set "Reply-To: list" header for their own mails. This is impossible or difficult to configure to be automatic in most email clients. So, a user-specific option to specify if the Reply-To header should be added to mails the user himself sends would be nice. ---------------------------------------------------------------------- >Comment By: Timo Sirainen (cras) Date: 2006-07-10 01:11 Message: Logged In: YES user_id=11334 Yes, "Avoid duplicate copies" could do the same, except I find that whole feature a really bad idea to use. I guess it works by Mailman not sending the message to the user if he's already in To/Cc headers? If this is done then those messages won't have the List-ID header and filtering must be done in less reliable ways. Also it could lose the mail completely if the direct reply wasn't received (eg. more strict SMTP server checks or even intentionally faked), making you the only one in the list not seeing the mail. And sure, sender's MUA could in theory also add the header, except there are only a couple MUAs which allow doing it automatically. I probably wouldn't have bothered with the patch for this if Evolution had allowed me to do it. :) ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-07-10 00:27 Message: Logged In: YES user_id=1123998 Apparently, as you say, this is not the same as RFEs 788314 and 828564. Those ask that a member be able to specify whether or not to receive posts from the list with a Reply-To: the list added. This RFE (and the associated patch 1515716) asks that a posting member be able to instruct the list to put a Reply-To: the list in her posts delivered to the list members. I really don't see the need for this. If a member selects the "Avoid duplicate copies", he will only receive one copy of a "reply all" whether or not he is explicitly addressed in the reply. Further, the poster can simply add a Reply-To: the list to her post if desired (and if her MUA allows this conveniently). Finally, the appropriate reply address is dynamic. For some posts one may want replies to the list and for others one may want replies off list, and it is as much the choice of the responder as the original poster which is appropriate in any particular case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&group_…

1 0

[ mailman-Patches-1515716 ] Per-user selectable Reply-to header
by SourceForge.net July 10, 2006

July 10, 2006

Patches item #1515716, was opened at 2006-07-01 19:29 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1515716&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: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Timo Sirainen (cras) Assigned to: Nobody/Anonymous (nobody) Summary: Per-user selectable Reply-to header Initial Comment: Feature request 1469343 explains this. Having the field remembered in listinfo page causes most of the changes and I think it's missing some backwards compatibility checks for the pending requests in database. I'd be happy to have it just in the options page too. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-07-09 17:28 Message: Logged In: YES user_id=1123998 See my comment to RFE 1469343 - https://sourceforge.net/tracker/index.php?func=detail&aid=1469343&group_id=… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1515716&group_…

1 0

[ mailman-Feature Requests-1469343 ] Per-user Reply-To mungling for sent mails
by SourceForge.net July 10, 2006

July 10, 2006

Feature Requests item #1469343, was opened at 2006-04-12 08:16 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&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: None Status: Open Resolution: None Priority: 5 Submitted By: Timo Sirainen (cras) Assigned to: Nobody/Anonymous (nobody) Summary: Per-user Reply-To mungling for sent mails Initial Comment: This feature request isn't the same as the existing ones about per-user reply-to mungling (eg. 788314). I like the ability for users to be able to select if they want to get both private and list replies (highly useful in big traffic lists) or only list replies (if you're going to read all the mails in the list anyway). Now this is already possible assuming that everyone hits Reply-to-all, which I think is what most people do. However for those who want only the list replies, they need to set "Reply-To: list" header for their own mails. This is impossible or difficult to configure to be automatic in most email clients. So, a user-specific option to specify if the Reply-To header should be added to mails the user himself sends would be nice. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-07-09 17:27 Message: Logged In: YES user_id=1123998 Apparently, as you say, this is not the same as RFEs 788314 and 828564. Those ask that a member be able to specify whether or not to receive posts from the list with a Reply-To: the list added. This RFE (and the associated patch 1515716) asks that a posting member be able to instruct the list to put a Reply-To: the list in her posts delivered to the list members. I really don't see the need for this. If a member selects the "Avoid duplicate copies", he will only receive one copy of a "reply all" whether or not he is explicitly addressed in the reply. Further, the poster can simply add a Reply-To: the list to her post if desired (and if her MUA allows this conveniently). Finally, the appropriate reply address is dynamic. For some posts one may want replies to the list and for others one may want replies off list, and it is as much the choice of the responder as the original poster which is appropriate in any particular case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&group_…

1 0

[ mailman-Bugs-1518281 ] Bad Content-Disposition breaks senddigest
by SourceForge.net July 8, 2006

July 8, 2006

Bugs item #1518281, was opened at 2006-07-06 10:27 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&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: Philip Crotwell (crotwell) Assigned to: Nobody/Anonymous (nobody) Summary: Bad Content-Disposition breaks senddigest Initial Comment: We are using the default mailman on mac osx server 10.3 which is mailman 2.1.2, so this may be old. But just in case, we got an email with attachement that caused mailman to croak in senddigest. Here is the output of running it by hand. I added 2 prints to see what the offending filename variable had in it. The Content-Disposition headers are below. Note that the two parts of the filename have been joined, but because of the bizarre endquoting in filename*0, there is an embedded \n\t. We fixed this locally by editing the mbox to change the offending filename to be shorter and not split into two parts, but it might be nice if mailman would check for illegal characters embedded in filenames? In addition to senddigest croaking, all emails after this bad one were not added to the archive. Luckily we had made a copy of digest.mbox before running senddigest manually and were able to manually add the lost emails to the archive mbox. roo:/usr/share/mailman root# python -S cron/senddigests -l chair-archive (None, None, 'Outside Professional Activities GS Policy_4-22-03 rev\n\t5-16-05.doc') (None, None, 'Outside Professional Activities GS Policy_4-22-03 rev\n\t5-16-05.doc') Traceback (most recent call last): File "cron/senddigests", line 94, in ? main() File "cron/senddigests", line 86, in main mlist.send_digest_now() File "/usr/share/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 130, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 303, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/share/mailman/Mailman/Handlers/Scrubber.py", line 257, in process url = save_attachment(mlist, part, dir) File "/usr/share/mailman/Mailman/Handlers/Scrubber.py", line 348, in save_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/share/mailman/pythonlib/email/Message.py", line 709, in get_filename return unicode(newvalue[2], newvalue[0]) TypeError: unicode() argument 2 must be string, not None --Apple-Mail-5-348793981 Content-Transfer-Encoding: base64 Content-Type: application/msword; x-unix-mode=0666; name="Outside Professional Activities GS Policy_4-22-03 rev 5-16-05.doc" Content-Disposition: attachment; filename*0="Outside Professional Activities GS Policy_4-22-03 rev 5-16-05.do"; filename*1=c ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-07-07 18:07 Message: Logged In: YES user_id=1123998 >We fixed this locally by editing the mbox to change the >offending filename to be shorter and not split into two >parts, but it might be nice if mailman would check for >illegal characters embedded in filenames? I'm not sure if it is clear from my first comment, but the cause of this exception (bug) was the RFC2231 splitting, not the '\n\t' from header folding. Also, in later Mailman versions, Scrubber is much more robust against bad characters/encodings in filenames. >In addition to senddigest croaking, all emails after >this bad one were not added to the archive. Luckily we >had made a copy of digest.mbox before running >senddigest manually and were able to manually add the >lost emails to the archive mbox. I suspect these messages were shunted and could have been reprocessed to the archive by bin/unshunt. At this point, since the messages are in the archive, you should check to see if they are still in qfiles/shunt/ and if so, delete them from there so the don't get inadvertently unshunted in the future. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-07-07 17:50 Message: Logged In: YES user_id=1123998 There are a couple of different issues here. The '\n\t' in the filename come about because the header is folded in the middle of the quoted value of the filename*0 parameter. The filename*0 and filename*1 parameters split the filename per RFC2231, the very purpose of which is to allow breaking of long parameter values into smaller pieces so that header folding/unfolding can be accomplished at syntactic breaks - e.g. at the semicolons. In this case, either the generating MUA (Apple Mail) folded the header in the middle of the filename*0 value or it made the value so long that a subsequent MTA folded it. Thus, with respect to the '\n\t' in the middle of the name, it results from a non-compliant message. The immediate cause of the exception in your case was fixed in the email library shipped with Mailman 2.1.3. The fix replaces return unicode(newvalue[2], newvalue[0]) with return unicode(newvalue[2], newvalue[0] or 'us-ascii') and makes a similar change in a few other places. The patch for this change is attached here. There is also a bug in the (in your case) /usr/share/mailman/pythonlib/email/Utils.py module. See the post at http://mail.python.org/pipermail/email-sig/2006-July/000293.html for more on this and a possible patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&group_…

1 0

[ mailman-Bugs-1518281 ] Bad Content-Disposition breaks senddigest
by SourceForge.net July 8, 2006

July 8, 2006

Bugs item #1518281, was opened at 2006-07-06 10:27 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&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: Philip Crotwell (crotwell) Assigned to: Nobody/Anonymous (nobody) Summary: Bad Content-Disposition breaks senddigest Initial Comment: We are using the default mailman on mac osx server 10.3 which is mailman 2.1.2, so this may be old. But just in case, we got an email with attachement that caused mailman to croak in senddigest. Here is the output of running it by hand. I added 2 prints to see what the offending filename variable had in it. The Content-Disposition headers are below. Note that the two parts of the filename have been joined, but because of the bizarre endquoting in filename*0, there is an embedded \n\t. We fixed this locally by editing the mbox to change the offending filename to be shorter and not split into two parts, but it might be nice if mailman would check for illegal characters embedded in filenames? In addition to senddigest croaking, all emails after this bad one were not added to the archive. Luckily we had made a copy of digest.mbox before running senddigest manually and were able to manually add the lost emails to the archive mbox. roo:/usr/share/mailman root# python -S cron/senddigests -l chair-archive (None, None, 'Outside Professional Activities GS Policy_4-22-03 rev\n\t5-16-05.doc') (None, None, 'Outside Professional Activities GS Policy_4-22-03 rev\n\t5-16-05.doc') Traceback (most recent call last): File "cron/senddigests", line 94, in ? main() File "cron/senddigests", line 86, in main mlist.send_digest_now() File "/usr/share/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 130, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 303, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/share/mailman/Mailman/Handlers/Scrubber.py", line 257, in process url = save_attachment(mlist, part, dir) File "/usr/share/mailman/Mailman/Handlers/Scrubber.py", line 348, in save_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/share/mailman/pythonlib/email/Message.py", line 709, in get_filename return unicode(newvalue[2], newvalue[0]) TypeError: unicode() argument 2 must be string, not None --Apple-Mail-5-348793981 Content-Transfer-Encoding: base64 Content-Type: application/msword; x-unix-mode=0666; name="Outside Professional Activities GS Policy_4-22-03 rev 5-16-05.doc" Content-Disposition: attachment; filename*0="Outside Professional Activities GS Policy_4-22-03 rev 5-16-05.do"; filename*1=c ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-07-07 17:50 Message: Logged In: YES user_id=1123998 There are a couple of different issues here. The '\n\t' in the filename come about because the header is folded in the middle of the quoted value of the filename*0 parameter. The filename*0 and filename*1 parameters split the filename per RFC2231, the very purpose of which is to allow breaking of long parameter values into smaller pieces so that header folding/unfolding can be accomplished at syntactic breaks - e.g. at the semicolons. In this case, either the generating MUA (Apple Mail) folded the header in the middle of the filename*0 value or it made the value so long that a subsequent MTA folded it. Thus, with respect to the '\n\t' in the middle of the name, it results from a non-compliant message. The immediate cause of the exception in your case was fixed in the email library shipped with Mailman 2.1.3. The fix replaces return unicode(newvalue[2], newvalue[0]) with return unicode(newvalue[2], newvalue[0] or 'us-ascii') and makes a similar change in a few other places. The patch for this change is attached here. There is also a bug in the (in your case) /usr/share/mailman/pythonlib/email/Utils.py module. See the post at http://mail.python.org/pipermail/email-sig/2006-July/000293.html for more on this and a possible patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&group_…

1 0

[ mailman-Bugs-1230865 ] spam filters get removed when changing other privacy pages
by SourceForge.net July 7, 2006

July 7, 2006

Bugs item #1230865, was opened at 2005-07-01 03:51 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1230865&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: security/privacy Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Alex (ams001) Assigned to: Nobody/Anonymous (nobody) Summary: spam filters get removed when changing other privacy pages Initial Comment: Originally reported in 1020013 http://sourceforge.net/tracker/?group_id=103&atid=100103&func=detail&aid=10… This problem still very annoyingly ocurrs in the 2.1.6 release which appears not to include the patch submitted. I have updated the patch against 2.1.6 and included it below. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-07-06 18:13 Message: Logged In: YES user_id=1123998 The bug reported in the 2005-07-08 comment was fixed in 2.1.7 as well as in the trunk (2.2.0a0). The bug described in report 1020013 was fixed in 2.1.6b5. The patch attached to this report for 2.1.6 is redundant and only adds a second test if subcat == 'spam': in the _handleForm() method definition when the test has already been applied before calling _handleForm(). Apparently, the submitter confused the original bug which had been fixed differently but equivalently to the patch with the different bug reported in the 2005-07-08 comment. If you have evidence that any bug with these symptoms is still in 2.1.7 or 2.1.8, please submit a new report with supporting information as to how to reproduce it. ---------------------------------------------------------------------- Comment By: Mantas K (mantas) Date: 2006-07-06 12:49 Message: Logged In: YES user_id=439618 According to bugreporter (and my personal experience with mailman) spam filters still gets removed when changing other privacy pages in mailman 2.1.x :( I think this bug should be reopened and closed only when it will be really fixed in stable release of mailman. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-09-20 21:30 Message: Logged In: YES user_id=67709 Fixed in CVS. (2.2.0a0) ---------------------------------------------------------------------- Comment By: Alex (ams001) Date: 2005-07-08 10:29 Message: Logged In: YES user_id=1156173 Unfortunately this patch does not fix all occurances of the problem. I can reliably "lose" all spam filters entered by going directly to the spam filter section after logging out. To reproduce: 1. Login as list admin 2. Goto Privacy / Spam filters and create a spam filter 3. Logout 4. Modify logout URL from .../<listname>/logout to .../<listname>/privacy/spam 5. Enter password and observe absense of Spam filter. The worrying thing is that it appears to be the login through the privacy/spam script that kills the spam filter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1230865&group_…

1 0

[ mailman-Bugs-1230865 ] spam filters get removed when changing other privacy pages
by SourceForge.net July 6, 2006

July 6, 2006

Bugs item #1230865, was opened at 2005-07-01 13:51 Message generated for change (Comment added) made by mantas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1230865&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: security/privacy Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Alex (ams001) Assigned to: Nobody/Anonymous (nobody) Summary: spam filters get removed when changing other privacy pages Initial Comment: Originally reported in 1020013 http://sourceforge.net/tracker/?group_id=103&atid=100103&func=detail&aid=10… This problem still very annoyingly ocurrs in the 2.1.6 release which appears not to include the patch submitted. I have updated the patch against 2.1.6 and included it below. ---------------------------------------------------------------------- Comment By: Mantas K (mantas) Date: 2006-07-06 22:49 Message: Logged In: YES user_id=439618 According to bugreporter (and my personal experience with mailman) spam filters still gets removed when changing other privacy pages in mailman 2.1.x :( I think this bug should be reopened and closed only when it will be really fixed in stable release of mailman. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-09-21 07:30 Message: Logged In: YES user_id=67709 Fixed in CVS. (2.2.0a0) ---------------------------------------------------------------------- Comment By: Alex (ams001) Date: 2005-07-08 20:29 Message: Logged In: YES user_id=1156173 Unfortunately this patch does not fix all occurances of the problem. I can reliably "lose" all spam filters entered by going directly to the spam filter section after logging out. To reproduce: 1. Login as list admin 2. Goto Privacy / Spam filters and create a spam filter 3. Logout 4. Modify logout URL from .../<listname>/logout to .../<listname>/privacy/spam 5. Enter password and observe absense of Spam filter. The worrying thing is that it appears to be the login through the privacy/spam script that kills the spam filter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1230865&group_…

1 0

[ mailman-Bugs-1518281 ] Bad Content-Disposition breaks senddigest
by SourceForge.net July 6, 2006

July 6, 2006

Bugs item #1518281, was opened at 2006-07-06 13:27 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=1518281&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: Philip Crotwell (crotwell) Assigned to: Nobody/Anonymous (nobody) Summary: Bad Content-Disposition breaks senddigest Initial Comment: We are using the default mailman on mac osx server 10.3 which is mailman 2.1.2, so this may be old. But just in case, we got an email with attachement that caused mailman to croak in senddigest. Here is the output of running it by hand. I added 2 prints to see what the offending filename variable had in it. The Content-Disposition headers are below. Note that the two parts of the filename have been joined, but because of the bizarre endquoting in filename*0, there is an embedded \n\t. We fixed this locally by editing the mbox to change the offending filename to be shorter and not split into two parts, but it might be nice if mailman would check for illegal characters embedded in filenames? In addition to senddigest croaking, all emails after this bad one were not added to the archive. Luckily we had made a copy of digest.mbox before running senddigest manually and were able to manually add the lost emails to the archive mbox. roo:/usr/share/mailman root# python -S cron/senddigests -l chair-archive (None, None, 'Outside Professional Activities GS Policy_4-22-03 rev\n\t5-16-05.doc') (None, None, 'Outside Professional Activities GS Policy_4-22-03 rev\n\t5-16-05.doc') Traceback (most recent call last): File "cron/senddigests", line 94, in ? main() File "cron/senddigests", line 86, in main mlist.send_digest_now() File "/usr/share/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 130, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 303, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/share/mailman/Mailman/Handlers/Scrubber.py", line 257, in process url = save_attachment(mlist, part, dir) File "/usr/share/mailman/Mailman/Handlers/Scrubber.py", line 348, in save_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/share/mailman/pythonlib/email/Message.py", line 709, in get_filename return unicode(newvalue[2], newvalue[0]) TypeError: unicode() argument 2 must be string, not None --Apple-Mail-5-348793981 Content-Transfer-Encoding: base64 Content-Type: application/msword; x-unix-mode=0666; name="Outside Professional Activities GS Policy_4-22-03 rev 5-16-05.doc" Content-Disposition: attachment; filename*0="Outside Professional Activities GS Policy_4-22-03 rev 5-16-05.do"; filename*1=c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1518281&group_…

1 0

[ mailman-Patches-1516454 ] Host based langage selection
by SourceForge.net July 3, 2006

July 3, 2006

Patches item #1516454, was opened at 2006-07-03 19:01 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=1516454&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: configure/install Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Toots (metamorph68) Assigned to: Nobody/Anonymous (nobody) Summary: Host based langage selection Initial Comment: Hi! I forward a patch that I found in debian's BTS, and applyed sucessfully here. The aim is to have welcome and admin langague settings per virtual host. Modifications seems really straight forward: I hope we will se something like this applied to main source code! Thanks for the good good work guys! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351431 s patch lets you have a different DEFAULT_SERVER_NAME for defined virtual hosts. Useful because initial pages always refers to site DEFAULT_SERVER_NAME, even if lists are in an other language. A patch that adds a configuration variable to support this is included. The patch is made with dpatch. This is an usage example: # Required when setting any of its arguments. add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) add_virtualhost('it.gnu.org', 'it.gnu.org') #------------------------------------------------------------- # The default language for this server. DEFAULT_SERVER_LANGUAGE = 'es' VIRTUAL_HOSTS_LANGUAGE['it.gnu.org']='it' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1516454&group_…

1 0

[ mailman-Patches-1515716 ] Per-user selectable Reply-to header
by SourceForge.net July 2, 2006

July 2, 2006

Patches item #1515716, was opened at 2006-07-02 02:29 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=1515716&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: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Timo Sirainen (cras) Assigned to: Nobody/Anonymous (nobody) Summary: Per-user selectable Reply-to header Initial Comment: Feature request 1469343 explains this. Having the field remembered in listinfo page causes most of the changes and I think it's missing some backwards compatibility checks for the pending requests in database. I'd be happy to have it just in the options page too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1515716&group_…

1 0