Mailman-Users January 2011

mailman-users@python.org

56 participants
62 discussions

Add "sender's name/email" to BODY of mail as header?

by Mal

I want all mails sent to the list to come from the list's email address... But, in this case, if the user forgets to sign their name at the bottom of their mail body, effectively the mail to the list is anonymous...! Is there a way to add the user name (or email address) to the top of each mail so that the mails have the name of the sender, while the mail itself comes from the list address? I have looked high and low for an answer, but noone seems to have the solution. Thank you! Mal

2 weeks, 3 days

Mailman CGI Error-Group mismatch error

by Wang, Mary Y

Hi, I received the following error this morning. So I rerun configure again with the following command: ./configure --with-cgi-id=apache --prefix=/var/mailman. I'm still getting the same error. Is there any place that I can look for so that I can debug this problem better? Perhaps, looking at the config history file or something. Any other places that I can check the cause of this error? "Mailman CGI error!!! The Mailman CGI wrapper encountered a fatal error. This entry is being stored in your syslog: Group mismatch error. Mailman expected the CGI wrapper script to be executed as group "nobody", but the system's web server executed the CGI script as group "apache". Try tweaking the web server to run the script as group "nobody", or re-run configure, providing the command line option `--with-cgi-gid=apache'." Thanks Mary

5 months, 3 weeks

Setting MIME as default for new Non-Digest subscribers

by Steve Reiter

Hi - I have searched FAQ and archives to find an answer. Hoping you can help. I have a new list (with previously imported addresses) for announcements only, and wish these announcements to be received immediately. I set the defaults to allow non-digest and to not allow digest. I wish to send out announcements in html, and so wish to make the default for new subscribers be MIME. While I see a setting under Digest Options (MIME_is_Default_Digest), I don't see any equivalent option under Non-Digest Options... and new subscribers continue to come in as plain text. QUESTIONS: In order to avoid having to manually change this option for each existing subscriber, is there a way to force all existing subscribers to receive MIME in Non-Digest mode? If not, is there a way to force all NEW subscribers to be enrolled with MIME as their default? Also, is there a way to "lock" the MIME switch on, so that users who try to change their option to plain text will be prevented from doing so? Thanks - Steve

9 years, 7 months

Mailman list sends but doesn't receive mail.

by JRC Groups

Hello, All. I've just set up my first Mailman mailing list in OS X Server. It sends mail as welcome notifications were received by several different members subscribed to the mailing list. However, it doesn't seem to be receiving e-mail. All attempts I've made have resulted in Delivery Failure Notifications. This is the text returned with this Delivery Failure Notifications: > Delivery to the following recipient failed permanently: > > list(a)3domain.com > > Technical details of permanent failure: > Google tried to deliver your message, but it was rejected by the recipient > domain. We recommend contacting the other email provider for further > information about the cause of this error. The error that the other server > returned was: 550 550 5.1.1 <list(a)domain.com>: Recipient address rejected: > User unknown in virtual alias table (state 14). What could be the cause ? In order for a Mailman list to work properly do I need to create an account for it in Workgroup Manager with its e-mail address ? Sorry if this is a simple question but I am not an IT specialist and don't have any experience with Mailman. Thank you in advance, Joe

9 years, 10 months

Cannot exec /etc/mail/smrsh: Permission denied

by John Espiro

When I send a message to the mailing list I get: sm-mta[16327]: p0SJuInx016321: SYSERR(root): Cannot exec /etc/mail/smrsh: Permission denied Jan 28 19:56:22 sm-mta[16326]: p0SJuInx016321: to="|/usr/lib/mailman/mail/mailman post LISTNAME", ctladdr=<ADDRESS> (8/0), delay=00:00:01, xdelay=00:00:00, mailer=prog, pri=31689, dsn=4.0.0, stat=Operating system error System: Ubuntu 10.10 Server 64bit I've read through this: http://www.gnu.org/software/mailman/mailman-install/node32.html grep smrsh /etc/mail/sendmail.cf ##### $Id: smrsh.m4,v 8.14 1999/11/18 05:06:23 ca Exp $ ##### Mprog, P=/etc/mail/smrsh, F=lsDFM smrsh is in: :/usr/lib/sm.bin In /usr/lib/sm.bin, I ran: ln -s /usr/lib/mailman/mail/mailman mailman In /etc/mail/smrsh, I ran: ln -s /usr/lib/mailman/mail/mailman mailman Still, the problem persists. I am sure this must be a permissions issue, then again, maybe not. Other data: uid=51(smmsp) gid=51(smmsp) groups=51(smmsp),45(sasl) uid=103(smmta) gid=106(smmta) groups=106(smmta),45(sasl) uid=8(mail) gid=8(mail) groups=8(mail) ls -la /etc/mail/smrsh drwsr-sr-x 2 root root 4096 2011-01-28 19:31 .

10 years

Administrivia Messages

by Beau Barnhart

Hello, We have been asked by mail-abuse.org to make changes to the configuration to one of our servers. The following this their request... -- message from mail-abuse.org ---------- Currently, when messages arrive at your mail server it runs them through SpamAssassin, which checks for spam and tags them. Your mail server then passes this tagged message to mailman. Because it is to a -request address, mailman "knows" that these messages should contain commands. It ignores the fact that SpamAssassin has already tagged it (Subject: {Definitely Spam?}), and looks through every line looking for a "subscribe", "unsubscribe" or other command. Of course, it doesn't find one. So, it builds up a helpful reply, sets the X-Administrivia header to yes, and appends the original message, and forwards this to the From: address. Except that the From: address is forged, so the message, and its spam payload, get sent to an innocent third party. Please properly configure your mailing list software to send list administrivia _only_ to a local administrator, or configure it not to send to forged From: addresses. In general, there is no need for "list administrivia" - it was an artifact of some of the original list management software. It does not serve a useful purpose today. ---------------------------- Actually we use administrivia in custom scripts and don't want to disable it. We even have members that still use the request commands. Ive searched the mailman wiki as well as the mailman-users archive and have not been able to find how to configure the administrivia recipient. Any help would be appreciated. Thanks, Beau Barnhart Look Media

10 years, 1 month

handling mail undeliverable to list owners

by Richard Haas

Greetings. We have a moderately sized Mailman installation (+2000 mailing lists) which recently upgraded a long-standing Mailman v2.1.5 service to v2.1.14. The upgrade went quite well, but since the upgrade the list owners of the DEFAULT_SITE_LIST (i.e. "mailman") mailing list are seeing a marked increase in the number of undeliverable emails to (other) list owner addresses, which the "mailman" list owners did not see with the previous version/installation of the software. While unlikely, they may have been a customization in either Mailman or Postfix that was lost in the transition; the logic in ~/Mailman/Message.py which sends list owner bounces to DEFAULT_SITE_LIST seems unchanged since 2.1.5 (at least). Let me be clear: these are valid bounces from some list owner addresses that do not deliver, because a person who was a list owner has departed the organization and the mailbox to which a list owner address routes no longer exists. These messages not errors in Mailman. Often, a single list owner address will bounce to the DEFAULT_SITE_LIST, while other valid list owners remain available for that same list -- in that case, DEFAULT_SITE_LIST members need take no action. When there's just one owner for a list and that address bounces, the list is orphaned (which is good to know), but we have other means to reclaim unused lists (periodic reregistration), and the administrative notice which bounced is frequently not something that would be posted to the list anyway (e.g. spam, erroneous out-of-office mail, spoofed sender, etc.) -- particularly if the list has fallen into disuse. It would be nice to only see the bounces when there are no other list owners (of the same list) to receive them. Are there any Mailman configuration options which adjust the handling of bouncing list owner emails, short of customizing the Messages.py or adjusting filters on the DEFAULT_SITE_LIST policies? None leap out in Defaults.py. Thanks for any insight. -- Richard Haas <rhaas(a)rhaas.us> --

10 years, 1 month

Mailman + Postfix + Virtual Domain (LDAP) not working

by Roberto Mascarenhas Braga

I'm trying to get Mailman working with Postfix as a MTA but with some trouble with virtual domains. I've made setup fine and create my first mailing list, called "mailman". So, as my domain is cdt.unb.br, the list address is mailman(a)cdt.unb.br. The machine that hosts the mailserver is called mailcdt. So its hostname is mailcdt.cdt.unb.br. If I send a message to mailman(a)cdt.unb.br - the desired email to the testing list - I cannot receive the message. But if I send the email to mailman(a)mailcdt.cdt.unb.br (undesired address) I got the message. Here is my config: ___________________________________________________________________________________ *** /etc/mailman/mm_cfg.py *** ___________________________________________________________________________________ POSTFIX_STYLE_VIRTUAL_DOMAINS = ['cdt.unb.br'] from socket import * try: fqdn = getfqdn() except: fqdn = 'mm_cfg_has_unknown_host_domains' DEFAULT_URL_HOST = "mailcdt.cdt.unb.br" DEFAULT_EMAIL_HOST = "cdt.unb.br" VIRTUAL_HOSTS.clear() MTA = 'Postfix' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) ___________________________________________________________________________________ *** /etc/postfix/main.cf ___________________________________________________________________________________ unknown_local_recipient_reject_code = 550 relay_domains = virtual_maps = hash:/etc/postfix/virtual alias_maps = hash:/etc/aliases, hash:/etc/mailman/aliases alias_database = hash:/etc/aliases home_mailbox = Maildir/ debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop html_directory = no manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-2.3.3/samples readme_directory = /usr/share/doc/postfix-2.3.3/README_FILE virtual_mailbox_domains = $mydomain virtual_mailbox_base = /home/vmail virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf virtual_uid_maps = static:500 virtual_gid_maps = static:500 message_size_limit = 30720000 mime_header_checks = regexp:/etc/postfix/mime_header_checks header_checks = regexp:/etc/postfix/header_checks virtual_alias_maps = hash:/etc/mailman/virtual-mailman recipient_delimiter = +

10 years, 1 month

To use or not to use content filtering

by Andrew Hodgson

Hi, I have read various discussions on this list about content filtering settings in Mailman. For the most part, I usually leave content filtering on, and leave the defaults, primarily for protecting list users against malicious attachments (I am enough of an MS veteran now not to care about filtering all HTML). However, over recent months we have had some issues with content filtering on some lists, with users who send emails with disclaimers, where the disclaimer is added as an attachment to the message, and Mailman appears to strip off the actual message, leaving the disclaimer to post to the list, and of course adding in the standard footer. Are people using content filtering in lists where most people are using MS products, and a suitable antivirus package on the MTA as well as a low posting size limit, or are there any tweaks I can make to the content filtering settings that may get some of this stuff through? Thanks. Andrew.

10 years, 1 month

postfix-to-mailman.py => mail loops back to myself

by Russell L. Carter

Hi there, I've spent the afternoon attempting to install mailman on debian testing with postfix, following the instructions in /etc/mailman/postfix-to-mailman.py precisely, and I'm getting the classic 'mail for "host" loops back to myself'. From my getting to know the issue sessions with google there appear to be a variety of ways this can show up. Anyway I've checked permissions, am able to create lists and add users with confirmation, etc. But sending from the user to the list bounces with postfix complaining 'loops back to myself'. Q1: I was not previously using postfix virtual domains as described in www.postfix.org/VIRTUAL_README.html, should I be? If so I'll go off and try to figure out how the information in there is related to the instructions in /etc/mailman/postfix-to-mailman.py. However, AFAICT, the two sources appear to have zero intersection even though the concepts are of course are quite similar. If the answer to Q1 is "no", the only change to my existing system was to add a CNAME 'lists.pinyon.org' pointing to 'quine.pinyon.org'. Here is the relevant part of of my long time working main.cf, with the mailman modifications (all checked, many times): ------------------------------------------------------------------ myhostname = quine.pinyon.org mydomain = pinyon.org myorigin = $mydomain mydestination = $myhostname, localhost.$mydomain, $mydomain, mail.$mydomain, www.$mydomain, ftp.$mydomain troupesalamat.com masquerade_domains = pinyon.org relay_domains = lists.pinyon.org $mydestination esturion.net troupesalamat.com relay_recipient_maps = hash:/var/lib/mailman/data/virtual-mailman transport_maps = hash:/etc/postfix/transport mailman_destination_recipient_limit = 1 ------------------------------------------------------------------ I've tried quite a few permutations of ordering, etc., but no luck. Q2: Any idea what might be the problem? Many thanks! Russell

10 years, 1 month