Mailman 3 June 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-871062 ] A MemberAdaptor for LDAP-based membership
by SourceForge.net June 30, 2006

June 30, 2006

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 June 23, 2006

June 23, 2006

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 June 23, 2006

June 23, 2006

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 June 22, 2006

June 22, 2006

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 June 19, 2006

June 19, 2006

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 June 17, 2006

June 17, 2006

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 June 16, 2006

June 16, 2006

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 June 16, 2006

June 16, 2006

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 June 16, 2006

June 16, 2006

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

[ mailman-Bugs-1506338 ] cannot post to list
by SourceForge.net June 14, 2006

June 14, 2006

Bugs item #1506338, was opened at 2006-06-14 14:07 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1506338&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: Closed >Resolution: Invalid Priority: 5 Submitted By: mdbiker (mdbiker) Assigned to: Nobody/Anonymous (nobody) Summary: cannot post to list Initial Comment: i am an administrator (but i didn't install it nor do i have access to the server) of an announcement only mailing list. despite having 3 addresses listed as administrator and moderator, we have only been able to use one address to post. that was ok till last week when we were subject to a spoofing attack appearing to come from that address. i removed that address, having forgotten about the problem in posting from the others. now i cannot post tothe list at all even though i returned the removed address. for each i get back a "this is an announcement list - send your email to xxxx for posting and now even xxxx cannot post. so the bug is that even though listed as admin/mod i cannot post. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-14 17:25 Message: Logged In: YES user_id=1123998 First, I see you've already posted this to mailman-users(a)python.org which is probably a more appropriate place to go first. Second, this is not a bug. The addresses in the 'owner' and 'moderator' attributes are ONLY addresses to which owner and moderator notices are mailed, and in the case of owner, listed in the 'run by' footer at the bottom of web pages. These addresses have no other function. If they are not also members, they will not receive list posts. If posting is restricted to members or unmoderated members, they will not be allowed to post unless they are (unmoderated) members or listed in accept_these_nonmembers. It seems from your description that the default for your list is that new members are moderated and moderated members can't post. You deleted the one unmoderated member so no one could post and when you added xxxx back, xxxx was moderated by default. You could turn off moderation for those members you want to post, but a more 'spoof proof' method is use of an Approved: header as discussed in FAQs http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.011.htp and http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.034.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1506338&group_…

1 0

[ mailman-Bugs-1506338 ] cannot post to list
by SourceForge.net June 14, 2006

June 14, 2006

Bugs item #1506338, was opened at 2006-06-14 17:07 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=1506338&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: mdbiker (mdbiker) Assigned to: Nobody/Anonymous (nobody) Summary: cannot post to list Initial Comment: i am an administrator (but i didn't install it nor do i have access to the server) of an announcement only mailing list. despite having 3 addresses listed as administrator and moderator, we have only been able to use one address to post. that was ok till last week when we were subject to a spoofing attack appearing to come from that address. i removed that address, having forgotten about the problem in posting from the others. now i cannot post tothe list at all even though i returned the removed address. for each i get back a "this is an announcement list - send your email to xxxx for posting and now even xxxx cannot post. so the bug is that even though listed as admin/mod i cannot post. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1506338&group_…

1 0

[ mailman-Bugs-1495122 ] Mailman strips format=flowed from Content-Type header
by SourceForge.net June 13, 2006

June 13, 2006

Bugs item #1495122, was opened at 2006-05-25 12:24 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&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: Bart Jacobs (radiantskies) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman strips format=flowed from Content-Type header Initial Comment: It seems that Mailman strips the format=flowed argument from the Content-Type: text/plain header when delivering incoming e-mails to subscribers. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-13 09:34 Message: Logged In: YES user_id=1123998 I think you have found the cause. Scrubber also does the same thing when flattening the message, but now we have a difficult decision. If we want to 'fix' Decorate, we now are faced with a situation where we may be adding a 'format=fixed' header and/or footer to a 'format=flowed' message body. This potential incompatability may require us to 'wrap' the message and add the header/footer as separate parts in this case. This will undoubtedly raise additional complaints. In the case of Scrubber, this may lead us to scrub the actual message body part - not a good thing. I may be over-reacting here. It may turn out that it is OK to render the header/footer/scrubber messages as 'format=flowed'. Although I can contrive a footer for example (by putting trailing spaces on intermediate lines) that will be munged by rendering as 'format=flowed', this may not be a problem in practice, and Decorate could always be made to strip the spaces. There are also potentially issues with stripping of leading spaces because of the assumption that they are 'stuffed'. I don't know how big an issue this is in practice. Note, if we do preserve 'format=' we also need to preserve 'delsp='. ---------------------------------------------------------------------- Comment By: Bart Jacobs (radiantskies) Date: 2006-06-12 23:54 Message: Logged In: YES user_id=924185 I've browsed the mailman source code a bit and I found some suspicious code in /trunk/mailman/Mailman/Handlers/Decorate.py. If the list admin specifies a header or footer to be added to outgoing messages, then the content-type header is zapped and then regenerated from just the charset info, i.e. the format=flowed parameter is lost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&group_…

1 0

[ mailman-Bugs-1495122 ] Mailman strips format=flowed from Content-Type header
by SourceForge.net June 13, 2006

June 13, 2006

Bugs item #1495122, was opened at 2006-05-25 21:24 Message generated for change (Comment added) made by radiantskies You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&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: Bart Jacobs (radiantskies) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman strips format=flowed from Content-Type header Initial Comment: It seems that Mailman strips the format=flowed argument from the Content-Type: text/plain header when delivering incoming e-mails to subscribers. ---------------------------------------------------------------------- >Comment By: Bart Jacobs (radiantskies) Date: 2006-06-13 08:54 Message: Logged In: YES user_id=924185 I've browsed the mailman source code a bit and I found some suspicious code in /trunk/mailman/Mailman/Handlers/Decorate.py. If the list admin specifies a header or footer to be added to outgoing messages, then the content-type header is zapped and then regenerated from just the charset info, i.e. the format=flowed parameter is lost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1495122&group_…

1 0

[ mailman-Bugs-1504546 ] Subscription log mixes up names and email addresses
by SourceForge.net June 11, 2006

June 11, 2006

Bugs item #1504546, was opened at 2006-06-12 04:19 Message generated for change (Settings changed) made by mnaumann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&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: (un)subscribing Group: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Moritz Naumann (mnaumann) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription log mixes up names and email addresses Initial Comment: On /var/log/mailman/subscribe successful subscriptions are logged like this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "henry23(a)hotmail.com" <Henry>, via web confirmation The intended way to log them is probably rather this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "Henry" <henry23(a)hotmail.com>, via web confirmation Thanks! ---------------------------------------------------------------------- >Comment By: Moritz Naumann (mnaumann) Date: 2006-06-12 04:42 Message: Logged In: YES user_id=407680 This indeed refers to 2.1.7. And the patch you refer to should fix this. Thanks for the quick reply. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-12 04:35 Message: Logged In: YES user_id=1123998 What Mailman version is this? This error was fixed in 2.1.8 unless there is some other way it can occur. See http://svn.sourceforge.net/viewcvs.cgi/mailman/tags/Release_2_1_8/mailman/M… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_…

1 0

[ mailman-Bugs-1504546 ] Subscription log mixes up names and email addresses
by SourceForge.net June 11, 2006

June 11, 2006

Bugs item #1504546, was opened at 2006-06-11 19:19 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&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: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Moritz Naumann (mnaumann) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription log mixes up names and email addresses Initial Comment: On /var/log/mailman/subscribe successful subscriptions are logged like this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "henry23(a)hotmail.com" <Henry>, via web confirmation The intended way to log them is probably rather this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "Henry" <henry23(a)hotmail.com>, via web confirmation Thanks! ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-11 19:35 Message: Logged In: YES user_id=1123998 What Mailman version is this? This error was fixed in 2.1.8 unless there is some other way it can occur. See http://svn.sourceforge.net/viewcvs.cgi/mailman/tags/Release_2_1_8/mailman/M… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_…

1 0

[ mailman-Bugs-1504546 ] Subscription log mixes up names and email addresses
by SourceForge.net June 11, 2006

June 11, 2006

Bugs item #1504546, was opened at 2006-06-12 04:19 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=1504546&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: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Moritz Naumann (mnaumann) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription log mixes up names and email addresses Initial Comment: On /var/log/mailman/subscribe successful subscriptions are logged like this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "henry23(a)hotmail.com" <Henry>, via web confirmation The intended way to log them is probably rather this: Jun 11 18:40:58 2006 (30403) mylistname: new (digest) "Henry" <henry23(a)hotmail.com>, via web confirmation Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504546&group_…

1 0

[ mailman-Feature Requests-782436 ] members per page on admin page
by SourceForge.net June 11, 2006

June 11, 2006

Feature Requests item #782436, was opened at 2003-08-03 12:32 Message generated for change (Comment added) made by jwbaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=782436&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: JC Dill (jcdill) Assigned to: Nobody/Anonymous (nobody) Summary: members per page on admin page Initial Comment: Put a radio button option on the membership page to allow list owners to change the number of members returned on each page. I suggest that the options include: 25 per page 50 per page 100 per page 200 per page 500 per page all subscribers on one page (use with caution if you have a big list!) ---------------------------------------------------------------------- Comment By: John W. Baxter (jwbaxter) Date: 2006-06-11 10:55 Message: Logged In: YES user_id=664644 This seems like a quite reasonable proposal. Is the intent to return to the old method, where the pages (except last) were all full and there was on each page an index of links giving the first (first and last) address on each other page? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=782436&group_i…

1 0

[ mailman-Bugs-1504204 ] re-confirm memberships
by SourceForge.net June 10, 2006

June 10, 2006

Bugs item #1504204, was opened at 2006-06-10 19:32 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504204&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: bounce detection Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Daevid Vincent (daevid) Assigned to: Nobody/Anonymous (nobody) Summary: re-confirm memberships Initial Comment: I have a suspicion that some of my lists' mails are not getting to their destinations. This could be that some people used their job email and no longer work there, could be that they are on AOL or hotmail (which seem to just silently discard), or could be just people that joined up and now 'junk mail or filter' the list because they're either to stupid or lazy to properly unsubscribe. Bottom line is that I'm paying per emails sent (via my quota on DynDNS) and I want to unsubscribe these dead members. It would be great if I could push a button in the web GUI (or run some command on the CLI) and mailman would reset every members status to 'unconfirmed' (or whatever it is), mail them a link to click (with some crazy code in it like when you join a list), and then mark the responders as 'confirmed'. Then after some period of time, say a week or so, I could then go into the GUI, click some link and see a list of all 'unconfirmed' people with the option to unsubscribe them all (without sending an email obviously, since the address is bogus). Extra points if I can schedule this task to occur every month, every six months, once a year, etc... (probably some 'day' interval would be sufficient here). ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-10 20:45 Message: Logged In: YES user_id=1123998 This is really an RFE, not a bug and it duplicates RFE 1495305. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504204&group_…

1 0

[ mailman-Bugs-1504204 ] re-confirm memberships
by SourceForge.net June 10, 2006

June 10, 2006

Bugs item #1504204, was opened at 2006-06-10 19:32 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=1504204&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: bounce detection Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daevid Vincent (daevid) Assigned to: Nobody/Anonymous (nobody) Summary: re-confirm memberships Initial Comment: I have a suspicion that some of my lists' mails are not getting to their destinations. This could be that some people used their job email and no longer work there, could be that they are on AOL or hotmail (which seem to just silently discard), or could be just people that joined up and now 'junk mail or filter' the list because they're either to stupid or lazy to properly unsubscribe. Bottom line is that I'm paying per emails sent (via my quota on DynDNS) and I want to unsubscribe these dead members. It would be great if I could push a button in the web GUI (or run some command on the CLI) and mailman would reset every members status to 'unconfirmed' (or whatever it is), mail them a link to click (with some crazy code in it like when you join a list), and then mark the responders as 'confirmed'. Then after some period of time, say a week or so, I could then go into the GUI, click some link and see a list of all 'unconfirmed' people with the option to unsubscribe them all (without sending an email obviously, since the address is bogus). Extra points if I can schedule this task to occur every month, every six months, once a year, etc... (probably some 'day' interval would be sufficient here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1504204&group_…

1 0

[ mailman-Feature Requests-567096 ] list_members script export Name+Address
by SourceForge.net June 10, 2006

June 10, 2006

Feature Requests item #567096, was opened at 2002-06-10 15:13 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=567096&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: 5 Submitted By: Rodolfo Pilas (alkalino) Assigned to: Nobody/Anonymous (nobody) Summary: list_members script export Name+Address Initial Comment: I uses MM 2.1b2+ (from CVS this month -June 2002) The mass subscription (web) option enables me to put one user address form each line with this format: Name Surname <name(a)address.com> and works ok. However the $PREFIX/bin/list_members script do not export with this format, it list name(a)address.com only. Please, add to list_members a complete user data exportation. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-10 12:47 Message: Logged In: YES user_id=1123998 Actually implemented in 2.1b4 (Oct 2002) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=567096&group_i…

1 0

[ mailman-Patches-1502441 ] newlist mail without prompt
by SourceForge.net June 8, 2006

June 8, 2006

Patches item #1502441, was opened at 2006-06-07 12:06 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1502441&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: command line scripts Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Patrick Bogen (pdbogen) >Assigned to: Mark Sapiro (msapiro) Summary: newlist mail without prompt Initial Comment: bin/newlist should have an option to send a mail to the administrator without requiring the user to ansewr a prompt. The attached patch adds a '-a/--automate' option to accomplish this. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-06-08 08:34 Message: Logged In: YES user_id=1123998 Applied (somewhat differently because of new framework for bin/ and cron/ commands) to Subversion trunk for 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1502441&group_…

1 0

[ mailman-Patches-762130 ] web interface for editing archives
by SourceForge.net June 7, 2006

June 7, 2006

Patches item #762130, was opened at 2003-06-27 18:05 Message generated for change (Comment added) made by aaboyd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&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: Adriane Boyd (aaboyd) Assigned to: Nobody/Anonymous (nobody) Summary: web interface for editing archives Initial Comment: This patch makes it possible for list administrators to edit their list archives through a web interface linked into the admin interface. A new cgi script called editarch allows administrators to browse by month and delete messages from the archives. The messages are immediately deleted from the mbox file, but because of the overhead in reprocessing archives, the archives aren't redone on-the-fly. Instead, a file is kept with a running list of recently edited archives and a nightly cron job does the reprocessing. The file location is configurable in mm_cfg. (Note: since it has to read through the mbox file message by message, pages will load slowly for lists with large archives.) In the mailman 2.1.2 source directory: patch -p1 < editarch-2.1.2-0.1.patch ---------------------------------------------------------------------- >Comment By: Adriane Boyd (aaboyd) Date: 2006-06-07 23:45 Message: Logged In: YES user_id=696276 The nightly cron script just runs "bin/arch --wipe" for any list with edited archives, so the pipermail URLs for particular messages in a list archive may change. Because of the way pipermail works, there's no easy solution that keeps the URLs the same and removes messages from mailman's mbox archives. (There might be a solution that keeps URLs the same if unwanted messages were replaced with empty placeholder messages instead, but I'm not sure you'd want empty messages cluttering up your archives, either.) Even if you haven't edited the mbox file, badly formed date stamps will also cause your pipermail URLs to change if you ever run "bin/arch --wipe" because messages with bad dates get thrown into the current month. ---------------------------------------------------------------------- Comment By: Paul Wise (pabs3) Date: 2006-06-06 23:22 Message: Logged In: YES user_id=35028 How does this handle the changing of pipermail URLs when you delete messages? ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2006-06-02 19:57 Message: Logged In: YES user_id=696276 Updated patch to work with 2.1.8: fixed problems with mailbox.py and updated to patch cleanly against 2.1.8. ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2003-08-11 17:25 Message: Logged In: YES user_id=696276 Updated so that the permissions on the mbox file are set properly after editing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&group_i…

1 0

[ mailman-Patches-1502441 ] newlist mail without prompt
by SourceForge.net June 7, 2006

June 7, 2006

Patches item #1502441, was opened at 2006-06-07 14: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=1502441&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: command line scripts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick Bogen (pdbogen) Assigned to: Nobody/Anonymous (nobody) Summary: newlist mail without prompt Initial Comment: bin/newlist should have an option to send a mail to the administrator without requiring the user to ansewr a prompt. The attached patch adds a '-a/--automate' option to accomplish this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1502441&group_…

1 0

[ mailman-Patches-762130 ] web interface for editing archives
by SourceForge.net June 6, 2006

June 6, 2006

Patches item #762130, was opened at 2003-06-28 06:05 Message generated for change (Comment added) made by pabs3 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&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: Adriane Boyd (aaboyd) Assigned to: Nobody/Anonymous (nobody) Summary: web interface for editing archives Initial Comment: This patch makes it possible for list administrators to edit their list archives through a web interface linked into the admin interface. A new cgi script called editarch allows administrators to browse by month and delete messages from the archives. The messages are immediately deleted from the mbox file, but because of the overhead in reprocessing archives, the archives aren't redone on-the-fly. Instead, a file is kept with a running list of recently edited archives and a nightly cron job does the reprocessing. The file location is configurable in mm_cfg. (Note: since it has to read through the mbox file message by message, pages will load slowly for lists with large archives.) In the mailman 2.1.2 source directory: patch -p1 < editarch-2.1.2-0.1.patch ---------------------------------------------------------------------- Comment By: Paul Wise (pabs3) Date: 2006-06-07 11:22 Message: Logged In: YES user_id=35028 How does this handle the changing of pipermail URLs when you delete messages? ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2006-06-03 07:57 Message: Logged In: YES user_id=696276 Updated patch to work with 2.1.8: fixed problems with mailbox.py and updated to patch cleanly against 2.1.8. ---------------------------------------------------------------------- Comment By: Adriane Boyd (aaboyd) Date: 2003-08-12 05:25 Message: Logged In: YES user_id=696276 Updated so that the permissions on the mbox file are set properly after editing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=762130&group_i…

1 0