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
Hi Mailman folks.
I wrote an MTA hook for qmail to automate creation/deletion of
list aliases. This seems to work well on my environment (I tested
this on FreeBSD 4.11-STABLE with qmail-1.03 and Mailman 2.1.5
installed from FreeBSD ports):
The qmail-to-mailman.py script also detect newly-created lists
automatically. But "accept and verify" approach by this script
seems not to able to prevent/reduce generating unuseful bounces
(so-called "backscatter mails") in its nature. My approach will
make their reduction somewhat possible --- combined with a
patch for qmail.
For details, please read submitted attachment README.qmail.
Sorry for the delay of 2.1.6 but a serious bug was found in the previous
beta releases. I put a final beta release before jumping up to the
release candidate. The bug is related to 'Privacy -> SPAM filter ->
header_filter_rules'. So, I want all of you, who have had brave souls to
upgrade 2.1.6 beta and who use this feature, to upgrade again to 2.1.6
The tarball is placed at
# Sorry but it looks like I have not access to the file releases on SF.
Tokio Kikuchi tkikuchi@ is.kochi-u.ac.jp
At work I have the following real-world postfix setup:
mydomain = redoaksw.com
mydestination = local.redoaksw.com # note that this domain doesn't exist
virtual_mailbox_domains = redoaksw.com
I installed mailman and created the list 'test1(a)redoaksw.com'. So far
so good, however the "virtual-mailman" alias map mailman generates
does not work.
The problem is as follows :
1) the map contains entries such as
2) postfix converts "test1(a)redoaksw.com" to "test1" as it should,
and then qualifies the address with $mydomain,
(note: this does not actually create a loop)
3) with the address test1(a)redoaksw.com, postfix hands the message
to virtual(8) which looks in the virtual_mailbox_maps and
correctly reports no such user
The solution is simple -- change the map to:
In this scenario, after the virtual_alias_map rewriting, postfix will
hand the message to local(8) which will find the mailman command in
To this end I created the attached patch to mailman. It WorksForMe,
but is not yet complete enough to include in the next release. I need
some assistance in polishing it for inclusion. The core of the patch
is simply to optionally fully-qualify the map value in _addvirtual()
The parts I need help with are :
+ What are good names for the parameters (in mm_cfg.py and the
mail list object)? I'm not convinced you want to be stuck
with the names in my patch forever :-).
+ How do you handle additional parameters on maillist objects? I
noted that __getattr__ fails when the web interface tries to
load the current value from a list created before the
parameter was added.
+ Should the default value for 'local_domain' (as it is currently
called in my patch) be '' or None? I would generally choose
None, but that seems to not play well with the web interface
(it shows "None" instead of nothing).
+ Do I need to do anything with any translation files with regards
to the new list parameter?
One OS to rule them all, one OS to find them,
One OS to bring them all and in the darkness bind them,
In the Land of Redmond, where the Shadows lie.
www: http://dman13.dyndns.org/~dman/ jabber: dman(a)dman13.dyndns.org
-----BEGIN PGP SIGNED MESSAGE-----
I am new to this list. I am the admin of several mailman-based lists
and I'd like to submit a RFE to be able to recover admin passwords
(NOT subscriber passwords). I haven't seen this submitted as a bug or
as an RFE in the Sourceforge site, and I see the RFEs there don't seem
to be maintained/assigned. Where should I post this ?
Thanks for any pointers :)
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
I thought you might be interested in the fact that mail2forum, the hack
that provides phpbb/list gatewaying, has released a new 'stable'
version. Haven't tried it yet but will do so once I get back from the
nonprofit technology conference in Chicago. Sorry to be missing all the
Mailman visitors to DC - hope you have a productive and fruitful time
at PyCon DC!
Begin forwarded message:
> From: "SourceForge.net" <noreply(a)sourceforge.net>
> Date: March 22, 2005 3:39:38 PM EST
> To: noreply(a)sourceforge.net
> Subject: [SourceForge.net Release] m2f : m2f
> Project: mail2forum (m2f)
> Package: m2f
> Date : 2005-03-22 16:39
> Project "mail2forum" ('m2f') has released the new version of package
> You can download it from SourceForge.net by following this link:
> or browse Release Notes and ChangeLog by visiting this link:
I'm a Savane (gna.org/p/savane) developer, and we noticed that when we
send mail with newlines in the \r\n format, Mailman converts them to
I would like to get your point on what we should do to fix the
problem. I had a look at RFC 822; the EOL (end of line) description is
not very clear, but it seems that the standard EOL convention is \r\n
The issue can be fixed if I make Savane convert all \r\n to \n before
to send the notifications, but I am not sure this is very
compliant. Anyway I do think this is a bug in Mailman. What do you
think we (Mailman and Savane) should do?
I posted a detailed bug report at:
for more information.
The Savane bug report counterpart is at:
Mathieu Roy wrote:
>Mark Sapiro <msapiro(a)value.net> tapota :
>> How does Savane inject its messages into the internet mail transport
>> system? If it is sending via SMTP, then it MUST send line terminators
>> as <CRLF> (or \r\n).
>I do not remember the specifics exactly but Sylvain wrote previously
>"we noticed that when we send mail with newlines in the \r\n format,
>Mailman converts them to \n\n.". So I assume Savane is sending
>newlines in the \r\n format.
>> If this results in doubling, then the receiving SMTP server is non
>> compliant. If it is sending messages via some non SMTP intermediary,
>> then it needs to format the messages as expected by the
>> Does Savane perhaps pipe outgoing messages directly to the Mailman
>> wrapper in the same way that an incoming MTA might do? If so, this is
>> _not_ an SMTP transfer and end of line sequences should be those of
>> the platform, i.e just \n for Unix.
>It uses the default mail() function provided by PHP, which would send
>the mail via the locally available SMTP server -- maybe through a pipe
>but still there's an SMTP server between Savane and mailman.
>The main reason why we have the feeling that the bug comes from
>mailman is the fact that only mails redistributed by mailman
>mailing-list have this problem -- not copies sent directly to users or
>mailing-list managed by other list managers.
>Savane and the SMTP server itself are completely unaffected by this
>problem when mailman is not involved.
I certainly understand why you would think this given your
observations, but I have never seen this problem from Mailman, nor
have I seen any report of it other than yours, so I'm inclined to be
Here's a suggestion for a test. Presumably, your current MTA that
delivers to Mailman has aliases (or equivalents) to hand off incomming
mail to Mailman. In particular, the posting address for listname has
listname(a)example.com: "|/usr/local/mailman/mail/mailman post listname"
The path to mailman/mail/mailman may be different, but assuming there
is an alias like this, you could change it temporarily to something
listname(a)example.com: "|tee somefile|/usr/local/mailman/mail/mailman
i.e. you could capture a copy in somefile of the incoming message as
delivered to Mailman. Then, by comparing this copy both to what you're
sending and to what Mailman sends, you should be able to pinpoint
where the problem is.
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
I'm wondering if anybody out there can donate a Subversion repository
for use at the upcoming Pycon sprint next week (actually, starting
Saturday). I had a machine that I was going to use for this, but it
lost its disk over the weekend, and it doesn't look like I'm going to be
able to get it back online in time. :(
Ideally, someone who will be coming to the sprint would be able to
donate a repository, since we'll need to set up access control once
we're there and we know who's going to be participating. It will be
tough to coordinate this if you're not at the sprint, but if you're
willing to be accessible via IM or IRC, we might be able to work around
I'd like for us to have a separate repository, not tainted by other
projects or code. Access can be by http or ssh+svn, whichever you
prefer (although the latter requires us to coordinate pubkeys, so that's
less desirable). I would send you a dump file of my private repository,
and then you'd send me a dump file when the sprints are all done.
This will not be the permanent subversion repository for Mailman3. For
the long term, we'll either host at SourceForge when they make
Subversion available, or I'll host it at my site after I get my machine
back online. We just need something we can use for the week of Pycon.
If you think you can help out, please respond to me directly. Thanks!