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.htmlhttp://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_…
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_…
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_…
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_…
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_…
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_…
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_…
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_…
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_…
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_…