Mailman-coders March 2008

mailman-coders@python.org

1 participants
38 discussions

[ mailman-Patches-1167696 ] add support for PGP and S/MIME encryption and signing

by SourceForge.net

Patches item #1167696, was opened at 2005-03-21 17:28 Message generated for change (Comment added) made by mnaumann 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 Private: No 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: Moritz Naumann (mnaumann) Date: 2008-03-30 14:01 Message: Logged In: YES user_id=407680 Originator: NO This patch has since been updated for 2.1.9: http://ulm.ccc.de/pipermail/ssls-dev/2008-January/000003.html http://www.mail-archive.com/mailman-developers@python.org/msg10530.html ---------------------------------------------------------------------- Comment By: Joost van Baal (vanbaal) Date: 2006-10-13 07: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_…

13 years, 10 months

[ mailman-Bugs-1920151 ] CGI going bonkers

by SourceForge.net

Bugs item #1920151, was opened at 2008-03-19 13:42 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1920151&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: Invalid Priority: 5 Private: No Submitted By: paddymcpaddy (paddymcpaddy) Assigned to: Nobody/Anonymous (nobody) Summary: CGI going bonkers Initial Comment: Hi all, I just started getting this message when attempting to modify my list on Bluehost. The interface is Fantastico Deluxe. I'm not a coder, so I have know idea what this is telling me. . .can you help?!? Thanks, D Mailman CGI error!!! The Mailman CGI wrapper encountered a fatal error. This entry is being stored in your syslog: Group mismatch error. Mailman expected the CGI wrapper script to be executed as group "nobody", but the system's web server executed the CGI script as group "daemon". Try tweaking the web server to run the script as group "nobody", or re-run configure, providing the command line option `--with-cgi-gid=daemon'. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-19 19:58 Message: Logged In: YES user_id=1123998 Originator: NO Unless you control your own web server configuration, this is an issue for Bluehost. It is not a bug. It is a misconfiguration. See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.016.htp> for some information on group mismatch errors, but as I said, this is a problem with the configuration of Mailman and/or the web server at Bluehost. There's probably nothing you can do about it other than reporting the issue to Bluehost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1920151&group_…

13 years, 10 months

[ mailman-Bugs-1920151 ] CGI going bonkers

by SourceForge.net

Bugs item #1920151, was opened at 2008-03-19 15:42 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=1920151&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 Private: No Submitted By: paddymcpaddy (paddymcpaddy) Assigned to: Nobody/Anonymous (nobody) Summary: CGI going bonkers Initial Comment: Hi all, I just started getting this message when attempting to modify my list on Bluehost. The interface is Fantastico Deluxe. I'm not a coder, so I have know idea what this is telling me. . .can you help?!? Thanks, D Mailman CGI error!!! The Mailman CGI wrapper encountered a fatal error. This entry is being stored in your syslog: Group mismatch error. Mailman expected the CGI wrapper script to be executed as group "nobody", but the system's web server executed the CGI script as group "daemon". Try tweaking the web server to run the script as group "nobody", or re-run configure, providing the command line option `--with-cgi-gid=daemon'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1920151&group_…

13 years, 10 months

[ mailman-Bugs-1913963 ] Better error checking for MM list in accept_these_nonmembers

by SourceForge.net

Bugs item #1913963, was opened at 2008-03-13 17:38 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&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 beta >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: James E. Blair (corvus_at_gnu) Assigned to: Mark Sapiro (msapiro) Summary: Better error checking for MM list in accept_these_nonmembers Initial Comment: As of the 2.1.10 beta series, accept_these_nonmembers and other related fields accept the name of another mailing list in the form "@listname", or "@listname@hostname". Currently a user can specify a list's own name in its accept_these_nonmembers fields. This should not be allowed for two reasons: 1) It's confusing for users -- it would be better to simply use a list's own moderation feature rather than specifying that members of a list can post by listing the name of the list in a field where you specify non-members that can post. 2) It causes a new MailList object for a list to be created inside of a section of code that already has a locked MailList object for the same list. This is a source of potential lock problems that does not occur elsewhere in the Mailman source. I'm attaching a patch that handles this condition as well as improving the error reporting for the case where the user specifies a list that doesn't exist. Additionally, the patch adds protection in the GUI so that users are not permitted to enter either the name of the list they are editing, or a list that does not exist (the latter was already a suggestion in the comments). ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-16 10:23 Message: Logged In: YES user_id=1123998 Originator: NO This has all been applied except for verifying in the GUI that the list exists. I don't think it's an error to reference a list in *_these_nonmembers with the intent of creating it later. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-03-13 19:01 Message: Logged In: YES user_id=1123998 Originator: NO You can take it to the bank. Make a release - get a new bug report. ;-) (2.1.10b4 was packaged and uploaded less than an hour befor this report) Thanks for the report. I will incorporate at least some of your patch before the next 2.1.10 release. A couple of notes. Regarding 1) - intentionally putting the name of 'this list' in *_these_nonmembers will never have an effect since a post from anyone who is a member will be handled based on that members moderate flag, and *_these_nonmembers will never be consulted. A further argument for preventing it from being done. Regarding not allowing a non-existent list name, I decided to allow it at the time to permit creating a 'list of nonmembers allowed to post', and adding that list to this list's accept_these_nonmembers to be done in either order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&group_…

13 years, 10 months

[ mailman-Bugs-1913963 ] Better error checking for MM list in accept_these_nonmembers

by SourceForge.net

Bugs item #1913963, was opened at 2008-03-13 17:38 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&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 beta Status: Open Resolution: None Priority: 5 Private: No Submitted By: James E. Blair (corvus_at_gnu) >Assigned to: Mark Sapiro (msapiro) Summary: Better error checking for MM list in accept_these_nonmembers Initial Comment: As of the 2.1.10 beta series, accept_these_nonmembers and other related fields accept the name of another mailing list in the form "@listname", or "@listname@hostname". Currently a user can specify a list's own name in its accept_these_nonmembers fields. This should not be allowed for two reasons: 1) It's confusing for users -- it would be better to simply use a list's own moderation feature rather than specifying that members of a list can post by listing the name of the list in a field where you specify non-members that can post. 2) It causes a new MailList object for a list to be created inside of a section of code that already has a locked MailList object for the same list. This is a source of potential lock problems that does not occur elsewhere in the Mailman source. I'm attaching a patch that handles this condition as well as improving the error reporting for the case where the user specifies a list that doesn't exist. Additionally, the patch adds protection in the GUI so that users are not permitted to enter either the name of the list they are editing, or a list that does not exist (the latter was already a suggestion in the comments). ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-03-13 19:01 Message: Logged In: YES user_id=1123998 Originator: NO You can take it to the bank. Make a release - get a new bug report. ;-) (2.1.10b4 was packaged and uploaded less than an hour befor this report) Thanks for the report. I will incorporate at least some of your patch before the next 2.1.10 release. A couple of notes. Regarding 1) - intentionally putting the name of 'this list' in *_these_nonmembers will never have an effect since a post from anyone who is a member will be handled based on that members moderate flag, and *_these_nonmembers will never be consulted. A further argument for preventing it from being done. Regarding not allowing a non-existent list name, I decided to allow it at the time to permit creating a 'list of nonmembers allowed to post', and adding that list to this list's accept_these_nonmembers to be done in either order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&group_…

13 years, 10 months

[ mailman-Bugs-1913963 ] Better error checking for MM list in accept_these_nonmembers

by SourceForge.net

Bugs item #1913963, was opened at 2008-03-13 17:38 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=1913963&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 beta Status: Open Resolution: None Priority: 5 Private: No Submitted By: James E. Blair (corvus_at_gnu) Assigned to: Nobody/Anonymous (nobody) Summary: Better error checking for MM list in accept_these_nonmembers Initial Comment: As of the 2.1.10 beta series, accept_these_nonmembers and other related fields accept the name of another mailing list in the form "@listname", or "@listname@hostname". Currently a user can specify a list's own name in its accept_these_nonmembers fields. This should not be allowed for two reasons: 1) It's confusing for users -- it would be better to simply use a list's own moderation feature rather than specifying that members of a list can post by listing the name of the list in a field where you specify non-members that can post. 2) It causes a new MailList object for a list to be created inside of a section of code that already has a locked MailList object for the same list. This is a source of potential lock problems that does not occur elsewhere in the Mailman source. I'm attaching a patch that handles this condition as well as improving the error reporting for the case where the user specifies a list that doesn't exist. Additionally, the patch adds protection in the GUI so that users are not permitted to enter either the name of the list they are editing, or a list that does not exist (the latter was already a suggestion in the comments). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1913963&group_…

13 years, 10 months

[ mailman-Patches-1902402 ] Updated README

by SourceForge.net

Patches item #1902402, was opened at 2008-02-26 13:28 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1902402&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: documentation Group: Mailman 2.1 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Updated README Initial Comment: The README hasn't been touched in a while; it encourages the user to download Python 2.3.3, points to a now-404 /mailman-21/ URL, and refers to the inactive mailman3-dev list and to public CVS. The attached patch modernizes the README. I think I have commit privs so I could commit it, but wanted to get the changes double-checked. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2008-03-13 10:05 Message: Logged In: YES user_id=11375 Originator: YES Change has been applied by merging the small-fixes branch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2008-02-26 13:50 Message: Logged In: YES user_id=12800 Originator: NO Andrew, how about creating a bzr branch with these changes and pushing them to Launchpad? :) I'd love to review a branch more than a patch! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2008-02-26 13:38 Message: Logged In: YES user_id=11375 Originator: YES Attaching another patch, for UPGRADING. File Added: UPGRADING.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1902402&group_…

13 years, 10 months

[ mailman-Patches-1911318 ] Include message-id in bounce log

by SourceForge.net

Patches item #1911318, was opened at 2008-03-10 14:52 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1911318&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 processing Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Include message-id in bounce log Initial Comment: The attached patch improves the content of the bounce log, determining the message-id of the bounced message. This should make it possible for mmdsr or similar tools to determine what percentage of e-mails bounced. The patch also exercises the message-id code in test_bounces.py. Currently it fails because some of the messages in tests/bounces/ have mbox-style 'From ' lines, and this seems to make email.Message ignore the headers; this causes test_bounces.py to fail at the moment after the patch is applied. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2008-03-13 09:09 Message: Logged In: YES user_id=11375 Originator: YES Here's an updated version of the patch that leaves the <> characters in message-ids, and updates the tests correspondingly. File Added: bounce-log-2.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1911318&group_…

13 years, 10 months

[ mailman-Patches-1911318 ] Include message-id in bounce log

by SourceForge.net

Patches item #1911318, was opened at 2008-03-10 14:52 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=1911318&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 processing Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Include message-id in bounce log Initial Comment: The attached patch improves the content of the bounce log, determining the message-id of the bounced message. This should make it possible for mmdsr or similar tools to determine what percentage of e-mails bounced. The patch also exercises the message-id code in test_bounces.py. Currently it fails because some of the messages in tests/bounces/ have mbox-style 'From ' lines, and this seems to make email.Message ignore the headers; this causes test_bounces.py to fail at the moment after the patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1911318&group_…

13 years, 10 months

[ mailman-Patches-1910552 ] admindb: new label for 'preserve for admin'

by SourceForge.net

Patches item #1910552, was opened at 2008-03-09 18:58 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=1910552&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Schuette (slyh) Assigned to: Nobody/Anonymous (nobody) Summary: admindb: new label for 'preserve for admin' Initial Comment: In my experience nobody really knows what the 'Preserve messages for the site administrator' checkbox does and why it is there. -- But after I changed the text to 'train spamfilter' people really started using it and it became useful. Thus I suggest to find a new label for this checkbox and clearly indicate a spam-related action (so the user knows a marked mail will be used to train a spamfilter). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1910552&group_…

13 years, 10 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders March 2008