Mailman 3 October 2006 - Mailman-coders

[ mailman-Bugs-1495122 ] Mailman strips format=flowed from Content-Type header
by SourceForge.net 13 Oct '06

13 Oct '06

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-10-13 11:23 Message: Logged In: YES user_id=1123998 Regarding the previous comment. I don't disagee with you, and my 2006-06-13 comment wasn't meant to imply that I wasn't interested in fixing this, just that there might be more to it than is apparent at first glance. I do have it on my 'to do' list. ---------------------------------------------------------------------- Comment By: P T Withington (ptwithy) Date: 2006-10-13 10:05 Message: Logged In: YES user_id=615189 Man this bug drives me NUTS! Surely it is more important to maintain the content of the message that to quibble about the format on header/footer. Any halfway intelligent mail client will wrap long URLs, expecting them to be reflowed by the recipient, but since mailman strips out the format and delsp from the Content-type, the recipient is left in the lurch and sees the URL as multiple lines. In format-flowed, only lines that end in <space><linefeed> are re-flowed. If the header/footer lines end in <linefeed> they will not be reflowed, so I don't see the need to have a different format for them? What am I missing? ---------------------------------------------------------------------- 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 13 Oct '06

13 Oct '06

Bugs item #1495122, was opened at 2006-05-25 15:24 Message generated for change (Comment added) made by ptwithy 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: P T Withington (ptwithy) Date: 2006-10-13 13:05 Message: Logged In: YES user_id=615189 Man this bug drives me NUTS! Surely it is more important to maintain the content of the message that to quibble about the format on header/footer. Any halfway intelligent mail client will wrap long URLs, expecting them to be reflowed by the recipient, but since mailman strips out the format and delsp from the Content-type, the recipient is left in the lurch and sees the URL as multiple lines. In format-flowed, only lines that end in <space><linefeed> are re-flowed. If the header/footer lines end in <linefeed> they will not be reflowed, so I don't see the need to have a different format for them? What am I missing? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-06-13 12: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-13 02: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-Patches-1167696 ] add support for PGP and S/MIME encryption and signing
by SourceForge.net 13 Oct '06

13 Oct '06

Patches item #1167696, was opened at 2005-03-21 16:28 Message generated for change (Comment added) made by vanbaal You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1167696&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: Joost van Baal (vanbaal) Assigned to: Nobody/Anonymous (nobody) Summary: add support for PGP and S/MIME encryption and signing Initial Comment: This patch is based upon a patch by Stefan Schlott ( http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.html ) It extends Mailman to: - A post will be distributed only if the PGP signature on the post is from one of the list members. - For sending encrypted email, a list member encrypts to the public key of the list. The post will be decrypted and re-encrypted to the public keys of all list members. (Later, the patch will handle RFC 2633 (S/MIME) messages too, next to RFC 2440 (OpenPGP)). In order to achieve this, each list has a public and private key, as well as a key passphrase. Furthermore, new list settings are defined: gpg_postings_allowed: Is it allowed to send to this list postings which are encrypted with the GPG list key? gpg_msg_distribution: Are subscribers allowed (or even forced) to upload their GPG public key in order to receive all messages encrypted? gpg_post_sign: Should posts be GPG signed with an acknowledged subscriber key before being distributed? gpg_msg_sign: Should the server sign encrypted messages? Finally, each subscriber can upload her PGP public key using the webinterface. Latest version of the patch is available from http://www.non-gnu.uvt.nl/pub/mailman/ . ---------------------------------------------------------------------- >Comment By: Joost van Baal (vanbaal) Date: 2006-10-13 05:40 Message: Logged In: YES user_id=28781 The patch fully supports S/MIME too. Between 2006-01 and 2006-10, no work has been done on this patch. It applies to Mailman 2.1.7 only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1167696&group_…

1 0

[ mailman-Patches-1167696 ] add support for PGP and S/MIME encryption and signing
by SourceForge.net 13 Oct '06

13 Oct '06

Patches item #1167696, was opened at 2005-03-21 16:28 Message generated for change (Settings changed) made by vanbaal You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1167696&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: Joost van Baal (vanbaal) Assigned to: Nobody/Anonymous (nobody) >Summary: add support for PGP and S/MIME encryption and signing Initial Comment: This patch is based upon a patch by Stefan Schlott ( http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.html ) It extends Mailman to: - A post will be distributed only if the PGP signature on the post is from one of the list members. - For sending encrypted email, a list member encrypts to the public key of the list. The post will be decrypted and re-encrypted to the public keys of all list members. (Later, the patch will handle RFC 2633 (S/MIME) messages too, next to RFC 2440 (OpenPGP)). In order to achieve this, each list has a public and private key, as well as a key passphrase. Furthermore, new list settings are defined: gpg_postings_allowed: Is it allowed to send to this list postings which are encrypted with the GPG list key? gpg_msg_distribution: Are subscribers allowed (or even forced) to upload their GPG public key in order to receive all messages encrypted? gpg_post_sign: Should posts be GPG signed with an acknowledged subscriber key before being distributed? gpg_msg_sign: Should the server sign encrypted messages? Finally, each subscriber can upload her PGP public key using the webinterface. Latest version of the patch is available from http://www.non-gnu.uvt.nl/pub/mailman/ . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1167696&group_…

1 0

[ mailman-Patches-646989 ] NAH6 Secure List patch: GPG plugin
by SourceForge.net 13 Oct '06

13 Oct '06

Patches item #646989, was opened at 2002-12-02 16:07 Message generated for change (Comment added) made by s0undt3ch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=646989&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.2 / 3.0 Status: Open Resolution: None Priority: 6 Submitted By: Rop Gonggrijp (rop) Assigned to: Thomas Wouters (twouters) Summary: NAH6 Secure List patch: GPG plugin Initial Comment: "NAH6 Secure List" is a patch for Mailman 2.1b5 that adds GPG functionality. It is built around a key-scheme that allows an admin to create an encrypted list for which even the server operator doesn't have access to the messages. Only the public key for the list is given to the server, so it can perform 'emergency encryption' in case someone forgets, and all users get the public and private key for the list. We think we've done a decent job of describing the new functionality from server-operator, list-admin and list- member points of view. There's also a technical document for those familiar with the Mailman code. Please have a look at: http://www.nah6.com/products/secure-list/ and follow the links from there We feel more people need this, and we'd really like it to be part of the Mailman distribution at some point... Kind Regards, Rop Gonggrijp Joshua Eichen Please forgive mangling the Mailman logo on the site: if y'all don't like it or think it's over the top we'll use something else.... ---------------------------------------------------------------------- Comment By: Pedro Algarvio (s0undt3ch) Date: 2006-10-13 02:06 Message: Logged In: YES user_id=927681 +1 for this patch ---------------------------------------------------------------------- Comment By: Pat Carr (pcarr) Date: 2003-06-21 03:23 Message: Logged In: YES user_id=710070 The problem with the NAH approach is that every time a member leaves the list, the administrator needs to generate and distribute a new key, and every remaining member would have to remove the old list key and replace it with the new one. This could become a logistical nightmare, and makes it more difficult to sell this capability to a group that has people who are email savvy, but not necessarily pgp-savvy. I prefer the approach in patch #645297, recognizing that the task there is to maintain strict security of the server and the secret keys of the lists. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-10 16:16 Message: Logged In: YES user_id=34209 I'm looking at this patch, but I'm a bit confused. Which is the newer patch, v1.0 for Mailman 2.1 (uploaded last) or v1.1 for Mailman 2.1b5 (which is linked to from the NAH6 secure-list page.) Otherwise, the patch looks okay. There are some whitespace issues, and the PGP specific options aren't properly internationalized, but that can all be fixed. The patch edits Defaults.py, but it should be Defaults.py.in (if you want to apply to CVS before installation, anyway.) Oh, and a 'global' statement for DETAILS in the global namespace really isn't necessary... Do you need someone to come over and give a Python tutorial at NAH6 ? :-) Assigning to myself so I don't forget it; if someone else wants it, that's fine by me. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-12 04:01 Message: Logged In: YES user_id=12800 The logo's fine (plus the original is free software). I'm defering this until after MM2.1 because we're about ready for the first release candidate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=646989&group_i…

1 0

[ mailman-Patches-943827 ] true virtual hosting patch for 2.1
by SourceForge.net 13 Oct '06

13 Oct '06

Patches item #943827, was opened at 2004-04-28 17:57 Message generated for change (Comment added) made by s0undt3ch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=943827&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: The Anarcat (anarcat) Assigned to: Nobody/Anonymous (nobody) Summary: true virtual hosting patch for 2.1 Initial Comment: [copy of the mail sent to -developpers@] We developped a reliable solution for running lists with the same name on different domains on the same Mailman installation. I implemented that on top of the Mailman 2.1.1-5.1 Debian stable package. All that is needed is to patch 2 files (bin/newlist, Mailman/MailList.py) in the mailman install, and here is the patch: http://bugs.koumbit.net/file_download.php?file_id=3&type=bug There's only one caveat right now: Mailman/Cgi/create.py might need to get patched too, but I haven't got around looking at it yet, and it "just works", for now. I don't know what's the current status of virtual hosting support on Mailman, but this patch is a simple hack that should bring joy in the homes of all Mailman admins around the world. :) I got my inspiration and part of the code from: http://mithrandr.moria.org/blog/139.html All it does is to add the domain to the internal_name() of a list. The real_name is kept as is, and the getListAddress() does the Right Thing. This makes Mailman generate aliases like: list-example.com: "|/var/lib/mailman/mail/mailman post list-example.com" Care will have to be taken on the MTA side to map those list-example.com to list(a)example.com. We are using alternc.org to manage our server, so we are using LDAP, so everything went pretty smoothly. :) But I guess it will require some magic on the Postfix side or something... Cheers, A. PS: for those wanting to see more, you can come to our Wiki: http://koumbit.net/wiki/VirtualMailman You'll probably have a little trouble finding your way if you don't read french though. :) Babelfish might help, haven't tried. ---------------------------------------------------------------------- Comment By: Pedro Algarvio (s0undt3ch) Date: 2006-10-13 02:05 Message: Logged In: YES user_id=927681 +1 for this patch ---------------------------------------------------------------------- Comment By: Paul Hampson (tbble) Date: 2006-04-22 12:48 Message: Logged In: YES user_id=87909 Crud, wrapping... The changes are all on one line. ---------------------------------------------------------------------- Comment By: Paul Hampson (tbble) Date: 2006-04-22 12:47 Message: Logged In: YES user_id=87909 minfrin, create it as listname-domain or try this patch: diff -urNad mailman-2.1.5/Mailman/Cgi/create.py /tmp/dpep.bPHYjm/mailman-2.1.5/Mailman/Cgi/create.py --- mailman-2.1.5/Mailman/Cgi/create.py 2006-04-22 20:58:10.324872941 +1000 +++ /tmp/dpep.bPHYjm/mailman-2.1.5/Mailman/Cgi/create.py 2006-04-22 21:13:31.596133649 +1000 @@ -184,7 +184,7 @@ oldmask = os.umask(002) try: try: - mlist.Create(listname, owner, pw, langs, emailhost) + mlist.Create("%s@%s" % (listname,hostname), owner, pw, langs, emailhost) finally: os.umask(oldmask) except Errors.EmailAddressError, s: Which will add the '@domain' to the listname before passing it to mlist.Create, which the patch changes to deal with '@' the way we want. ---------------------------------------------------------------------- Comment By: Graham Leggett (minfrin) Date: 2006-03-17 20:39 Message: Logged In: YES user_id=129704 I tried the patch at http://al.blog.free.fr/mailman/mailman-vh-2.1.5.patch and it applied cleanly to mailman as provided by RHEL4. I tried to create a list called "list(a)domain1.com", but this failed with the error "Error: List name must not include "@"". Does this patch have any sort of instructions anywhere? ---------------------------------------------------------------------- Comment By: Arnaud Lavrard (arnaudlavrard) Date: 2005-07-20 14:52 Message: Logged In: YES user_id=1315788 I ported the patch to mailman 2.1.5 : http://al.blog.free.fr/mailman/mailman-vh-2.1.5.patch ---------------------------------------------------------------------- Comment By: The Anarcat (anarcat) Date: 2005-03-16 20:40 Message: Logged In: YES user_id=246797 I have ported the patch to 2.1.4, no news on 2.1.5 yet. I have also put the patch in a seperate CVS server. Fetch all the goods there: http://cvs.koumbit.net/cgi-bin/cvsweb/koumbit-maint/patches/mailman-true-vi… http://cvs.koumbit.net/cgi-bin/cvsweb/koumbit-maint/patches/mailman-true-vi… I've also updated the 2.1.1 patch to fix the list-id, so I delete the attachment, fetch the patch straight from our CVS for the latest fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=943827&group_i…

1 0

[ mailman-Patches-645297 ] Add PGP support
by SourceForge.net 13 Oct '06

13 Oct '06

Patches item #645297, was opened at 2002-11-28 14:54 Message generated for change (Comment added) made by s0undt3ch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=645297&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: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Thomas Wouters (twouters) Summary: Add PGP support Initial Comment: Support PGP encrypted lists using GnuPG. ---------------------------------------------------------------------- Comment By: Pedro Algarvio (s0undt3ch) Date: 2006-10-13 02:04 Message: Logged In: YES user_id=927681 +1 for this patch ---------------------------------------------------------------------- Comment By: Joost van Baal (vanbaal) Date: 2005-03-22 08:30 Message: Logged In: YES user_id=28781 One might like to take a look at patch #1167696 too. It implements about the same functionality. As an added bonus, it has some documentation :) ---------------------------------------------------------------------- Comment By: Arthur Lutz (arthur_lutz) Date: 2004-12-20 14:24 Message: Logged In: YES user_id=848508 another +1 for this patch, I've been looking for this functionality too... willing to contribute ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-11-10 18:31 Message: Logged In: YES user_id=935 another +1 for this patch, I've been looking for this functionality too... ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-17 22:17 Message: Logged In: YES user_id=34209 I'll look at incorporating this when I look at the SecureList patch by NAH6 (SF patch #646989, currently.) ---------------------------------------------------------------------- Comment By: Nicolas Marchildon (elecnix) Date: 2003-02-06 05:16 Message: Logged In: YES user_id=106549 My vote goes to a PGP whitelist and blacklist feature. Messages signed with a key present in the whitelist could go skip moderation, messages in the blacklist would be either ignored or rejected, and all other messages could go through moderation. That way, PGP signatures are not required, but those using them would see their messages delivered quickly. Mailman would have two keyrings, and would manage them by specifying --keyring to gpg. PGP keys would be retreived from a PGP key server. When moderating a message that was signed with a key missing from the whitelist, there would be an option named "Add key to whitelist", and an other one for the blacklist. Keys could be added to the white/blacklist through the web interface by specifying at least a key ID, and mailman would ask gpg to fetch the key from mailman's default key server. Initially proposed in French on: http://www.linux-quebec.org/archives/general/msg03787.html Nicolas Marchildon ---------------------------------------------------------------------- Comment By: David Shaw (dmshaw) Date: 2003-01-04 19:59 Message: Logged In: YES user_id=606006 Another vote of support. I actually submitted an enhancement request earlier today for exactly this. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 19:37 Message: Logged In: YES user_id=147905 Adding a vote of support for this patch. Please add it as soon as it's appropriate! I've been waiting a long time for this functionality and I'd hate to see the patch bitrot. :-) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-12 03:56 Message: Logged In: YES user_id=12800 I have to defer this patch until after MM2.1 since we're about ready for the first release candidate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=645297&group_i…

1 0

[ mailman-Bugs-1576038 ] unexistent sender adress: mailman-bounces@virtualdomain.tld
by SourceForge.net 12 Oct '06

12 Oct '06

Bugs item #1576038, was opened at 2006-10-12 16:47 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=1576038&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.0.x Status: Open Resolution: None Priority: 5 Submitted By: brrrt (brrrt) Assigned to: Nobody/Anonymous (nobody) Summary: unexistent sender adress: mailman-bounces(a)virtualdomain.tld Initial Comment: subscription notices were sent by mailman-bounces(a)virtualdomain.tld instead of listname-bounces(a)virtualdomain.tld. mailman-bounces(a)virtualdomain.tld is invalid and nonexistent, which also leads to such mails being dropped to "nirvana" if some mailserver rejects mail from invalid senders. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1576038&group_…

1 0

[ mailman-Bugs-1573393 ] Missing handling for unexpected content of 'varhelp'
by SourceForge.net 11 Oct '06

11 Oct '06

Bugs item #1573393, was opened at 2006-10-08 16:37 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1573393&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Moritz Naumann (mnaumann) Assigned to: Nobody/Anonymous (nobody) Summary: Missing handling for unexpected content of 'varhelp' Initial Comment: Invoking /mailman/admin/mailman/?VARHELP=/ after having logged in triggers an error. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-10-11 09:55 Message: Logged In: YES user_id=1123998 Fixed in Subversion for Mailman 2.1 and 2.2. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1573393&group_…

1 0

[ mailman-Feature Requests-1574066 ] show list members in web interface
by SourceForge.net 11 Oct '06

11 Oct '06

Feature Requests item #1574066, was opened at 2006-10-09 17:39 Message generated for change (Comment added) made by jimpop You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1574066&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: ulph (ulph) Assigned to: Nobody/Anonymous (nobody) Summary: show list members in web interface Initial Comment: our users / list owners would like it very much to have the possability to get a list of ALL users one one page in the web.interface ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2006-10-11 12:15 Message: Logged In: YES user_id=3142 I can't imagine the submitter wanted two different, yet related, features. I would say this RFE could be closed if RFE 1574060 is going forward. (IMHO) ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-10-11 12:06 Message: Logged In: YES user_id=1123998 I understand what you're saying Jim, and I agree, but I think that is RFE 1574060 by the same submitter, so I think this RFE is for something different. ---------------------------------------------------------------------- Comment By: Jim Popovitch (jimpop) Date: 2006-10-11 11:56 Message: Logged In: YES user_id=3142 I don't think so Mark. I think there needs to be a way to "click and download" a list of members that can be saved as a backup. Then one day in the future add a feature to "click and upload" a membership list to import those members into the system. This way bob's list at providerA could very easily be moved to providerB without much worry by bob. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-10-11 11:48 Message: Logged In: YES user_id=1123998 Would the current 'roster' page be sufficient if it showed ALL members to a user logged in with the list admin or site password? See request # 782436 for a related request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1574066&group_…

1 0