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 think CAN-2005-0202 gives us the opportunity to finally implement what
we have long considered an embarrassing exposure in Mailman's config.pck
databases. Member passwords are kept in this database in the clear.
The obvious fix is to hash member passwords and keep only the hash in
We haven't changed this before now for two reasons:
1. We would have to regenerate all member passwords, which is an
administrative burden. We might also need to implement checks to see if
the passwords were cleartext or hashed and do the password comparison
2. This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate their
member passwords anyway, so this gives us an opening to fix this
properly. And we have a better internal password generator now too.
As for #2, well, I think most people hate those password reminders
anyway, and we've decided that they are going away for MM3. I don't
think many people would shed too many tears if we killed off monthly
password reminders for 2.1.6. Doing that would also eliminate the
requirement for the site list, since its primary purpose is to function
as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My Password To Me"
feature in the options page and in the member login page. These would
have to become a "create a new password for me" feature. Also,
crontab.in should not call mailpasswds anymore, or that script should
turn into a simple "here's the lists you are on" reminder, without the
password information in it. This will require i18n updates too.
The downside to doing this now is that it's more coding work for 2.1.6
and I'd like to get the new version out asap. Still, this seems like an
opportunity that we shouldn't lightly dismiss.
What do you all think? Is anybody willing to take a crack at a patch
I read some old post back in 2002 on this list about Load balancing. In my scenario I don't have near the volume to warrant load balancing but I am interested in fail over capabilities. Would it cause Mailman any heartburn if I simply wrote an rsync script to keep the trees in sync? And then use the heartbeat package to do automatic fail over. I realize depending on my sync cycle I will potentially loose some data. Is there a better alternative to this?
Also I saw there are plans to move to a user store were users would have one password for all list. Have there been any considerations for LDAP as that user store?
In the scripts subdirectory is a file called "driver", the comments at
the top of the file say its used to run CGI scripts. In a standard 2.1.5
installation I don't see anything that actually invokes "driver", but
perhaps I've overlooked something. When is driver invoked? Is it only
for optional third party cgi scripts?
John Dennis <jdennis(a)redhat.com>
a long long *long* time ago now, I made a small hack to SMTPDeliver.py
to add options to the sendmail connection EHLO, to enable VERP
generation in the MTA (so that the sending system didn't have to send N
messages to the MTA to accomplish VERP, but rather let the MTA deal with
it). For Postfix, this is as simple as adding the XVERP option.
I still don't see any facility for doing this in a generic way; has
anyone addressed the problem, and if so can someone point me at the
On Fri, 25 Feb 2005 11:03:34 +0800
pabs <pabs(a)cat.org.au> wrote:
> Is this list broken, or has everyone left?
<Looks up from his editor that's wrapping libproc into a python
<goes back to hacking>
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.