![](https://secure.gravatar.com/avatar/0df724a41a9440aea36563edd8738763.jpg?s=120&d=mm&r=g)
Although I have a few years of experience as a list administrator of lists hosted on other sites, so far I never managed a mailman server on my own. In our institute we manage small list via /etc/aliases :include:s
Recently I decided to make an experiment, so I installed mailman 2.1.11 via the suse 11.3 distribution on my machine. I read carefully the PDF "GNU Mailman Installation Manual release 2.1" by Barry Warsaw, and other stuff on the wiki, including those concerning sendmail (we are a sendmail site).
I say "experiment" since I am testing it on my personal machine, although the target system will be one of the institute servers (in process of being upgraded). I thought to gain experience first in a simpler arrangement.
I followed the manual except that at step 6 (6.3) I followed http://wiki.list.org/display/DOC/Integrating+Mailman+with+Sendmail+-+Method+... and related links.
The suse installation via yast2 installs mailman partly in /usr/lib/mailman, partly in /var/lib/mailman/ (and also /usr/share/man/man8 and /usr/share/doc/packages/mailman/), it also creates the user and group.
It does not provide any automatic configuration for apache, so I did it manually (I actually like this better). I had to place in default-server.conf also this block
<Directory "/usr/lib/mailman/cgi-bin"> AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all </Directory>
in order to be able to execute the CGIs.
I note that the startup script /etc/init.d/mailman gives a message "Starting mailman (Warning: the Apache2 webinterface for Mailman has not been activated!)" which seems to imply a flag missing in line APACHE_SERVER_FLAGS in /etc/sysconfig/apache2, but I have no documentation for it, and it seems that the site can be accessed ok
(QUESTION 1) Any Suse user can confirm this is unnecessary ?
Concerning sendmail, I followed the "method 2" (WITHOUT mm_handler) because it seems to apply better to our institute arrangements. So I have a sudo wrapper script with the two lines
/bin/cp /var/lib/mailman/data/aliases /etc/mail/mailman.aliases
/usr/bin/newaliases
a sendmail.cf with O AliasFile=/etc/mail/aliases,/etc/mail/mailman.aliases
and the fake arrangement in mm_cfg.py
MTA='Postfix'
POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/sbin/mailman.aliases'
POSTFIX_STYLE_VIRTUAL_DOMAINS = []
I have verified the command /usr/lib/mailman/bin/genaliases works and touches the right files.
I have also run "/usr/lib/mailman/bin/newlist mailman" to create the top list and it works (it said to have sent a mail, but actually it was just queued, and it was sent as soon as I started the qrunner from /etc/init.d
I set my own e-mail as list owner, and set a password (incidentally the same test password used by /usr/lib/mailman/bin/mmsitepass)
(QUESTION 2) I hope the fact I always use the same test password is not a problem
At this point I entered the admin web page of such a list (for which I received the "Your new mailing list" message). It seems I can browse it OK.
Then I wanted to subscribe myself to the list.
If I do it via the Membership Management -> Mass Subscription, and I enter my e-mail address in the form, I get no errors but nothing happens.
If I try to subscribe via the mailman/listinfo/mailman page, I get instead an error "you must supply a valid e-mail address"
(QUESTION 3) Why does that happen ? see also question 4
I tried also to create a new mailing list via the web interface (this requires supplying the site password as well)
this gives me instead an error "Unknown virtual host: sax.iasf-milano.inaf.it "
(QUESTION 4)
This may have to do with our institute standard arrangement, and will apply also to the real arrangement on our target server. Unfortunately I cannot find the documentation for the keywords in mm_cfg.py so I am not sure what shall be tuned.
This is the content of mm_cfg.py. The first 9-10 lines were added automatically by the suse yast installation, the rest was edited/added by me to suite our apache config and the "sendmail method 2"
DEFAULT_URL_PATTERN = 'http://%s/mailman/' DEFAULT_NNTP_HOST = 'poseidon.lambrate.inaf.it' DEFAULT_EMAIL_HOST = 'poseidon.lambrate.inaf.it' DEFAULT_URL_HOST = 'poseidon.lambrate.inaf.it' MTA = 'Postfix' DELIVERY_MODULE = 'SMTPDirect' SMTPHOST = 'localhost' SMTPPORT = '25' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) #IMAGE_LOGOS = '/mailmanicons/' IMAGE_LOGOS = '/icons/' # changed lines above manually # inserted this stuff for sendmail POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/sbin/mailman.aliases'
I have to explain our configuration:
we have two domains. lambrate.inaf.it is the one where all A and PTR records are, and also a number of CNAMEs for various services.
iasf-milano.inaf.it is a more formal domain alias, which contains just CNAMEs for the main services visible from outside
poseidon(.lambrate.inaf.it) is my machine FQDN
sax.iasf-milano.inaf.it is the CNAME for the web server on it. It is also the ServerName in default-server.conf (so one can get to the server as sax or poseidon or localhost but is shown just that)
This will apply not only to my test configuration, but also to the target configuration (the institute web server will be www.iasf-milano.inaf.it, which is a CNAME for a server [let us say server3] ... actually that server runs different virtual servers)
all our e-mail address are FULLY MASQUERADED, i.e. they are of the form "user@lambrate.inaf.it" or "user@iasf-milano.inaf.it" (our MXs accept both in entrance, and each user selects which form to use on exit).
The message from mailman when I created the initial list did have From: mailman-owner@lambrate.inaf.it (obviously masqueraded by sendmail)
It did contain URLs like http://poseidon.lambrate.inaf.it (reachable but translated as sax.iasf-milano.inaf.it)
It did contain e-mail like mailman-request@poseidon.lambrate.inaf.it (so far I haven't tested them)
I am not sure how much of the above applies to QUESTION 4 (i.e. to run on my local machine)
(QUESTION 5) The arrangement on the target system will be more complicated.
As I said the www server is "server3", but the MX servers are instead "server1" and "server2". They are also NIS master and slave server, and all our e-mail aliases are NIS aliases (so
I am not expecting a solution to question 5 now, I guess that if I can have a running solution on my local machine, and an understanding of the inner working of mailman, some creative user of crontab scripts or NFS mounts could make the mailman aliases available to all NIS clients and visible to the outside world.
But any hint will be gratefully acknowledged.
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Lucio Chiappetti wrote:
Recently I decided to make an experiment, so I installed mailman 2.1.11 via the suse 11.3 distribution on my machine. I read carefully the PDF "GNU Mailman Installation Manual release 2.1" by Barry Warsaw, and other stuff on the wiki, including those concerning sendmail (we are a sendmail site).
When you install a downstream packaged Mailman, it is best to refer first to any documentation the packager provides. The installation manual may be largely relevant, but there may be conflicts due to packager changes.
I say "experiment" since I am testing it on my personal machine, although the target system will be one of the institute servers (in process of being upgraded). I thought to gain experience first in a simpler arrangement.
I followed the manual except that at step 6 (6.3) I followed http://wiki.list.org/display/DOC/Integrating+Mailman+with+Sendmail+-+Method+... and related links.
The suse installation via yast2 installs mailman partly in /usr/lib/mailman, partly in /var/lib/mailman/ (and also /usr/share/man/man8 and /usr/share/doc/packages/mailman/), it also creates the user and group.
It does not provide any automatic configuration for apache, so I did it manually (I actually like this better). I had to place in default-server.conf also this block
<Directory "/usr/lib/mailman/cgi-bin"> AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all </Directory>
in order to be able to execute the CGIs.
I note that the startup script /etc/init.d/mailman gives a message "Starting mailman (Warning: the Apache2 webinterface for Mailman has not been activated!)" which seems to imply a flag missing in line APACHE_SERVER_FLAGS in /etc/sysconfig/apache2, but I have no documentation for it, and it seems that the site can be accessed ok
(QUESTION 1) Any Suse user can confirm this is unnecessary ?
I'm not a Suse user, but see <http://mail.python.org/pipermail/mailman-users/2011-March/071310.html>.
Concerning sendmail, I followed the "method 2" (WITHOUT mm_handler) because it seems to apply better to our institute arrangements. So I have a sudo wrapper script with the two lines
/bin/cp /var/lib/mailman/data/aliases /etc/mail/mailman.aliases /usr/bin/newaliases
a sendmail.cf with O AliasFile=/etc/mail/aliases,/etc/mail/mailman.aliases
and the fake arrangement in mm_cfg.py
MTA='Postfix' POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/sbin/mailman.aliases' POSTFIX_STYLE_VIRTUAL_DOMAINS = []
I have verified the command /usr/lib/mailman/bin/genaliases works and touches the right files.
I have also run "/usr/lib/mailman/bin/newlist mailman" to create the top list and it works (it said to have sent a mail, but actually it was just queued, and it was sent as soon as I started the qrunner from /etc/init.d
So all this seems to be working.
I set my own e-mail as list owner, and set a password (incidentally the same test password used by /usr/lib/mailman/bin/mmsitepass)
(QUESTION 2) I hope the fact I always use the same test password is not a problem
It's not a problem for Mailman, but it is possible that in some cases if say the list admin and site passwords are the same, your authentication context will be that of the list admin rather than the site admin, but unless you have ALLOW_SITE_ADMIN_COOKIES = Yes in mm_cfg.py, this probably doesn't matter.
At this point I entered the admin web page of such a list (for which I received the "Your new mailing list" message). It seems I can browse it OK.
Then I wanted to subscribe myself to the list.
If I do it via the Membership Management -> Mass Subscription, and I enter my e-mail address in the form, I get no errors but nothing happens.
If I try to subscribe via the mailman/listinfo/mailman page, I get instead an error "you must supply a valid e-mail address"
(QUESTION 3) Why does that happen ? see also question 4
See the FAQ at <http://wiki.list.org/x/ioA9>. That may help. Usually this occurs because of some http redirect that loses the POST data from the form.
I tried also to create a new mailing list via the web interface (this requires supplying the site password as well)
this gives me instead an error "Unknown virtual host: sax.iasf-milano.inaf.it "
You are accessing the create CGI via a URL with host sax.iasf-milano.inaf.it, but the only host known to Mailman is poseidon.lambrate.inaf.it.
(QUESTION 4)
This may have to do with our institute standard arrangement, and will apply also to the real arrangement on our target server. Unfortunately I cannot find the documentation for the keywords in mm_cfg.py so I am not sure what shall be tuned.
This is the content of mm_cfg.py. The first 9-10 lines were added automatically by the suse yast installation, the rest was edited/added by me to suite our apache config and the "sendmail method 2"
DEFAULT_URL_PATTERN = 'http://%s/mailman/' DEFAULT_NNTP_HOST = 'poseidon.lambrate.inaf.it' DEFAULT_EMAIL_HOST = 'poseidon.lambrate.inaf.it' DEFAULT_URL_HOST = 'poseidon.lambrate.inaf.it' MTA = 'Postfix' DELIVERY_MODULE = 'SMTPDirect' SMTPHOST = 'localhost' SMTPPORT = '25' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) #IMAGE_LOGOS = '/mailmanicons/' IMAGE_LOGOS = '/icons/' # changed lines above manually # inserted this stuff for sendmail POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/sbin/mailman.aliases'
I have to explain our configuration:
we have two domains. lambrate.inaf.it is the one where all A and PTR records are, and also a number of CNAMEs for various services.
iasf-milano.inaf.it is a more formal domain alias, which contains just CNAMEs for the main services visible from outside
poseidon(.lambrate.inaf.it) is my machine FQDN
sax.iasf-milano.inaf.it is the CNAME for the web server on it. It is also the ServerName in default-server.conf (so one can get to the server as sax or poseidon or localhost but is shown just that)
This will apply not only to my test configuration, but also to the target configuration (the institute web server will be www.iasf-milano.inaf.it, which is a CNAME for a server [let us say server3] ... actually that server runs different virtual servers)
all our e-mail address are FULLY MASQUERADED, i.e. they are of the form "user@lambrate.inaf.it" or "user@iasf-milano.inaf.it" (our MXs accept both in entrance, and each user selects which form to use on exit).
The message from mailman when I created the initial list did have From: mailman-owner@lambrate.inaf.it (obviously masqueraded by sendmail)
It did contain URLs like http://poseidon.lambrate.inaf.it (reachable but translated as sax.iasf-milano.inaf.it)
It did contain e-mail like mailman-request@poseidon.lambrate.inaf.it (so far I haven't tested them)
I am not sure how much of the above applies to QUESTION 4 (i.e. to run on my local machine)
Every list has an email domain and a web domain. You need to decide what these should be. I.e. for any particular list, what host/doman name should be in URLs for that list and what domain should be in the enail addresses for that list. The most common or only ones should be set as the value of DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST. If there are others, they should be in additional add_virtualhost directives in mm_cfg.py, e.g.
add_virtualhost('sax.iasf-milano.inaf.it', 'iasf-milano.inaf.it')
See FAQs at <http://wiki.list.org/x/8YA9>, <http://wiki.list.org/x/lYA9> and <http://wiki.list.org/x/mIA9> and perhaps others.
(QUESTION 5) The arrangement on the target system will be more complicated.
As I said the www server is "server3", but the MX servers are instead "server1" and "server2". They are also NIS master and slave server, and all our e-mail aliases are NIS aliases (so
I am not expecting a solution to question 5 now, I guess that if I can have a running solution on my local machine, and an understanding of the inner working of mailman, some creative user of crontab scripts or NFS mounts could make the mailman aliases available to all NIS clients and visible to the outside world.
But any hint will be gratefully acknowledged.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/0df724a41a9440aea36563edd8738763.jpg?s=120&d=mm&r=g)
Please advise if preferred policy on this list is reply to all or reply to list, and excuse if I did wrong.
On Tue, 29 Mar 2011, Mark Sapiro wrote:
Lucio Chiappetti wrote:
Recently I decided to make an experiment, so I installed mailman 2.1.11 via the suse 11.3 distribution on my machine.
When you install a downstream packaged Mailman, it is best to refer first to any documentation the packager provides.
yes thanks, that will be file /usr/share/doc/packages/mailman/README.SuSE (somewhat hidden and unannounced, but it is there)
APACHE_SERVER_FLAGS in /etc/sysconfig/apache2, but I have no documentation for it, and it seems that the site can be accessed ok
(QUESTION 1) Any Suse user can confirm this is unnecessary ?
De facto I found out that this flag is documented in README.SuSE. A command a2enflag (NOT applied during yast installation) applies all necessary changes to apache .conf files. They are equivalent to what I did, but simpler to use. So I reset things and did it, and will recommend that for our final installation.
--> question 1 solved
Concerning sendmail, I followed the "method 2" (WITHOUT mm_handler)
So all this seems to be working.
yes. After I posted to mailman-users I also verified that creation of another list, adding members, removing members or lists via the linemode commands in mailman/bin also do work
problems below appl(ied) only to the web interface
(QUESTION 2) I hope the fact I always use the same test password is not a problem
unless you have ALLOW_SITE_ADMIN_COOKIES = Yes in mm_cfg.py, this probably doesn't matter.
thanks
At this point I entered the admin web page of such a list [...] If I try to subscribe via the mailman/listinfo/mailman page, I get instead an error "you must supply a valid e-mail address"
(QUESTION 3) Why does that happen ? see also question 4
(QUESTION 4)
I tried also to create a new mailing list via the web interface (this requires supplying the site password as well)
this gives me instead an error "Unknown virtual host: sax.iasf-milano.inaf.it "
You are accessing the create CGI via a URL with host sax.iasf-milano.inaf.it, but the only host known to Mailman is poseidon.lambrate.inaf.it.
I have read the FAQ entries. I changed mm_cfg.py first from
DEFAULT_EMAIL_HOST = 'poseidon.lambrate.inaf.it' DEFAULT_URL_HOST = 'poseidon.lambrate.inaf.it'
to
DEFAULT_URL_HOST = 'sax.iasf-milano.inaf.it' DEFAULT_EMAIL_HOST = 'lambrate.inaf.it'
and ran bin/withlist -l -a -r fix_url
and finally to
DEFAULT_URL_HOST = 'sax.iasf-milano.inaf.it' DEFAULT_EMAIL_HOST = 'poseidon.lambrate.inaf.it'
and did the same.
The first case (sax/lambrate) is similar to what we wish on the target system (a web server name, and the domain name as mail host)
The second case (sax/poseidon) is necessary in the test arrangement to create valid e-mail addresses.
Both *mostly* work (if I use a list@poseidon type address for posting) in the sense that the web interface works (so URL_HOST is what solves questions 3 and 4.
I still have some problems when subscribing a new user, and concerning message archiving. I will post a separate request for clarity.
(QUESTION 5) The arrangement on the target system will be more complicated.
because our aliases are mantained on the NIS master server. The master and slave servers are also the domain main and backup MX.
However the web server is on a third machine. A configuration like the one I use on my test machine (local sendmail aliases inherited from local mailman aliases, which "pipe" into local mailman executables) is likely to work there ...
... but we'd have to expose somehow this machine name in the e-mail address (we currently mask all behind the domain) or replicate all mailman aliases in the NIS maps as
xxxxx: xxxxx@mailmanhost
but I do understand we cannot use a CNAME for mailmanhost ?
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
L'Italia ripudia la guerra [...] Italy repudiates war [...] come mezzo di risoluzione delle as a way of resolution of controversie internazionali ? international controversies ? [Art. 11 Constitution of the Italian Republic]
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
![](https://secure.gravatar.com/avatar/0df724a41a9440aea36563edd8738763.jpg?s=120&d=mm&r=g)
On Wed, 30 Mar 2011, Lucio Chiappetti wrote in thread starting at http://mail.python.org/pipermail/mailman-users/2011-March/071332.html
and ran bin/withlist -l -a -r fix_url
I still have some problems when subscribing a new user, and concerning message archiving. I will post a separate request for clarity.
After I fixed the problems described in the thread quoted above, I had the following problems.
- when subscribing an user (myself) to the "mailman" list via the web interface I get the message on the screen
Bug in Mailman version 2.1.11 We're sorry, we hit a bug!
Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs.
after a while *root* (not me as "mailman-owner" !!) receives a message
to visit the list control page to accept the subscription request,
but such page has no pending requests
- when subscribing an user (myself) to any other list via the web interface I get the same "bug" message, but after a while I receive the confirmation message, and if I confirm the welcome message, and are subscribed
I removed ALL lists, because "mailman" was created with newlist before I ran fix_url. When I recreate it with newlist, also mailman behaves as any other list i.e.
- "bug message" on the screen
- nevertheless confirmation e-mail
- and regular welcome if I confirm
what stuff in /var/lib/mailman/logs/error is relevant ?
The other question is that if I send a message to a list, the member receive it, but the message is NOT archived.
I see that a file appears in qfiles/shunt/
Note that I did not install any crontab (since my machine is just a test arrangement). Are crontabs necessary for the archiver ?
Is there any FAQ or doc which describes what is in logs and qfiles, and how to interpret and dispose of it ?
In particular how do I get rid of all old stuff there (other than doing it manually), so that I'll have only errors after a fresh restart ?
What material from logs/error or qfiles/shunt should be posted to this list for diagnostics (if any) ?
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
L'Italia ripudia la guerra [...] Italy repudiates war [...] come mezzo di risoluzione delle as a way of resolution of controversie internazionali international controversies [Art. 11 Constitution of the Italian Republic]
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Lucio Chiappetti wrote:
On Wed, 30 Mar 2011, Lucio Chiappetti wrote in thread starting at http://mail.python.org/pipermail/mailman-users/2011-March/071332.html
and ran bin/withlist -l -a -r fix_url
I still have some problems when subscribing a new user, and concerning message archiving. I will post a separate request for clarity.
After I fixed the problems described in the thread quoted above, I had the following problems.
- when subscribing an user (myself) to the "mailman" list via the web interface I get the message on the screen
Bug in Mailman version 2.1.11 We're sorry, we hit a bug!
Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs.
after a while *root* (not me as "mailman-owner" !!) receives a message to visit the list control page to accept the subscription request, but such page has no pending requests
- when subscribing an user (myself) to any other list via the web interface I get the same "bug" message, but after a while I receive the confirmation message, and if I confirm the welcome message, and are subscribed
I removed ALL lists, because "mailman" was created with newlist before I ran fix_url. When I recreate it with newlist, also mailman behaves as any other list i.e.
- "bug message" on the screen
- nevertheless confirmation e-mail
- and regular welcome if I confirm
what stuff in /var/lib/mailman/logs/error is relevant ?
Potentially all of it from one such error, but most problems can be diagnosed with just the python traceback from the error. In some cases, the web server information is helpful for errors in CGIs.
The other question is that if I send a message to a list, the member receive it, but the message is NOT archived.
I see that a file appears in qfiles/shunt/
Here again, there will be an error and a python traceback associated with the shunted message. Archiving issues are often permission problems. Have you run Mailman's bin/check_perms? In any case, the traceback is needed to say more.
Note that I did not install any crontab (since my machine is just a test arrangement). Are crontabs necessary for the archiver ?
No. None of the cron jobs are required for Mailman's basic operation. There should be a crontab.in file in Mailman's cron/ directory that has more detail as to what the individual crons do.
Is there any FAQ or doc which describes what is in logs and qfiles, and how to interpret and dispose of it ?
There's probably some, but not collected in one place :(
See the mmdsr script in the contrib/ directory for a daily log analysis program.
In particular how do I get rid of all old stuff there (other than doing it manually), so that I'll have only errors after a fresh restart ?
There should be no "old stuff" other than logs which are normally handled by logrotate.
On my test/development system, I have a shell script to copy /dev/null to all the logs, but you can simply rm them as they will be automatically created when written.
There is a cron job called cull_bad_shunt if your MM is recent enough. See the documentation for BAD_SHUNT_* settings in Defaults.py.
What material from logs/error or qfiles/shunt should be posted to this list for diagnostics (if any) ?
Most likely nothing from qfiles/shunt. These are the messages that couldn't be completely processed due to some exception. After the underlying issue is fixed, you can finish processing the message by running bin/unshunt. If you run bin/unshunt before fixing the underlying issue, the message will be shunted again. To view the files use bin/show_qfiles or bin/dumpdb. show_qfiles displays only the message and accepts multiple file arguments. dumpdb only accepts a single file, but also dumps the metadata associated with the queue entry.
For logs/error, for a shunted message, post the python exception and the entire traceback. For a CGI error, it's safest to post everything with the timestamp of the error, but if there is sensitive information in the web server or python configuration sections, it is OK to mung it as long as the munging is obvious. You don't have to post more than one traceback if they are the same.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/0df724a41a9440aea36563edd8738763.jpg?s=120&d=mm&r=g)
On Wed, 30 Mar 2011, Mark Sapiro wrote:
Lucio Chiappetti wrote:
- when subscribing an user (myself) to [any] list via the web
interface I get the message on the screen
Bug in Mailman version 2.1.11 We're sorry, we hit a bug!
Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs.
I confirm that despite the fact this message is shown on the web page, I receive the regular confirmation message, and if I click on the provided URL I am regularly subscribed.
The logs show nothing strange except /var/lib/mailman/logs/error
I cleared all logs and qfiles before restarting mailman, and did a single subscribe test on a new list (creation goes ok). I attach the error log (I hope an attachment is ok for the list policy)
The error is generated at the same time the confirmation request is sent.
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Lucio Chiappetti wrote:
I confirm that despite the fact this message is shown on the web page, I receive the regular confirmation message, and if I click on the provided URL I am regularly subscribed.
This error is due to one of several known incompatibilities between Mailman versions older than 2.1.12 and Python 2.6 or later. See the FAQ at <http://wiki.list.org/x/pYA9>.
If suse is packaging Mailman 2.1.11 with the Python 2.6.5 that you are apparently using, this is a serious suse packaging problem.
If you have upgraded your Python independent of suse, perhaps you can also install Mailman 2.1.14-1 or even the head of the Bazaar lp:mailman/2.1 branch.
As you have observed, this particular error only results in the bug page rather than the appropriate subscription results page, but other errors due to this incompatibility will be more disruptive.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/0df724a41a9440aea36563edd8738763.jpg?s=120&d=mm&r=g)
On Thu, 31 Mar 2011, Mark Sapiro wrote:
This error is due to one of several known incompatibilities between Mailman versions older than 2.1.12 and Python 2.6 or later. See the FAQ at <http://wiki.list.org/x/pYA9>.
I read the FAQ, which was however last updated in 2009.
This MIGHT not be a problem, because I'm running tests (as a sort of power user) on my machine (suse 11.3 installed last december), but this is NOT the target system. I'm pretty sure the target system will have suse 11.4 which came out recently.
suse 11.3 bundles mailman 2.1.11-13.2 and python 2.6.5-2.11 (however they provide separately mailman 2.1.14-21.1 and python 2.7-43.1)
suse 11.4 bundles mailman 2.1.14-4.7.1 and python 2.7-8.2 (and provides also 2.7-43.1)
I am really confused by all these minor subsubversions.
Is the suse 11.4 mm/python coupling sound ? If so I will tell our sysadm to proceed, and pass on my test experience. I might do a few further tests on my machine and occasionally report problems here (be free to reply "usual 2.1.11/2.6 incompatibility").
Eventually I could upgrade mailman on my test machine (but not python) if that is likely to work (just to test also the upgrade procedure).
If suse is packaging Mailman 2.1.11 with the Python 2.6.5 that you are apparently using, this is a serious suse packaging problem.
I could report a bug, however if their 11.4 packaging is sound, they are likely to consider it irrelevant.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Lucio Chiappetti wrote:
On Thu, 31 Mar 2011, Mark Sapiro wrote:
This error is due to one of several known incompatibilities between Mailman versions older than 2.1.12 and Python 2.6 or later. See the FAQ at <http://wiki.list.org/x/pYA9>.
I read the FAQ, which was however last updated in 2009.
Yes, but the key part in this case is
"Update - March 2009: Mailman 2.1.12 has been released and requires Python 2.4.x or later. It is the *first* Mailman release compatible with Python 2.6." (emphasis mine).
This MIGHT not be a problem, because I'm running tests (as a sort of power user) on my machine (suse 11.3 installed last december), but this is NOT the target system. I'm pretty sure the target system will have suse 11.4 which came out recently.
suse 11.3 bundles mailman 2.1.11-13.2 and python 2.6.5-2.11 (however they provide separately mailman 2.1.14-21.1 and python 2.7-43.1)
suse 11.4 bundles mailman 2.1.14-4.7.1 and python 2.7-8.2 (and provides also 2.7-43.1)
I am really confused by all these minor subsubversions.
Everything to the right of the hyphen (-) is a designation by the packager of build, patch level, whatever. Only suse can tell you what it means.
I strongly suggest that for a fair test, you upgrade the Mailman on your test platform to the 2.1.14 package. The suse 11.3 bundle has the compatibility issues you have already seen and others as well.
Is the suse 11.4 mm/python coupling sound ?
It should be, but I don't think the combination of Mailman 2.1.14 and Python 2.7.x has seen much use, so there may be as yet undiscovered issues.
If so I will tell our sysadm to proceed, and pass on my test experience. I might do a few further tests on my machine and occasionally report problems here (be free to reply "usual 2.1.11/2.6 incompatibility").
Eventually I could upgrade mailman on my test machine (but not python) if that is likely to work (just to test also the upgrade procedure).
I would recommend that.
If suse is packaging Mailman 2.1.11 with the Python 2.6.5 that you are apparently using, this is a serious suse packaging problem.
I could report a bug, however if their 11.4 packaging is sound, they are likely to consider it irrelevant.
I suggest you report it anyway, if for no other reason than to document the issue with suse.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/0df724a41a9440aea36563edd8738763.jpg?s=120&d=mm&r=g)
I separate this other error in a separate thread.
The other question is that if I send a message to a list, the member receive it, but the message is NOT archived.
I see that a file appears in qfiles/shunt/
Have you run Mailman's bin/check_perms?
yes I did. As a result of the first run, as instructed in manual, I did
cd /var/lib/mailman/archives/
chown wwwrun private
chmod o-x private
and re-run it again. (wwwrun is the suse user under which apache runs)
I see now that the default configuration of the list is archive=yes archive_private=public.
I see there are directories archive/private/listname, archive/private/listname.mbox and public/listname. The latter is a softlink to private. Is this normal ?
All of them are setgid directories owned by wwwrun.mailman except for those of list mailman which are owned by root.mailman, but I guess such list is special, and will have no traffic to be archived.
As a result of posting the first message to the list, a file listname.mbox is created in archive/private/listname.mbox (why private ?) and it contain the messages. But the index.html is not updated. A message is shunted, and the attached errors are generated.
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Lucio Chiappetti wrote:
The other question is that if I send a message to a list, the member receive it, but the message is NOT archived.
I see that a file appears in qfiles/shunt/
Have you run Mailman's bin/check_perms?
yes I did. As a result of the first run, as instructed in manual, I did
cd /var/lib/mailman/archives/ chown wwwrun private chmod o-x private
and re-run it again. (wwwrun is the suse user under which apache runs)
While the above changes result in the most secure configuration, they are only necessary (as opposed to o+x) if you have a multi-user system and you are concerned about local users being able to access private archives.
I see now that the default configuration of the list is archive=yes archive_private=public.
I see there are directories archive/private/listname, archive/private/listname.mbox and public/listname. The latter is a softlink to private. Is this normal ?
Yes, this is exactly as it should be. archives/private/listname.mbox contains a single file archives/private/listname.mbox/listname.mbox which is a unix mbox containing all archived posts to the list and which can be used as input to bin/arch to rebuild the pipermail archive which is in archives/private/listname/.
The symlinks in archives/public/ exist only for lists with public archives and are used by the web server to serve public archive pages without authentication. These are maintained automatically by Mailman as the list archives are changed from public to private or vice versa.
The actual archive is always in archives/private.
All of them are setgid directories owned by wwwrun.mailman except for those of list mailman which are owned by root.mailman, but I guess such list is special, and will have no traffic to be archived.
The owner doesn't matter. Only the group. The 'mailman' list is not special in this case and can have archives. The ownership difference is because the mailman list was created with bin/newlist (by root) whereas the others were created by the web CGI.
As a result of posting the first message to the list, a file listname.mbox is created in archive/private/listname.mbox (why private ?) and it contain the messages. But the index.html is not updated. A message is shunted, and the attached errors are generated.
The HTML is not updated because the exception occurs after the listname.mbox file is (created and) written, but before the HTML archive is updated.
The underlying problem is the same Mailman 2.1.11/Python2.6.5 incompatibility I mentioned in the 'bug adding user, and archiving gets "shunted"' thread.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Lucio Chiappetti wrote:
Please advise if preferred policy on this list is reply to all or reply to list, and excuse if I did wrong.
There is no policy per se. I prefer reply to all, and it seems to me, although I haven't actually counted in any rigorous way, that most long time members of this list do too. My reasons for preferring reply to all are:
Tt keeps digest subscribers who post up to date on replies to their posts and can facilitate their replying to replies.
Although the list policy is that posting is restricted to list members, non-member posts are sometimes accepted, and reply to all includes the non-member poster.
It is not a burden for most list members as they have set their duplicate avoidance appropriately for their preference.
On Tue, 29 Mar 2011, Mark Sapiro wrote:
Lucio Chiappetti wrote:
[...]
(QUESTION 5) The arrangement on the target system will be more complicated.
because our aliases are mantained on the NIS master server. The master and slave servers are also the domain main and backup MX.
However the web server is on a third machine. A configuration like the one I use on my test machine (local sendmail aliases inherited from local mailman aliases, which "pipe" into local mailman executables) is likely to work there ...
... but we'd have to expose somehow this machine name in the e-mail address (we currently mask all behind the domain) or replicate all mailman aliases in the NIS maps as
xxxxx: xxxxx@mailmanhost
but I do understand we cannot use a CNAME for mailmanhost ?
There is no Mailman restriction per se, but there is an email standard (RFC 1123, STD 3) that is clear that the names in MX records must have A records, not CNAME. See the FAQ at <http://wiki.list.org/x/uYA9> for some of the consequences.
I don't think I actually understand the configuration or what the problem is.
Ultimately, mail to a list must be delivered to the Mailman machine, but I don't understand why the existing MXs can't relay it there or can they?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/0df724a41a9440aea36563edd8738763.jpg?s=120&d=mm&r=g)
On Wed, 30 Mar 2011, Mark Sapiro wrote:
Lucio Chiappetti wrote:
(QUESTION 5) The arrangement on the target system will be more complicated.
because our aliases are mantained on the NIS master server. The master and slave servers are also the domain main and backup MX.
However the web server is on a third machine. A configuration like the one I use on my test machine (local sendmail aliases inherited from local mailman aliases, which "pipe" into local mailman executables) is likely to work there ...
I don't think I actually understand the configuration or what the problem is.
Ultimately, mail to a list must be delivered to the Mailman machine, but I don't understand why the existing MXs can't relay it there or can they?
So far not unless explicitly aliased. This is how I see it (and how our other things work currently).
all our e-mail are of the form user@domain NOT user@host.domain
all outgoing mail is masqueraded as user@domain by sendmail
the DNS advertises two MX's for the domain. We do not advertise MX's for particular hosts. Hosts other than MX's should have the SMTP port blocked by a firewall on the boundary router (we are several institutes in the same building, the boundary router is not managed by ours).
incoming mail of the form user@domain is delivered to other hosts via alias expansion managed by NIS. So some users get it delivered to user@personalhost, some other to user@projectimapserver.
our current mailing lists (e.g. staff@domain) are managed by :include: in the NIS aliases source, pointing to list of addresses in include files. The expansion works because all local hosts (including the MX's) can access (via NFS) the included files. We do manage both "system" lists (include file in a system directory) and "project" lists (include file in an user directory)
We plan to replace those lists by mailman-managed lists.
mailman will be installed on a given host (I call it mmhost for the purposes of this mail, but the real name will be different). Most likely it will be our www server (www.domain where www is a CNAME for its real host name), NOT the MXs (the two MXs are redundant, and are also the primary and secondary DNS and NIS servers).
I know now that DEFAULT_URL_HOST shall point to www.domain (or perhaps a dedicated virtual www server)
I know now that DEFAULT_EMAIL_HOST can be set to "domain" to make lists and service addresses of the form "list@domain" (preferred to list@mmhost.domain)
I know from my tests how to coerce sendmail and mailman to use (and automatically create) LOCAL aliases of the form
listname: "|/usr/lib/mailman/mail/mailman post listname"
but of course THESE aliases are not suitable to be NIS aliases. /usr/lib/mailman/mail/mailman won't exist on the MXs and on the clients !
I can imagine two ways out of it.
a) having some manual or crontab operated script which for all mailman alias on the mmhost, replicates in the NIS aliases aliases of the form
listname: listname@mmhost listname-owner : listname-owner@mmhost etc.
b) renouncing to the listname@domain in favour of listname@mmhost.domain addresses, and doing some clever use of MX records and sendmail mailertable to route all mail for mmhost (firewalled from outside) to such machine
PS I read also FAQs 4.84 and 4.72. Any more suitable for our configuration ?
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Lucio Chiappetti wrote:
- all our e-mail are of the form user@domain NOT user@host.domain
OK
- all outgoing mail is masqueraded as user@domain by sendmail
OK
- the DNS advertises two MX's for the domain. We do not advertise MX's for particular hosts. Hosts other than MX's should have the SMTP port blocked by a firewall on the boundary router (we are several institutes in the same building, the boundary router is not managed by ours).
OK
[...]
- mailman will be installed on a given host (I call it mmhost for the purposes of this mail, but the real name will be different). Most likely it will be our www server (www.domain where www is a CNAME for its real host name), NOT the MXs (the two MXs are redundant, and are also the primary and secondary DNS and NIS servers).
If it is not the www server, you can use one of the methods in FAQ 4.84
I know now that DEFAULT_URL_HOST shall point to www.domain (or perhaps a dedicated virtual www server)
I know now that DEFAULT_EMAIL_HOST can be set to "domain" to make lists and service addresses of the form "list@domain" (preferred to list@mmhost.domain)
I know from my tests how to coerce sendmail and mailman to use (and automatically create) LOCAL aliases of the form
listname: "|/usr/lib/mailman/mail/mailman post listname"
but of course THESE aliases are not suitable to be NIS aliases. /usr/lib/mailman/mail/mailman won't exist on the MXs and on the clients !
But it is trivial to augment your script that copies Mailman's aliases for sendmail by adding something like
sed -r -e "s/^(.*):.*$/\1: \1@mmhost.domain/" < /path/data/aliases > ...
plus the command(s) necessary to install those in NIS.
[...]
PS I read also FAQs 4.84 and 4.72. Any more suitable for our configuration ?
I think those are good.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Lucio Chiappetti
-
Mark Sapiro