Mailman 3 May 2016 - Mailman-Users

Mm_cfg.py not setting attribute
by Beu, Ed (DOA) May 24, 2016

May 24, 2016

Hi, We currently have two instances of Mailman running for test purposes. The newlist command along with a customized mm_cfg.py file is producing different results on the two systems. Configurations are as follows on these two test systems. T1 Solaris 10 Mailman 2.1.20 (csw package) T2 CentOS 6.7 (Final) Mailman 2.1.12 (yum package) On the T1 system I am adding the following statement to the mm_cfg.py file: DEFAULT_RESPOND_TO_POST_REQUESTS = No Then, when I run "./newlist -q listname my.email(a)domain.com<mailto:my.email@domain.com> 12345678" the list setting is as desired (respond_to_post_request = No). On the T2 system using the same scenario above, the "respond_to_post_request" attribute does not change from the Defaults.py setting of Yes. On the T2 system I have tried changing the attribute from DEFAULT_RESPOND_TO_POST_REQUESTS to just RESPOND_TO_POST_REQUESTS, changed No to Zero (0) and tried DEFAULT_RESPOND_TO_POST_REQUESTS = 0. A number of combinations, and none work on the CentOS machine. Do you have any suggestions or recommendations? Our goal is to use the CentOS system for production, so getting this worked out will be very helpful. Thx, Ed Ed Beu , Systems Programmer Enterprise Technology Services Department of Administration 619 E Shipcreek Ave., Ste 232 Anchorage, AK 99501-1677 [ETSLogo]---------------------------------------- *Desk:(907)269-6790 ?Fax: (907)269-6719 * ed.beu(a)alaska.gov<mailto:ed.beu@alaska.gov> " http://www.doa.alaska.gov/ets/ ----------------------------------------

2 3

Mailman suddenly passing through spam from the -bounces addresses
by Rusty Newton May 24, 2016

May 24, 2016

Hi! New to the list! I'm the community support manager at the Asterisk project. We've used mailman for ages and we are on 2.1.14 at the moment. I rarely get too deep with mailman other than the administration interface. It mostly works and we don't touch much underneath. Recently I started receiving a lot of spam on the mailman-bounces@ addresses where the From address no longer contains the mailman-bounces@ address and instead contains the spammer's address. In this case the spam doesn't look like bounce traffic. I'm wondering if someone can help me identify why mailman might let it through? From reading documentation and the mailman mail archives I get the impression that it should be discarding this traffic. However I can't identify why it isn't discarding this non-bounce traffic. Here is one example of the spam that comes to the owners addresses via mailman-bounces: http://pastebin.com/u2HyNLw6 The list in question has all three bounce notification options set to *no*. That is: bounce_unrecognized_goes_to_list_owner bounce_notify_owner_on_disable bounce_notify_owner_on_removal With these three options disabled - should I expect mailman to relay spam like this to the list owners through mailman-bounces@ ? Is there a way to tell mailman to not send anything from mailman-bounces? Preferably I'd like to have mailman only pass through legitimate bounce messages. If that isn't possible then I'd like to find out how to disable the traffic from mailman-bounces completely. If I haven't provided enough information, let me know and I'll do my best to get it for you. Thanks in advance. -- Rusty Newton

2 1

accept_these_nonmembers and Reg Expression
by Franck Aerts May 24, 2016

May 24, 2016

Hello everyone, I am sorry to bother you with this question, but even though the question has been asked on this list and a answer has been gaven, it doesn’t work for me. I want any email coming from a particular domain to be accepted without moderation. I added a regular expression to accept_these_nonmembers which goes : ^…(a)domain\.com$ and ^.*(a)asana\.com$ but with no success : the emails are still moderated. Is there an option I should change somewhere that overrule the settings in « accept_these_nonmembers » ?? The reason i want to have to accept any email from that domain is that the « user » part of the email is a token that changes all the time. Thanks in advance, Franck

2 1

Pending subscription request weirdness
by Sebastian Hagedorn May 22, 2016

May 22, 2016

Hi, I have a problem that looks like this FAQ, but I'm pretty sure it's not: <http://wiki.list.org/x/EoCE> There is only one Mailman instance in play, and I can actually see the subscription request in /var/lib/mailman/lists/LISTNAME/request.pck. I've been getting the email notification for a few days, but in the GUI there are "no pending requests". dumpdb shows this: dumpdb -p request.pck [----- start pickle file -----] <----- start object 1 -----> { 18: ( 2, ( 1463673214.732806, 'redacted(a)ukmuenster.de', u'Universit\xe4tsklinikum M\xfcnster', 'redacted', 0, 'de')), 'version': (0, 1)} [----- end pickle file -----] This is Mailman 2.1.18. Any ideas? Cheers Sebastian -- Sebastian Hagedorn - Weyertal 121, Zimmer 2.02 Regionales Rechenzentrum (RRZK) Universität zu Köln / Cologne University - Tel. +49-221-470-89578

2 3

mailman postfix connection on debian
by John Griessen May 21, 2016

May 21, 2016

I am setting up 2.1 on debian and get no receive of a mail to the server that is not a virtual_mailbox_domain address in postfix. For instance, a reply to a subscribe request doesn't get received or even mentioned much by the MTA logs in /var/log/mail.log, but a email to a virtual address, not local to the server, goes fine. There are so many uids and gids I can't figure it: This is ll /run/dovecot --> srw------- 1 root root 0 May 20 02:26 anvil srw------- 1 root root 0 May 20 02:26 anvil-auth-penalty srw------- 1 dovecot root 0 May 20 02:26 auth-client srw------- 1 dovecot root 0 May 20 02:26 auth-login srw------- 1 root root 0 May 20 02:26 auth-master -rw------- 1 root root 32 May 20 02:18 auth-token-secret.dat srw------- 1 vmail root 0 May 20 02:26 auth-userdb srw------- 1 dovecot root 0 May 20 02:26 auth-worker srw------- 1 root root 0 May 20 02:26 config srw------- 1 root root 0 May 20 02:26 dict srw------- 1 root root 0 May 20 02:26 director-admin srw-rw-rw- 1 root root 0 May 20 02:26 dns-client srw------- 1 root root 0 May 20 02:26 doveadm-server lrwxrwxrwx 1 root root 25 May 20 02:26 dovecot.conf -> /etc/dovecot/dovecot.conf drwxr-xr-x 2 root root 40 May 20 02:18 empty srw-rw-rw- 1 root root 0 May 20 02:26 imap-urlauth srw------- 1 dovecot root 0 May 20 02:26 imap-urlauth-worker srw-rw-rw- 1 root root 0 May 20 02:26 indexer srw------- 1 dovecot root 0 May 20 02:26 indexer-worker srw------- 1 root root 0 May 20 02:26 ipc ll /run/mailman/ rw-rw---- 1 list list 4 May 20 02:18 mailman.pid There's no telling what postfix is running as... I tried a simplifying test and it seems not simple enough: I wanted to send a test email, so I could see it in the logs: I have a list called catjuggling for testing things out. No users in it but me, no one to bother... $ sudo echo "test email" | /var/lib/mailman/mail/mailman post catjuggling Group mismatch error. Mailman expected the mail wrapper script to be executed as group "daemon", but the system's mail server executed the mail script as group "cibolo". Try tweaking the mail server to run the script as group "daemon", or re-run configure, providing the command line option `--with-mail-gid=cibolo'. If I su root I can send a message, and get a reponse from mailman that it is from no one, so needs approval, so that tests that mailmanis intalled somewhat, and postfix is the hangup. list and vmail are no login users, so can't test this that way... $ postconf -n -bash: postconf: command not found cibolo@mail1:/etc/dovecot$ sudo postconf -n alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no config_directory = /etc/postfix inet_interfaces = all mailbox_size_limit = 0 mydestination = cibolo.us, mail1.cibolo.us, localhost mydomain = cibolo.us myhostname = mail1 mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 myorigin = $mydomain readme_directory = no recipient_delimiter = + relayhost = smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/xxxxxxxxxxxxxxxxxxxxxxxxxx smtpd_tls_key_file = /etc/xxxxxxxxxxxxxxxxxxxxxxx smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache virtual_alias_maps = hash:/etc/postfix/virtual_aliases virtual_mailbox_domains = casaxxxxxxxxxx.com, casitaxxxxxxxxxxxx.com, etc.com virtual_mailbox_maps = hash:/etc/postfix/vmailboxes virtual_transport = lmtp:unix:private/dovecot-lmtp ====================mm_cfg.py changes=============== MTA='Postfix' # Default domain for email addresses of newly created MLs DEFAULT_EMAIL_HOST = 'cibolo.us' #------------------------------------------------------------- # Default host for web interface of newly created MLs DEFAULT_URL_HOST = 'mail1.cibolo.us' Thanks, John Griessen

2 7

mailman to inn gateway
by jdd May 21, 2016

May 21, 2016

Hello, I'm moving a server from openSUSE 13.1 to openSUSE Leap 42.1. Simply coping the config files do not get the expected result. It's probably something small, but I can't put my finger on it. list manager works fine with mailman + postfix. I use to have a news server (inn) as mail<>gateway and it worked my last notes said that mailman do all the job and is simple to configure. http://dodin.info/wiki/pmwiki.php?n=Doc.Mailman#toc13 but now it's chaotic. for the list "test", it works from list to news, but not the other way round for the list linux-31, no result for any way any hint? thanks jdd

2 4

FWD: [dmarc-ietf] Last Call: <draft-ietf-dmarc-interoperability-15.txt> (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC
by Stephen J. Turnbull May 21, 2016

May 21, 2016

Hi, all This IETF work affects us all, so I'm reposting here so those with the interest can participate. "Indirect mail flows" includes but is not limited to mailing lists. "DMARC" is the protocol which Yahoo! and AOL used to unsubscribe thousands of innocent list members in April 2014. This Internet Draft is about to be promoted to RFC, so this is really the last chance to get any changes made. (You can comment on a Request for Comments, but you'll never get one changed. :-) For our purposes, "interoperability" means best practices for both email providers and mailing list operators to avoid reoccurance of that "April Fool's Joke". If you haven't participated in IETF work before, you might want to run your comments by us (or me personally, if you prefer) before sending them off to the IESG. RFC-ese is not really English. ;-) I'll be happy to provide translation of portions of interest on request. My personal opinion is that the last draft I looked at (#12) was very good, but the more eyes the better. Reply-To set to mailman-users, but personal replies to me also welcome. Please don't reply-all. Also, there is no chance that DMARC "p=reject" itself is going away, so let's not rehash that issue. Standards-geek-ily y'rs, The IESG writes: > > The IESG has received a request from the Domain-based Message > Authentication, Reporting & Conformance WG (dmarc) to consider the > following document: > - 'Interoperability Issues Between DMARC and Indirect Email Flows' > <draft-ietf-dmarc-interoperability-15.txt> as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf(a)ietf.org mailing lists by 2016-06-03. Exceptionally, comments may be > sent to iesg(a)ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > DMARC introduces a mechanism for expressing domain-level policies and > preferences for email message validation, disposition, and reporting. > The DMARC mechanism can encounter interoperability issues when > messages do not flow directly from the author's administrative domain > to the final recipients. Collectively these email flows are referred > to as indirect email flows. This document describes interoperability > issues between DMARC and indirect email flows. Possible methods for > addressing interoperability issues are presented. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > dmarc mailing list > dmarc(a)ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >

1 0

Re: [Mailman-Users] Lost GNU Web mgmt interface after MAC OSX update
by Kevin Ross May 20, 2016

May 20, 2016

The url is : http://mail.vrcis.com/mailman/admindb/vip The response is: Not Found The requested URL /mailman/admindb/vip was not found on this server. Apache Server at mail.vrcis.com Port 80 The URL http://mail.vrcis.com Works fine, however Mailman logs are empty, /var/apache2 logs have the usual minimal stuff, no primary website, no webmail, this is just an OSX server running postfix, clamav and mailman. We can still execute commandline mailman commands, I have a feeeling its in the apache httpd conf possibly where the ./mailman/admindb/... is added ..? Thank Kevin -----Original Message----- From: Mailman-Users [mailto:mailman-users-bounces+kross=vrcis.com@python.org] On Behalf Of Mark Sapiro Sent: Friday, May 20, 2016 9:18 AM To: mailman-users(a)python.org Subject: Re: [Mailman-Users] Lost GNU Web mgmg interface after MAC OSX update On 05/20/2016 08:18 AM, Caulfield Kevin Ross wrote: > > Silly question, during a MAC OSX update we lost the ability to manage > our mailman GNU system using the http interface. What happens when you try to go to the Mailman web GUI? What is your web server? What is in it's logs? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list Mailman-Users(a)python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/kross%40vrcis.com ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7597 / Virus Database: 4568/12265 - Release Date: 05/20/16

2 1

Re: [Mailman-Users] turn on tracing?
by Mark Sapiro May 20, 2016

May 20, 2016

On 05/20/2016 12:04 PM, Richard Shetron wrote: > That only tells me about long running processes, not ones that start and > stop/die very quickly. There are programs that aren't starting due to > permission problems like qrunner. The qrunners are started by mailmanctl which shoud be started as root but then sets itself to the user:group that were configured with the configure options --with-username and --with-groupname. These default to 'mailman'. You can find the values in Defaults.py in the settings for MAILMAN_USER and MAILMAN_GROUP > The latest web page now says (which > doesn't tell me what the eid/gid were when the problem occured): The web server is a persistent process, it's user:group on Ubuntu are usually www_data, however, the web server invokes a CGI wrapper, e.g. /var/lib/mailman/cgi-bin/admin which should be SETGID and group = Mailman's group. > Bug in Mailman version 2.1.21rc2 > > We're sorry, we hit a bug! > > If you would like to help us identify the problem, please email a copy > of this page to the webmaster for this site with a description of what > happened. Thanks! > Traceback: > > Traceback (most recent call last): > File "/var/lib/mailman/scripts/driver", line 86, in run_main > immediate=1) > File "/var/lib/mailman/Mailman/Logging/StampedLogger.py", line 52, in > __init__ > Logger.__init__(self, category, nofail, immediate) > File "/var/lib/mailman/Mailman/Logging/Logger.py", line 50, in __init__ > self.__get_f() > File "/var/lib/mailman/Mailman/Logging/Logger.py", line 68, in __get_f > 1) > File "/usr/lib/python2.7/codecs.py", line 878, in open > file = __builtin__.open(filename, mode, buffering) > IOError: [Errno 13] Permission denied: '/var/lib/mailman/logs/error' This is a secondary error because of the inability to write the real error to the error log. Is the error log writable by Mailman's group? Is there something like apparmor preventing access? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Re: [Mailman-Users] turn on tracing?
by Richard Shetron May 20, 2016

May 20, 2016

How do I find out what uid:gid the programs are running with? Would I be better downloading a fresh copy of mailman and doing a reinstall over the broken copy? The initial version was installed back in ubuntu 8.04 days when mailman wasn't a ubuntu package. Since then for Ubuntu they changed some of the default groups for things, like mailing lists. On 5/20/2016 11:47 AM, Mark Sapiro wrote: > On 05/20/2016 05:35 AM, Richard Shetron wrote: >> How do I turn on tracing to find the source of this error. The >> interface worked until I told check_perms to fix permissions so I'm sure >> there is a permission issue. Also the qrunner won't run, which I also >> suspect is a permission error. My partner who did the install has >> retired for medical reasons so I'm trying to learn how to do all sorts >> of things in too little time :( I tried to look in both the mailman >> logs and the apache logs for errors and didn't find anything. >> >> Bug in Mailman version 2.1.21rc2 >> >> We're sorry, we hit a bug! > > > There should be a traceback and other information about this error in > Mailman's error log. If it's not there, there is probably a permission > issue in writing the log. > > You can at least temporarily ensure that Mailman's logs are writable by > anyone and see if that helps. > > Also, you can edit $prefix/scripts/driver and at line 33 set > > STEALTH_MODE = 0 > > and the traceback will be included on the "we hit a bug" page. > > Also, if check_perms -f broke things, permissions must have been set in > some non-standard way to begin with. See the FAQ article at > <https://wiki.list.org/x/4030645>. >

2 1