I've noticed that Mailman's "You're already subscribed to this list" behavior isn't consistent between the web and email interfaces. Specifically, if you send a message to listname-join(a)domain.tld, it kicks you a brief "you are already subscribed to this list" message. However, if you subscribe from the web interface (and are already a member), it has a long message about how it could be a security violation (or nothing to worry about!). Any chance someone can change it kicks out the same message no matter how you try to double-subscribe? (Or even better, allow the site admin to change that message. It doesn't look like it's one of the messages that site admins can edit.)
I know this might be simplistic, and I cannot get it to work, but the Defaults.py say
# These variables controls how headers must be cleansed in order to be
# accepted by your NNTP server. Some servers like INN reject messages
# containing prohibited headers, or duplicate headers. The NNTP server may
# reject the message for other reasons, but there's little that can be
# programmatically done about that. See Mailman/Queue/NewsRunner.py
# First, these headers (case ignored) are removed from the original message.
NNTP_REMOVE_HEADERS = ['nntp-posting-host', 'nntp-posting-date', 'x-
'x-complaints-to', 'xref', 'date-received', 'posted',
'posting-version', 'relay-version', 'received']
# Next, these headers are left alone, unless there are duplicates in the
# original message. Any second and subsequent headers are rewritten to the
# second named header (case preserved).
NNTP_REWRITE_DUPLICATE_HEADERS = [
I was trying to use it to remove X-Mailer and X-Url codes, but as I read it this should
also remove the original received header - which would be great for announce only
lists. Since my IP is in the header my attacks on my personal machine get out of
hand by pop-up spammers.
Lloyd F. Tennison
No trees were harmed in the transmission of this message.
However, a rather large number of electrons were temporarily
I've just recently started playing around with Mailman, so I apologize
in advance if this is an FAQ, or if I'm sending this to the wrong
forum, etc. Any etiquette corrections would be greatly appeciated. :)
I think I've found a way to install Mailman without the need for
setgid files and directories, but I'd like to get a sanity check from
people who are more familiar with the code than I am, just to make
sure that there aren't any security implications in how I have things
Here's how I've set things up. Basicly, I solved the problem by using
external mechanisms to ensure that the Mailman binaries are always
executed as user and group mailman. For the CGI scripts, there is
suEXEC. For the mail interface, there is the Procmail MTA handler,
which was posted on SourceForge:
Because these external mechanisms take care of all of the uid/gid
changing, I built Mailman with "--with-mail-gid=mailman
Now here's the complication. I'm trying to build a distributable
binary package of Mailman, and I'd like it to be usable in different
environments. In particular, I'd like to use the same package in my
environment, where I avoid the setgid bit as described above, as well
as in other environments, which may still use the normal setgid
approach. However, if I build with "--with-mail-gid=mailman
--with-cgi-gid=mailman", then the package isn't really usable in other
environments, since most mailers and web servers will not be invoking
the binaries as group "mailman". I would prefer to build the package
with something like "--with-mail-gid=mailnull --with-cgi-gid=httpd",
which is more likely to be useful on other people's systems.
To solve this problem, I propose that the wrapper code be modified to
allow execution by MAILMAN_GROUP in addition to the "--with-mail-gid"
and "--with-cgi-gid" values. My thought is that this shouldn't
present a security risk, since the setregid() call wouldn't give the
caller any permissions that it doesn't already have. In fact, there's
no point in calling setregid() to begin with in this case, since it's
already running as group MAILMAN_GROUP; the wrapper can simply exec
So, my question is, are there any security issues I haven't thought of
with respect to the configuration I'm using in my environment? If
not, does anyone see any problem with modifying the wrapper code as I
If this seems like a reasonable change, I'd be happy to submit a
Thanks in advance for your feedback!
Mark D. Roth <roth(a)feep.net>
Mailman + postfix + amavisd-new HOWTO
by Fil <fil AT rezo.net>
8/04/2004 - This is a first draft. Comments are welcome. This file is
released under the GNU Free Documentation License (FDL, see below).
INTRODUCTION: Installing the antispam/antivirus amavisd-new on a
mailing-list server poses a serious performance issue: when the server sends
out thousands of emails to the mailing-list subscribers, some of these
subscribers return bounce messages, which can number in the hundreds and
might clog the antivirus daemon if you're not careful.
Here's how we do it on http://listes.rezo.net/
1) Before all, make sure you run postfix v2.x, otherwise the FILTER feature
will not be here. Configure postfix so that it accepts scanned messages from
amavisd-new on localhost:10025
Add to /etc/postfix/master.cf the following lines:
localhost:10025 inet n - n - - smtpd
2) Configure amavisd-new the usual way, so that it accepts incoming mail on
localhost:10024 (or any other port you choose) and sends it back into the
mail queue via localhost:10025; this is very standard, but I guess the
settings is as follows, in /etc/amavis/amavis.log:
$inet_socket_port = 10024;
@inet_acl = qw( 127.0.0.1 );
$max_servers = 2; # two servers max at the same time
3) Define a smtp-amavis service on postfix, so that it can be invoked later:
Add to /etc/postfix/master.cf:
smtp-amavis unix - - n - 2 lmtp
Note here that the maximum number of processes running in parallel (2) is
the same as in the amavisd-new configuration. You can increase both a bit if
you experience delays in delivery because of amavis, but that's out of the
scope of this HOWTO. 2 is fine for us, with a daily average of 10 emails to
check per minute (and a powerful computer).
4) Test your filter by sending messages locally through SMTP:10024
5) Configure postfix to send all emails through the filter EXCEPT those
messages that are only addressed to a list-bounces address :
Create the address regexp in /etc/postfix/amavis_check (do 'man
regexp_table' to get more information):
Modify /etc/postfix/main.cf to have the check_recipient_access use this
smtpd_recipient_restrictions = permit_mynetworks
# other UCE checks here
6) You're done. Check your log files and enjoy an almost spam- and
7) Now you can focus on the viruses and politics that kill people in the
real world, and read "Global Aids: Myths and Facts" by Alec Irwin and Joyce
Millen, published by South End Press.
Copyright (c) 2004 PHILIPPE RIVIERE.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
I try to configure mailman to use lurker as archiver, but the usage of
External Archivers is not clear for me, and i didn't find any
documentation about this topic except of a hint in mailmans faq wizard,
which only describes the way of subscribing a archiving user to every
list and set the right alias to the archiver for the mta.
Since this requires procmail, which is quite steady at heavy load, i'dd
like to use the PUBLIC_EXTERNAL_ARCHIVER and PRIVATE_EXTERNAL_ARCHIVER
config options of mailman.
After searching some pages and files, i got from Defaults.py, that these
two options should be what I searched for.
I understood them as options where you set a shell command where the
message is passed to that should archive the message at the external
If this is wrong, what's the intention of these two options?
For my external archiver (lurker), i have the binary lurker-index, which
needs the listname with option -l and expects the message at stdin.
so i set the two options like following:
PUBLIC_EXTERNAL_ARCHIVER = '/usr/bin/lurker-index -l `echo %(listname)s \
| tr "[:upper:]" "[:lower:]"` -m'
PRIVATE_EXTERNAL_ARCHIVER = '/usr/bin/lurker-index -l `echo %(listname)s \
| tr "[:upper:]" "[:lower:]"` -m'
this should do nothing else than running lurker-index with -l listname
(changed to lowercase letters, since lurker only support lowercase
listnames). so if the listname is either mylist or MyList, the command
/usr/bin/lurker-index -l `echo MyList | tr "[:upper:]" "[:lower:]"` -m
which ends normally ends up in:
/usr/bin/lurker-index -l mylist -m
but regardless if I use the above listed option, or directly
PUBLIC_EXTERNAL_ARCHIVER = '/usr/bin/lurker-index -l mylist -m'
i get at /var/log/mailman/error:
Apr 09 02:21:15 2004 (18207) external archiver non-zero exit status: 1
any suggestions what I might have forgotten?
ah, i turned off multipart message filtering for not messing up lurker
at initial tests:
ARCHIVE_SCRUBBER = 0
sorry, i absolutely have no idea what I did wrong, and I CCed this
message to -developers since there seems to be no documented common
usage of the EXTERNAL_ARCHIVER options.
Maybe the message isn't passed to the shell command on stding because
other delivery method is expected, but i don't believe that.
Additional, what exactly does this ARCHIVE_TO_MBOX option do?
Defaults.py tells me:
# 1 - archive to mbox to use an external archiving mechanism only
does this mean that mailman archives to an mbox file and the external
archiver is intended to use this file for archiving new messages?
if yes, where can i find this mbox file? should the external archiver
option then use the file for updating archive rather than getting the
new message directly over standard input (stdin)?
sorry if i'm confusing, please tell me in this case, but i have too much
questions i'm not able to answer on my own, to get the whole big puzzle
put together out of all the little pieces.
On Thu, 8 Apr 2004 15:41:08 -0400
Terri Oda <terri(a)zone12.com> wrote:
> On Apr 8, 2004, at 3:14 PM, Dave Kliczbor wrote:
>> I just set up mailman on my Debian woody box, using the mailman
>> 2.1.4-2.backports.org debian package from backports.org.
> I haven't looked at more recent mailman packages, but I've been
> largely unimpressed with the debs I've seen in the past -- there's so
> much munging in there that sometimes it causes more problems than it
> "solves" through standardizing. Not sure why.
Having run from the Debian packages for some years now without problem
I'd counter this, and instead recommend just installing the appropriate
mailman package from /testing.
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hello out there...
I just set up mailman on my Debian woody box, using the mailman
2.1.4-2.backports.org debian package from backports.org.
Everything seems to be ok, except one tiny bit... If I create a new list
via webinterface, the wrong hostname is used (namely 'domain.tld')-- if
I create it via command line, the right hostname is used (namely
Nothing concerning my mailing lists is associated with 'domain.tld',
everything, including web traffic, has to use 'lists.domain.tld'. As a
result, I put 'lists.domain.tld' everywhere I could find before even
starting mailman the very first time.
I dove a bit further in this issue, but all I could find was that the
host_name config variable has been set inproperly when using the
webinterface to create a list. I even used the deprecated
DEFAULT_HOST_NAME variable in mm_cfg.py, but no result. I still have to
manually set the host_name in the list option page after creating.
I found only one post without answer in the last three months regarding
such an issue on mailman-users, nothing found in mailman-developers
(keywords I used: web, host)
I tried posting first on mailman-users, but I got no answer (I suppose
my question was a bit too technical :-). Even on the bug tracker I
found nothing and now I'm at the end of my knowledge... (OK, if I learn
python maybe I could solve the problem, but that's a little bit more
time-consuming than I could afford...)
DEFAULT_URL = 'https://lists.domain.tld/cgi-bin/mailman/'
DEFAULT_EMAIL_HOST = 'lists.domain.tld'
DEFAULT_URL_HOST = 'lists.domain.tld'
IMAGE_LOGOS = '/images/mailman/'
USE_ENVELOPE_SENDER = 0
DEFAULT_SEND_REMINDERS = 0
DEFAULT_HOST_NAME = 'lists.domain.tld'
HOST_NAME = 'lists.domain.tld'
MAILMAN_SITE_LIST = 'mailman'
PRIVATE_ARCHIVE_URL = '/cgi-bin/mailman/private'
DEFAULT_URL_PATTERN = 'https://%s/cgi-bin/mailman/'
PUBLIC_ARCHIVE_URL = 'https://%(hostname)s/pipermail/%(listname)s'
DEFAULT_SERVER_LANGUAGE = 'de'
docs on mail serving and spam preventing in
the courier mail suite: http://da.andaka.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
I've just spotted that in the archives for a list with
"Reply-to:list" many messages appear as coming from
the list, some with no record of the sender.
Is this a known bug?
Or is there some admin setting I'm missing? I've looked
hard and not found one...
How do I get mailman to parse the whole message to get the email commands?The email command only works if it is the first line of the email body.
I am trying to change the subject of the confirmation email to make it user friendly. I changed the verify.txt to include the confirmation cookie and changed Utils.py to read the first 20 lines.
It still doesnt work! What am I missing?
I have a problem. We have, I think, a problem.
1) Message is sent with a line exactly 76 characters
long, ending with ".". User (a computerphobe) still has
pretty email turned on, so something en route wraps the
line at column 75, leaving a "." by itself on the
2) For another digest user - who is reading email
as plain text that means "here endeth the message".
Rest of digest not visible. Potential for fouling
up their email client when they reindex.
I've asked all members of the list to switch to plain
text emails. But it ain't gonna happen :(
Can something be done to make mailman transparent
I can find one message about this in the archive, but
# From: Michael Schwendt
# Subject: [Mailman-Developers] Mailman transparency
# Date: Sat, 13 Sep 2003 06:24:03 -0700
2) Occasionally, a subscriber finds that a posted message has made it
to the mailing-list only truncated. It turns out that the message
contained a line with only a single dot by itself. Mailman cuts off
the message body at that line before distributing the truncated
message to all subscribers. It looks much like the dot is treated as
SMTP message body delimiter but in a non-transparent way. The users
should be protected from something like that.