Mailman 3 August 2006 - Mailman-coders

[ mailman-Bugs-1537308 ] Error in 'de' translation: "Membership exposure"
by SourceForge.net 09 Aug '06

09 Aug '06

Bugs item #1537308, was opened at 2006-08-09 07:15 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1537308&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: Closed Resolution: None Priority: 5 Submitted By: Thijs Kinkhorst (kink) Assigned to: Nobody/Anonymous (nobody) Summary: Error in 'de' translation: "Membership exposure" Initial Comment: Hello, In Debian we got the following bug report: > In German "Membership exposure" becomes "Mitgliedschaft > abgelaufen" which means "Membership expired". It was suggested to me that "Mitglieder anzeigen" would be the right translation. Thanks, Thijs Kinkhorst ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-09 08:53 Message: Logged In: YES user_id=12800 Please contact the German translation team: http://wiki.list.org/display/DEV/Languages ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1537308&group_…

1 0

[ mailman-Bugs-1537312 ] Typo in comment
by SourceForge.net 09 Aug '06

09 Aug '06

Bugs item #1537312, was opened at 2006-08-09 13:18 Message generated for change (Settings changed) made by kink You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1537312&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: 1 Submitted By: Thijs Kinkhorst (kink) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in comment Initial Comment: Hello, A Debian user found it necessary to report a typo in a comment :) Well, better forward it to you guys then... here it is: > Tiny typo: > > /usr/lib/mailman/Mailman/Utils.py > > def ValidateEmail(s): > """Verify that the an email address isn't grossly evil.""" > ^^^^^^ Thanks, Thijs Kinkhorst ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1537312&group_…

1 0

[ mailman-Bugs-1537312 ] Typo in comment
by SourceForge.net 09 Aug '06

09 Aug '06

Bugs item #1537312, was opened at 2006-08-09 13:18 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=1537312&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: Thijs Kinkhorst (kink) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in comment Initial Comment: Hello, A Debian user found it necessary to report a typo in a comment :) Well, better forward it to you guys then... here it is: > Tiny typo: > > /usr/lib/mailman/Mailman/Utils.py > > def ValidateEmail(s): > """Verify that the an email address isn't grossly evil.""" > ^^^^^^ Thanks, Thijs Kinkhorst ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1537312&group_…

1 0

[ mailman-Bugs-1537308 ] Error in 'de' translation: "Membership exposure"
by SourceForge.net 09 Aug '06

09 Aug '06

Bugs item #1537308, was opened at 2006-08-09 13:15 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=1537308&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: Thijs Kinkhorst (kink) Assigned to: Nobody/Anonymous (nobody) Summary: Error in 'de' translation: "Membership exposure" Initial Comment: Hello, In Debian we got the following bug report: > In German "Membership exposure" becomes "Mitgliedschaft > abgelaufen" which means "Membership expired". It was suggested to me that "Mitglieder anzeigen" would be the right translation. Thanks, Thijs Kinkhorst ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1537308&group_…

1 0

[ mailman-Bugs-1536532 ] digest mails: RFC2046 non-compliance
by SourceForge.net 09 Aug '06

09 Aug '06

Bugs item #1536532, was opened at 2006-08-08 11:40 Message generated for change (Settings changed) made by colinleroy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1536532&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: None Priority: 5 Submitted By: Colin Leroy (colinleroy) Assigned to: Nobody/Anonymous (nobody) Summary: digest mails: RFC2046 non-compliance Initial Comment: Hi, Mailman 2.1.6 does not respect RFC2046 when sending out digests: the end boundary of the last inner digested mail is not separated from the separator boundary between the multipart/digest main part and footer part, as described on http://www.thewildbeast.co.uk/sylpheed-claws/bugzilla/show_bug.cgi?id=998 See the attachments (broken email, hand-fixed email and diff between the two). The relevant part of RFC2046 is: RFC 2046 - page 19: NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary. ---------------------------------------------------------------------- >Comment By: Colin Leroy (colinleroy) Date: 2006-08-09 08:34 Message: Logged In: YES user_id=460566 Sorry. After more reading of the RFC, I found out that I was wrong and this double-separator isn't needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1536532&group_…

1 0

[ mailman-Bugs-1536532 ] digest mails: RFC2046 non-compliance
by SourceForge.net 08 Aug '06

08 Aug '06

Bugs item #1536532, was opened at 2006-08-08 11:40 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=1536532&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: Colin Leroy (colinleroy) Assigned to: Nobody/Anonymous (nobody) Summary: digest mails: RFC2046 non-compliance Initial Comment: Hi, Mailman 2.1.6 does not respect RFC2046 when sending out digests: the end boundary of the last inner digested mail is not separated from the separator boundary between the multipart/digest main part and footer part, as described on http://www.thewildbeast.co.uk/sylpheed-claws/bugzilla/show_bug.cgi?id=998 See the attachments (broken email, hand-fixed email and diff between the two). The relevant part of RFC2046 is: RFC 2046 - page 19: NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1536532&group_…

1 0

[ mailman-Feature Requests-1533331 ] support moving lists to another mailman instance
by SourceForge.net 07 Aug '06

07 Aug '06

Feature Requests item #1533331, was opened at 2006-08-02 13:27 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&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: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: support moving lists to another mailman instance Initial Comment: I'm having to move a project off a hosting site that uses Mailman, and have discovered to my shock that there is no easy way to capture a snapshot of the list state and re-instantiate it on another Mailman instance. While this remains the case, Mailman is a prison for my data. The only way I could get even the subscriber list was by tedious screen-scraping of the membership management CGI, made more tedious because the interface only wants to show me the subscriber list in small chunks. Breaking up the list archives by month is all very well but I want to be able to get all of the traffic -- and I want to be able to upload it into another Mailman instance. I gave up on metadata such as hide and digest bits entirely; there's no equivalent of mass subscribe that would let me set those, I'd have to patch them in by hand per each subscriber address in the new list instance. The *correct* design would be to allow me to download one file that's an XML document containing subscriber list, metadata such as digest and hide bits, and the traffic. That blob should be uploadable to another Mailman instance in a way that simply re-instantiates the list. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-06 20:02 Message: Logged In: YES user_id=12800 Here's the procedure for moving a list with shell access: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.004.htp As for security, should the XML output include user passwords? If you're exporting via the web, probably not. If you're exporting via the shell, probably so. Also, not every installation will want to allow list owners to move their lists (e.g. python.org probably wouldn't). If I had to guess I'd say that if list owners can delete their lists, they can probably move them. See what I mean about there being issues? It's a good idea though so I've added it as a possible item for MM2.2: http://wiki.list.org/x/IQ It probably needs more discussion on mailman-developers though. ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-08-02 13:58 Message: Logged In: YES user_id=3060 First, that "if you have shell access" is a big if. I do not in fact have shell access to the list server, and it's a bad thing if the Mailman design assumes I do. Second, AFAIK the "easy" procedure is not documented. Third, I don't see any (additional) security implications. All the pieces of state are already available through the administration interface, they're just a royal pain in the ass to extract by hand. Finally, you should support moveable list snapshots because it gives Mailman users the guarantee that they can have *all* their data back in a transparent form whenever they need it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-02 13:39 Message: Logged In: YES user_id=12800 FWIW, It's very easy to move a list if you have shell access to the server Mailman is running on. There are many security implications to allowing access to all that data via the web. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&group_…

1 0

[ mailman-Feature Requests-1533331 ] support moving lists to another mailman instance
by SourceForge.net 02 Aug '06

02 Aug '06

Feature Requests item #1533331, was opened at 2006-08-02 17:27 Message generated for change (Comment added) made by esr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&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: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: support moving lists to another mailman instance Initial Comment: I'm having to move a project off a hosting site that uses Mailman, and have discovered to my shock that there is no easy way to capture a snapshot of the list state and re-instantiate it on another Mailman instance. While this remains the case, Mailman is a prison for my data. The only way I could get even the subscriber list was by tedious screen-scraping of the membership management CGI, made more tedious because the interface only wants to show me the subscriber list in small chunks. Breaking up the list archives by month is all very well but I want to be able to get all of the traffic -- and I want to be able to upload it into another Mailman instance. I gave up on metadata such as hide and digest bits entirely; there's no equivalent of mass subscribe that would let me set those, I'd have to patch them in by hand per each subscriber address in the new list instance. The *correct* design would be to allow me to download one file that's an XML document containing subscriber list, metadata such as digest and hide bits, and the traffic. That blob should be uploadable to another Mailman instance in a way that simply re-instantiates the list. ---------------------------------------------------------------------- >Comment By: Eric S. Raymond (esr) Date: 2006-08-02 17:58 Message: Logged In: YES user_id=3060 First, that "if you have shell access" is a big if. I do not in fact have shell access to the list server, and it's a bad thing if the Mailman design assumes I do. Second, AFAIK the "easy" procedure is not documented. Third, I don't see any (additional) security implications. All the pieces of state are already available through the administration interface, they're just a royal pain in the ass to extract by hand. Finally, you should support moveable list snapshots because it gives Mailman users the guarantee that they can have *all* their data back in a transparent form whenever they need it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-02 17:39 Message: Logged In: YES user_id=12800 FWIW, It's very easy to move a list if you have shell access to the server Mailman is running on. There are many security implications to allowing access to all that data via the web. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&group_…

1 0

[ mailman-Feature Requests-1533331 ] support moving lists to another mailman instance
by SourceForge.net 02 Aug '06

02 Aug '06

Feature Requests item #1533331, was opened at 2006-08-02 13:27 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&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: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: support moving lists to another mailman instance Initial Comment: I'm having to move a project off a hosting site that uses Mailman, and have discovered to my shock that there is no easy way to capture a snapshot of the list state and re-instantiate it on another Mailman instance. While this remains the case, Mailman is a prison for my data. The only way I could get even the subscriber list was by tedious screen-scraping of the membership management CGI, made more tedious because the interface only wants to show me the subscriber list in small chunks. Breaking up the list archives by month is all very well but I want to be able to get all of the traffic -- and I want to be able to upload it into another Mailman instance. I gave up on metadata such as hide and digest bits entirely; there's no equivalent of mass subscribe that would let me set those, I'd have to patch them in by hand per each subscriber address in the new list instance. The *correct* design would be to allow me to download one file that's an XML document containing subscriber list, metadata such as digest and hide bits, and the traffic. That blob should be uploadable to another Mailman instance in a way that simply re-instantiates the list. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-02 13:39 Message: Logged In: YES user_id=12800 FWIW, It's very easy to move a list if you have shell access to the server Mailman is running on. There are many security implications to allowing access to all that data via the web. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&group_…

1 0

[ mailman-Feature Requests-1533331 ] support moving lists to another mailman instance
by SourceForge.net 02 Aug '06

02 Aug '06

Feature Requests item #1533331, was opened at 2006-08-02 17:27 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=1533331&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: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: support moving lists to another mailman instance Initial Comment: I'm having to move a project off a hosting site that uses Mailman, and have discovered to my shock that there is no easy way to capture a snapshot of the list state and re-instantiate it on another Mailman instance. While this remains the case, Mailman is a prison for my data. The only way I could get even the subscriber list was by tedious screen-scraping of the membership management CGI, made more tedious because the interface only wants to show me the subscriber list in small chunks. Breaking up the list archives by month is all very well but I want to be able to get all of the traffic -- and I want to be able to upload it into another Mailman instance. I gave up on metadata such as hide and digest bits entirely; there's no equivalent of mass subscribe that would let me set those, I'd have to patch them in by hand per each subscriber address in the new list instance. The *correct* design would be to allow me to download one file that's an XML document containing subscriber list, metadata such as digest and hide bits, and the traffic. That blob should be uploadable to another Mailman instance in a way that simply re-instantiates the list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1533331&group_…

1 0