I will write and publish a patch which integrates PGP signature
validation and re-encryption of encrypted posts to mailman. Specs are:
- 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)).
I've taken a look at the NAH6 secure list patch #646989 at
and at Ben Laurie's patch #645297 at
, but I believe none of these completely implements the listed
requirements (although these will help me implementing, of course). I
am asking you to take a look at my plan for implementation. Am I on the
So, the plan:
I think one way to implement it would be to add two modules to
GLOBAL_PIPELINE: in front, before SpamDetect, there would be 'PGPCheck'.
PGPCheck would check wether the message is encrypted, and, if so, make a
temporary decrypted copy in order to verify with which key is was
signed. If the message is unencrypted, it would check the signature.
It would store this information in new properties of the Mailman Message
A second new module in GLOBAL_PIPELINE would be 'PGPRecrypt', to be
called after CookHeaders' and before 'ToDigest'. This would, if needed,
decrypt the message and reencrypt it to all recipients, and would sign
If for instance a list member erroneously signs a post with a wrong
public key, and encrypts the message, this message should be handled
carefully. I believe the Hold module should be adapted for this. A
copy of the original encrypted message should be kept. The message
should be decrypted, signed with the listkey, encrypted to the list
moderator key, and sent for acknowledgement. If the moderator chooses
to deny the message, the poster should get her original message back.
For all PGP handling, I plan to use Frank J. Tobin's GnuPGInterface (
http://py-gnupg.sourceforge.net/ ). I plan to write the patch against
current stable Mailman.
Any insight to share on this?
Joost van Baal http://abramowitz.uvt.nl/
j.e.vanbaal(a)uvt.nl The Netherlands
> -----Original Message-----
> From: mailman-developers-bounces+john.airey=rnib.org.uk(a)python.org
> Behalf Of Tollef Fog Heen
> Sent: Monday, 06 September 2004 16:47
> To: mailman-developers(a)python.org
> Subject: Re: [Mailman-Developers] Min requirements for
> running Mailman?
> * Nigel Metheringham
> | I'd tend to take this as:-
> | * Mailman is a bitch to package
> Not really. It's fairly well-behaved in my experience. It's a
> semi-large web application with some requirements, but nothing
> | * RH have packaged it for a while
> | * RH found a good few of the gotchas in packaging Mailman
> | * RH have subsequently learnt from their mistakes and recently
> | have produced good packages.
> | * Other distros may do better, or may yet have to
> learn from their
> | mistakes :-)
> Mailman has been in Debian since June 1998 (1.0b4), so we've been
> working on it for a while as well. I think our packages are of good
> quality (far from perfect, but making perfect packages is _a lot_ of
> work. ;)
Just to throw my tuppence worth in...
I've used mailman since Red Hat 7.2. I found that the version that came with
Red Hat 9.0 wouldn't work for me (ie I couldn't upgrade to it) so I stuck
with the 7.2 version (2.0.13) till the end of Red Hat 9 support.
We are now running the 2.1.5 version that comes with Fedora but running it
on Red Hat Enterprise Linux (RHEL). I did however have to recreate all the
lists by hand in an overnight shift (what fun that was...) a few days before
leaving the country (hence the rush). At that time I didn't know I could
export the configuration (Doh!).
Red Hat have taken some packages out of RHEL eg arpwatch and mysql-server
(although this is in the "extras" channel) even though these are in the
source RPM. Mailman is currently not included but might be being put back in
to RHEL 4.0. I would like to hope so, as I find 2.1.5 far superior to
John Airey, BSc (Jt Hons), CNA, RHCE
Internet systems support officer, ITCSD, Royal National Institute of the
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey(a)rnib.org.uk
To truly believe in Evolution requires complete faith that life has no
meaning. Fortunately there are billions of people who aren't that stupid.
NOTICE: The information contained in this email and any attachments is
confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.
RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants. However, it
cannot accept any responsibility for any such which are transmitted.
We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.
RNIB Registered Charity Number: 226227
I have submitted a patch to SourceForge for consideration.
- New third party archiving option that uses The Mail Archive. The implementation subscribes or unsubscribes the archive(a)mail-archive.com address from the subscriber list.
The benefit to the list admin is to have a one-click setup option to provide them with mirroring and searchable archives.
We (me and the other Jeff that admin The Mail Archive) have spoken with Lars at Gmane to see if we could make this work for Gmane as well, but he said their subscription process is manual and requires extra information, so Lars didn't think it would work for him.
Patch was made against the latest CVS in branch Release_2_1-maint, which is currently 2.1.6rc3.
I have just uploaded a patch that will make the web UI for MM 2.1.6rc1
XHTML 1 strict compliant. This patch allows for some CSS formatting as well.
I have tried to make all the pages compliant, but I may have missed
some combinations of pages and options, so if you find some that
aren't compliant, please let me know which page isn't compliant and
under which circumstances it's not.
It it patch 1160353 in the Sourceforge Mailman patch repository.
If anyone has any feedback on it, I'd love to hear it,since this is my
first attempt at something like this.
Bryan Carbonnell - carbonnb(a)gmail.com
Life's journey is not to arrive at the grave safely in a well
preserved body, but rather to skid in sideways, totally worn out,
shouting "What a great ride!"
Thomas Hochstein wrote:
> Am I missing something, or wouldn't it be enough for a listowner who
> wishes to use that service to subscribe archive(a)mail-archive.com to
> the list to achieve that goal?
Yes, although the patch contains two options. The first is the option to archive externally at mail-archive.com. The second option asks if the list admin wants to treat the external archive as primary, which sets the List-Archive header and the link on the list info page to the external archive. This is for admins that prefer a searchable archive as their primary.
(It'd be nicer if RFC 2369 stated that the List-Archive header could support multiple URLs, but it doesn't.)
The other positive for adding external archiving/mirroring as a Yes/No option is that it is helpful for list admins that don't know the services exist. The Mailman FAQ entry "How do I make the archives searchable" is a bit daunting, whereas this gives admins an easy option right in the Gui.
The option for mail-archive.com mirroring is defaulted to No.
This is a great discussion so far.
Release candidate 3 for Mailman 2.1.6 is now available. This fixes a
late-breaking problem with RFC 2231 encoded headers containing bogus or
non-existent charsets. Specifically, this release includes an updated
version of the email package (2.5.6).
Please try this version out as much as possible. Hopefully Tokio and I
will get a 2.1.6 final out in about two weeks.
There is a rumor that mailman security check is not proper and
recommending patch to void our security check. Can someone write
a refutation to this article? (In a fluent English of course ;-)
-------- Original Message --------
Subject: [ mailman-Bugs-1188133 ] CGI group id not properly tested
Date: Fri, 22 Apr 2005 07:58:37 -0700
From: SourceForge.net <noreply(a)sourceforge.net>
Bugs item #1188133, was opened at 2005-04-22 15:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
Group: 2.1 (stable)
Submitted By: Graham Klyne (grahamk)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGI group id not properly tested
[I tried to send this to mailman-developers, but my
message was discarded]
I've just downloaded and installed the latest mailman
2.1.6rc1 and encountered a CGI permissions problem
(running with Apache 2.0 on Scientific Linux 3.04), for
which a patch is described in:
(briefly, replace getgid with getegid in common.c)
Applying this patch resolves the problem I was
Is there any reason this isn't applied in the mailman
You can respond by visiting:
Mailman-coders mailing list
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
Now we are on the last stage before the final release of 2.1.6.
After the release of 2.1.6b5, we've got translation updates from the
language champions including Leona for zh_CN (Chinese, China).
Hopefully, I will be able to release the 2.1.6 final within a week.
Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp