Mailman 3 April 2004 - Mailman-Developers

Mailman "Already Subscribed" behavior.
by Bradach, Jack 12 Apr '04

12 Apr '04

Hello, 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.) Thanks! Jack Bradach List Support list-support(a)orst.edu 541-737-3474

1 0

Re: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman
by Lloyd F. Tennison 12 Apr '04

12 Apr '04

I know this might be simplistic, and I cannot get it to work, but the Defaults.py say the following: # 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- trace', '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 = [ ('to', 'X-Original-To'), ('cc', 'X-Original-Cc'), ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), ('mime-version', 'X-MIME-Version'), ] 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. Thanks. Lloyd F. Tennison lloyd_tennison(a)whoever.com No trees were harmed in the transmission of this message. However, a rather large number of electrons were temporarily inconvenienced.

1 0

Avoiding setgid Binaries and Directories
by Mark D. Roth 12 Apr '04

12 Apr '04

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 configured. 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: http://sourceforge.net/tracker/index.php?func=detail&aid=723918&group_id=10… Because these external mechanisms take care of all of the uid/gid changing, I built Mailman with "--with-mail-gid=mailman --with-cgi-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 the binary. 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 suggest? If this seems like a reasonable change, I'd be happy to submit a patch. Thanks in advance for your feedback! -- Mark D. Roth <roth(a)feep.net> http://www.feep.net/~roth/

1 0

Mailman + postfix + amavisd-new HOWTO
by Fil 09 Apr '04

09 Apr '04

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 -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 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 -o smtp_data_done_timeout=1200 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): !/-bounces(a)(my\.domain\.tld|other\.domain\.net)$/i FILTER smtp-amavis:[127.0.0.1]:10024 Modify /etc/postfix/main.cf to have the check_recipient_access use this regexp table: smtpd_recipient_restrictions = permit_mynetworks check_client_access hash:$config_directory/access reject_unauth_destination check_recipient_access regexp:$config_directory/amavis_check # other UCE checks here 6) You're done. Check your log files and enjoy an almost spam- and virus-free server. 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. REFERENCES: Amavisd-new: http://www.amavis.org/ Mailman: http://www.list.org/ postfix: http://www.postfix.org/ 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 Texts.

2 2

external archiver
by Jonas Meurer 09 Apr '04

09 Apr '04

hello, 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 archiver. 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 should be: /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. bye jonas

2 2

Re: [Mailman-Developers] Wrong host_name when creating list via webinterface
by J C Lawrence 08 Apr '04

08 Apr '04

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.

1 0

Wrong host_name when creating list via webinterface
by Dave Kliczbor 08 Apr '04

08 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 'lists.domain.tld'). 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...) My mm_cfg.py: - ---- 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' VIRTUAL_HOSTS.clear() add_virtualhost('lists.domain.tld') - ---- cya Dave KLiczbor - -- 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) iD8DBQFAdaSi9gy0Ccu0VlMRAuacAJ0V/tGPnt0l7w03OBZvfHvj4pwWKwCfVTA7 q7NyBI8yE4+BDTvS3x20048= =FmPe -----END PGP SIGNATURE-----

2 1

"Reply-to" addresses in archive
by mch＠cix.compulink.co.uk 08 Apr '04

08 Apr '04

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... Mike

2 1

Placing the confirmation string in email body instead of the Subject
by Subha Subramanian 08 Apr '04

08 Apr '04

Hi, 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? -Subha

1 0

Truncated digest with MIME
by mch＠cix.compulink.co.uk 08 Apr '04

08 Apr '04

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 next line. 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 to this? I can find one message about this in the archive, but no response: # 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.

1 0