Mailman 3 October 2008 - Mailman-Users

Re: [Mailman-Users] Mailman on multiple domains
by Scott Race 01 Nov '08

01 Nov '08

As a follow-up, I don't seem to have the virtual-mailman file on my server anywhere as stated in the documentation.... ________________________________ From: Scott Race Sent: Tuesday, October 28, 2008 1:18 PM To: mailman-users(a)python.org Subject: Mailman on multiple domains I have Postfix and Mailman running on a RHLE server. Mailman and Postfix work fine for a single domain setup. I have now setup my postfix configuration setup to accept mail for multiple domains. I did so editing main.cf to include the new domain I want to receive mail for, created a local user account for the user, and created a virtual_alias_maps file which tells the email to the second domain to forward to the new user account I setup. So I have mailman running on a new VirtualHost, I can create a list from the web interface, I can join lists and all emails from the system look ok (having the second domain name). When posting, I get the following: Your message did not reach some or all of the intended recipients. Subject: Test Post Sent: 10/28/2008 1:11 PM The following recipient(s) could not be reached: Scott-test-request(a)second-domain.org on 10/28/2008 1:11 PM You do not have permission to send to this recipient. For assistance, contact your system administrator. MSEXCH:MSExchangeIS:/DC=local/DC=jda:SERVER This must have something to do with my virtual_alias_maps file, which currently has nothing in it except a map from the second domain to a local user (which I just did as a test). I'm sure I'm missing something here? Thanks Scott

3 15

Mailman receives posts but no sent them
by NetBiker 31 Oct '08

31 Oct '08

Hello, I've enabled mailing lists with Mailman 2.1.2 and Postfix in a Mac OS X Server 10.3.9 I've the following errors when a subscribed user sent a post to the list: logs/smtp Oct 30 16:52:39 2008 (378) All recipients refused: (7, 'No address associated with nodename') Oct 30 16:52:39 2008 (378) All recipients refused: (7, 'No address associated with nodename') Oct 30 16:52:39 2008 (378) <Pine.LNX.4.64.0810301651440.26490(a)server.dom.ain.one> smtp for 3 recips, completed in 0.059 seconds logs/logs Oct 30 16:52:39 2008 (378) post to prueba from user(a)dom.ain.one, size=2374, message-id=<Pine.LNX.4.64.0810301651440.26490(a)server.dom.ain.one>, 3 failures the list prueba has three subscribers the same problem occurs with other messages in the list logs/smtp Oct 30 16:38:38 2008 (378) All recipients refused: (7, 'No address associated with nodename') Oct 30 16:38:38 2008 (378) <mailman.5.1225229913.12728.prueba(a)dom.ain> smtp for 1 recips, completed in 0.033 seconds logs/post Oct 30 16:38:38 2008 (378) post to prueba from mailman-bounces(a)dom.ain, size=605, message-id=<mailman.5.1225229913.12728.prueba(a)dom.ain>, 1 failures No messages or posts were sent since the list was created but in the list archives we can see all the posts Postfix is working fine with messages for the dom.ain domain in the same Mac OS X server we only added in the mm_cfg.py file: DEFAULT_EMAIL_HOST = 'dom.ain' DEFAULT_URL_HOST = 'lists.dom.ain' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) thank you very much

3 2

Processing missed digests...
by John Gray 31 Oct '08

31 Oct '08

the box had been running our mailman set up died. No problem, I had another box ready to take its place. But the mailman cron jobs didn't run for about a week. Is there a way for get senddigets to send out the digests for the missing days? Or did senddigest send everything since the last digest? Thanks, John

2 1

deletion reason in email template
by Fil 31 Oct '08

31 Oct '08

Hello, is there a possibility to add, in the email template sent to the list owner when someone is deleted, the REASON (BYBOUNCE etc) ? -- Fil

2 1

Seeking qfiles/shunt recovery advice.
by TGPlatt, WebMaster 31 Oct '08

31 Oct '08

Now that my archiver is working again, I have several files in qfiles/shunt that I'd like to recover and convince mailman to insert into my (now working) October archive. If it's possible to do so, I also have a few shunted files from the end of September that I'd like to recover and have included in the September archive as well. Under the circumstances, I'd rather not attack this using a trial and error process. Can anyone point me to a post that explains how to retrieve and recover pck files from the qfiles/shunt directory and convince ARCHrunner to try processing them again? Thanks!

2 3

Re: [Mailman-Users] What happened to my archive? Why isn't the archive process running?
by Mark Sapiro 31 Oct '08

31 Oct '08

TGPlatt, WebMaster wrote: > >Could this be a group/owner-ship issue? Yes. It took me a while, but I finally connected you with our exchanges from last June/July :) >It hadn't occurred to me to look for mailman's error log. Plus I had no idea >where it was. I've seen it mentioned but I'd seen nothing in the docs that >said where to find it. But with a bit of looking, I found it in >/usr/local/mailman/logs/error > > > >The error log that was saved when we made our final September 28 backup on >the old server was last updated 9/25. The more I look the more this looks >like an ownership issue to me. It may be I screwed up somewhere back in >July. In our current mailman directory structure a smattering of files >throughout the mailman directory tree seem to be owned by root / mailman >now; whereas in the old backup everything seems to have been owned by >mailman / mailman or www-data (Debian's default Apache user) / mailman. On >9/28, the error log was owned by mailman / mailman. Indeed everything except >mischief, subscribed and vet were owned by mailman / mailman back then. >Those three files were different and were owned by "www-data" / mailman. >Today in our running copy of mailman, all logs are owned by mailman/mailman >except error which is owned by root / mailman and mischief, vet and >subscribed which are owned by www-data / mailman. There were undoubtedly problems on the old server because of SUExec issues which I told you at the time was incompatible with Mailman's security model since Mailman's CGI wrappers can't be SETGID under SUExec and that's the whole point of the wrappers in the first place. So ownership and permissions within Mailman have to be such that the SUExec user can read and write. But the qrunner processes also have to be able to read and write and they will run as the mailman user:group. Normally the owner doesn't matter because everything runs as group mailman, but that may not be the case here. >The reason I think this is an ownership issue is because when I look at the >July - September error log I see lots of errors like this: > > > >Jul 09 07:29:22 2008 (10592) Archive file access failure: > > /usr/local/mailman/archives/private/ourlist.mbox/ourlist.mbox [Errno >13] Permission denied: >'/usr/local/mailman/archives/private/ourlist.mbox/ourlist.mbox' > >Jul 09 07:29:22 2008 (10592) Uncaught runner exception: [Errno 13] >Permission denied: '/usr/local/mailman/archives/private/ourlist > >.mbox/ourlist.mbox' > > > >.and when I check the files in that directory, they're owned by root as a >member of the group mailman. That should be OK because ArchRunner should be running as group mailman and the files shoud be group writable. <snip> > >Sep 25 21:09:31 2008 (16599) SHUNTING: >1222394969.723012+6122e5f84bb97875a24698a159961936bed8802b > > > >Sadly, when I look at the qfiles/shunt directory in the 9/28 backup, the >oldest file there seems to be from 09-20-2008. So it looks to me like it was >only keeping those shunt files 5 or 6 days before discarding them. If you are running Mailman 2.1.11, there is a cron that runs daily and by default it discards anything in qfiles/bad and qfiles/shunt older than 7 days. From Defaults.py # The length of time after which a qfiles/bad or qfiles/shunt file is # considered to be stale. Set to zero to disable culling of qfiles/bad and # qfiles/shunt entries. BAD_SHUNT_STALE_AFTER = days(7) # The pathname of a directory (searchable and writable by the Mailman cron # user) to which the culled qfiles/bad and qfiles/shunt entries will be # moved. Set to None to simply delete the culled entries. BAD_SHUNT_ARCHIVE_DIRECTORY = None >Here are the first and last error in the current error file: > > > >Oct 18 10:43:54 2008 mailmanctl(25124): Site list is missing: mailman > >Oct 18 10:43:54 2008 (25124) Site list is missing: mailman > >Oct 18 18:38:42 2008 (14433) admin.py access for non-existent list: ourlist > >Oct 18 18:39:34 2008 (14458) admin.py access for non-existent list: ourlist > >Oct 18 20:34:08 2008 (19034) admin.py access for non-existent list: ourlist > >Oct 20 08:58:31 2008 (9822) admin.py access for non-existent list: ourlist > >Oct 21 22:33:46 2008 (1431) Uncaught runner exception: [Errno 13] Permission >den > >ied: '/usr/local/mailman/archives/private/ourlist/index.html' > >Oct 21 22:33:46 2008 (1431) Traceback (most recent call last): > > File "/usr/local/mailman/Mailman/Queue/Runner.py", line 120, in _oneloop > > self._onefile(msg, msgdata) > > > >... > > > >Oct 28 10:09:30 2008 (2589) Uncaught runner exception: [Errno 13] Permission >den > >ied: '/usr/local/mailman/archives/private/ourlist/index.html' > >Oct 28 10:09:30 2008 (2589) Traceback (most recent call last): > > File "/usr/local/mailman/Mailman/Queue/Runner.py", line 120, in _oneloop > > self._onefile(msg, msgdata) > > File "/usr/local/mailman/Mailman/Queue/Runner.py", line 191, in _onefile > > keepqueued = self._dispose(mlist, msg, msgdata) > > File "/usr/local/mailman/Mailman/Queue/ArchRunner.py", line 73, in >_dispose > > mlist.ArchiveMail(msg) > > File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 217, in >ArchiveMa > >il > > h.close() > > File "/usr/local/mailman/Mailman/Archiver/pipermail.py", line 324, in >close > > self.write_TOC() > > File "/usr/local/mailman/Mailman/Archiver/HyperArch.py", line 1097, in >write_T > >OC > > toc = open(os.path.join(self.basedir, 'index.html'), 'w') > >IOError: [Errno 13] Permission denied: >'/usr/local/mailman/archives/private/ourlist/index.html' > > > >Oct 28 10:09:30 2008 (2589) SHUNTING: >1225213769.6014299+1a6c02d7003773ec8b731f9 > >23e4d1e0eb795d0b5 So you still have permissions issues. You could start with bin/check_perms which should get them right except if the web server is still SUExec, the web interface may not work. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 11

Hurray! My archive works again... User warning for check_perms!
by TGPlatt, WebMaster 31 Oct '08

31 Oct '08

I'm pleased to report my mailman archive update process is working again. As it turned out, what was keeping the feature from working was ownership and/or permissions on files in /usr/mailman/archives/private/[LISTNAME] and /usr/mailman/archives/private/[LISTNAME]/database directories. Somehow, (I'm not sure how) many -- but not all -- files in those directories were owned by root rather than by mailman and many of them also had permissions of 644 (rw-r--r--) RATHER than 664 (rw-rw-r--). That has been corrected now and ALL files in the mailman directory structure are now owned by mailman PLUS the permissions on virtually all data files are 664 and not 644. This issue apparently goes back to when mailman was first laid down on our old server in the early summer; because a check of the last backup taken from the old server at the end of September shows ALL files in those directories were owned by root and not by mailman. That was CLEARLY caused by some error I made when installing and setting up mailman. I added, the "User warning for check_perms" because although the perms shown on that final old-server backup were 664 for all mailman files in /usr/mailman/archives/private/mylist directory and 660 for all files in /usr/mailman/archives/private/mylist/database and check_perms reported "No Problems Found", check_perms was flat wrong about that. The ownership on ALL those files was wrong but check_perms failed to detect and report that issue. This issue has been reported and should soon be fixed. But in the meantime be cautions about putting too much faith in check_perms in mailman v2.1.11. The data files in those directories must ALL be owned by mailman. In our case they were owned by ROOT! That prevented mailman's ARCHrunner from updating the archive and produced the same errors every day for almost 3 months when mailman tried to update the archive. The errors were recorded each day in the mailman error log (/usr/local/mailman/logs/error); but I never checked the error log! Duhhh! Also, because of those errors the archives were not updated for 3 months and mailman's automatic cleanup process was systematically discarding ALL new posts that hadn't been updated after 7 days. Sadly, neither I nor anyone else was checking the archive either. Double Duhhh!! So, in the end we lost 3 months worth of archive updates. The lessons here are: 1. Just because check_perms reports "No Problems Found", don't assume everything is set right or working correctly. CHECK THE ERROR LOG and CHECK THE ARCHIVES! Then, DOUBLE-CHECK both the file and directory permissions and OWNERSHIPs in the archive directories for each of your mailman lists. There is a post in the archives that briefly explains exactly what permissions should be for both files and directories. You'll find that post here: <http://mail.python.org/pipermail/mailman-users/2008-October/063748.html>. 2. If you don't understand why your list's permissions and ownerships are set the way they are, keep asking questions until you DO understand. Otherwise you may wake up one day as I did and need to explain to your client why 3 months of their conversations have unexpectedly gone missing. :-( A word to the wise.

2 1

Postfix, Mailman, and postfix-to-mailman.py trouble
by Craig Stacey 30 Oct '08

30 Oct '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've searched the archives on this, and haven't come up with a solution, any tips would be appreciated. I'll begin by describing our setup. We run a number of virtual domains on our mailman server. In each case, we run a separate instance of mailman for each domain. The handoff from postfix to mailman is done via postfix-to-mailman.py. It doesn't *feel* like that is relevant to the problem, but in case it is, here are the relevant bits from master.cf and transport: master.cf: mailmancom unix - n n - - pipe flags=FR user=list argv=/www/lists.example.com/bin/postfix-to- mailman.py ${nexthop} ${user} mailmanorg unix - n n - - pipe flags=FR user=list argv=/www/lists.example.org/bin/postfix-to- mailman.py ${nexthop} ${user} mailmannet unix - n n - - pipe flags=FR user=list argv=/www/lists.example.net/bin/postfix-to- mailman.py ${nexthop} ${user} transport: lists.example.com mailmancom: lists.example.org mailmanorg: lists.example.net mailmannet: I'm explaining it this way to lay out why we're running things through the postfix-to-mailman.py script instead of the traditional method. In the above domains, there are numerous duplication of listnames, and this seemed the best path to resolution. I realize postfix-to- mailman.py is not official (or supported), but I'm wondering if anyone else has come across this issue. Now, here's the behavior we observe. If a is sent to multiple lists in a domain, only the first list (alphabetically) will see it. This includes when multiple lists within the same domain are defined in the To: line, or in an umbrella list situation where the member lists live in the same domain. When looking at the logfiles, we can see the messages go in multiple times, but only spit out once on the other side. An example: /var/log/mail.info: Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2: to=<core-other(a)lists.example.com >, relay=mailmancom, delay=0, status=sent (lists.example.com) Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2: to=<core-staff(a)lists.example.com >, relay=mailmancom, delay=0, status=sent (lists.example.com) Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2: to=<core-students(a)lists.example.com >, relay=mailmancom, delay=0, status=sent (lists.example.com) Then, from /www/lists.example.com/logs/smtp, we see only one come out the other side: Oct 27 14:39:23 2008 (2652) <B99088C8-7429-4FBA-ADE8-56E6DCF03ABD(a)stace.com > smtp to core-other for 2 recips, completed in 0.013 seconds Three messages go in, one comes out the other end. I did some logging, and found that postfix-to-mailman.py is only processing *one* message. The script gets the listname from this line: local = sys.argv[2] All the docs specify you should put this line in main.cf: mailman_destination_recipient_limit = 1 I can find no documentation on that particular config, but it seems like it's telling postfix to only put one recipient per message when sending to mailman, which would jibe with what the variable setting in the above script is looking for. However, it looks like that setting is totally being ignored by our postfix install. If I type "postconf", I do *not* see "mailman_destination_recipient_limit" listed in the output. That seems to me to indicate to me that it's not being honored. Am I off base here? Has anyone run into this before? We're running the unbuntu 6.06 version of postfix (2.2.10-1ubuntu), and all of the mailman instances are installed from source due to our above virtual list setup. Any help on this unsupported config is greatly appreciated. :) == Craig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkI+JMACgkQbVNGA3HOzQsa9gCfd31Wn7QqX5z8ns+QT2/mQ6DS eTwAoIFuYkCzj8kRlsVmzOPWbE0zLGFp =1PrD -----END PGP SIGNATURE-----

2 3

mailman archiver not archiving
by James Chapman 30 Oct '08

30 Oct '08

I've set up postfix / dovecot / mailman on my server and it works well, except that no messages to mailman lists are archived. The server hosts several domains, though mailman serves only one of the domains. Mail is delivered to mailing list subscribers as expected, but the messages are never added to the mbox archive file. Mailman logs show no errors. I'm using Fedora 9, mailman 2.1.9, python 2.5.1, postfix 2.5.1, all installed from standard f9 RPMs. Archiving is enabled. The aliases for the mailman lists are set up correctly. Regular users have mail delivered in Maildir format. Does this affect mailman? Any suggestions for things to check? Thanks! /james

2 2

Changing a user's email address
by Dennis Putnam 29 Oct '08

29 Oct '08

Suppose I have a user that changes his email address and I don't want to wait for that user to confirm the address change? How do I change the address of any user simply as the list admin with no involvement of the list member? Thanks.

2 1