From jason at barnesos.net  Mon Jan  5 16:09:19 2015
From: jason at barnesos.net (Jason W. Barnes)
Date: Mon, 5 Jan 2015 07:09:19 -0800 (PST)
Subject: [Mailman-Users] mailman posts disappear after upgrade
Message-ID: <alpine.BSF.2.11.1501050659330.5817@oom9.barnesos.net>

Mailman-users:

 	I have a problem that I was hoping that you guys might have some 
insight into.
 	I'm running Mailman 2.1.14_6 on FreeBSD 9.2-STABLE with postfix 
2.11.1 as the MTA.  I recently upgraded all of my ports, and in doing so 
managed to break mailman.  I was messing with owners and permissions, but 
eventually figured out to remake mailman by hand to work with postfix.
 	But. . .
 	Now mailman posts just disappear.  Here's the output from the 
postfix maillog:

Jan  5 06:45:39 oom9 postfix/pickup[5668]: 142FE3D7E: uid=1002 from=<jason at barnesos.net>
Jan  5 06:45:39 oom9 postfix/cleanup[5841]: 142FE3D7E: message-id=<alpine.BSF.2.11.1501050645320.5817 at oom9.barnesos.net>
Jan  5 06:45:39 oom9 postfix/qmgr[46022]: 142FE3D7E: from=<jason at barnesos.net>, size=662, nrcpt=1 (queue active)
Jan  5 06:45:39 oom9 postfix/trivial-rewrite[5842]: warning: do not list domain barnesos.net in BOTH mydestination and virtual_alias_domains
Jan  5 06:45:39 oom9 postfix/local[5843]: 142FE3D7E: to=<posttest at barnesos.net>, relay=local, delay=0.46, delays=0.15/0.01/0/0.3, dsn=2.0.0, status=sent (delivered to command: /usr/local/mailman/mail/mailman post posttest)
Jan  5 06:45:39 oom9 postfix/qmgr[46022]: 142FE3D7E: removed

So that all looks fine.  In fact when I run that command, 
"/usr/local/mailman/mail/mailman post posttest" by hand as the mailman 
user (after a temporary change from it being /sbin/nologin), it works 
fine.  When I control-C out of that it gives me an error message in the 
mailman logs under 'error'.  But when I pipe in a file to post it just 
goes away.  None of the logs get updated to a new date, and nothing else 
seems to change.  It's just gone.
 	Any idea how to diagnose the problem?  Without an error message 
I'm struggling to know where to go next.  Thanks in advance if anyone has 
any ideas!

 			- Jason


From aba at westmont.edu  Mon Jan  5 18:03:23 2015
From: aba at westmont.edu (Anne Anderson)
Date: Mon, 5 Jan 2015 09:03:23 -0800
Subject: [Mailman-Users] Automatic addition/removal of aliases no longer
	works
Message-ID: <CAE+6J_kaz9dfSq0KX3bMu_mHjTTKa7q+zx3-dFshVX-HX0V8iw@mail.gmail.com>

Hello -

We upgraded to *2.1.14* not too long ago and made the discovery that when a
new list is created, the *lines that used to get written automatically into
the aliases file are no longer automatically written,* instead they are
displayed on the screen with the instructions to cut and paste them in.
(This change may have occurred long ago as far as we know; our previous
version was *2.1.9*)

This would not be much of a bother if we only had to make a new list
occasionally, but we make lists for all our courses at the beginning of
each semester, and to do this *we have a perl script that automatically
generates over 500 lists in batch mode*.

The same problem occurs when we remove the previous semester's lists...
 their entries are not automatically removed from the aliases file, and
removing them by hand is not a trivial task.   We could just leave them in,
but *whenever a new course is the same as one that's already in the aliases
file, it will error out and crash the script that builds the new lists. *

*Is there any fix for this?*  I would like to create the course lists for
spring semester, but I am feeling daunted by the task of doing all the
aliases part of it by hand.

Anne

Anne Anderson
Web Application Developer / Database Manager
Information Technology
Westmont College

From mark at msapiro.net  Mon Jan  5 19:15:58 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 05 Jan 2015 10:15:58 -0800
Subject: [Mailman-Users] mailman posts disappear after upgrade
In-Reply-To: <alpine.BSF.2.11.1501050659330.5817@oom9.barnesos.net>
References: <alpine.BSF.2.11.1501050659330.5817@oom9.barnesos.net>
Message-ID: <54AAD4DE.5000801@msapiro.net>

On 01/05/2015 07:09 AM, Jason W. Barnes wrote:
> 
>     Now mailman posts just disappear.  Here's the output from the
> postfix maillog:
> 
> Jan  5 06:45:39 oom9 postfix/pickup[5668]: 142FE3D7E: uid=1002
> from=<jason at barnesos.net>
> Jan  5 06:45:39 oom9 postfix/cleanup[5841]: 142FE3D7E:
> message-id=<alpine.BSF.2.11.1501050645320.5817 at oom9.barnesos.net>
> Jan  5 06:45:39 oom9 postfix/qmgr[46022]: 142FE3D7E:
> from=<jason at barnesos.net>, size=662, nrcpt=1 (queue active)
> Jan  5 06:45:39 oom9 postfix/trivial-rewrite[5842]: warning: do not list
> domain barnesos.net in BOTH mydestination and virtual_alias_domains
> Jan  5 06:45:39 oom9 postfix/local[5843]: 142FE3D7E:
> to=<posttest at barnesos.net>, relay=local, delay=0.46,
> delays=0.15/0.01/0/0.3, dsn=2.0.0, status=sent (delivered to command:
> /usr/local/mailman/mail/mailman post posttest)
> Jan  5 06:45:39 oom9 postfix/qmgr[46022]: 142FE3D7E: removed
> 
> So that all looks fine.  In fact when I run that command,
> "/usr/local/mailman/mail/mailman post posttest" by hand as the mailman
> user (after a temporary change from it being /sbin/nologin), it works
> fine.  When I control-C out of that it gives me an error message in the
> mailman logs under 'error'.  But when I pipe in a file to post it just
> goes away.  None of the logs get updated to a new date, and nothing else
> seems to change.  It's just gone.


See the FAQ at <http://wiki.list.org/x/A4E9>. In particular, are the
qrunners running? Are the messages just sitting in queue entries in
qfiles/in?


-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Mon Jan  5 19:27:30 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 05 Jan 2015 10:27:30 -0800
Subject: [Mailman-Users] Automatic addition/removal of aliases no longer
 works
In-Reply-To: <CAE+6J_kaz9dfSq0KX3bMu_mHjTTKa7q+zx3-dFshVX-HX0V8iw@mail.gmail.com>
References: <CAE+6J_kaz9dfSq0KX3bMu_mHjTTKa7q+zx3-dFshVX-HX0V8iw@mail.gmail.com>
Message-ID: <54AAD792.7030204@msapiro.net>

On 01/05/2015 09:03 AM, Anne Anderson wrote:
> 
> We upgraded to *2.1.14* not too long ago and made the discovery that when a
> new list is created, the *lines that used to get written automatically into
> the aliases file are no longer automatically written,* instead they are
> displayed on the screen with the instructions to cut and paste them in.
> (This change may have occurred long ago as far as we know; our previous
> version was *2.1.9*)


I suspect that your prior version had set MTA = 'Postfix', and this got
lost in the upgrade. If you had set

MTA = 'Postfix'

in mm_cfg.py as you should have (see the FAQ at
<http://wiki.list.org/x/fIA9>), it wouldn't be lost in a normal upgrade,
so maybe this was set in Defaults.py.

Anyway, setting

MTA = 'Postfix'

in mm_cfg.py should help.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From tracey at fairhousing.com  Mon Jan  5 19:35:45 2015
From: tracey at fairhousing.com (Tracey McCartney)
Date: Mon, 5 Jan 2015 12:35:45 -0600
Subject: [Mailman-Users] How to deal with these spam submissions?
Message-ID: <178b01d02916$6b7df2e0$4279d8a0$@fairhousing.com>

I run a list at fair_housing@(my domain here). 

 

Over the last few days, I've received some spammy non-member submissions
from these e-mail addresses:

 

fair_housingbnqq at maxcom.net.mx

fair_housinghjhn at woohoo.ro

fair_housingrjs at fourlads.com

fair_housingrprs at pepempilhadeiras.com.br
<mailto:fair_housingrprs at pepempilhadeiras.com.br> 

 

So clearly these aren't totally random - they have bot-generated addresses
based on the address of my list.  I would like to add these and e-mail
addresses like them to my sender filter to be discarded upon receipt.  I am
vaguely aware that one can use regular expressions to do this, but I don't
want to screw something up and filter out legit posters.  Can someone help
me with the correct regex?

 

Thanks,

 

Tracey McCartney

Tennessee Fair Housing Council

107 Music City Circle, Suite 318

Nashville, TN 37214

www.tennfairhousing.org <http://www.tennfairhousing.org> 

615-874-2344

 



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

From mark at msapiro.net  Mon Jan  5 23:09:27 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 05 Jan 2015 14:09:27 -0800
Subject: [Mailman-Users] How to deal with these spam submissions?
In-Reply-To: <178b01d02916$6b7df2e0$4279d8a0$@fairhousing.com>
References: <178b01d02916$6b7df2e0$4279d8a0$@fairhousing.com>
Message-ID: <54AB0B97.1030002@msapiro.net>

On 01/05/2015 10:35 AM, Tracey McCartney wrote:
> I run a list at fair_housing@(my domain here). 
> 
>  
> 
> Over the last few days, I've received some spammy non-member submissions
> from these e-mail addresses:
> 
>  
> 
> fair_housingbnqq at maxcom.net.mx
> 
> fair_housinghjhn at woohoo.ro
> 
> fair_housingrjs at fourlads.com
> 
> fair_housingrprs at pepempilhadeiras.com.br
> <mailto:fair_housingrprs at pepempilhadeiras.com.br> 
> 
>  
> 
> So clearly these aren't totally random - they have bot-generated addresses
> based on the address of my list.  I would like to add these and e-mail
> addresses like them to my sender filter to be discarded upon receipt.


If these are subscription requests, adding something to Sender filters
won't help. You want Privacy options... -> Subscription rules ->
ban_list to prevent addresses from subscribing. A regex like

^fair_housing.*

or more simply just

^fair_housing

will prevent any email address beginning with 'fair_housing' from
subscribing to the list. You could also add the same regexp to Privacy
options... -> Sender filters -> discard_these_nonmembers to prevent such
addresses from posting if your list otherwise accepts non-member posts.

Also, if these are bots requesting subscription via the web and your
Mailman version is >= 2.1.16 and you have access, see the section about
SUBSCRIBE_FORM_SECRET in Defaults.py for information on a mitigation for
this attack. To use it, you would set

SUBSCRIBE_FORM_SECRET = 'some string of your choice'

in mm_cfg.py.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From jason at barnesos.net  Tue Jan  6 09:25:39 2015
From: jason at barnesos.net (Jason W. Barnes)
Date: Tue, 6 Jan 2015 00:25:39 -0800 (PST)
Subject: [Mailman-Users] mailman posts disappear after upgrade
In-Reply-To: <54AAD4DE.5000801@msapiro.net>
References: <alpine.BSF.2.11.1501050659330.5817@oom9.barnesos.net>
 <54AAD4DE.5000801@msapiro.net>
Message-ID: <alpine.BSF.2.11.1501060024570.18093@oom9.barnesos.net>

> See the FAQ at <http://wiki.list.org/x/A4E9>. In particular, are the
> qrunners running? Are the messages just sitting in queue entries in
> qfiles/in?

 	Thanks for your help; this was it.  The new mailman uses the 
daemon, and I had to start it and now things are going through.

 				- Jason

From dap1 at bellsouth.net  Thu Jan  8 03:44:11 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Wed, 07 Jan 2015 21:44:11 -0500
Subject: [Mailman-Users] Migration Problem
Message-ID: <54ADEEFB.9010608@bellsouth.net>

I am trying to migrate mailman from CentOS 6 (32 bit) to CentOS 7 (64
bit) and have run into a problem. I am having problems with the web
pages. They all get a permissions denied error and the log shows:

[Wed Jan 07 21:37:50.331181 2015] [authz_core:error] [pid 5012] [client
::1:60272] AH01630: client denied by server configuration:
/usr/lib/mailman/cgi-bin/listinfo

Here is my mailman.conf file:
-------------------------------------------------------------------------------------------------------
# Directives for the mailman web interface

Alias /pipermail/ "/var/lib/mailman/archives/public/"
ScriptAlias /mailman/ "/usr/lib/mailman/cgi-bin/"

# For the archives

<Directory "/var/lib/mailman/archives/public">
        Options +FollowSymLinks
        Require all granted
</Directory>
------------------------------------------------------------------------------------------------------------

My permissions and ownership of /var/lib/mailman and /usr/lib/mailman
look correct to me but then the error seems to imply the problem is not
permissions but rather a problem with mailman.conf. Can someone tell me
how to debug this? TIA.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150107/e97a8350/attachment.sig>

From mark at msapiro.net  Thu Jan  8 04:18:35 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 07 Jan 2015 19:18:35 -0800
Subject: [Mailman-Users] Migration Problem
In-Reply-To: <54ADEEFB.9010608@bellsouth.net>
References: <54ADEEFB.9010608@bellsouth.net>
Message-ID: <54ADF70B.1000407@msapiro.net>

On 01/07/2015 06:44 PM, Dennis Putnam wrote:
> I am trying to migrate mailman from CentOS 6 (32 bit) to CentOS 7 (64
> bit) and have run into a problem. I am having problems with the web
> pages. They all get a permissions denied error and the log shows:
> 
> [Wed Jan 07 21:37:50.331181 2015] [authz_core:error] [pid 5012] [client
> ::1:60272] AH01630: client denied by server configuration:
> /usr/lib/mailman/cgi-bin/listinfo


And CentOS 7 has Apache 2.4?


> Here is my mailman.conf file:
> -------------------------------------------------------------------------------------------------------
> # Directives for the mailman web interface
> 
> Alias /pipermail/ "/var/lib/mailman/archives/public/"
> ScriptAlias /mailman/ "/usr/lib/mailman/cgi-bin/"
> 
> # For the archives
> 
> <Directory "/var/lib/mailman/archives/public">
>         Options +FollowSymLinks
>         Require all granted
> </Directory>


You probably also need

<Directory "/usr/lib/mailman/cgi-bin/">
        Options ExecCGI
        Require all granted
</Directory>


See <http://www.list.org/mailman-install/node10.html>.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150107/478390d5/attachment.sig>

From jebva at yahoo.com  Wed Jan  7 19:50:18 2015
From: jebva at yahoo.com (JB)
Date: Wed, 7 Jan 2015 10:50:18 -0800
Subject: [Mailman-Users] TOPICS
Message-ID: <1420656618.1140.YahooMailBasic@web122503.mail.ne1.yahoo.com>

I am setting up a new mailing list and I am having difficulty with the TOPICS option.  The whole problem may be that I am using the feature incorrectly but I am hoping it is intended for what i want to do.  Here is the situation...

I have set up a web site for a small business that have several distinct product lines (lets say fishing, books, and model trains).  I want to be able to set up a single list that is customers can subscribe to and indicate for which combination of the three products they want to get mail.  Then I want the users to be able to send mail out that somehow goes only to the subscribers that have indicated they want to get mail for the product line(s) in question.  A given email may be applicable to one, or any combination of product lines.

I have finished setting up the list and then I went into the TOPICS section and set up three topics (fishing, books, trains).  I do not see anywhere that allows users to subscribe to specific topics nor do I know how to send out an email and indicate which topic(s) it is pertaining to.

I am very dyslexic so reading through a volume of posts to find what I am looking for is extremely difficult for me.  Can someone please tell me what all I need to do to set this up?

I would like to have a subscribe page (or link) that allows the user to sign up for the list and indicate which topics he wants to receive all in one place.  I really want to use custom skinned pages to do this.  I know how to write the pages for a simple subscribe/unsubscribe page but this whole mess with topics is throwing me.



From jebva at yahoo.com  Wed Jan  7 21:50:04 2015
From: jebva at yahoo.com (JB)
Date: Wed, 7 Jan 2015 12:50:04 -0800
Subject: [Mailman-Users] custon mm page
Message-ID: <1420663804.14859.YahooMailBasic@web122506.mail.ne1.yahoo.com>

what file name do I use and where do I upload a custom member options login page?

From mark at msapiro.net  Thu Jan  8 09:58:20 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 08 Jan 2015 00:58:20 -0800
Subject: [Mailman-Users] TOPICS
In-Reply-To: <1420656618.1140.YahooMailBasic@web122503.mail.ne1.yahoo.com>
References: <1420656618.1140.YahooMailBasic@web122503.mail.ne1.yahoo.com>
Message-ID: <54AE46AC.1020000@msapiro.net>

On 01/07/2015 10:50 AM, JB wrote:
> 
> I have finished setting up the list and then I went into the TOPICS section and set up three topics (fishing, books, trains).  I do not see anywhere that allows users to subscribe to specific topics nor do I know how to send out an email and indicate which topic(s) it is pertaining to.


Users subscribe to topics on their respective user options pages.

When you set up the topics you provided a regexp to match against to
determine if a message is in that topic. This regexp is matched against
the Subject: header of the message, the Keywords: header if any.

Also in the Topics setup is a setting for topics_bodylines_limit.
Mailman will also look at up to this many of the initial body lines of
the message looking for pseudo Subject: and Keywords: headers. This body
lines search stops when the limit is reached or a non-header like line
is encountered.

Say the regexp for the 'books' topic is 'books?'. A message will match
the books topic if for example the Subject: contains the word 'book' or
'books' or the first body line is for example 'Keywords: books'.


> I would like to have a subscribe page (or link) that allows the user to sign up for the list and indicate which topics he wants to receive all in one place.  I really want to use custom skinned pages to do this.  I know how to write the pages for a simple subscribe/unsubscribe page but this whole mess with topics is throwing me.


Making Mailman support a single CGI transaction to both subscribe a user
and specify topics for that subscription would require creating a new
CGI and making significant source changes. The major hurdles are the
fact that subscribing is a request that normally requires confirmation,
approval or both, and topic subscription can only be done for an
existing user.

The current process has a mechanism for carrying things like the user's
real name and preferred language with the subscription request, but that
would have to be extended to carry topics as well.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Thu Jan  8 10:03:31 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 08 Jan 2015 01:03:31 -0800
Subject: [Mailman-Users] custon mm page
In-Reply-To: <1420663804.14859.YahooMailBasic@web122506.mail.ne1.yahoo.com>
References: <1420663804.14859.YahooMailBasic@web122506.mail.ne1.yahoo.com>
Message-ID: <54AE47E3.8020809@msapiro.net>

On 01/07/2015 12:50 PM, JB wrote:
> what file name do I use and where do I upload a custom member options login page?


The options login page is built on the fly by the loginpage() function
in the $prefix/Mailman/Cgi/options.py module. There is no template
involved for the login page. You have to modify it in the source code
and the mods apply to all lists unless you test for something to trigger
different behavior.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From Jan at Bytesmiths.com  Thu Jan  8 18:49:31 2015
From: Jan at Bytesmiths.com (Jan Steinman)
Date: Thu, 8 Jan 2015 09:49:31 -0800
Subject: [Mailman-Users] All my lists quit working!
In-Reply-To: <mailman.94987.1416859863.18129.mailman-users@python.org>
References: <mailman.94987.1416859863.18129.mailman-users@python.org>
Message-ID: <A7DA5AB0-F6DF-4701-9165-BDD74DEAA72D@Bytesmiths.com>

First, the bad news: Mac OS X 10.6.8. Yea, I've read Mark's dire warning. Please don't shoot me. I'm hoping this is a generic sort of problem.

When I send a message to ANY of the dozen or so lists I host, my MTA immediately says it doesn't know the addressee.

/etc/postfix/main.cf contains the following lines:
	virtual_alias_maps = hash:/etc/postfix/virtual,hash:/var/mailman/data/virtual-mailman,hash:/etc/postfix/virtual_users
	alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases

The file "/var/mailman/data/virtual-mailman" is empty.

The file "/var/mailman/data/aliases" has all my lists in it.

The corresponding ".db" files for those two have the same timestamp as their corresponding text files.

Here is an example of what is in the "aliases" file:

	# STANZA START: beaders
	# CREATED: Wed Jan  7 13:06:39 2015
	beaders:             "|/usr/share/mailman/mail/mailman post beaders"
	beaders-admin:       "|/usr/share/mailman/mail/mailman admin beaders"
	beaders-bounces:     "|/usr/share/mailman/mail/mailman bounces beaders"
	beaders-confirm:     "|/usr/share/mailman/mail/mailman confirm beaders"
	beaders-join:        "|/usr/share/mailman/mail/mailman join beaders"
	beaders-leave:       "|/usr/share/mailman/mail/mailman leave beaders"
	beaders-owner:       "|/usr/share/mailman/mail/mailman owner beaders"
	beaders-request:     "|/usr/share/mailman/mail/mailman request beaders"
	beaders-subscribe:   "|/usr/share/mailman/mail/mailman subscribe beaders"
	beaders-unsubscribe: "|/usr/share/mailman/mail/mailman unsubscribe beaders"
	# STANZA END: beaders

I run "dumpdb aliases.db" and get:

	[----- start marshal file -----] Traceback (most recent call last): File "/usr/share/mailman/bin/dumpdb", line 156, in <module> msg = main() 	File "/usr/share/mailman/bin/dumpdb", line 136, in main obj = load(fp) ValueError: bad marshal data 

Does this mean that "dumpdb" is bad, or does it mean that "aliases.db" is bad, or neither?

Any help (despite my using an unsupported version) appreciated!

I promise to jump on the 3.0 bandwagon as soon as I can. I hate what Apple did to this.

:::: ...the exploitation of animals for milk was already an established practice at the time farming arrived in Britain in the late fifth millennium B.C. -- M.S. Copley
:::: Jan Steinman, EcoReality Co-op ::::


From lstone19 at stonejongleux.com  Thu Jan  8 19:54:44 2015
From: lstone19 at stonejongleux.com (Larry Stone)
Date: Thu, 8 Jan 2015 08:54:44 -1000
Subject: [Mailman-Users] All my lists quit working!
In-Reply-To: <A7DA5AB0-F6DF-4701-9165-BDD74DEAA72D@Bytesmiths.com>
References: <mailman.94987.1416859863.18129.mailman-users@python.org>
 <A7DA5AB0-F6DF-4701-9165-BDD74DEAA72D@Bytesmiths.com>
Message-ID: <1F9E161B-D593-4F8E-9134-5B0B039E14C2@stonejongleux.com>


On Jan 8, 2015, at 7:49 AM, Jan Steinman <Jan at Bytesmiths.com> wrote:

> First, the bad news: Mac OS X 10.6.8. Yea, I've read Mark's dire warning. Please don't shoot me. I'm hoping this is a generic sort of problem.
> 

OS X Server? or OS X (client)?

> When I send a message to ANY of the dozen or so lists I host, my MTA immediately says it doesn't know the addressee.

Log entries please.

> /etc/postfix/main.cf contains the following lines:
> 	virtual_alias_maps = hash:/etc/postfix/virtual,hash:/var/mailman/data/virtual-mailman,hash:/etc/postfix/virtual_users
> 	alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
> 
Please provide your postconf -n . That will show how postfix is actually configured, not how you think it is configured by providing just a few lines out of main.cf. 

> The file "/var/mailman/data/virtual-mailman" is empty.
> 
> The file "/var/mailman/data/aliases" has all my lists in it.
> 
> The corresponding ".db" files for those two have the same timestamp as their corresponding text files.
> 
> Here is an example of what is in the "aliases" file:
> 
> 	# STANZA START: beaders
> 	# CREATED: Wed Jan  7 13:06:39 2015
> 	beaders:             "|/usr/share/mailman/mail/mailman post beaders"
> 	beaders-admin:       "|/usr/share/mailman/mail/mailman admin beaders"
> 	beaders-bounces:     "|/usr/share/mailman/mail/mailman bounces beaders"
> 	beaders-confirm:     "|/usr/share/mailman/mail/mailman confirm beaders"
> 	beaders-join:        "|/usr/share/mailman/mail/mailman join beaders"
> 	beaders-leave:       "|/usr/share/mailman/mail/mailman leave beaders"
> 	beaders-owner:       "|/usr/share/mailman/mail/mailman owner beaders"
> 	beaders-request:     "|/usr/share/mailman/mail/mailman request beaders"
> 	beaders-subscribe:   "|/usr/share/mailman/mail/mailman subscribe beaders"
> 	beaders-unsubscribe: "|/usr/share/mailman/mail/mailman unsubscribe beaders"
> 	# STANZA END: beaders
> 
> I run "dumpdb aliases.db" and get:
> 
> 	[----- start marshal file -----] Traceback (most recent call last): File "/usr/share/mailman/bin/dumpdb", line 156, in <module> msg = main() 	File "/usr/share/mailman/bin/dumpdb", line 136, in main obj = load(fp) ValueError: bad marshal data 

Mailman?s dumpdb is for Python databases. aliases.db is not a Python database.

> Does this mean that "dumpdb" is bad, or does it mean that "aliases.db" is bad, or neither

It means dumpdb is the wrong tool for dumping aliases.db.

> Any help (despite my using an unsupported version) appreciated!

Show log entries and postconf -n as requested above as it looks correct at first glance. Also, check your master.cf to see if there are any overrides (-o) on your smtpd entry.

-- 
Larry Stone
lstone19 at stonejongleux.com
http://www.stonejongleux.com/




From dap1 at bellsouth.net  Fri Jan  9 00:23:58 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Thu, 08 Jan 2015 18:23:58 -0500
Subject: [Mailman-Users] Migration Problem
In-Reply-To: <54ADF70B.1000407@msapiro.net>
References: <54ADEEFB.9010608@bellsouth.net> <54ADF70B.1000407@msapiro.net>
Message-ID: <54AF118E.5010001@bellsouth.net>

On 1/7/2015 10:18 PM, Mark Sapiro wrote:
> On 01/07/2015 06:44 PM, Dennis Putnam wrote:
>> I am trying to migrate mailman from CentOS 6 (32 bit) to CentOS 7 (64
>> bit) and have run into a problem. I am having problems with the web
>> pages. They all get a permissions denied error and the log shows:
>>
>> [Wed Jan 07 21:37:50.331181 2015] [authz_core:error] [pid 5012] [client
>> ::1:60272] AH01630: client denied by server configuration:
>> /usr/lib/mailman/cgi-bin/listinfo
>
> And CentOS 7 has Apache 2.4?
Yes. 2.4.6-17 to be precise.
>
>
>> Here is my mailman.conf file:
>> -------------------------------------------------------------------------------------------------------
>> # Directives for the mailman web interface
>>
>> Alias /pipermail/ "/var/lib/mailman/archives/public/"
>> ScriptAlias /mailman/ "/usr/lib/mailman/cgi-bin/"
>>
>> # For the archives
>>
>> <Directory "/var/lib/mailman/archives/public">
>>         Options +FollowSymLinks
>>         Require all granted
>> </Directory>
>
> You probably also need
>
> <Directory "/usr/lib/mailman/cgi-bin/">
>         Options ExecCGI
>         Require all granted
> </Directory>
>
>
> See <http://www.list.org/mailman-install/node10.html>.
>
>
Thanks for the reply. Yep, that was it. Odd that the install package
included the directive for the archives but not the scripts. However,
the only step I did not do yet is the URL change (I am testing a
kickstart file) so my last problem may be due to that but I am thinking
not. When I access the listinfo, no lists are published but I can see
them in /var/lib/mailman/lists. Also the admin pages are not password
projected. So either I did not copy something from the old server
(CentOS 6 (32 bit)) or whatever I did copy from 2.1.12 (32 bit) is not
compatible with 2.1.15 (64 bit). There is probably a 'withlist' command
that fixes all this but that command cannot be run in the kickstart file
so I'd rather copy the appropriate files from the old server if
possible. Is there something other than /var/lib/mailman that I should
have copied? Perhaps something in /usr/lib/mailman.

P.S. I still have to figure out how to migrate my custom changes which
are in /usr/lib/mailman.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150108/91926a9f/attachment.sig>

From mark at msapiro.net  Fri Jan  9 01:06:21 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 08 Jan 2015 16:06:21 -0800
Subject: [Mailman-Users] Migration Problem
In-Reply-To: <54AF118E.5010001@bellsouth.net>
References: <54ADEEFB.9010608@bellsouth.net> <54ADF70B.1000407@msapiro.net>
 <54AF118E.5010001@bellsouth.net>
Message-ID: <54AF1B7D.8080102@msapiro.net>

On 01/08/2015 03:23 PM, Dennis Putnam wrote:

> However,
> the only step I did not do yet is the URL change (I am testing a
> kickstart file) so my last problem may be due to that but I am thinking
> not. When I access the listinfo, no lists are published but I can see
> them in /var/lib/mailman/lists.


It probably is the URL used to visit the page. See the FAQ at
<http://wiki.list.org/x/6oA9>


> Also the admin pages are not password
> projected. So either I did not copy something from the old server
> (CentOS 6 (32 bit)) or whatever I did copy from 2.1.12 (32 bit) is not
> compatible with 2.1.15 (64 bit).


A much more likely explanation is you have an authentication cookie in
your browser. There is no configuration or data (other than the cookie)
that would cause authentication for the admin pages to be bypassed.


> There is probably a 'withlist' command
> that fixes all this but that command cannot be run in the kickstart file
> so I'd rather copy the appropriate files from the old server if
> possible. Is there something other than /var/lib/mailman that I should
> have copied? Perhaps something in /usr/lib/mailman.


Probably not.


> P.S. I still have to figure out how to migrate my custom changes which
> are in /usr/lib/mailman.


The moral here is whenever you make a change to any Mailman module, you
should keep a diff that can be reapplied as a patch when you upgrade.

At this point, if you don't have that, you could download the 2.1.12
source tarball from <https://launchpad.net/mailman/2.1/2.1.12> or
<http://ftp.gnu.org/gnu/mailman/>, unpack it and diff it against your
2.1.12 /usr/lib/mailman to see what you changed. You may have to sift a
bit to separate your changes from any RedHat package changes, but you
should be able to work it out.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150108/d1166861/attachment.sig>

From dap1 at bellsouth.net  Fri Jan  9 01:35:37 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Thu, 08 Jan 2015 19:35:37 -0500
Subject: [Mailman-Users] Migration Problem
In-Reply-To: <54AF1B7D.8080102@msapiro.net>
References: <54ADEEFB.9010608@bellsouth.net> <54ADF70B.1000407@msapiro.net>
 <54AF118E.5010001@bellsouth.net> <54AF1B7D.8080102@msapiro.net>
Message-ID: <54AF2259.10802@bellsouth.net>

On 1/8/2015 7:06 PM, Mark Sapiro wrote:
> On 01/08/2015 03:23 PM, Dennis Putnam wrote:
>
>> However,
>> the only step I did not do yet is the URL change (I am testing a
>> kickstart file) so my last problem may be due to that but I am thinking
>> not. When I access the listinfo, no lists are published but I can see
>> them in /var/lib/mailman/lists.
>
> It probably is the URL used to visit the page. See the FAQ at
> <http://wiki.list.org/x/6oA9>
>
>
>> Also the admin pages are not password
>> projected. So either I did not copy something from the old server
>> (CentOS 6 (32 bit)) or whatever I did copy from 2.1.12 (32 bit) is not
>> compatible with 2.1.15 (64 bit).
>
> A much more likely explanation is you have an authentication cookie in
> your browser. There is no configuration or data (other than the cookie)
> that would cause authentication for the admin pages to be bypassed.
>
>
>> There is probably a 'withlist' command
>> that fixes all this but that command cannot be run in the kickstart file
>> so I'd rather copy the appropriate files from the old server if
>> possible. Is there something other than /var/lib/mailman that I should
>> have copied? Perhaps something in /usr/lib/mailman.
>
> Probably not.
>
>
>> P.S. I still have to figure out how to migrate my custom changes which
>> are in /usr/lib/mailman.
>
> The moral here is whenever you make a change to any Mailman module, you
> should keep a diff that can be reapplied as a patch when you upgrade.
>
> At this point, if you don't have that, you could download the 2.1.12
> source tarball from <https://launchpad.net/mailman/2.1/2.1.12> or
> <http://ftp.gnu.org/gnu/mailman/>, unpack it and diff it against your
> 2.1.12 /usr/lib/mailman to see what you changed. You may have to sift a
> bit to separate your changes from any RedHat package changes, but you
> should be able to work it out.
>
>
Thanks again for the reply. I doubt it is a cookie cache issue since I
tried the access from the newly installed user and browser but I'll play
with it some more. I'll see if I can run the change URL script in the
kickstart file. I am hoping that mailman does not need to be running to
do that. I do have the patch files, but I question if they are directly
compatible with this version so I haven't tried that yet.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150108/69afcd20/attachment-0001.sig>

From xie.47 at osu.edu  Fri Jan  9 15:30:47 2015
From: xie.47 at osu.edu (Xie, Wei)
Date: Fri, 9 Jan 2015 14:30:47 +0000
Subject: [Mailman-Users] Does mailman 2.1.18 support hebrew language ?
Message-ID: <2F60D2B899AFBC4FAF660B2D9845BE8F0DD80A49@CIO-KRC-D1MBX06.osuad.osu.edu>

Mark,

We have a customer who reports one problem - digest is changing hebrew language to question marks. We just want to know whether mailman 2.1.18 support hebrew language. If support, how to set up?

Thanks,

Carl Xie
Ohio State University

From mark at msapiro.net  Fri Jan  9 17:21:43 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 09 Jan 2015 08:21:43 -0800
Subject: [Mailman-Users] Does mailman 2.1.18 support hebrew language ?
In-Reply-To: <2F60D2B899AFBC4FAF660B2D9845BE8F0DD80A49@CIO-KRC-D1MBX06.osuad.osu.edu>
References: <2F60D2B899AFBC4FAF660B2D9845BE8F0DD80A49@CIO-KRC-D1MBX06.osuad.osu.edu>
Message-ID: <54B00017.9010503@msapiro.net>

On 01/09/2015 06:30 AM, Xie, Wei wrote:
> Mark,
> 
> We have a customer who reports one problem - digest is changing hebrew language to question marks. We just want to know whether mailman 2.1.18 support hebrew language. If support, how to set up?


Mailman has supported Hebrew since 2.1.10. That is not your issue. Your
issue is that users are posting Hebrew to a list whose
preferred_language is English and Mailman's character set for English is
ASCII. The plain text digest is encoded in the character set of the
list's preferred language, thus the non-ascii characters are replaced.

You have a number of choices:

1) If users subscribe to the MIME format digest, each message will be in
a separate message/rfc822 MIME part and will retain its original encoding.

2) If you set the list's preferred_language to Hebrew on the list admin
Language options page, the plain text digest will be utf-8 encoded and
the Hebrew characters won't be replaced, but then the web UI and other
things like the digest boiler plate and TOC will be in Hebrew.

3) You can set Mailman's character set for English to utf-8 by putting

add_language('en', 'English (USA)', 'utf-8')

in mm_cfg.py (and restarting Mailman). The downside of this is the
bodies of Mailman generated messages including plain digests will be
base64 encoded and will not be readable by non-MIME aware MUAs. This is
not much of an issue these days as such MUAs are rare.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From xie.47 at osu.edu  Fri Jan  9 18:41:29 2015
From: xie.47 at osu.edu (Xie, Wei)
Date: Fri, 9 Jan 2015 17:41:29 +0000
Subject: [Mailman-Users] Does mailman 2.1.18 support hebrew language ?
In-Reply-To: <54B00017.9010503@msapiro.net>
References: <2F60D2B899AFBC4FAF660B2D9845BE8F0DD80A49@CIO-KRC-D1MBX06.osuad.osu.edu>
 <54B00017.9010503@msapiro.net>
Message-ID: <2F60D2B899AFBC4FAF660B2D9845BE8F0DD80C33@CIO-KRC-D1MBX06.osuad.osu.edu>

Mark,

First, thank for your explanation in  detail.

Second, Let me tell you what current settings related to digest.

1) In the member option page http://WEBSERVER/mailman/options/LISTNAME/<this user>, there is one setting "Get MIME or Plain Text Digests?", current setting is "Plain Text";
     In same page, the setting " What language do you prefer?" is "English(USA)" but there is a drop-down list including language "Hebrew";

2) In the list admin Language options page, the setting "default language for this list" is set to "English(USA)", the setting "Languages supported by this list" is set to "English (USA)" and "Hebrew";
     In same page, the setting " When receiving digests, which format is default?" is "Plain", but I see the note "(Edit mime is default digest)";

3) In file Defaults.py, I see the following setting about English (USA). But in mm_cfg.py, there is no customized setting about English (USA).

add_language('en',    _('English (USA)'),       'us-ascii',    'ltr')


Third, the below is my questions about three choices.

1)      If users subscribe to the MIME format digest, each message will be in a separate message/rfc822 MIME part and will retain its original encoding.

      Questions - do you mean this customer can change setting "Get MIME or Plain Text Digests?" to "MIME" in above member options page I mention?  No need to change other customer settings?
                              Can the setting ensure this customer is able to read English and Hebrew in same message

2)      If you set the list's preferred_language to Hebrew on the list admin Language options page, the plain text digest will be utf-8 encoded and the Hebrew characters won't be replaced, but then the web UI and other things like the digest boiler plate and TOC will be in Hebrew.

      Questions - if we make above change, other digest users in this list will see Hebrew, right? The list owners must not agree to this change. Also, do you think we should change the setting the " When receiving digests, which format is default?" from "Plain" to "MIME".

3)      You can set Mailman's character set for English to utf-8 by putting

      add_language('en', 'English (USA)', 'utf-8')

      in mm_cfg.py (and restarting Mailman). The downside of this is the bodies of Mailman generated messages including plain digests will be
      base64 encoded and will not be readable by non-MIME aware MUAs. This is not much of an issue these days as such MUAs are rare.

      If the settings in above member option page can fix this customer's problem, we will be cautious to make the change to impact our mailing lists.

Thanks,

Carl Xie

-----Original Message-----
From: Mark Sapiro [mailto:mark at msapiro.net]
Sent: Friday, January 09, 2015 11:22 AM
To: Xie, Wei; mailman-users at python.org
Subject: Re: Does mailman 2.1.18 support hebrew language ?

On 01/09/2015 06:30 AM, Xie, Wei wrote:
> Mark,
>
> We have a customer who reports one problem - digest is changing hebrew language to question marks. We just want to know whether mailman 2.1.18 support hebrew language. If support, how to set up?


Mailman has supported Hebrew since 2.1.10. That is not your issue. Your issue is that users are posting Hebrew to a list whose preferred_language is English and Mailman's character set for English is ASCII. The plain text digest is encoded in the character set of the list's preferred language, thus the non-ascii characters are replaced.

You have a number of choices:

1) If users subscribe to the MIME format digest, each message will be in a separate message/rfc822 MIME part and will retain its original encoding.

2) If you set the list's preferred_language to Hebrew on the list admin Language options page, the plain text digest will be utf-8 encoded and the Hebrew characters won't be replaced, but then the web UI and other things like the digest boiler plate and TOC will be in Hebrew.

3) You can set Mailman's character set for English to utf-8 by putting

add_language('en', 'English (USA)', 'utf-8')

in mm_cfg.py (and restarting Mailman). The downside of this is the bodies of Mailman generated messages including plain digests will be
base64 encoded and will not be readable by non-MIME aware MUAs. This is not much of an issue these days as such MUAs are rare.

--
Mark Sapiro <mark at msapiro.net<mailto:mark at msapiro.net>>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan


From mark at msapiro.net  Sat Jan 10 02:42:57 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 09 Jan 2015 17:42:57 -0800
Subject: [Mailman-Users] Does mailman 2.1.18 support hebrew language ?
In-Reply-To: <2F60D2B899AFBC4FAF660B2D9845BE8F0DD80C33@CIO-KRC-D1MBX06.osuad.osu.edu>
References: <2F60D2B899AFBC4FAF660B2D9845BE8F0DD80A49@CIO-KRC-D1MBX06.osuad.osu.edu>
 <54B00017.9010503@msapiro.net>
 <2F60D2B899AFBC4FAF660B2D9845BE8F0DD80C33@CIO-KRC-D1MBX06.osuad.osu.edu>
Message-ID: <54B083A1.80501@msapiro.net>

On 01/09/2015 09:41 AM, Xie, Wei wrote:
>  
> 1) In the member option page
> _http://WEBSERVER/mailman/options/LISTNAME/<this_ user>, there is one
> setting "Get MIME or Plain Text Digests?", current setting is "Plain Text";
>      In same page, the setting " What language do you prefer?" is
> "English(USA)" but there is a drop-down list including language "Hebrew";


OK. Note that this user could set her preferred language to Hebrew, but
that wont help solve this issue.


> 2) In the list admin Language options page, the setting "default
> language for this list" is set to "English(USA)", the setting "Languages
> supported by this list" is set to "English (USA)" and "Hebrew";


OK


>      In same page, the setting " When receiving digests, which format is
> default?" is "Plain", but I see the note "(Edit mime is default digest)";


I think that would be on the Digest options page, not the Language
options page.  The name of the list attribute (setting) is
'mime_is_default_digest' It has two possible values, False indicating
Plain is the default and True indicating MIME is the default.

Every setting in the web UI has a link associated with it which is
either "Details for setting_name" (a link to additional info) or if
there is no additional info, "Edit setting_name" which just links to a
page containing only that setting.

I.E. 'mime_is_default_digest' is the name of the setting, not the actual
default.


> 3) In file Defaults.py, I see the following setting about English (USA).
> But in mm_cfg.py, there is no customized setting about English (USA).
>  
> add_language('en',    _('English (USA)'),       'us-ascii',    'ltr')


Yes, and if you wanted to change that default you could put, e.g.

add_language('en',    'English (USA)',       'utf-8',    'ltr')

in mm_cfg.py (never change Defa>
>ults.py). For technical reasons, if you override this setting in
mm_cfg.py, you should not include the i18n _() function around the
language name. Also, the language direction 'ltr' -> left to right is
the default and can be omitted which Is why it would be sufficient to put

add_language('en', 'English (USA)', 'utf-8')

in mm_cfg.py to change Mailman's character set for 'en'.  Note also that
this only works because the English templates and messages are in ASCII
which is a proper subset of utf-8.


> Third, the below is my questions about three choices.
>  
> 
>  1. If users subscribe to the MIME format digest, each message will be
>     in a separate message/rfc822 MIME part and will retain its original
>     encoding.
> 
>  
> Questions ? do you mean this customer can change setting "Get MIME or
> Plain Text Digests?" to ?MIME? in above member options page I mention? 
> No need to change other customer settings?


Yes.


>                         Can the setting ensure this customer is able to
> read English and Hebrew in same message


I have no idea what the user can read, but with this setting and no
change to the list's preferred_language, the digest masthead and TOC
will still be in English, and each message in the digest will be in its
own message/rfc822 part in the original language and character set in
which it was posted, just like the messages delivered to non-digest members.

Note however that some MUAs (mail clients) are not good at understanding
MIME format digests so the user experience will vary depending on their
choice of MUA. The only way for a user to know if she will like the MIME
format is to try it.


>  2. If you set the list's preferred_language to Hebrew on the list admin
>     Language options page, the plain text digest will be utf-8 encoded
>     and the Hebrew characters won't be replaced, but then the web UI and
>     other things like the digest boiler plate and TOC will be in Hebrew.
> 
>  
> Questions ? if we make above change, other digest users in this list
> will see Hebrew, right? The list owners must not agree to this change.
> Also, do you think we should change the setting the " When receiving
> digests, which format is default?" from "Plain" to ?MIME?.


Yes, I think for this list in particular, 'mime_is_default_digest'
should be set to MIME.

If you change the list's preferred language to Hebrew, the list's admin
and admindb interfaces will be in Hebrew, the digest manifest and TOC
will be in Hebrew, Mailman's notices to the admins/moderators will be in
Hebrew, but Mailman notices (not digests) to users will be in the user's
preferred language as set on the options page.

The individual messages in the digest will be in whatever language they
were originally posted, but the character set of the plain format digest
will be utf-8 so that Hebrew letters won't be changed to '?'


>  3. You can set Mailman's character set for English to utf-8 by putting
> 
>  
> add_language('en', 'English (USA)', 'utf-8')
>  
> in mm_cfg.py (and restarting Mailman). The downside of this is the
> bodies of Mailman generated messages including plain digests will be
> base64 encoded and will not be readable by non-MIME aware MUAs. This is
> not much of an issue these days as such MUAs are rare.
>  
> If the settings in above member option page can fix this customer?s
> problem, we will be cautious to make the change to impact our mailing lists.


Set the users to receive MIME digests and set MIME as the default
format. There is now a script at
<http://www.msapiro.net/scripts/set_mime.py> that will do that.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From sm at noisynotes.com  Sat Jan 10 15:53:20 2015
From: sm at noisynotes.com (Steve Matzura)
Date: Sat, 10 Jan 2015 09:53:20 -0500
Subject: [Mailman-Users] We're sorry, we hit a bug!
In-Reply-To: <mpro.n81hvj1ubbxhc02sz@wagenaar.nu>
References: <mpro.n81dyg1j1bsxc02sz@wagenaar.nu>
 <53B2CDC0.1090409@msapiro.net> <mpro.n81hvj1ubbxhc02sz@wagenaar.nu>
Message-ID: <n5f2ba1ebr3s49e7j820q814gum6f094tq@4ax.com>

Well, on a new implementation, I'm getting the same thing in 2.18-1.
What'd you do to fix it on your end?

On Tue, 1 Jul 2014 17:33:19 +0200, you wrote:

>Mark Sapiro <mark at msapiro.net> wrote:
>
>
>> The above message indicates the traceback was written to some 'error' log,
>> just not the one you're looking at.
>> 
>> You can always edit (temporarily) Mailman's scripts/driver and at line 33
>> change
>> 
>> STEALTH_MODE = 1
>> 
>> to
>> 
>> STEALTH_MODE = 0
>> 
>> and that will allow the traceback and other diagnostic info to be displayed
>> instead of the "We're sorry, we hit a bug!" message.
>> 
>> 
>> > Would like to show some logging, but it simply is not there.
>> 
>> 
>> It was successfully written to an 'error' log somewhere or the "We're sorry,
>> we hit a bug!" message would say:
>> 
>> "Mailman experienced a very low level failure and could not even generate a
>> useful traceback for you.  Please report this to the Mailman administrator at
>> this site."
>> 
>
>Thanks Mark, the page is showing that the log location was not writeable, must
>be the bug.
>
>Resetting the LOG_DIR to default saved me.
>
>Apologies for the noise.

From sm at noisynotes.com  Sat Jan 10 16:01:25 2015
From: sm at noisynotes.com (Steve Matzura)
Date: Sat, 10 Jan 2015 10:01:25 -0500
Subject: [Mailman-Users] 18-1 Bug with Empty error logfile
Message-ID: <9jf2ba1psaf7hfqtj0e7qs86nsanlem7ts@4ax.com>

I just brought up a new 2.1.18-1 installation and am geting the "we're
sorry but we encountered a bug" page on theadmin interface.
/var/log/mail/error is 0-length. Should I turn stealth mode off to get
more info possibly?
 

From jim.black2006 at hotmail.co.uk  Sat Jan 10 16:14:41 2015
From: jim.black2006 at hotmail.co.uk (Jim Black)
Date: Sat, 10 Jan 2015 15:14:41 +0000
Subject: [Mailman-Users] Tend to pending moderator requests error when
	logging in
Message-ID: <DUB110-W479EB97A945B14EC9DD063B1450@phx.gbl>

Does anyone know how to solve this error problem when clicking on the link to 

"Tend to pending moderator requests" 

resulting in the error message:

Bug in Mailman version 2.1.18-1 
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. 


My hosting provider cannot get me the log files, so hopefully there will be others who encountered this problem too. 		 	   		  

From mark at msapiro.net  Sat Jan 10 19:04:43 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 10 Jan 2015 10:04:43 -0800
Subject: [Mailman-Users] 18-1 Bug with Empty error logfile
In-Reply-To: <9jf2ba1psaf7hfqtj0e7qs86nsanlem7ts@4ax.com>
References: <9jf2ba1psaf7hfqtj0e7qs86nsanlem7ts@4ax.com>
Message-ID: <54B169BB.7000509@msapiro.net>

On 01/10/2015 07:01 AM, Steve Matzura wrote:
> I just brought up a new 2.1.18-1 installation and am geting the "we're
> sorry but we encountered a bug" page on theadmin interface.
> /var/log/mail/error is 0-length. Should I turn stealth mode off to get
> more info possibly?


First, try running Mailman's

bin/check_perms -f

as root and see if it fixes permissions on the log directory/files.

Once permissions are fixed, your "bug" may go away. If not and if there
is still no error log entry, try turning off stealth mode.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Sat Jan 10 19:08:59 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 10 Jan 2015 10:08:59 -0800
Subject: [Mailman-Users] We're sorry, we hit a bug!
In-Reply-To: <n5f2ba1ebr3s49e7j820q814gum6f094tq@4ax.com>
References: <mpro.n81dyg1j1bsxc02sz@wagenaar.nu>
 <53B2CDC0.1090409@msapiro.net> <mpro.n81hvj1ubbxhc02sz@wagenaar.nu>
 <n5f2ba1ebr3s49e7j820q814gum6f094tq@4ax.com>
Message-ID: <54B16ABB.9090002@msapiro.net>

On 01/10/2015 06:53 AM, Steve Matzura wrote:
> Well, on a new implementation, I'm getting the same thing in 2.18-1.
> What'd you do to fix it on your end?


I think that one was a permissions error. As Mr. Wagenaar reported, he
had overridden the LOG_DIR setting and it pointed to an unwritable location.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From brian at emwd.com  Sat Jan 10 19:08:14 2015
From: brian at emwd.com (Brian Carpenter)
Date: Sat, 10 Jan 2015 13:08:14 -0500
Subject: [Mailman-Users] Tend to pending moderator requests error
	when	logging in
In-Reply-To: <DUB110-W479EB97A945B14EC9DD063B1450@phx.gbl>
References: <DUB110-W479EB97A945B14EC9DD063B1450@phx.gbl>
Message-ID: <238c01d02d00$67688f60$3639ae20$@emwd.com>

It is very important that your hosting provider reviews the mailman error
log to see what is causing that error. In my experience it is usually a
permission issue and those are easily fixed. cPanel (which I believe is your
platform, provides scripts that will correct permission problems on
individual lists. Your hosting provider should be able to easily do this for
you. If not send me a private message to inquire more about moving to a host
that gladly supports mailman (that would be us).


Brian Carpenter
Owner

www.mailmanhost.com
www.emwd.com

E: brian at emwd.com
www.emwd.com

?



> -----Original Message-----
> From: Mailman-Users [mailto:mailman-users-
> bounces+brian=emwd.com at python.org] On Behalf Of Jim Black
> Sent: Saturday, January 10, 2015 10:15 AM
> To: mailman-users at python.org
> Subject: [Mailman-Users] Tend to pending moderator requests error when
> logging in
> 
> Does anyone know how to solve this error problem when clicking on the link
> to
> 
> "Tend to pending moderator requests"
> 
> resulting in the error message:
> 
> Bug in Mailman version 2.1.18-1
> 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.
> 
> 
> My hosting provider cannot get me the log files, so hopefully there will
be
> others who encountered this problem too.
> 
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/brian%40emwd.com


From mark at msapiro.net  Sat Jan 10 20:12:47 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 10 Jan 2015 11:12:47 -0800
Subject: [Mailman-Users] Tend to pending moderator requests error when
 logging in
In-Reply-To: <DUB110-W479EB97A945B14EC9DD063B1450@phx.gbl>
References: <DUB110-W479EB97A945B14EC9DD063B1450@phx.gbl>
Message-ID: <54B179AF.4080106@msapiro.net>

On 01/10/2015 07:14 AM, Jim Black wrote:
> Does anyone know how to solve this error problem when clicking on the link to 
> 
> "Tend to pending moderator requests" 
> 
> resulting in the error message:
> 
> Bug in Mailman version 2.1.18-1 


See my comments in your bug report at
<https://bugs.launchpad.net/mailman/+bug/1409292>

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From sm at noisynotes.com  Sat Jan 10 22:29:12 2015
From: sm at noisynotes.com (Steve Matzura)
Date: Sat, 10 Jan 2015 16:29:12 -0500
Subject: [Mailman-Users] 18-1 Bug with Empty error logfile
In-Reply-To: <54B169BB.7000509@msapiro.net>
References: <9jf2ba1psaf7hfqtj0e7qs86nsanlem7ts@4ax.com>
 <54B169BB.7000509@msapiro.net>
Message-ID: <d563bahvjkrk9t9imcsnjq9nv9gel515ac@4ax.com>

Yes!Found and fixed three permissions errors. Then I logged in as
asministrator and turned up another perms error, but this time it was
logged to /var/log/mail/error so I was able to find and fix it.
/etc/mailman/adm.pw was +644 owner=root group=roott. check_perms
changed it to group=mailman as it should be. All good now, and of
course, many thanks. It's always the little things.

On Sat, 10 Jan 2015 10:04:43 -0800, you wrote:

>On 01/10/2015 07:01 AM, Steve Matzura wrote:
>> I just brought up a new 2.1.18-1 installation and am geting the "we're
>> sorry but we encountered a bug" page on theadmin interface.
>> /var/log/mail/error is 0-length. Should I turn stealth mode off to get
>> more info possibly?
>
>
>First, try running Mailman's
>
>bin/check_perms -f
>
>as root and see if it fixes permissions on the log directory/files.
>
>Once permissions are fixed, your "bug" may go away. If not and if there
>is still no error log entry, try turning off stealth mode.

From mark at msapiro.net  Sun Jan 11 07:06:11 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 10 Jan 2015 22:06:11 -0800
Subject: [Mailman-Users] Migration Problem
In-Reply-To: <54AF2259.10802@bellsouth.net>
References: <54ADEEFB.9010608@bellsouth.net> <54ADF70B.1000407@msapiro.net>
 <54AF118E.5010001@bellsouth.net> <54AF1B7D.8080102@msapiro.net>
 <54AF2259.10802@bellsouth.net>
Message-ID: <54B212D3.8090000@msapiro.net>

On 01/08/2015 04:35 PM, Dennis Putnam wrote:

> I do have the patch files, but I question if they are directly
> compatible with this version so I haven't tried that yet.


Usually when applying patches from a prior version, there are at most
only minor line number offsets. Occasionally there are more serious
conflicts that have to be resolved by hand, but this is normally not
difficult if you understand what the patch is doing.

The only way to know is to apply the patches and see the results. if the
patch command doesn't complain, that patch is good. if it complains only
about line # offsets, it's almost certainly still good, and you can diff
the .orig file the patch command makes with the new file to get a new
patch with correct line numbers. If it complains about failed hunks, you
have to manually examine the .rej file to see the problems and figure
out how to fix them. Often the changed code is good, but the patch fails
because one of the adjacent lines changed.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150110/9c77dc42/attachment.sig>

From dap1 at bellsouth.net  Sun Jan 11 15:23:26 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Sun, 11 Jan 2015 09:23:26 -0500
Subject: [Mailman-Users] Migration Problem
In-Reply-To: <54B212D3.8090000@msapiro.net>
References: <54ADEEFB.9010608@bellsouth.net> <54ADF70B.1000407@msapiro.net>
 <54AF118E.5010001@bellsouth.net> <54AF1B7D.8080102@msapiro.net>
 <54AF2259.10802@bellsouth.net> <54B212D3.8090000@msapiro.net>
Message-ID: <54B2875E.2070204@bellsouth.net>

Hi Mark,

As usual you set me on the right path. Thanks.

On 1/11/2015 1:06 AM, Mark Sapiro wrote:
> On 01/08/2015 04:35 PM, Dennis Putnam wrote:
>
>> I do have the patch files, but I question if they are directly
>> compatible with this version so I haven't tried that yet.
>
> Usually when applying patches from a prior version, there are at most
> only minor line number offsets. Occasionally there are more serious
> conflicts that have to be resolved by hand, but this is normally not
> difficult if you understand what the patch is doing.
>
> The only way to know is to apply the patches and see the results. if the
> patch command doesn't complain, that patch is good. if it complains only
> about line # offsets, it's almost certainly still good, and you can diff
> the .orig file the patch command makes with the new file to get a new
> patch with correct line numbers. If it complains about failed hunks, you
> have to manually examine the .rej file to see the problems and figure
> out how to fix them. Often the changed code is good, but the patch fails
> because one of the adjacent lines changed.
>
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/dap1%40bellsouth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150111/d8bb2685/attachment.sig>

From cnulk at scu.edu  Wed Jan 14 06:04:36 2015
From: cnulk at scu.edu (Chris Nulk)
Date: Tue, 13 Jan 2015 21:04:36 -0800
Subject: [Mailman-Users] Upgrading/migrating Mailman v2.1.9 -> v2.1.18-1
Message-ID: <CA+SpAKWmBQ8j6Y1PkmNzN-7mkp=QpAt2PUdqrZOHumtk==1JiQ@mail.gmail.com>

Hello all,

I will be upgrading/migrating from a v2.1.9 Mailman installation to a
v2.1.18-1 Mailman installation.  In addition, I will be upgrading the
hardware and will be keeping the name of the system the same.  I have a few
questions if anyone can help.

I will be keeping the current installation (v2.1.9) running while I build
the new installation (v2.1.18-1).

Are there any issues I should watch for using the following process?

Assuming the current system is named 'lists.example.com' and the new system
is named 'newlists.example.com' (temporarily)

- Build the new installation (v2.1.18-1), configure and test it
- Migrate all the list configs and list archives from the current system to
the new system
- run check_perms -f (just to be safe)
- run fix_url on the new system (probably not necessary but I want to make
sure the lists are working on the new system).
- test several of the key lists (receiving messages, sending messages to
members, ability to make config changes)
- change the current system from 'lists.example.com' to '
oldlists.example.com', change/update system name/DNS/firewall entries, run
check_perms and fix_url, and restart Mailman
- change the new system from 'newlists.example.com' to 'lists.example.com',
change/update system name/DNS/firewall entries, run check_perms and
fix_url, and restart Mailman
- test several of the key lists for proper operation

At a first pass, I think I have covered most (hopefully, all) potential
issues.  The process should allow me make sure the new installation is
working before the lists are moved, after the lists are moved but before
the system name is changed, and after the system named is change.  The
result should be a new upgraded and migrated Mailman installation.

Does the process seem reasonable and workable?

The next issue that I have to mix in are customizations to Mailman.  I plan
on adding the customizations back in between the first two steps above with
additional testing of course.

The question about customizations is how different is the code between
v2.1.9 and 2.1.18-1?
If I create patches with the difference between the original v2.1.9 code
and my customizations using diff -Nu, will I be able to apply those patches
to the v2.1.18-1 code?

Naturally, I will make copies of any files that will be changed before
applying the patches.  Also, since I do add additional attributes to the
list configs, I will be very careful with changes to versions.py and
Version.py.


Any help is appreciated.

Thanks,
Chris

From Jan at EcoReality.org  Wed Jan 14 03:21:07 2015
From: Jan at EcoReality.org (Jan Steinman)
Date: Tue, 13 Jan 2015 18:21:07 -0800
Subject: [Mailman-Users] All my lists quit working!
In-Reply-To: <mailman.103862.1420763885.18129.mailman-users@python.org>
References: <mailman.103862.1420763885.18129.mailman-users@python.org>
Message-ID: <A9523D7D-D59A-4F2A-9A06-3F6D9FDFAE57@EcoReality.org>

Thanks for your suggestions and help!

> From: Larry Stone <lstone19 at stonejongleux.com>
> 
> On Jan 8, 2015, at 7:49 AM, Jan Steinman <Jan at Bytesmiths.com> wrote:
> 
>> First, the bad news: Mac OS X 10.6.8. Yea, I've read Mark's dire warning. Please don't shoot me. I'm hoping this is a generic sort of problem.
> 
> OS X Server? or OS X (client)?

Server. If it was the client, I would just have installed Mailman myself, and it would have worked without all the crap Apple does to shoehorn it into their miserable server management package. :-(

>> When I send a message to ANY of the dozen or so lists I host, my MTA immediately says it doesn't know the addressee.
> 
> Log entries please.

It never gets as far as Mailman. No log info occurs in mailman/error or mailman/qrunner.

This is what shows up in mail.log:

Jan 13 18:04:16 dns postfix/smtpd[49973]: connect from unknown[10.1.1.2]
Jan 13 18:04:16 dns postfix/smtpd[49973]: NOQUEUE: reject: RCPT from unknown[10.1.1.2]: 550 5.1.1 <Farmers at EcoReality.org>: Recipient address rejected: User unknown in virtual alias table; from=<Jan at EcoReality.org> to=<Farmers at EcoReality.org> proto=ESMTP helo=<[10.1.1.2]>
Jan 13 18:04:16 dns postfix/smtpd[49973]: disconnect from unknown[10.1.1.2]

>> /etc/postfix/main.cf contains the following lines:
>> 	virtual_alias_maps = hash:/etc/postfix/virtual,hash:/var/mailman/data/virtual-mailman,hash:/etc/postfix/virtual_users
>> 	alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
>> 
> Please provide your postconf -n . That will show how postfix is actually configured, not how you think it is configured by providing just a few lines out of main.cf. 

# postconf -n
2bounce_notice_recipient = postmaster
access_map_reject_code = 554
address_verify_default_transport = $default_transport
address_verify_local_transport = $local_transport
address_verify_map = 
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_poll_count = 3
address_verify_poll_delay = 3s
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
address_verify_relay_transport = $relay_transport
address_verify_relayhost = $relayhost
address_verify_sender = $double_bounce_sender
address_verify_sender_dependent_relayhost_maps = $sender_dependent_relayhost_maps
address_verify_service_name = verify
address_verify_transport_maps = $transport_maps
address_verify_virtual_transport = $virtual_transport
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
allow_mail_to_commands = alias, forward
allow_mail_to_files = alias, forward
always_bcc = 
anvil_rate_time_unit = 60s
anvil_status_update_time = 600s
application_event_drain_time = 100s
authorized_flush_users = static:anyone
authorized_mailq_users = static:anyone
authorized_submit_users = static:anyone
backwards_bounce_logfile_compatibility = yes
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
best_mx_transport = 
body_checks_size_limit = 51200
bounce_notice_recipient = postmaster
bounce_queue_lifetime = 5d
bounce_service_name = bounce
bounce_size_limit = 50000
bounce_template_file = 
canonical_classes = envelope_sender, envelope_recipient, header_sender, header_recipient
check_for_od_forward = yes
cleanup_service_name = cleanup
command_directory = /usr/sbin
command_execution_directory = 
command_expansion_filter = 1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
command_time_limit = 1000s
config_directory = /etc/postfix
connection_cache_protocol_timeout = 5s
connection_cache_service_name = scache
connection_cache_status_update_time = 600s
connection_cache_ttl_limit = 2s
content_filter = smtp-amavis:[127.0.0.1]:10024
cyrus_sasl_config_path = 
daemon_directory = /usr/libexec/postfix
daemon_timeout = 18000s
data_directory = /var/lib/postfix
debug_peer_level = 2
debug_peer_list = 
default_database_type = hash
default_delivery_slot_cost = 5
default_delivery_slot_discount = 50
default_delivery_slot_loan = 3
default_destination_concurrency_failed_cohort_limit = 1
default_destination_concurrency_limit = 20
default_destination_concurrency_negative_feedback = 1
default_destination_concurrency_positive_feedback = 1
default_destination_rate_delay = 0s
default_destination_recipient_limit = 50
default_extra_recipient_limit = 1000
default_minimum_delivery_slots = 3
default_privs = nobody
default_process_limit = 100
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}
default_recipient_limit = 20000
default_recipient_refill_delay = 5s
default_recipient_refill_limit = 100
default_transport = smtp
default_verp_delimiters = +=
defer_code = 450
defer_service_name = defer
defer_transports = 
delay_logging_resolution_limit = 2
delay_notice_recipient = postmaster
delay_warning_time = 0h
deliver_lock_attempts = 20
deliver_lock_delay = 1s
destination_concurrency_feedback_debug = no
detect_8bit_encoding_header = yes
dont_remove = 0
double_bounce_sender = double-bounce
duplicate_filter_limit = 1000
empty_address_recipient = MAILER-DAEMON
empty_address_relayhost_maps_lookup_key = <>
enable_original_recipient = yes
enable_server_options = yes
error_notice_recipient = postmaster
error_service_name = error
execution_directory_expansion_filter = 1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
export_environment = TZ MAIL_CONFIG LANG
fallback_transport = 
fallback_transport_maps = 
fast_flush_domains = $relay_domains
fast_flush_purge_time = 7d
fast_flush_refresh_time = 12h
fault_injection_code = 0
flush_service_name = flush
fork_attempts = 5
fork_delay = 1s
forward_expansion_filter = 1234567890!@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
forward_path = $home/.forward${recipient_delimiter}${extension}, $home/.forward
frozen_delivered_to = yes
hash_queue_depth = 1
hash_queue_names = deferred,defer
header_address_token_limit = 10240
header_checks = pcre:/etc/postfix/custom_header_checks
header_size_limit = 102400
hopcount_limit = 50
html_directory = /usr/share/doc/postfix/html
import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY DISPLAY LANG=C
in_flow_delay = 1s
inet_interfaces = all
inet_protocols = ipv4
initial_destination_concurrency = 5
internal_mail_filter_classes = 
invalid_hostname_reject_code = 501
ipc_idle = 5s
ipc_timeout = 3600s
ipc_ttl = 1000s
line_length_limit = 2048
lmtp_bind_address = 
lmtp_bind_address6 = 
lmtp_body_checks = 
lmtp_cname_overrides_servername = no
lmtp_connect_timeout = 0s
lmtp_connection_cache_destinations = 
lmtp_connection_cache_on_demand = yes
lmtp_connection_cache_time_limit = 2s
lmtp_connection_reuse_time_limit = 300s
lmtp_data_done_timeout = 600s
lmtp_data_init_timeout = 120s
lmtp_data_xfer_timeout = 180s
lmtp_defer_if_no_mx_address_found = no
lmtp_destination_concurrency_failed_cohort_limit = $default_destination_concurrency_failed_cohort_limit
lmtp_destination_concurrency_limit = $default_destination_concurrency_limit
lmtp_destination_concurrency_negative_feedback = $default_destination_concurrency_negative_feedback
lmtp_destination_concurrency_positive_feedback = $default_destination_concurrency_positive_feedback
lmtp_destination_rate_delay = $default_destination_rate_delay
lmtp_destination_recipient_limit = $default_destination_recipient_limit
lmtp_discard_lhlo_keyword_address_maps = 
lmtp_discard_lhlo_keywords = 
lmtp_enforce_tls = no
lmtp_generic_maps = 
lmtp_header_checks = 
lmtp_host_lookup = dns
lmtp_initial_destination_concurrency = $initial_destination_concurrency
lmtp_lhlo_name = $myhostname
lmtp_lhlo_timeout = 300s
lmtp_line_length_limit = 990
lmtp_mail_timeout = 300s
lmtp_mime_header_checks = 
lmtp_mx_address_limit = 5
lmtp_mx_session_limit = 2
lmtp_nested_header_checks = 
lmtp_pix_workaround_delay_time = 10s
lmtp_pix_workaround_maps = 
lmtp_pix_workaround_threshold_time = 500s
lmtp_pix_workarounds = disable_esmtp,delay_dotcrlf
lmtp_quit_timeout = 300s
lmtp_quote_rfc821_envelope = yes
lmtp_randomize_addresses = yes
lmtp_rcpt_timeout = 300s
lmtp_rset_timeout = 20s
lmtp_sasl_auth_cache_name = 
lmtp_sasl_auth_cache_time = 90d
lmtp_sasl_auth_soft_bounce = yes
lmtp_sasl_mechanism_filter = 
lmtp_sasl_path = 
lmtp_sasl_security_options = noplaintext, noanonymous
lmtp_sasl_tls_security_options = $lmtp_sasl_security_options
lmtp_sasl_tls_verified_security_options = $lmtp_sasl_tls_security_options
lmtp_sasl_type = cyrus
lmtp_send_xforward_command = no
lmtp_sender_dependent_authentication = no
lmtp_skip_5xx_greeting = yes
lmtp_starttls_timeout = 300s
lmtp_tcp_port = 24
lmtp_tls_CAfile = 
lmtp_tls_CApath = 
lmtp_tls_cert_file = 
lmtp_tls_dcert_file = 
lmtp_tls_dkey_file = $lmtp_tls_dcert_file
lmtp_tls_enforce_peername = yes
lmtp_tls_exclude_ciphers = 
lmtp_tls_fingerprint_cert_match = 
lmtp_tls_fingerprint_digest = md5
lmtp_tls_key_file = $lmtp_tls_cert_file
lmtp_tls_loglevel = 0
lmtp_tls_mandatory_ciphers = medium
lmtp_tls_mandatory_exclude_ciphers = 
lmtp_tls_mandatory_protocols = SSLv3, TLSv1
lmtp_tls_note_starttls_offer = no
lmtp_tls_per_site = 
lmtp_tls_policy_maps = 
lmtp_tls_scert_verifydepth = 9
lmtp_tls_secure_cert_match = nexthop
lmtp_tls_security_level = 
lmtp_tls_session_cache_database = 
lmtp_tls_session_cache_timeout = 3600s
lmtp_tls_verify_cert_match = hostname
lmtp_use_tls = no
lmtp_xforward_timeout = 300s
local_command_shell = 
local_destination_concurrency_failed_cohort_limit = $default_destination_concurrency_failed_cohort_limit
local_destination_concurrency_limit = 2
local_destination_concurrency_negative_feedback = $default_destination_concurrency_negative_feedback
local_destination_concurrency_positive_feedback = $default_destination_concurrency_positive_feedback
local_destination_rate_delay = $default_destination_rate_delay
local_destination_recipient_limit = 1
local_header_rewrite_clients = permit_inet_interfaces
local_initial_destination_concurrency = $initial_destination_concurrency
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
local_transport = local:$myhostname
luser_relay = 
mail_name = Postfix
mail_owner = _postfix
mail_release_date = 20080902
mail_spool_directory = /var/mail
mail_version = 2.5.5
mailbox_command = 
mailbox_command_maps = 
mailbox_delivery_lock = flock, dotlock
mailbox_size_limit = 0
mailbox_transport = dovecot
mailbox_transport_maps = 
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains = 
maps_rbl_reject_code = 554
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains = 
masquerade_exceptions = 
max_idle = 100s
max_use = 100
maximal_backoff_time = 4000s
maximal_queue_lifetime = 5d
message_reject_characters = 
message_size_limit = 10485760
message_strip_characters = 
milter_command_timeout = 30s
milter_connect_macros = j {daemon_name} v
milter_connect_timeout = 30s
milter_content_timeout = 300s
milter_data_macros = i
milter_default_action = tempfail
milter_end_of_data_macros = i
milter_end_of_header_macros = i
milter_helo_macros = {tls_version} {cipher} {cipher_bits} {cert_subject} {cert_issuer}
milter_macro_daemon_name = $myhostname
milter_macro_v = $mail_name $mail_version
milter_mail_macros = i {auth_type} {auth_authen} {auth_author} {mail_addr}
milter_protocol = 2
milter_rcpt_macros = i {rcpt_addr}
milter_unknown_command_macros = 
mime_boundary_length_limit = 2048
mime_header_checks = $header_checks
mime_nesting_limit = 100
minimal_backoff_time = 300s
multi_recipient_bounce_reject_code = 550
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = bytesmiths.com
mydomain_fallback = localhost
myhostname = mail.bytesmiths.com
mynetworks = 10.1.1.0/24,127.0.0.0/8,184.69.9.80/30
mynetworks_style = subnet
myorigin = $mydomain
nested_header_checks = $header_checks
newaliases_path = /usr/bin/newaliases
non_fqdn_reject_code = 504
non_smtpd_milters = 
notify_classes = resource, software
owner_request_special = no
parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps
permit_mx_backup_networks = 
pickup_service_name = pickup
plaintext_reject_code = 450
prepend_delivered_header = command, file, forward
process_id_directory = pid
propagate_unmatched_extensions = canonical, virtual
proxy_interfaces = 
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
proxy_write_maps = $smtp_sasl_auth_cache_name $lmtp_sasl_auth_cache_name
qmgr_clog_warn_time = 300s
qmgr_fudge_factor = 100
qmgr_message_active_limit = 20000
qmgr_message_recipient_limit = 20000
qmgr_message_recipient_minimum = 10
qmqpd_authorized_clients = 
qmqpd_client_port_logging = no
qmqpd_error_delay = 1s
qmqpd_timeout = 300s
queue_directory = /private/var/spool/postfix
queue_file_attribute_count_limit = 100
queue_minfree = 0
queue_run_delay = 300s
queue_service_name = qmgr
rbl_reply_maps = 
readme_directory = /usr/share/doc/postfix
receive_override_options = 
recipient_bcc_maps = 
recipient_canonical_classes = envelope_recipient, header_recipient
recipient_delimiter = +
reject_code = 554
relay_clientcerts = 
relay_destination_concurrency_failed_cohort_limit = $default_destination_concurrency_failed_cohort_limit
relay_destination_concurrency_limit = $default_destination_concurrency_limit
relay_destination_concurrency_negative_feedback = $default_destination_concurrency_negative_feedback
relay_destination_concurrency_positive_feedback = $default_destination_concurrency_positive_feedback
relay_destination_rate_delay = $default_destination_rate_delay
relay_destination_recipient_limit = $default_destination_recipient_limit
relay_domains = $mydestination
relay_domains_reject_code = 554
relay_initial_destination_concurrency = $initial_destination_concurrency
relay_recipient_maps = 
relay_transport = relay
relayhost = 
relocated_maps = 
remote_header_rewrite_domain = 
resolve_null_domain = no
resolve_numeric_domain = no
rewrite_service_name = rewrite
sample_directory = /usr/share/doc/postfix/examples
send_cyrus_sasl_authzid = no
sender_bcc_maps = 
sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps = 
sender_dependent_relayhost_maps = 
sendmail_path = /usr/sbin/sendmail
service_throttle_time = 60s
setgid_group = _postdrop
showq_service_name = showq
smtp_bind_address6 = 
smtp_body_checks = 
smtp_cname_overrides_servername = no
smtp_connect_timeout = 30s
smtp_connection_cache_destinations = 
smtp_connection_cache_on_demand = yes
smtp_connection_cache_time_limit = 2s
smtp_connection_reuse_time_limit = 300s
smtp_data_done_timeout = 600s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 180s
smtp_defer_if_no_mx_address_found = no
smtp_destination_concurrency_failed_cohort_limit = $default_destination_concurrency_failed_cohort_limit
smtp_destination_concurrency_limit = $default_destination_concurrency_limit
smtp_destination_concurrency_negative_feedback = $default_destination_concurrency_negative_feedback
smtp_destination_concurrency_positive_feedback = $default_destination_concurrency_positive_feedback
smtp_destination_rate_delay = $default_destination_rate_delay
smtp_destination_recipient_limit = $default_destination_recipient_limit
smtp_discard_ehlo_keyword_address_maps = 
smtp_discard_ehlo_keywords = 
smtp_enforce_tls = no
smtp_fallback_relay = $fallback_relay
smtp_generic_maps = 
smtp_header_checks = 
smtp_helo_name = $myhostname
smtp_helo_timeout = 300s
smtp_host_lookup = dns
smtp_initial_destination_concurrency = $initial_destination_concurrency
smtp_line_length_limit = 990
smtp_mail_timeout = 300s
smtp_mime_header_checks = 
smtp_mx_address_limit = 5
smtp_mx_session_limit = 2
smtp_nested_header_checks = 
smtp_pix_workaround_delay_time = 10s
smtp_pix_workaround_maps = 
smtp_pix_workaround_threshold_time = 500s
smtp_pix_workarounds = disable_esmtp,delay_dotcrlf
smtp_quit_timeout = 300s
smtp_quote_rfc821_envelope = yes
smtp_rcpt_timeout = 300s
smtp_rset_timeout = 20s
smtp_sasl_auth_cache_name = 
smtp_sasl_auth_cache_time = 90d
smtp_sasl_auth_soft_bounce = yes
smtp_sasl_mechanism_filter = 
smtp_sasl_password_maps = 
smtp_sasl_path = 
smtp_sasl_security_options = noplaintext, noanonymous
smtp_sasl_tls_security_options = $smtp_sasl_security_options
smtp_sasl_tls_verified_security_options = $smtp_sasl_tls_security_options
smtp_sasl_type = cyrus
smtp_send_xforward_command = no
smtp_sender_dependent_authentication = no
smtp_starttls_timeout = 300s
smtp_tls_CAfile = 
smtp_tls_CApath = 
smtp_tls_cert_file = 
smtp_tls_dcert_file = 
smtp_tls_dkey_file = $smtp_tls_dcert_file
smtp_tls_enforce_peername = yes
smtp_tls_exclude_ciphers = 
smtp_tls_fingerprint_cert_match = 
smtp_tls_fingerprint_digest = md5
smtp_tls_key_file = $smtp_tls_cert_file
smtp_tls_loglevel = 0
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = 
smtp_tls_mandatory_protocols = SSLv3, TLSv1
smtp_tls_note_starttls_offer = no
smtp_tls_per_site = 
smtp_tls_policy_maps = 
smtp_tls_scert_verifydepth = 9
smtp_tls_secure_cert_match = nexthop, dot-nexthop
smtp_tls_security_level = 
smtp_tls_session_cache_database = 
smtp_tls_session_cache_timeout = 3600s
smtp_tls_verify_cert_match = hostname
smtp_use_tls = no
smtp_xforward_timeout = 300s
smtpd_authorized_verp_clients = $authorized_verp_clients
smtpd_authorized_xclient_hosts = 
smtpd_authorized_xforward_hosts = 
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 0
smtpd_client_event_limit_exceptions = ${smtpd_client_connection_limit_exceptions:$mynetworks}
smtpd_client_message_rate_limit = 0
smtpd_client_new_tls_session_rate_limit = 0
smtpd_client_port_logging = no
smtpd_client_recipient_rate_limit = 0
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated reject_rbl_client zen.spamhaus.org permit
smtpd_data_restrictions = 
smtpd_delay_open_until_valid_rcpt = yes
smtpd_discard_ehlo_keyword_address_maps = 
smtpd_discard_ehlo_keywords = 
smtpd_end_of_data_restrictions = 
smtpd_enforce_tls = no
smtpd_error_sleep_time = 1s
smtpd_etrn_restrictions = 
smtpd_expansion_filter = \t\40!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~
smtpd_forbidden_commands = CONNECT GET POST
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
smtpd_history_flush_threshold = 100
smtpd_junk_command_limit = 100
smtpd_milters = 
smtpd_noop_commands = 
smtpd_null_access_lookup_key = <>
smtpd_peername_lookup = yes
smtpd_policy_service_max_idle = 300s
smtpd_policy_service_max_ttl = 1000s
smtpd_policy_service_timeout = 100s
smtpd_proxy_ehlo = $myhostname
smtpd_proxy_filter = 
smtpd_proxy_timeout = 100s
smtpd_pw_server_security_options = gssapi,cram-md5,login,plain
smtpd_recipient_limit = 1000
smtpd_recipient_overshoot_limit = 1000
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_policy_service unix:private/policy permit
smtpd_reject_unlisted_recipient = yes
smtpd_reject_unlisted_sender = no
smtpd_restriction_classes = 
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = no
smtpd_sasl_exceptions_networks = 
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sasl_type = cyrus
smtpd_sender_login_maps = 
smtpd_sender_restrictions = 
smtpd_soft_error_limit = 10
smtpd_starttls_timeout = 300s
smtpd_timeout = 300s
smtpd_tls_CAfile = /etc/certificates/dns.bytesmiths.com.273AA2AEDB9AB7175B6F6846F5305DFC7506F932.chain.pem
smtpd_tls_CApath = 
smtpd_tls_always_issue_session_ids = yes
smtpd_tls_ask_ccert = no
smtpd_tls_auth_only = no
smtpd_tls_ccert_verifydepth = 9
smtpd_tls_cert_file = /etc/certificates/dns.bytesmiths.com.273AA2AEDB9AB7175B6F6846F5305DFC7506F932.cert.pem
smtpd_tls_dcert_file = 
smtpd_tls_dh1024_param_file = 
smtpd_tls_dh512_param_file = 
smtpd_tls_dkey_file = $smtpd_tls_dcert_file
smtpd_tls_exclude_ciphers = 
smtpd_tls_fingerprint_digest = md5
smtpd_tls_key_file = /etc/certificates/dns.bytesmiths.com.273AA2AEDB9AB7175B6F6846F5305DFC7506F932.key.pem
smtpd_tls_loglevel = 0
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_exclude_ciphers = 
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_received_header = no
smtpd_tls_req_ccert = no
smtpd_tls_security_level = 
smtpd_tls_session_cache_database = 
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_wrappermode = no
smtpd_use_pw_server = yes
smtpd_use_tls = yes
stale_lock_time = 500s
stress = 
strict_mailbox_ownership = yes
syslog_facility = mail
syslog_name = postfix
tls_daemon_random_bytes = 32
tls_export_cipherlist = ALL:+RC4:@STRENGTH
tls_high_cipherlist = ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
tls_low_cipherlist = ALL:!EXPORT:+RC4:@STRENGTH
tls_medium_cipherlist = ALL:!EXPORT:!LOW:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL
tls_random_bytes = 32
tls_random_exchange_name = ${data_directory}/prng_exch
tls_random_prng_update_period = 3600s
tls_random_reseed_period = 3600s
tls_random_source = dev:/dev/urandom
trace_service_name = trace
transport_maps = 
transport_retry_time = 60s
trigger_timeout = 10s
undisclosed_recipients_header = To: undisclosed-recipients:;
unknown_address_reject_code = 450
unknown_client_reject_code = 450
unknown_hostname_reject_code = 450
unknown_local_recipient_reject_code = 450
unknown_relay_recipient_reject_code = 550
unknown_virtual_alias_reject_code = 550
unknown_virtual_mailbox_reject_code = 550
unverified_recipient_reject_code = 450
unverified_sender_reject_code = 450
use_getpwnam_ext = yes
use_od_delivery_path = no
verp_delimiter_filter = -=+
virtual_alias_domains = $virtual_alias_maps hash:/etc/postfix/virtual_domains
virtual_alias_expansion_limit = 1000
virtual_alias_maps = hash:/etc/postfix/virtual,hash:/var/mailman/data/virtual-mailman,hash:/etc/postfix/virtual_users
virtual_alias_recursion_limit = 1000
virtual_destination_concurrency_failed_cohort_limit = $default_destination_concurrency_failed_cohort_limit
virtual_destination_concurrency_limit = $default_destination_concurrency_limit
virtual_destination_concurrency_negative_feedback = $default_destination_concurrency_negative_feedback
virtual_destination_concurrency_positive_feedback = $default_destination_concurrency_positive_feedback
virtual_destination_rate_delay = $default_destination_rate_delay
virtual_destination_recipient_limit = $default_destination_recipient_limit
virtual_gid_maps = 
virtual_initial_destination_concurrency = $initial_destination_concurrency
virtual_mailbox_base = 
virtual_mailbox_domains = hash:/etc/postfix/virtual_domains
virtual_mailbox_limit = 51200000
virtual_mailbox_lock = fcntl, dotlock
virtual_mailbox_maps = 
virtual_minimum_uid = 100
virtual_uid_maps = 

> Also, check your master.cf to see if there are any overrides (-o) on your smtpd entry.

# fgrep ' -o ' master.cf
  -o smtpd_tls_security_level=encrypt
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o content_filter=
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
   -o smtp_data_done_timeout=1200
   -o smtp_send_xforward_command=yes
   -o disable_dns_lookups=yes
   -o content_filter=
   -o local_recipient_maps=
   -o relay_recipient_maps=
   -o smtpd_restriction_classes=
   -o smtpd_client_restrictions=
   -o smtpd_helo_restrictions=
   -o smtpd_sender_restrictions=
   -o smtpd_recipient_restrictions=permit_mynetworks,reject
   -o mynetworks=127.0.0.0/8
   -o smtpd_enforce_tls=no
   -o strict_rfc821_envelopes=yes
   -o smtpd_error_sleep_time=0
   -o smtpd_soft_error_limit=1001
   -o smtpd_hard_error_limit=1000
   -o receive_override_options=no_header_body_checks


:::: All those things which are now held to be of the greatest antiquity, were at one time new; and what we today hold up by example, will rank hereafter as precedent. -- Tacitus
:::: Jan Steinman, EcoReality Co-op ::::


From lstone19 at stonejongleux.com  Wed Jan 14 15:58:25 2015
From: lstone19 at stonejongleux.com (Larry Stone)
Date: Wed, 14 Jan 2015 04:58:25 -1000
Subject: [Mailman-Users] All my lists quit working!
In-Reply-To: <A9523D7D-D59A-4F2A-9A06-3F6D9FDFAE57@EcoReality.org>
References: <mailman.103862.1420763885.18129.mailman-users@python.org>
 <A9523D7D-D59A-4F2A-9A06-3F6D9FDFAE57@EcoReality.org>
Message-ID: <95D5E0A1-5A33-40D6-8284-E3EF5ED9BB98@stonejongleux.com>


On Jan 13, 2015, at 4:21 PM, Jan Steinman <Jan at EcoReality.org> wrote:

> Thanks for your suggestions and help!
> 
>> From: Larry Stone <lstone19 at stonejongleux.com>
>> 
>> Log entries please.
> 
> It never gets as far as Mailman. No log info occurs in mailman/error or mailman/qrunner.
> 
> This is what shows up in mail.log:
> 
> Jan 13 18:04:16 dns postfix/smtpd[49973]: connect from unknown[10.1.1.2]
> Jan 13 18:04:16 dns postfix/smtpd[49973]: NOQUEUE: reject: RCPT from unknown[10.1.1.2]: 550 5.1.1 <Farmers at EcoReality.org>: Recipient address rejected: User unknown in virtual alias table; from=<Jan at EcoReality.org> to=<Farmers at EcoReality.org> proto=ESMTP helo=<[10.1.1.2]>
> Jan 13 18:04:16 dns postfix/smtpd[49973]: disconnect from unknown[10.1.1.2]
> 
>>> /etc/postfix/main.cf contains the following lines:
>>> 	virtual_alias_maps = hash:/etc/postfix/virtual,hash:/var/mailman/data/virtual-mailman,hash:/etc/postfix/virtual_users
>>> 	alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
>>> 

Now we?re getting somewhere. Postfix thinks Farmers at EcoReality.org is a virtual address and is trying to look it up in the virtual alias table but your Mailman aliases (per your original post) are in alias_maps which is only used for local (not virtual) addresses. I?ve never used virtual addresses in Postfix but I?d suggest looking at http://www.gnu.org/software/mailman/mailman-install/postfix-virtual.html for information on using Mailman with Postfix virtual domains.

-- 
Larry Stone
lstone19 at stonejongleux.com
http://www.stonejongleux.com/




From mark at msapiro.net  Wed Jan 14 16:04:11 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 14 Jan 2015 07:04:11 -0800
Subject: [Mailman-Users] All my lists quit working!
In-Reply-To: <A9523D7D-D59A-4F2A-9A06-3F6D9FDFAE57@EcoReality.org>
References: <mailman.103862.1420763885.18129.mailman-users@python.org>
 <A9523D7D-D59A-4F2A-9A06-3F6D9FDFAE57@EcoReality.org>
Message-ID: <54B6856B.7020500@msapiro.net>

On 01/13/2015 06:21 PM, Jan Steinman wrote:
> 
> This is what shows up in mail.log:
> 
> Jan 13 18:04:16 dns postfix/smtpd[49973]: connect from unknown[10.1.1.2]
> Jan 13 18:04:16 dns postfix/smtpd[49973]: NOQUEUE: reject: RCPT from unknown[10.1.1.2]: 550 5.1.1 <Farmers at EcoReality.org>: Recipient address rejected: User unknown in virtual alias table; from=<Jan at EcoReality.org> to=<Farmers at EcoReality.org> proto=ESMTP helo=<[10.1.1.2]>
> Jan 13 18:04:16 dns postfix/smtpd[49973]: disconnect from unknown[10.1.1.2]


EcoReality.org is a virtual domain in Postfix.

You posted earlier that data/virtual-mailman was empty. This is the issue.

You need (you may have some of it)

MTA = 'Postfix'
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['ecorealty.org']

in mm_cfg.py. If you already have these, but ecorealty.org is not in the
POSTFIX_STYLE_VIRTUAL_DOMAINS list, it needs to be added.

You also need to ensure that on the admin General Options page for the
Farmers at EcoReality.org list that the setting towards the bottom for
host_name is ecorealty.org. Then, running Mailman's bin/genaliases
should create the necessary virtual alias mappings in data/virtual-mailman.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Wed Jan 14 16:57:58 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 14 Jan 2015 07:57:58 -0800
Subject: [Mailman-Users] Upgrading/migrating Mailman v2.1.9 -> v2.1.18-1
In-Reply-To: <CA+SpAKWmBQ8j6Y1PkmNzN-7mkp=QpAt2PUdqrZOHumtk==1JiQ@mail.gmail.com>
References: <CA+SpAKWmBQ8j6Y1PkmNzN-7mkp=QpAt2PUdqrZOHumtk==1JiQ@mail.gmail.com>
Message-ID: <54B69206.7070005@msapiro.net>

On 01/13/2015 09:04 PM, Chris Nulk wrote:
> 
> Are there any issues I should watch for using the following process?
...
> Does the process seem reasonable and workable?


It looks OK to me.


> The next issue that I have to mix in are customizations to Mailman.  I plan
> on adding the customizations back in between the first two steps above with
> additional testing of course.


OK


> The question about customizations is how different is the code between
> v2.1.9 and 2.1.18-1?


Many modules are unchanged. Some have significant changes. Some have
minor changes.


> If I create patches with the difference between the original v2.1.9 code
> and my customizations using diff -Nu, will I be able to apply those patches
> to the v2.1.18-1 code?


That's the way to go. See the recent post at
<https://mail.python.org/pipermail/mailman-users/2015-January/078261.html>
for more on this.


> Naturally, I will make copies of any files that will be changed before
> applying the patches.  Also, since I do add additional attributes to the
> list configs, I will be very careful with changes to versions.py and
> Version.py.


Your main concern is with DATA_FILE_VERSION in Versions.py. As long as
you apply the changes before moving the lists You just need to be sure
that DATA_FILE_VERSION is > than that of the old installation. Then
versions.py will be run to update the lists when they are moved.

As far as additional attributes are concerned, you could ignore the
whole issue. I wouldn't if for no other reasons than documentation and
consistency, but your lists will presumably have all the additional
attributes already so the code in versions.py to add them (if missing)
won't do any harm, but won't actually be needed. As I said though, I
would ensure the code was there just for documentation and consistency
and in case at some point you migrate a list that doesn't have the
attributes.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From cnulk at scu.edu  Wed Jan 14 18:31:23 2015
From: cnulk at scu.edu (Chris Nulk)
Date: Wed, 14 Jan 2015 09:31:23 -0800
Subject: [Mailman-Users] Upgrading/migrating Mailman v2.1.9 -> v2.1.18-1
In-Reply-To: <54B69206.7070005@msapiro.net>
References: <CA+SpAKWmBQ8j6Y1PkmNzN-7mkp=QpAt2PUdqrZOHumtk==1JiQ@mail.gmail.com>
 <54B69206.7070005@msapiro.net>
Message-ID: <54B6A7EB.2050203@scu.edu>

On 1/14/2015 7:57 AM, Mark Sapiro wrote:

Thanks for your help Mark.

> On 01/13/2015 09:04 PM, Chris Nulk wrote:
>> Are there any issues I should watch for using the following process?
> ...
>> Does the process seem reasonable and workable?
>
> It looks OK to me.
Great.
>> The question about customizations is how different is the code between
>> v2.1.9 and 2.1.18-1?
>
> Many modules are unchanged. Some have significant changes. Some have
> minor changes.

Below is a list of the files I have modified (base directory is 
/usr/lib/mailman).  Should I pay special attention due to changes to any 
particular files?

bin/add_members
bin/non_members
Mailman/LDAPMemberships.py
Mailman/ListAdmin.py
Mailman/MailList.py
Mailman/Version.py
Mailman/versions.py
Mailman/Cgi/listinfo.py
Mailman/Cgi/options.py
Mailman/Gui/GUIBase.py
Mailman/Gui/Privacy.py
Mailman/Handlers/Decorate.py
Mailman/Handlers/Moderate.py
Mailman/Queue/IncomingRunner.py


>
>
>> If I create patches with the difference between the original v2.1.9 code
>> and my customizations using diff -Nu, will I be able to apply those patches
>> to the v2.1.18-1 code?
>
> That's the way to go. See the recent post at
> <https://mail.python.org/pipermail/mailman-users/2015-January/078261.html>
> for more on this.
Yep.  Read the message.  Thanks for the reminder.
>
>> Naturally, I will make copies of any files that will be changed before
>> applying the patches.  Also, since I do add additional attributes to the
>> list configs, I will be very careful with changes to versions.py and
>> Version.py.
>
> Your main concern is with DATA_FILE_VERSION in Versions.py. As long as
> you apply the changes before moving the lists You just need to be sure
> that DATA_FILE_VERSION is > than that of the old installation. Then
> versions.py will be run to update the lists when they are moved.
>
> As far as additional attributes are concerned, you could ignore the
> whole issue. I wouldn't if for no other reasons than documentation and
> consistency, but your lists will presumably have all the additional
> attributes already so the code in versions.py to add them (if missing)
> won't do any harm, but won't actually be needed. As I said though, I
> would ensure the code was there just for documentation and consistency
> and in case at some point you migrate a list that doesn't have the
> attributes.
>
I will definitely make the mods prior to moving the lists since I will 
want to make sure Mailman is still functional.

I will also most likely do the same thing I did when I did the original 
mods to Version.py and versions.py.  I will bump the DATA_FILE_VERSION 
by one and make only the minimal change needed. Actually, here are the 
two patch files I plan on using for those two files.  So I will make 
copies of the original files (for all files to be modified) and for 
Version.py I will check for the current DATA_FILE_VERSION number and 
adjust appropriately.

Patch for Version.py
---------------------------
--- Version.py.original    2008-05-24 13:44:12.000000000 -0700
+++ Version.py.Modified    2009-09-25 10:47:02.000000000 -0700
@@ -37,7 +37,9 @@
                 (REL_LEVEL << 4)  | (REL_SERIAL << 0))

  # config.pck schema version number
-DATA_FILE_VERSION = 96
+# Updated the DATA_FILE_VERSION due to adding a new
+#    variable/attribute (previous value = 96) --Modified 24-Sep-2009
+DATA_FILE_VERSION = 97

  # qfile/*.db schema version number
  QFILE_SCHEMA_VERSION = 3

Patch file for versions.py
---------------------------------
--- versions.py.original    2008-05-24 13:44:12.000000000 -0700
+++ versions.py.Modified    2009-09-24 14:15:11.000000000 -0700
@@ -113,6 +113,11 @@
          l.forward_auto_discards = mm_cfg.DEFAULT_FORWARD_AUTO_DISCARDS
      if not hasattr(l, 'generic_nonmember_action'):
          l.generic_nonmember_action = 
mm_cfg.DEFAULT_GENERIC_NONMEMBER_ACTION
+
+    # Add an additional list attribute if not present --Modified 
24-Sep-2009
+    if not hasattr(l, 'accept_special_posters'):
+        l.accept_special_posters = []
+
      # Now convert what we can...  Note that the interaction between the
      # MM2.0.x attributes `moderated', `member_posting_only', and 
`posters' is
      # so confusing, it makes my brain really ache.  Which is why they 
go away


Thanks again for the assistance Mark,
Chris

From gayleard at eircom.net  Wed Jan 14 22:14:02 2015
From: gayleard at eircom.net (Timothy Murphy)
Date: Wed, 14 Jan 2015 21:14:02 +0000
Subject: [Mailman-Users] Changing name of mailman list that I own
Message-ID: <2206968.SmaIpRukuz@william.gayleard.com>

Can I change the name of a list if I am list-owner?
(But I am not the system administrator.)

-- 
Timothy Murphy  
gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin


From cnulk at scu.edu  Thu Jan 15 01:11:23 2015
From: cnulk at scu.edu (Chris Nulk)
Date: Wed, 14 Jan 2015 16:11:23 -0800
Subject: [Mailman-Users] Small issue (hopefully) with upgrading/migrating
	from v2.1.9 to v2.1.18-1
Message-ID: <54B705AB.6010304@scu.edu>

Hello,

In a previous message, I mentioned my plans on upgrading/migrating a 
customized v2.1.9 installation to a customized v2.1.18-1 installation.  
I have analyzed the changes needed and made to the v2.1.18-1 installation.

I have run into a small problem.  One of the customizations I did was to 
added an additional attribute to the sender filters similar to the 
*_these_nonmembers fields.  On the v2.1.9 installation, my customization 
will accept individual email addresses, regex's, and lists.  On the 
v2.1.18-1 installation, it only accepts the individual email addresses.  
I took a closer look at the code (GUIBase.py in the Gui directory) and I 
believe the solution lies there.

The code on the v2.1.18-1 installation has some additional checks. 
Specifically, the following:
                     # See if this is a context that accepts regular
                     # expressions, and that the re is legal
                     if wtype == mm_cfg.EmailListEx and 
addr.startswith('^'):
                         try:
                             re.compile(addr)
                         except re.error:
                             bad_addrs.append(addr)
                     elif (wtype == mm_cfg.EmailListEx and 
addr.startswith('@')
                             and property.endswith('_these_nonmembers')):
                         # XXX Needs to be reviewed for list at domain names.
                         # don't reference your own list
                         if addr[1:] == mlist.internal_name():
                             bad_addrs.append(addr)
                         # check for existence of list?  For now allow
                         # reference to list before creating it.
                     else:
                         bad_addrs.append(addr)

On v2.1.9, the code did not check for the 'and 
property.endswith('_these_nonmembers')):'.

I think that addtional check is preventing my additional 
attribute/property from accepting lists in the field.

Before I go off and possibly muck my installation up, can I simply 
duplicate the 'elif' section with the property.endswith code and replace 
the '_these_nonmembers' with my attribute/property?

Or is a better solution to do something list:
                          elif (wtype == mm_cfg.EmailListEx and 
addr.startswith('@')
                             and (property.endswith('_these_nonmembers') 
or (property.endswith('my_attribute'))):
Would that work?

Or even more optimially, I am open to the correct solution to my issue.

Thanks for any assistance,
Chris



From mark at msapiro.net  Thu Jan 15 03:16:22 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 14 Jan 2015 18:16:22 -0800
Subject: [Mailman-Users] Changing name of mailman list that I own
In-Reply-To: <2206968.SmaIpRukuz@william.gayleard.com>
References: <2206968.SmaIpRukuz@william.gayleard.com>
Message-ID: <54B722F6.6090404@msapiro.net>

On 01/14/2015 01:14 PM, Timothy Murphy wrote:
> Can I change the name of a list if I am list-owner?
> (But I am not the system administrator.)
> 


No. You can change the list's real_name attribute, but only so it
differs only in case from the list's internal name. E.g. If the list is
junklist, its real_name could be any of junklist, JunkList, JUNKlist,
etc., but not even Junk_List would be allowed. This is the only change
you can make.

See the FAQ at <http://wiki.list.org/x/mYA9>. All the methods there
require command shell access to the server. The best you can do as a
list admin is create a new list with the new name (if you can), manually
configure it like the old list, extract the membership from the old list
(see <http://wiki.list.org/x/aYA9> and/or the script at
<http://www.msapiro.net/mailman-subscribers.py>), mass subscribe the
mmembers to the new list and then manually set their options on the new
list. Such a process will not move the archives.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Thu Jan 15 03:33:05 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 14 Jan 2015 18:33:05 -0800
Subject: [Mailman-Users] Small issue (hopefully) with
 upgrading/migrating from v2.1.9 to v2.1.18-1
In-Reply-To: <54B705AB.6010304@scu.edu>
References: <54B705AB.6010304@scu.edu>
Message-ID: <54B726E1.6070804@msapiro.net>

On 01/14/2015 04:11 PM, Chris Nulk wrote:
> 
> I have run into a small problem.  One of the customizations I did was to
> added an additional attribute to the sender filters similar to the
> *_these_nonmembers fields.  On the v2.1.9 installation, my customization
> will accept individual email addresses, regex's, and lists.  On the
> v2.1.18-1 installation, it only accepts the individual email addresses. 
> I took a closer look at the code (GUIBase.py in the Gui directory) and I
> believe the solution lies there.
> 
> The code on the v2.1.18-1 installation has some additional checks.
> Specifically, the following:
>                     # See if this is a context that accepts regular
>                     # expressions, and that the re is legal
>                     if wtype == mm_cfg.EmailListEx and
> addr.startswith('^'):
>                         try:
>                             re.compile(addr)
>                         except re.error:
>                             bad_addrs.append(addr)
>                     elif (wtype == mm_cfg.EmailListEx and
> addr.startswith('@')
>                             and property.endswith('_these_nonmembers')):
>                         # XXX Needs to be reviewed for list at domain names.
>                         # don't reference your own list
>                         if addr[1:] == mlist.internal_name():
>                             bad_addrs.append(addr)
>                         # check for existence of list?  For now allow
>                         # reference to list before creating it.
>                     else:
>                         bad_addrs.append(addr)
> 
> On v2.1.9, the code did not check for the 'and
> property.endswith('_these_nonmembers')):'.
> 
> I think that addtional check is preventing my additional
> attribute/property from accepting lists in the field.


Correct.


> Before I go off and possibly muck my installation up, can I simply
> duplicate the 'elif' section with the property.endswith code and replace
> the '_these_nonmembers' with my attribute/property?
> 
> Or is a better solution to do something list:
>                          elif (wtype == mm_cfg.EmailListEx and
> addr.startswith('@')
>                             and (property.endswith('_these_nonmembers')
> or (property.endswith('my_attribute'))):
> Would that work?
> 
> Or even more optimially, I am open to the correct solution to my issue.


I would replace the elif clause with

     elif (wtype == mm_cfg.EmailListEx and addr.startswith('@') and
             (property.endswith('_these_nonmembers') or
              property == 'my_attribute')

indented to the proper level.

DRY

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Thu Jan 15 04:03:11 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 14 Jan 2015 19:03:11 -0800
Subject: [Mailman-Users] Upgrading/migrating Mailman v2.1.9 -> v2.1.18-1
In-Reply-To: <54B6A7EB.2050203@scu.edu>
References: <CA+SpAKWmBQ8j6Y1PkmNzN-7mkp=QpAt2PUdqrZOHumtk==1JiQ@mail.gmail.com>
 <54B69206.7070005@msapiro.net> <54B6A7EB.2050203@scu.edu>
Message-ID: <54B72DEF.1050705@msapiro.net>

On 01/14/2015 09:31 AM, Chris Nulk wrote:
> 
> Below is a list of the files I have modified (base directory is
> /usr/lib/mailman).  Should I pay special attention due to changes to any
> particular files?
> 
> bin/add_members
> bin/non_members
> Mailman/LDAPMemberships.py
> Mailman/ListAdmin.py
> Mailman/MailList.py
> Mailman/Version.py
> Mailman/versions.py
> Mailman/Cgi/listinfo.py
> Mailman/Cgi/options.py
> Mailman/Gui/GUIBase.py
> Mailman/Gui/Privacy.py
> Mailman/Handlers/Decorate.py
> Mailman/Handlers/Moderate.py
> Mailman/Queue/IncomingRunner.py


LDAPMemberships.py is not part of GNU Mailman. I think the latest
version is yours, but in any case you can continue to use whatever
you're using.

For the others, if you want to look at changes in advance, go to
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/944?remember=1484&compare_revid=1484>
to compare rev 944 (2.1.9) with rev 1484 (2.1.18-1), scroll down to the
list where file names are on the left preceded with > and click the > on
the ones you're interested in to see the diff



> I will also most likely do the same thing I did when I did the original
> mods to Version.py and versions.py.  I will bump the DATA_FILE_VERSION
> by one and make only the minimal change needed.


in 2.1.18-1, DATA_FILE_VERSION is already 104. The only reason to
increment DATA_FILE_VERSION is so versions.Update() will run when an
older list in first instantiated. Since your changes were made at
DATA_FILE_VERSION = 97, there's no point in incrementing
DATA_FILE_VERSION beyond 104.


> Actually, here are the
> two patch files I plan on using for those two files.  So I will make
> copies of the original files (for all files to be modified) and for
> Version.py I will check for the current DATA_FILE_VERSION number and
> adjust appropriately.
> 
> Patch for Version.py
> ---------------------------
> --- Version.py.original    2008-05-24 13:44:12.000000000 -0700
> +++ Version.py.Modified    2009-09-25 10:47:02.000000000 -0700
> @@ -37,7 +37,9 @@
>                 (REL_LEVEL << 4)  | (REL_SERIAL << 0))
> 
>  # config.pck schema version number
> -DATA_FILE_VERSION = 96
> +# Updated the DATA_FILE_VERSION due to adding a new
> +#    variable/attribute (previous value = 96) --Modified 24-Sep-2009
> +DATA_FILE_VERSION = 97
> 
>  # qfile/*.db schema version number
>  QFILE_SCHEMA_VERSION = 3
> 
> Patch file for versions.py
> ---------------------------------
> --- versions.py.original    2008-05-24 13:44:12.000000000 -0700
> +++ versions.py.Modified    2009-09-24 14:15:11.000000000 -0700
> @@ -113,6 +113,11 @@
>          l.forward_auto_discards = mm_cfg.DEFAULT_FORWARD_AUTO_DISCARDS
>      if not hasattr(l, 'generic_nonmember_action'):
>          l.generic_nonmember_action =
> mm_cfg.DEFAULT_GENERIC_NONMEMBER_ACTION
> +
> +    # Add an additional list attribute if not present --Modified
> 24-Sep-2009
> +    if not hasattr(l, 'accept_special_posters'):
> +        l.accept_special_posters = []
> +
>      # Now convert what we can...  Note that the interaction between the
>      # MM2.0.x attributes `moderated', `member_posting_only', and
> `posters' is
>      # so confusing, it makes my brain really ache.  Which is why they
> go away


This was the wrong place to add that code. This section of versions.py
is intended to transform old attributes from say Mailman 2.0 so that
they have the equivalent semantics in the current version.

The proper way to add a new attribute is in the NewVars(l) function at
the end around line 430 add

    add_only_if_missing('accept_special_posters', [])

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From cnulk at scu.edu  Thu Jan 15 06:38:35 2015
From: cnulk at scu.edu (Chris Nulk)
Date: Wed, 14 Jan 2015 21:38:35 -0800
Subject: [Mailman-Users] Small issue (hopefully) with
 upgrading/migrating from v2.1.9 to v2.1.18-1
In-Reply-To: <54B726E1.6070804@msapiro.net>
References: <54B705AB.6010304@scu.edu>
	<54B726E1.6070804@msapiro.net>
Message-ID: <CA+SpAKUjAnaKXhtqff76dQN+Zx+xVkN90omv5iNdPZGwMT7veQ@mail.gmail.com>

On Wed, Jan 14, 2015 at 6:33 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 01/14/2015 04:11 PM, Chris Nulk wrote:
> >
> > I have run into a small problem.  One of the customizations I did was to
>
> ?.....?

>
> >
> > I think that addtional check is preventing my additional
> > attribute/property from accepting lists in the field.
>
>
> Correct.
>

?Thanks for input.  From the last time I did mods to the source?, you
helped me with a few changes.  Specifically, v2.1.9 didn't allow lists in
those fields.  You sent me a patch that backported that change from
v2.1.10.  When I did my checking, I saw that I no longer needed to do the
backport so the GUIBase.py file was dropped from needing the modification.
I am trying to make the minimal changes needed.  Looks like I will have to
add the file back.  Not a problem.


>
> > Before I go off and possibly muck my installation up, can I simply
> > duplicate the 'elif' section with the property.endswith code and replace
> > the '_these_nonmembers' with my attribute/property?
> >
> > Or is a better solution to do something list:
> >                          elif (wtype == mm_cfg.EmailListEx and
> > addr.startswith('@')
> >                             and (property.endswith('_these_nonmembers')
> > or (property.endswith('my_attribute'))):
> > Would that work?
> >
> > Or even more optimially, I am open to the correct solution to my issue.
>
>
> I would replace the elif clause with
>
>      elif (wtype == mm_cfg.EmailListEx and addr.startswith('@') and
>              (property.endswith('_these_nonmembers') or
>               property == 'my_attribute')
>
> indented to the proper level.
>

?Cool.  I will make the change like you recommend.


>
> DRY
>

?DRY?

Thanks Mark.  You are an awesome help.

Chris

P.S. Using GMail to reply just really ***** (better not say it).   Who
thought up this P**** o* P** interface?

From mark at msapiro.net  Thu Jan 15 06:43:13 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 14 Jan 2015 21:43:13 -0800
Subject: [Mailman-Users] Small issue (hopefully) with
 upgrading/migrating from v2.1.9 to v2.1.18-1
In-Reply-To: <CA+SpAKUjAnaKXhtqff76dQN+Zx+xVkN90omv5iNdPZGwMT7veQ@mail.gmail.com>
References: <54B705AB.6010304@scu.edu>	<54B726E1.6070804@msapiro.net>
 <CA+SpAKUjAnaKXhtqff76dQN+Zx+xVkN90omv5iNdPZGwMT7veQ@mail.gmail.com>
Message-ID: <54B75371.7010703@msapiro.net>

On 01/14/2015 09:38 PM, Chris Nulk wrote:
> On Wed, Jan 14, 2015 at 6:33 PM, Mark Sapiro <mark at msapiro.net> wrote:
>>
>> DRY
>>
> 
> ?DRY?

<http://en.wikipedia.org/wiki/Don%27t_repeat_yourself>

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From cnulk at scu.edu  Thu Jan 15 06:50:44 2015
From: cnulk at scu.edu (Chris Nulk)
Date: Wed, 14 Jan 2015 21:50:44 -0800
Subject: [Mailman-Users] Upgrading/migrating Mailman v2.1.9 -> v2.1.18-1
In-Reply-To: <54B72DEF.1050705@msapiro.net>
References: <CA+SpAKWmBQ8j6Y1PkmNzN-7mkp=QpAt2PUdqrZOHumtk==1JiQ@mail.gmail.com>
 <54B69206.7070005@msapiro.net> <54B6A7EB.2050203@scu.edu>
 <54B72DEF.1050705@msapiro.net>
Message-ID: <CA+SpAKVMo1DMrGrLKfwfVgw-iFuJKTnzLxFp5=QQmPHxbwKcnA@mail.gmail.com>

On Wed, Jan 14, 2015 at 7:03 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 01/14/2015 09:31 AM, Chris Nulk wrote:
> >
>
> ?......?


>
> LDAPMemberships.py is not part of GNU Mailman. I think the latest
> version is yours, but in any case you can continue to use whatever
> you're using.
>

?Yeah, I know.  That list is an extract of the lists I have modified.  I
just copied and pasted it into the message.?



>
> For the others, if you want to look at changes in advance, go to
> <
> http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/944?remember=1484&compare_revid=1484
> >
> to compare rev 944 (2.1.9) with rev 1484 (2.1.18-1), scroll down to the
> list where file names are on the left preceded with > and click the > on
> the ones you're interested in to see the diff
>
>
>
> > I will also most likely do the same thing I did when I did the original
> > mods to Version.py and versions.py.  I will bump the DATA_FILE_VERSION
> > by one and make only the minimal change needed.
>
>
> in 2.1.18-1, DATA_FILE_VERSION is already 104. The only reason to
> increment DATA_FILE_VERSION is so versions.Update() will run when an
> older list in first instantiated. Since your changes were made at
> DATA_FILE_VERSION = 97, there's no point in incrementing
> DATA_FILE_VERSION beyond 104.
>

?Hmmm.  I have already changed it to 105, restarted Mailman, and created a
couple of lists to test.  Is there any harm with deleting the lists,
backing out the change, and restarting Mailman?  If I can do that, I can
take the file off the list of changed files since the only change is the
DATA_FILE_VERSION number.  I haven't migrated the real lists over yet so
there is no damage there.?



>
>
> > Actually, here are the
> > two patch files I plan on using for those two files.  So I will make
> > copies of the original files (for all files to be modified) and for
>
> ?........?


>
> This was the wrong place to add that code. This section of versions.py
> is intended to transform old attributes from say Mailman 2.0 so that
> they have the equivalent semantics in the current version.
>
> The proper way to add a new attribute is in the NewVars(l) function at
> the end around line 430 add
>
>     add_only_if_missing('accept_special_posters', [])
>
> ?Cool.  I will redo the change to do it the proper way.  Thanks for
information.

Mark, you have been awesome with your assistance not only to me but all the
other users of Mailman.

Thank you for your excellent support.

Chris

From cnulk at scu.edu  Thu Jan 15 06:58:31 2015
From: cnulk at scu.edu (Chris Nulk)
Date: Wed, 14 Jan 2015 21:58:31 -0800
Subject: [Mailman-Users] Small issue (hopefully) with
 upgrading/migrating from v2.1.9 to v2.1.18-1
In-Reply-To: <54B75371.7010703@msapiro.net>
References: <54B705AB.6010304@scu.edu> <54B726E1.6070804@msapiro.net>
 <CA+SpAKUjAnaKXhtqff76dQN+Zx+xVkN90omv5iNdPZGwMT7veQ@mail.gmail.com>
 <54B75371.7010703@msapiro.net>
Message-ID: <CA+SpAKVSrwnQpbYeXQWZkf6HM54cDfffDWgTXuRU8533Te7ybw@mail.gmail.com>

On Wed, Jan 14, 2015 at 9:43 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 01/14/2015 09:38 PM, Chris Nulk wrote:
> > On Wed, Jan 14, 2015 at 6:33 PM, Mark Sapiro <mark at msapiro.net> wrote:
> >>
> >> DRY
> >>
> >
> > ?DRY?
>
> <http://en.wikipedia.org/wiki/Don%27t_repeat_yourself>
>
> ? Well, I try not to but sometimes it doesn't work out.  Though I do try
to iterate dups out as I have time to revisit.

Chris

?P.S. I am more used to acronyms like FUBAR, DILLIGAF, and others.?  :)

From mark at msapiro.net  Thu Jan 15 07:25:23 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 14 Jan 2015 22:25:23 -0800
Subject: [Mailman-Users] Upgrading/migrating Mailman v2.1.9 -> v2.1.18-1
In-Reply-To: <CA+SpAKVMo1DMrGrLKfwfVgw-iFuJKTnzLxFp5=QQmPHxbwKcnA@mail.gmail.com>
References: <CA+SpAKWmBQ8j6Y1PkmNzN-7mkp=QpAt2PUdqrZOHumtk==1JiQ@mail.gmail.com>
 <54B69206.7070005@msapiro.net> <54B6A7EB.2050203@scu.edu>
 <54B72DEF.1050705@msapiro.net>
 <CA+SpAKVMo1DMrGrLKfwfVgw-iFuJKTnzLxFp5=QQmPHxbwKcnA@mail.gmail.com>
Message-ID: <54B75D53.6000102@msapiro.net>

On 01/14/2015 09:50 PM, Chris Nulk wrote:
> On Wed, Jan 14, 2015 at 7:03 PM, Mark Sapiro <mark at msapiro.net> wrote:
>>
>> in 2.1.18-1, DATA_FILE_VERSION is already 104. The only reason to
>> increment DATA_FILE_VERSION is so versions.Update() will run when an
>> older list in first instantiated. Since your changes were made at
>> DATA_FILE_VERSION = 97, there's no point in incrementing
>> DATA_FILE_VERSION beyond 104.
>>
> 
> ?Hmmm.  I have already changed it to 105, restarted Mailman, and created a
> couple of lists to test.  Is there any harm with deleting the lists,
> backing out the change, and restarting Mailman?


No, there's no problem with that. In fact it would be best as it
relieves you of the need to keep incrementing it.

Consider that if you leave yours at 105, and then I make a change which
increments mine to 105, you have to increment yours to 106 to pick up my
change on your existing lists. Better to leave yours at 104.

You do need to be sure that you have code in MailList.py in the InitVars
method to initialize your attribute for new lists.

The only way you would run into difficulty with not incrementing
DATA_FILE_VERSION beyond 104 would be if you moved a 2.1.18 or later
list's config.pck to your Mailman from another Mailman that didn't have
your changes, but I think it unlikely that you would do that, and if you
did, you could use withlist to either set the data_version attribute to
say 103 (which would then magically update the list and set it back to
104) or to add your new attribute manually.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From gayleard at eircom.net  Thu Jan 15 12:02:11 2015
From: gayleard at eircom.net (Timothy Murphy)
Date: Thu, 15 Jan 2015 11:02:11 +0000
Subject: [Mailman-Users] Changing name of mailman list that I own
In-Reply-To: <54B722F6.6090404@msapiro.net>
References: <2206968.SmaIpRukuz@william.gayleard.com>
 <54B722F6.6090404@msapiro.net>
Message-ID: <1918059.gBW22Wnx5h@william.gayleard.com>

On Wednesday 14 January 2015 18:16:22 Mark Sapiro wrote:

> > Can I change the name of a list if I am list-owner?
> > (But I am not the system administrator.)
> 
> No. You can change the list's real_name attribute, but only so it
> differs only in case from the list's internal name. E.g. If the list is
> junklist, its real_name could be any of junklist, JunkList, JUNKlist,
> etc., but not even Junk_List would be allowed. This is the only change
> you can make.
> 
> See the FAQ at <http://wiki.list.org/x/mYA9>.

Thanks for your response.

I should have made clear that I don't want to save any data from the old list.
The old list was concerned with a course I gave 2 years ago,
and the new list is for a course I am giving at present.

I thought that instead of removing the old list
and creating a new one, I could just change the name of the old list,
delete the list of members, and insert the new members.

I did look at the FAQ, but that seemed to be concerned
with passing on the data from the old list to the new,
which as I said I don't want to do.

So it seems the simplest thing to do is to get my sysadmin
to create a new list, and delete the old one.
(I do actually have superuser privileges on the system,
but am not sure of the finer details of creating a new list,
as the system is running under FreeBSD, with mmdf MTA,
and I am not familiar with these.)


-- 
Timothy Murphy  
gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin


From Lawrence.Levy at timeinc.com  Wed Jan 14 15:09:14 2015
From: Lawrence.Levy at timeinc.com (Levy, Lawrence - Technology & Product Engineering
 <Lawrence.Levy@timeinc.com>)
Date: Wed, 14 Jan 2015 14:09:14 +0000
Subject: [Mailman-Users] Customize Notifications
Message-ID: <DM2PR0701MB7295DA6E647571AE4DAC08CE9410@DM2PR0701MB729.namprd07.prod.outlook.com>

Hi All,

I was wondering if it is possible to customize the following notifications and how I would go about doing so.


*         Subscription email

*         Password reminders

*         Moderator message





Thanks!

Lawrence Levy
Jr. Technical Analyst, Global Technology Services
Time Inc. Technology & Product Engineering
(T) 212-522-8199

Need technical assistance? Please submit a request at 7777.timeinc.com.


From andrew.stuart at supercoders.com.au  Fri Jan 16 00:05:39 2015
From: andrew.stuart at supercoders.com.au (Andrew Stuart)
Date: Fri, 16 Jan 2015 10:05:39 +1100
Subject: [Mailman-Users] Redirected email address as entrypoint to mailing
	list
Message-ID: <D3D3390A-147E-4D55-B2E7-A3C7B7770244@supercoders.com.au>

Image a mailing list mylist at example.org

Is there any reason why the users could not be told to use adifferentlist at adifferentdomain.org which simply forwards mail to mylist at example.org

Would this raise any potential problems?

thanks



From mark at msapiro.net  Fri Jan 16 01:33:13 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 15 Jan 2015 16:33:13 -0800
Subject: [Mailman-Users] Changing name of mailman list that I own
In-Reply-To: <1918059.gBW22Wnx5h@william.gayleard.com>
References: <2206968.SmaIpRukuz@william.gayleard.com>
 <54B722F6.6090404@msapiro.net> <1918059.gBW22Wnx5h@william.gayleard.com>
Message-ID: <54B85C49.5090704@msapiro.net>

On 01/15/2015 03:02 AM, Timothy Murphy wrote:
> 
> So it seems the simplest thing to do is to get my sysadmin
> to create a new list, and delete the old one.


Yes. It seems that would be the best way to do this.


> (I do actually have superuser privileges on the system,
> but am not sure of the finer details of creating a new list,
> as the system is running under FreeBSD, with mmdf MTA,
> and I am not familiar with these.)


Creating and removing lists is straightforward. There are scripts
newlist and rmlist in Milman's bin/ directory. Each has a --help option
to get it to explain itself.

The MTA is potentially the tricky part and I too know nothing about mmdf
and can't help there except to say that whatever MTA changes are
required for removing one list and creating another would be exactly the
same for renaming an existing list.

It would be best to go to the sysadmin for this.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Fri Jan 16 02:54:15 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 15 Jan 2015 17:54:15 -0800
Subject: [Mailman-Users] Redirected email address as entrypoint to
 mailing list
In-Reply-To: <D3D3390A-147E-4D55-B2E7-A3C7B7770244@supercoders.com.au>
References: <D3D3390A-147E-4D55-B2E7-A3C7B7770244@supercoders.com.au>
Message-ID: <54B86F47.1020002@msapiro.net>

On 01/15/2015 03:05 PM, Andrew Stuart wrote:
> Image a mailing list mylist at example.org
> 
> Is there any reason why the users could not be told to use adifferentlist at adifferentdomain.org which simply forwards mail to mylist at example.org
> 
> Would this raise any potential problems?


Assuming the mylist at example.org list is Mailman 2.1.x, you need to
ensure that either Privacy options... -> Recipient filters ->
require_explicit_destination is No or that
adifferentlist at adifferentdomain.org is listed in Privacy options... ->
Recipient filters -> acceptable_aliases.

There may be other issues depending on what
adifferentlist at adifferentdomain.org actually is and how it delivers to
mylist at example.org and whether it delivers to other addresses as well.

Also, things like the List-* headers added by mylist at example.org may
cause issues, the most obvious being that reply-list will go to
mylist at example.org, not adifferentlist at adifferentdomain.org.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From stephen at xemacs.org  Fri Jan 16 02:58:25 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 16 Jan 2015 10:58:25 +0900
Subject: [Mailman-Users] Redirected email address as entrypoint to
	mailing	list
In-Reply-To: <D3D3390A-147E-4D55-B2E7-A3C7B7770244@supercoders.com.au>
References: <D3D3390A-147E-4D55-B2E7-A3C7B7770244@supercoders.com.au>
Message-ID: <87a91jxz9a.fsf@uwakimon.sk.tsukuba.ac.jp>

Andrew Stuart writes:
 > Image a mailing list mylist at example.org
 > 
 > Is there any reason why the users could not be told to use
 > adifferentlist at adifferentdomain.org which simply forwards mail to
 > mylist at example.org
 > 
 > Would this raise any potential problems?

Depends on what you are trying to do.  The main issues relate to users
being subscribed to mylist but post to adifferentlist.  Also MTA
configuration may be tricky (SPF, DKIM, DMARC) depending on whether
you have full control of both domains.

Problems with lists:

- This may be quite confusing to users, as they post to adifferentlist
  but set nomail, notmetoo, digest settings etc on mylist.
- This will confuse smart software, because the List-* headers will
  point to mylist.  (Some MUAs are smart enough to reply to List-Post
  by default or when a "list-reply" command is invoked.)
- If the lists are served by different MLM instances, ban settings etc
  on one cannot be referenced by the other.
- There are some settings to alleviate user confusion (sibling lists,
  umbrella lists) which you will not be able to use across instances.

Mailman 3 will help to alleviate some of these issues by making it
easier to serve multiple domains from one instance, but if your
domains are actually different hosts, you're not going to be able to
use those features without substantial extension to current Mailman 3
(as we've discussed on mailman-developers, access to many Mailman 3
databases requires running on the same host).



From stephen at xemacs.org  Fri Jan 16 03:07:32 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 16 Jan 2015 11:07:32 +0900
Subject: [Mailman-Users] Changing name of mailman list that I own
In-Reply-To: <1918059.gBW22Wnx5h@william.gayleard.com>
References: <2206968.SmaIpRukuz@william.gayleard.com>
 <54B722F6.6090404@msapiro.net>
 <1918059.gBW22Wnx5h@william.gayleard.com>
Message-ID: <878uh3xyu3.fsf@uwakimon.sk.tsukuba.ac.jp>

Timothy Murphy writes:

 > So it seems the simplest thing to do is to get my sysadmin
 > to create a new list, and delete the old one.

Yes.  Since you're at a university, it seems likely there are lots of
such lists and the sysadmin is familiar with the procedure.

I don't know if it's easy to reproduce various settings automatically
(@Mark: do you have script to "clone" a list with a new name?), but
you can ask your sysadmin to duplicate those.  As list owner you could
do it yourself, too, but if you need to reproduce "free text" fields,
the treatment of leading and trailing spaces can be fiddly.


From mark at msapiro.net  Fri Jan 16 06:19:20 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 15 Jan 2015 21:19:20 -0800
Subject: [Mailman-Users] Customize Notifications
In-Reply-To: <DM2PR0701MB7295DA6E647571AE4DAC08CE9410@DM2PR0701MB729.namprd07.prod.outlook.com>
References: <DM2PR0701MB7295DA6E647571AE4DAC08CE9410@DM2PR0701MB729.namprd07.prod.outlook.com>
Message-ID: <54B89F58.5000905@msapiro.net>

On 01/14/2015 06:09 AM, Levy, Lawrence - Technology & Product
Engineering <Lawrence.Levy at timeinc.com> wrote:
> 
> I was wondering if it is possible to customize the following notifications and how I would go about doing so.


Many notifications are created from templates. See the FAQ at
<http://wiki.list.org/x/jYA9> for instructions on creating list
specific, domain specific or sitewide edited templates. See the base
templates in Mailman's templates/en/ directory to find specific ones.


> *         Subscription email


I'm not sure which you are referring to here. If you mean the list
welcome message, this template is subscribeack.txt. This is also one of
a few templates that can be edited for a specific list by following the
"Edit the public HTML pages and text files" -> "Welcome email text file"
links in the list's web admin UI.

If you mean the confirmation request sent to a user who's requested
subscription, that one is verify.txt


> *         Password reminders


The header for monthly reminders is cronpass.txt. The on-demand reminder
is userpass.txt.


> *         Moderator message


Which one(s).

  Message                     template

Bounce notifications         bounce.txt
n moderator requests         checkdbs.txt
individual held post         postauth.txt
subscription authorization   subauth.txt
unsubscription authorization unsubauth.txt

There are other messages that are built totally from strings in the
code. Also, the Subject: headers for the ones built from templates are
also strings in the code.

For non-English languages, one can modify the translation in the
language's messages/<language-code>/LC_MESSAGES/mailman.po file and
recompile the corresponding mailman.mo.

For English, one can create a messages/en/LC_MESSAGES/mailman.po file
containing as "translations" the modified versions of the strings one
wants to change and compile that. You need some familiarity with
i18n/l10n and tools like msgfmt in order to do this.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Fri Jan 16 06:37:28 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 15 Jan 2015 21:37:28 -0800
Subject: [Mailman-Users] Changing name of mailman list that I own
In-Reply-To: <878uh3xyu3.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <2206968.SmaIpRukuz@william.gayleard.com>
 <54B722F6.6090404@msapiro.net> <1918059.gBW22Wnx5h@william.gayleard.com>
 <878uh3xyu3.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <54B8A398.1020501@msapiro.net>

On 01/15/2015 06:07 PM, Stephen J. Turnbull wrote:
> (@Mark: do you have script to "clone" a list with a new name?)


I don't currently, but it seems like a good idea, I'll see what I can
come up with.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Sat Jan 17 07:04:08 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 16 Jan 2015 22:04:08 -0800
Subject: [Mailman-Users] Changing name of mailman list that I own
In-Reply-To: <54B8A398.1020501@msapiro.net>
References: <54B8A398.1020501@msapiro.net>
Message-ID: <54B9FB58.40406@msapiro.net>

Mark Sapiro wrote:
> On 01/15/2015 06:07 PM, Stephen J. Turnbull wrote:
>> (@Mark: do you have script to "clone" a list with a new name?)
> 
> 
> I don't currently, but it seems like a good idea, I'll see what I can
> come up with.


OK, there now is one at <http://www.msapiro.net/scripts/clone_list>
(mirrored at <http://fog.ccsf.edu/~msapiro/scripts/clone_list>)

Here's the command help:

> usage: clone_list [-h] [-r REAL_NAME] [-o OWNER] [-p PASSWORD]
>                   [-s SUBJECT_PREFIX] [-m]
>                   old_list new_list
> 
> Clone an existing list. I.e., create a new list with settings that match as
> closely as possible those of an existing list.
> 
> positional arguments:
>   old_list              The name of the list to clone.
>   new_list              The name of the list to create.
> 
> optional arguments:
>   -h, --help            show this help message and exit
>   -r REAL_NAME, --real_name REAL_NAME
>                         The real_name attribute of the new list. This must
>                         differ only in case from the new_list argument. The
>                         default is the name of the new list with the initial
>                         character uppercased.
>   -o OWNER, --owner OWNER
>                         Specify the new list owner's email address. The
>                         default is the old list's owner(s).
>   -p PASSWORD, --password PASSWORD
>                         Specify a new list admin password. The default is the
>                         old list's password.
>   -s SUBJECT_PREFIX, --subject_prefix SUBJECT_PREFIX
>                         Specify a new value for subject_prefix. The default is
>                         the old list's subject_prefix.
>   -m, --members         Clone the membership list and member options from the
>                         old list. The default is the new list has no members.
> 
> Other than the list's name, real_name and any options given as above, all
> attributes of the new list except for membership will be the same as those of
> the old list. The new list will have no members unless -m/--members is
> specified.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Sat Jan 17 21:38:35 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 17 Jan 2015 12:38:35 -0800
Subject: [Mailman-Users] Changing name of mailman list that I own
In-Reply-To: <54B9FB58.40406@msapiro.net>
References: <54B8A398.1020501@msapiro.net> <54B9FB58.40406@msapiro.net>
Message-ID: <54BAC84B.9030607@msapiro.net>

On 01/16/2015 10:04 PM, Mark Sapiro wrote:
> Mark Sapiro wrote:
>> On 01/15/2015 06:07 PM, Stephen J. Turnbull wrote:
>>> (@Mark: do you have script to "clone" a list with a new name?)
>>
>>
>> I don't currently, but it seems like a good idea, I'll see what I can
>> come up with.
> 
> 
> OK, there now is one at <http://www.msapiro.net/scripts/clone_list>
> (mirrored at <http://fog.ccsf.edu/~msapiro/scripts/clone_list>)
> 
> Here's the command help:
> 
>> usage: clone_list [-h] [-r REAL_NAME] [-o OWNER] [-p PASSWORD]
>>                   [-s SUBJECT_PREFIX] [-m]
>>                   old_list new_list


And, as we know, since no program is finished until the programmer dies,
I have added an additional option to copy the archives as well.

I also added more to the help description to indicate the script needs
to be installed in Mailman's bin/ directory and that there are still
issues in copied archives due to links still pointing to the old list.

I considered adding a --remove option to remove the old list after
cloning to make it a 'rename' process, but decided against that both
because of the archive issues in the new list and because one can always
easily remove the old list with bin/rmlist anyway.

I also added reference to this script to the FAQ at
<https://wiki.mailman.psf.io/DOC/4.70%20How%20do%20I%20change%20the%20name%20of%20%28rename%29%20a%20list%3F>

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From clare at catspaw.plus.com  Mon Jan 19 00:14:57 2015
From: clare at catspaw.plus.com (Clare Redstone)
Date: Sun, 18 Jan 2015 23:14:57 -0000
Subject: [Mailman-Users] Which from,
	reply and DMARC settings for a discussion group?
Message-ID: <021a01d03374$9448db50$bcda91f0$@plus.com>

Apologies if this has been discussed before. I've read some of the archive
measures about DMARC but there are lots and there's so much technical stuff
in them that I don't understand. I don't understand what settings I need for
our email discussion group to work as smoothly as can be since DMARC caused
so much hassle.

 

I've been trying to understand from_is_list, anonymous_list,
first_strip_reply_to, reply_goes_to_list and reply_to_address and don't know
if I need to change options here or dmarc_moderation_action or both.

 

What I'm hoping to achieve:

1.       That when people hit the "reply" button, the reply goes to the
list.
(Currently most of the time it fills in both the poster's and the list's
address. I just tried a test from gmail using Outlook and it only filled in
the poster's address.)

2.       It would be good if the poster's email address was visible, so that
someone could chose to reply privately. In the same way as it used to be.
But I want that to be a deliberate choice. I think that since DMARC altered
how Mailman functioned, some are replying accidentally only to the poster
(as in the gmail example above) and don't realise that's happened. So we
lose out on the group discussion.
This isn't essential. In fact in some ways it may be a good thing if
posters' email addresses aren't visible. It's a self-help group and some
people prefer to remain anonymous. Occasionally people hadn't realised their
email addresses became visible to the group when they posted.

3.       None (or as few as possible) messages not reaching intended
recipients due to providers' and email clients' settings, DMARC etc causing
problems. None (or as few as possible) members being suspended due to
excessive bounces and the list being blacklisted.

4.       If there's a choice between 1 and 2 (ie, I can't have both) then 1
takes priority. There's been a noticeable drop in group discussion so I
wonder whether replies have been going to individuals quite often, instead
of the group. If someone needs to reply to someone privately, I think it's
still possible. If push comes to shove, they just post a reply saying "you
can email me off-list at XX at yy." That's no different from the senders' email
addresses being visible before in any case.

 

Is this possible? I'd be grateful if someone would tell me what settings I
need for this. Sorry I haven't been able to understand it myself.

 

Mailman v 2.1.18-1

On a shared host so I don't have access to root (I think)

Cpanel.

 

Thank you.

Clare

 


From mark at msapiro.net  Mon Jan 19 01:28:54 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 18 Jan 2015 16:28:54 -0800
Subject: [Mailman-Users] Which from,
 reply and DMARC settings for a discussion group?
In-Reply-To: <021a01d03374$9448db50$bcda91f0$@plus.com>
References: <021a01d03374$9448db50$bcda91f0$@plus.com>
Message-ID: <54BC4FC6.60501@msapiro.net>

On 01/18/2015 03:14 PM, Clare Redstone wrote:
> 
> I've been trying to understand from_is_list, anonymous_list,
> first_strip_reply_to, reply_goes_to_list and reply_to_address and don't know
> if I need to change options here or dmarc_moderation_action or both.


It's very tricky, and 2.1.19 will get you closer to what you want than
2.1.18-1 will, but 2.1.19 isn't released yet.


> What I'm hoping to achieve:
> 
> 1.       That when people hit the "reply" button, the reply goes to the
> list.
> (Currently most of the time it fills in both the poster's and the list's
> address. I just tried a test from gmail using Outlook and it only filled in
> the poster's address.)


Set the following
first_strip_reply_to = Yes
reply_goes_to_list = This list
reply_to_address - doesn't matter as it is only used if
reply_goes_to_list  is Explicit address.

Also set from_is_list to No and dmarc_moderation_action to either Munge
from or Wrap message. Actually, I think Wrap message is the better
transformation, but I had to back off from that on my lists because of
complaints (mostly from users of iThings) that the messages were
difficult to deal with in various ways.

This will still put the poster's address in Reply-To: along with the
list address. This is the change for 2.1.19 which will put the poster's
address in Cc: in this case.


> 2.       It would be good if the poster's email address was visible, so that
> someone could chose to reply privately. In the same way as it used to be.
> But I want that to be a deliberate choice. I think that since DMARC altered
> how Mailman functioned, some are replying accidentally only to the poster
> (as in the gmail example above) and don't realise that's happened. So we
> lose out on the group discussion.


Gmail itself will do the right thing; at least it does in a test I just
did, but what Outlook does with a list post originally from gmail (if
that's what you tested) is an Outlook issue.

In any case, as I note elsewhere, set from_is_list to No and control
From: munging with dmarc_moderation_action and posts from gmail won't be
munged.


> This isn't essential. In fact in some ways it may be a good thing if
> posters' email addresses aren't visible. It's a self-help group and some
> people prefer to remain anonymous. Occasionally people hadn't realised their
> email addresses became visible to the group when they posted.


If you don't want the poster's address to be visible, you can set
anonymous_list = Yes, and that will remove all headers that could be
used to identify the poster or the poster's domain. If you do that, you
can set from_is_list to No (because anonymous list does this anyway) and
dmarc_moderation_action to Accept.


> 3.       None (or as few as possible) messages not reaching intended
> recipients due to providers' and email clients' settings, DMARC etc causing
> problems. None (or as few as possible) members being suspended due to
> excessive bounces and the list being blacklisted.


You need to apply some kind of DMARC mitigation to accomplish this.
Setting anonymous_list = Yes counts as a DMARC mitigation in this case.


> 4.       If there's a choice between 1 and 2 (ie, I can't have both) then 1
> takes priority. There's been a noticeable drop in group discussion so I
> wonder whether replies have been going to individuals quite often, instead
> of the group. If someone needs to reply to someone privately, I think it's
> still possible. If push comes to shove, they just post a reply saying "you
> can email me off-list at XX at yy." That's no different from the senders' email
> addresses being visible before in any case.


You can't have 1 with MM 2.1.18-1. What you get with the settings I
suggest is that both the list address and the poster's address are in
Reply-To:.  In this case, a 'reply' is supposed to go to both the list
and the poster, but evidently, there are some MUAs (mail clients) that
are non-conformant in this respect.

Note however that for a non-anonymous list, setting from_is_list to No
and using dmarc_moderation_action to control From: munging is preferable
because then only messages From: AOL and Yahoo addresses (at present)
will be munged.


> Is this possible? I'd be grateful if someone would tell me what settings I
> need for this. Sorry I haven't been able to understand it myself.


You may find the bug at
<https://bugs.launchpad.net/mailman/+bug/1407098> of interest.

Also, these comments from the code express my thinking on this.

# MAS: We need to do some things with the original From: if we've munged
# it for DMARC mitigation.  We have goals for this process which are
# not completely compatible, so we do the best we can.  Our goals are:
# 1) as long as the list is not anonymous, the original From: address
#    should be obviously exposed, i.e. not just in a header that MUAs
#    don't display.
# 2) the original From: address should not be in a comment or display
#    name in the new From: because it is claimed that multiple domains
#    in any fields in From: are indicative of spamminess.  This means
#    it should be in Reply-To: or Cc:.
# 3) the behavior of an MUA doing a 'reply' or 'reply all' should be
#    consistent regardless of whether or not the From: is munged.
# Goal 3) implies sometimes the original From: should be in Reply-To:
# and sometimes in Cc:, and even so, this goal won't be achieved in
# all cases with all MUAs.  In cases of conflict, the above ordering of
# goals is priority order.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From johnl at taugh.com  Mon Jan 19 05:50:33 2015
From: johnl at taugh.com (John Levine)
Date: 19 Jan 2015 04:50:33 -0000
Subject: [Mailman-Users] Which from,
	reply and DMARC settings for a discussion group?
In-Reply-To: <54BC4FC6.60501@msapiro.net>
Message-ID: <20150119045033.2133.qmail@ary.lan>

># 1) as long as the list is not anonymous, the original From: address
>#    should be obviously exposed, i.e. not just in a header that MUAs
>#    don't display.

Have you tried any sort of reversible rewriting?  On my lists, sending
addresses in dmarc'ed domains get a local domain appended on the From:
line, e.g. mail From: marissa at yahoo.com ->
marissa at yahoo.com.dmarc.fail.  (Yes, that's a real domain.)  Then I do
some local magic so the rewritten addresses work for a few days in
case people write back to them.

It's gross and disgusting, but no worse than any other dmarc workaround.

R's,
John

From stephen at xemacs.org  Mon Jan 19 08:58:33 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 19 Jan 2015 16:58:33 +0900
Subject: [Mailman-Users] Which from,
	reply and DMARC settings for a discussion group?
In-Reply-To: <20150119045033.2133.qmail@ary.lan>
References: <54BC4FC6.60501@msapiro.net>
	<20150119045033.2133.qmail@ary.lan>
Message-ID: <87k30jw6ae.fsf@uwakimon.sk.tsukuba.ac.jp>

John Levine writes:

 > Have you tried any sort of reversible rewriting?  On my lists, sending
 > addresses in dmarc'ed domains get a local domain appended on the From:
 > line, e.g. mail From: marissa at yahoo.com ->
 > marissa at yahoo.com.dmarc.fail.
[...]

 > It's gross and disgusting, but no worse than any other dmarc
 > workaround.

Three problems:
1.  It confuses the h### out of naive users (typically those from
    offending domains).
2.  Some users from offending domains b#### loudly about having their
    addresses "deprecated".
3.  Mailman can't implement it anyway, because Mailman not only isn't
    the only MTA on the block, it isn't an MTA at all.

I don't think we want to go there until it becomes clear there's a
clientele for it, and we can tell them what switches they need to
flick in their MTAs to get proper service.




From Hagedorn at uni-koeln.de  Mon Jan 19 13:39:18 2015
From: Hagedorn at uni-koeln.de (Sebastian Hagedorn)
Date: Mon, 19 Jan 2015 13:39:18 +0100
Subject: [Mailman-Users] Changing name of mailman list that I own
In-Reply-To: <54BAC84B.9030607@msapiro.net>
References: <54B8A398.1020501@msapiro.net> <54B9FB58.40406@msapiro.net>
 <54BAC84B.9030607@msapiro.net>
Message-ID: <271828CD4B9C47F275B51E1C@tyrion.rrz.uni-koeln.de>

--On 17. Januar 2015 12:38:35 -0800 Mark Sapiro <mark at msapiro.net> wrote:

> On 01/16/2015 10:04 PM, Mark Sapiro wrote:
>> Mark Sapiro wrote:
>>> On 01/15/2015 06:07 PM, Stephen J. Turnbull wrote:
>>>> (@Mark: do you have script to "clone" a list with a new name?)
>>>
>>>
>>> I don't currently, but it seems like a good idea, I'll see what I can
>>> come up with.
>>
>>
>> OK, there now is one at <http://www.msapiro.net/scripts/clone_list>
>> (mirrored at <http://fog.ccsf.edu/~msapiro/scripts/clone_list>)
>>
>> Here's the command help:
>>
>>> usage: clone_list [-h] [-r REAL_NAME] [-o OWNER] [-p PASSWORD]
>>>                   [-s SUBJECT_PREFIX] [-m]
>>>                   old_list new_list
>
>
> And, as we know, since no program is finished until the programmer dies,
> I have added an additional option to copy the archives as well.
>
> I also added more to the help description to indicate the script needs
> to be installed in Mailman's bin/ directory and that there are still
> issues in copied archives due to links still pointing to the old list.
>
> I considered adding a --remove option to remove the old list after
> cloning to make it a 'rename' process, but decided against that both
> because of the archive issues in the new list and because one can always
> easily remove the old list with bin/rmlist anyway.

Thanks for that! We could've used that often in the past and will be able 
to do so from now on :-)
-- 
    .:.Sebastian Hagedorn - Weyertal 121 (Geb?ude 133), Zimmer 2.02.:.
                 .:.Regionales Rechenzentrum (RRZK).:.
   .:.Universit?t zu K?ln / Cologne University - ? +49-221-470-89578.:.

From ghmerrill at chathamdesign.com  Mon Jan 19 16:10:32 2015
From: ghmerrill at chathamdesign.com (Gary Merrill)
Date: Mon, 19 Jan 2015 10:10:32 -0500
Subject: [Mailman-Users] Diagnosing command failures
Message-ID: <009501d033fa$12c02fd0$38408f70$@com>

Is there any technique to diagnose precisely why/how a particular (email)
command to a list has failed?

 

I have a user (a SINGLE user, so far as I know) who cannot get the list of
members by using the 'who <password>' command.  He successfully gets his
password with the 'password' command, but the 'who' command fails.

 

This user is VERY difficult to work with since he is elderly, sloppy in how
he does things, and is often confused by instructions or requests for
information.  He successfully uses the list for communications.  I'm very
confident that he is either using the wrong password (we in fact determined
that at one point - which took a lot of effort) or is typing in his password
incorrectly.  But short of physically sitting down with him at this point, I
don't know what else to do.

 

Mailman must have a failure/error log of some sort for each list, does it
not?  How can I see exactly why this user's command is failing?  The
information in the failure messages to the user (when I can get him to
forward these) is uninformative.

 

_______________

 

Gary H. Merrill

Chatham Design Consultants

+1 919.271.7259

 


From sm at noisynotes.com  Mon Jan 19 17:18:28 2015
From: sm at noisynotes.com (Steve Matzura)
Date: Mon, 19 Jan 2015 11:18:28 -0500
Subject: [Mailman-Users] Unknown Virtual Host question
Message-ID: <n8bqbat3mp7qnb9ufu93ct0i0hh62stric@4ax.com>

I'm setting up a new Mailman implementation on a new machine that's a
virtual copy of a running production machine. I'm expecting problems
because I'm trying to use the same domain name in two places, and I
absolutely understand that's not going to work, but the bottom line
is, the faster I get the new machine up and functional, the faster the
old one will just go away and not bother me any more (LOL). So, on the
new machine, I'm trying to create email lists via the Web interface at
my new machine's IP address. When I log in with the Mailman
administrator account and password and attempt to create a new list, I
get the message "unknown virtual host at x.x.x.x" where 'x.x.x.x' is
the IP address of the new machine. Is this caused by the fact that my
A-record points to the old machine, or because my new machine is
trying to validate against the old one somehow? If I were to stop
Mailman on the old system temporarily and swing my A-record over to
the new machine, would this solve the problem long enough for me to
get lists created? If so, then I might as well just do the deed for
real, and get the old machine out of the equation completely. What's
best to do here?
 

From ghmerrill at chathamdesign.com  Mon Jan 19 17:30:44 2015
From: ghmerrill at chathamdesign.com (Gary Merrill)
Date: Mon, 19 Jan 2015 11:30:44 -0500
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
Message-ID: <00d301d03405$46715e20$d3541a60$@com>

Thanks.

The suggestions you make about typographical/character issues are precisely
the ones I have made to him -- in part because he has made such errors
previously in other contexts.  But unless Mailman provides me with some kind
of record or error log, I have no way of verifying what password he's used
and indeed what email address he's used to send the command from.

I honestly don't have a clear picture of exactly what he's attempted at this
point.  For example, has he attempted to do this via the email command or
via the web interface?  He uses "tech jargon" loosely and confusingly (as
many people do) and has said things like "I managed to get through and typed
my assigned password."  But what does this MEAN?  In response to a request
for clarification, he has said that " 'Get through' simply means
'connected'. "  An odd thing to say if the command is being sent via email,
but for a large group of people, "connected", "logged on", "accessed",
"emailed", etc. are used synonymously.  So you see what I'm dealing with in
any attempt to diagnose the problem with him remotely and indirectly.

There's no reason that an arbitrary member should not be able to retrieve
the membership list.  And this DOES work for me (using any of several
accounts that have no special privileges).  I know it works for at least
some others as well.

Second, this is a mailing list for a (loosely run) community band, this user
is the president of the band and needs access to the mailing list.
Implementing a Mailman list had as its primary goals addressing the problems
involved in this user's maintaining his own private copy of his own list --
which was always fraught with error and often out of date.  So having him be
able to EASILY get the list is pretty important.  It has taken over six
months to get him to switch from his own private list to using the Mailman
managed list.  The rest of the band is ecstatic about the Mailman list,
since they're now confident that it's always accurate and up to date, and
that they won't miss any messages.

But again, the big GENERAL question here is whether Mailman provides any way
of diagnosing such command failures.

_______________

Gary H. Merrill
Chatham Design Consultants
+1 919.271.7259


> -----Original Message-----
> From: Robert Heller [mailto:heller at deepsoft.com]
> Sent: Monday, January 19, 2015 11:10 AM
> To: ghmerrill at chathamdesign.com
> Cc: Mailman Users; Robert Heller
> Subject: Re: [Mailman-Users] Diagnosing command failures
> 
> At Mon, 19 Jan 2015 10:10:32 -0500 ghmerrill at chathamdesign.com wrote:
> 
> >
> > Is there any technique to diagnose precisely why/how a particular
> > (email) command to a list has failed?
> >
> >
> >
> > I have a user (a SINGLE user, so far as I know) who cannot get the
> > list of members by using the 'who <password>' command.  He
> > successfully gets his password with the 'password' command, but the
'who'
> command fails.
> >
> >
> >
> > This user is VERY difficult to work with since he is elderly, sloppy
> > in how he does things, and is often confused by instructions or
> > requests for information.  He successfully uses the list for
> > communications.  I'm very confident that he is either using the wrong
> > password (we in fact determined that at one point - which took a lot
> > of effort) or is typing in his password incorrectly.  But short of
> > physically sitting down with him at this point, I don't know what else
to do.
> 
> It sounds like issues relating to upper/lower case letters and confusing
zero and oh (0
> vs o/O) and one and el (1 vs l).
> 
> Question:  is there some *specific* reason he wants/needs the list of
members?
> Most of the time, random list members have no need for a member listing.
> 
> 
> >
> >
> >
> > Mailman must have a failure/error log of some sort for each list, does
> > it not?  How can I see exactly why this user's command is failing?
> > The information in the failure messages to the user (when I can get
> > him to forward these) is uninformative.
> >
> >
> >
> > _______________
> >
> >
> >
> > Gary H. Merrill
> >
> > Chatham Design Consultants
> >
> > +1 919.271.7259
> >
> >
> >
> > ------------------------------------------------------
> > Mailman-Users mailing list Mailman-Users at 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/heller%40deepsof
> > t.com
> >
> >
> 
> --
> Robert Heller             -- 978-544-6933
> Deepwoods Software        -- Custom Software Services
> http://www.deepsoft.com/  -- Linux Administration Services
> heller at deepsoft.com       -- Webhosting Services
> 


From heller at deepsoft.com  Mon Jan 19 17:09:40 2015
From: heller at deepsoft.com (Robert Heller)
Date: Mon, 19 Jan 2015 11:09:40 -0500
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <009501d033fa$12c02fd0$38408f70$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
Message-ID: <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>

At Mon, 19 Jan 2015 10:10:32 -0500 ghmerrill at chathamdesign.com wrote:

> 
> Is there any technique to diagnose precisely why/how a particular (email)
> command to a list has failed?
> 
>  
> 
> I have a user (a SINGLE user, so far as I know) who cannot get the list of
> members by using the 'who <password>' command.  He successfully gets his
> password with the 'password' command, but the 'who' command fails.
> 
>  
> 
> This user is VERY difficult to work with since he is elderly, sloppy in how
> he does things, and is often confused by instructions or requests for
> information.  He successfully uses the list for communications.  I'm very
> confident that he is either using the wrong password (we in fact determined
> that at one point - which took a lot of effort) or is typing in his password
> incorrectly.  But short of physically sitting down with him at this point, I
> don't know what else to do.

It sounds like issues relating to upper/lower case letters and confusing zero 
and oh (0 vs o/O) and one and el (1 vs l).

Question:  is there some *specific* reason he wants/needs the list of members? 
Most of the time, random list members have no need for a member listing.


> 
>  
> 
> Mailman must have a failure/error log of some sort for each list, does it
> not?  How can I see exactly why this user's command is failing?  The
> information in the failure messages to the user (when I can get him to
> forward these) is uninformative.
> 
>  
> 
> _______________
> 
>  
> 
> Gary H. Merrill
> 
> Chatham Design Consultants
> 
> +1 919.271.7259
> 
>  
> 
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/heller%40deepsoft.com
> 
>                                                   

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services
                           

From johnl at taugh.com  Mon Jan 19 19:04:52 2015
From: johnl at taugh.com (John R Levine)
Date: 19 Jan 2015 13:04:52 -0500
Subject: [Mailman-Users] Which from,
 reply and DMARC settings for a discussion group?
In-Reply-To: <87k30jw6ae.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <54BC4FC6.60501@msapiro.net> <20150119045033.2133.qmail@ary.lan>
 <87k30jw6ae.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <alpine.OSX.2.11.1501191301380.97095@ary.lan>

> 1.  It confuses the h### out of naive users (typically those from
>    offending domains).
> 2.  Some users from offending domains b#### loudly about having their
>    addresses "deprecated".

I've been doing this for the better part of a year, with some very 
non-technical users on lists for my church and a bunch of folk dancers. 
For the most part, they don't even notice it.  Perhaps one or two wrote to 
me to ask what it was.  Do you have concrete experience that says 
otherwise?

Remember that their real address is still there, e.g.:

   From: Marissa M <marissa at yahoo.com.dmarc.fail>

> 3.  Mailman can't implement it anyway, because Mailman not only isn't
>    the only MTA on the block, it isn't an MTA at all.

It's true, it needs cooperation from whatever MTA receives the rewritten 
addresses.  The code isn't hard, for people who want to do it.

Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

From mark at msapiro.net  Mon Jan 19 23:43:41 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 19 Jan 2015 14:43:41 -0800
Subject: [Mailman-Users] Unknown Virtual Host question
In-Reply-To: <n8bqbat3mp7qnb9ufu93ct0i0hh62stric@4ax.com>
References: <n8bqbat3mp7qnb9ufu93ct0i0hh62stric@4ax.com>
Message-ID: <54BD889D.30302@msapiro.net>

On 01/19/2015 08:18 AM, Steve Matzura wrote:
> So, on the
> new machine, I'm trying to create email lists via the Web interface at
> my new machine's IP address. When I log in with the Mailman
> administrator account and password and attempt to create a new list, I
> get the message "unknown virtual host at x.x.x.x" where 'x.x.x.x' is
> the IP address of the new machine. Is this caused by the fact that my
> A-record points to the old machine, or because my new machine is
> trying to validate against the old one somehow?


Neither. It is because you are going the the create page via an
http:/x.x.x.x/... URL and Mailman is therefore trying to create the list
in the web domain x.x.x.x which is not in Mailman's VIRTUAL_HOSTS
dictionary, i.e. there is no add_virtualhost('x.x.x.x', ...) in mm_cfg.py.

This is explained in more detail in the FAQ at <http://wiki.list.org/x/lYA9>


> If I were to stop
> Mailman on the old system temporarily and swing my A-record over to
> the new machine, would this solve the problem long enough for me to
> get lists created? If so, then I might as well just do the deed for
> real, and get the old machine out of the equation completely. What's
> best to do here?


You could do what you suggest, or you can just create the lists with the
proper URL and email host names with bin/newlist on the new machine, but
neither of these is "the best".

The best is to stop Mailman on the old machine, move, copy, rsync,
whatever Mailman's lists/ and archives/private/ directories to the new
machine, start Mailman on the new machine and switch DNS. See the FAQ at
<http://wiki.list.org/x/2oA9> and the first couple of posts linked
therefrom.

It is not necessary to move archives/public/, but if you do, make sure
your process copies symlinks as symlinks. If you don't move them, they
will be automagically created. (This also avoids any issue with changing
paths and incorrect symlinks.

You will probably need to run Mailman's bin/check_perms on the new
machine to be sure, and depending on your MTA you may need to run
Mailman's bin/genaliases and possibly add aliases manually.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Tue Jan 20 00:09:01 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 19 Jan 2015 15:09:01 -0800
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <00d301d03405$46715e20$d3541a60$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com>
Message-ID: <54BD8E8D.6050401@msapiro.net>

On 01/19/2015 08:30 AM, Gary Merrill wrote:
> 
> Second, this is a mailing list for a (loosely run) community band, this user
> is the president of the band and needs access to the mailing list.
> Implementing a Mailman list had as its primary goals addressing the problems
> involved in this user's maintaining his own private copy of his own list --
> which was always fraught with error and often out of date.  So having him be
> able to EASILY get the list is pretty important.  It has taken over six
> months to get him to switch from his own private list to using the Mailman
> managed list.  The rest of the band is ecstatic about the Mailman list,
> since they're now confident that it's always accurate and up to date, and
> that they won't miss any messages.


I suggest the easiest thing is to direct him to the list info page at a
URL like http://example.com/mailman/listinfo/LISTNAME, enter his email
address and list password in the Address: and Password: boxes near the
bottom of the page and click the 'Visit Subscriber List' button.

Unfortunately, if his address or password is incorrect, all he sees is

Error
LISTNAME roster authentication failed.


> But again, the big GENERAL question here is whether Mailman provides any way
> of diagnosing such command failures.


If he is using the email "who" command, he should get an email response.
Have him forward both his original email and the response email to you.
Between the two, they contain everything Mailman knows about it. Mailman
is designed to help the user find the mistake in this case, not to log
everything for an admin.

You can search the web server and Mail server logs to find if he is
mailing LISTNAME-request at ... or POSTing to /mailman/roster/LISTNAME, but
you won't be able to see the actual commands or data he's submitting.

You may ultimately find that actually sitting down with him is the
easiest thing to do. I can give you patches to log everything if that's
what you want, but walking him through it may be easier assuming he can
remember for the next time.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Tue Jan 20 00:27:45 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 19 Jan 2015 15:27:45 -0800
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <54BD8E8D.6050401@msapiro.net>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
Message-ID: <54BD92F1.9030503@msapiro.net>

On 01/19/2015 03:09 PM, Mark Sapiro wrote:
> 
> I suggest the easiest thing is to direct him to the list info page at a
> URL like http://example.com/mailman/listinfo/LISTNAME, enter his email
> address and list password in the Address: and Password: boxes near the
> bottom of the page and click the 'Visit Subscriber List' button.


In fact, if you know his subscribed address and list password, you can
have him go to a URL like
<http://example.com/mailman/roster/LISTNAME?roster-email=his_email&roster-pw=his_list_pw>
which should display the roster and which you would type for him and
email to him as a link.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From andrew at hodgsonfamily.org  Mon Jan 19 18:42:06 2015
From: andrew at hodgsonfamily.org (Andrew Hodgson)
Date: Mon, 19 Jan 2015 17:42:06 +0000
Subject: [Mailman-Users] Unknown Virtual Host question
In-Reply-To: <n8bqbat3mp7qnb9ufu93ct0i0hh62stric@4ax.com>
References: <n8bqbat3mp7qnb9ufu93ct0i0hh62stric@4ax.com>
Message-ID: <AM3PR04MB077604D363D01BC57F8EDC77C54A0@AM3PR04MB0776.eurprd04.prod.outlook.com>

Hi,

The issue you have is you are trying to access the web interface over a virtual host (x.x.x.x) which isn't defined.  You can change your Windows Hosts file to point lists.domain.com at your new IP whilst you do the setup and testing, that is what I did when I had to move a bunch of lists over to a new server.

Thanks.
Andrew.

-----Original Message-----
From: Mailman-Users [mailto:mailman-users-bounces+andrew=hodgsonfamily.org at python.org] On Behalf Of Steve Matzura
Sent: 19 January 2015 16:18
To: mailman
Subject: [Mailman-Users] Unknown Virtual Host question

I'm setting up a new Mailman implementation on a new machine that's a virtual copy of a running production machine. I'm expecting problems because I'm trying to use the same domain name in two places, and I absolutely understand that's not going to work, but the bottom line is, the faster I get the new machine up and functional, the faster the old one will just go away and not bother me any more (LOL). So, on the new machine, I'm trying to create email lists via the Web interface at my new machine's IP address. When I log in with the Mailman administrator account and password and attempt to create a new list, I get the message "unknown virtual host at x.x.x.x" where 'x.x.x.x' is the IP address of the new machine. Is this caused by the fact that my A-record points to the old machine, or because my new machine is trying to validate against the old one somehow? If I were to stop Mailman on the old system temporarily and swing my A-record over to the new machine, would this solve the problem long enough for me to get lists created? If so, then I might as well just do the deed for real, and get the old machine out of the equation completely. What's best to do here?
 
------------------------------------------------------
Mailman-Users mailing list Mailman-Users at 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/andrew%40hodgsonfamily.org

From stephen at xemacs.org  Wed Jan 21 03:36:37 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 21 Jan 2015 11:36:37 +0900
Subject: [Mailman-Users] Which from,
 reply and DMARC settings for a discussion group?
In-Reply-To: <alpine.OSX.2.11.1501191301380.97095@ary.lan>
References: <54BC4FC6.60501@msapiro.net> <20150119045033.2133.qmail@ary.lan>
 <87k30jw6ae.fsf@uwakimon.sk.tsukuba.ac.jp>
 <alpine.OSX.2.11.1501191301380.97095@ary.lan>
Message-ID: <87wq4gvozu.fsf@uwakimon.sk.tsukuba.ac.jp>

John R Levine writes:

[About munging p=reject addresses in From]

 > I've been doing this for the better part of a year, with some very
 > non-technical users on lists for my church and a bunch of folk
 > dancers. For the most part, they don't even notice it.  Perhaps one
 > or two wrote to me to ask what it was.  Do you have concrete
 > experience that says otherwise?

Just reports on this list, and on python-* where somebody
sophisticated mentioned that they didn't appreciate their address
being deprecated as ".invalid" (which is the logical deprecation
according to RFC if you aren't going to provide forwarding).

My users aren't affected by dmarc_moderation_action by their nature
(virtually no Yahoo! or AOL users @xemacs.org, and the Asian
affiliates of Yahoo!, often-seen on my academic lists, are DMARC
"p=none" domains).

 > Remember that their real address is still there, e.g.:
 > 
 >    From: Marissa M <marissa at yahoo.com.dmarc.fail>

I'm aware of that; the problems are that (1) some (few? many?) users
have indicated that they dislike it), and (2) providing forwarding
service is outside the scope of Mailman, and probably not available to
the great majority of list owners.

Are "dmarc.fail" subdomains generally available?  If such a service
could be made generally available (theoretically no problem, I
suppose, as the MX for example.com.dmarc.fail could point to
mail.example.com), that would be a great name for it.  But if there is
no general service, such names will proliferate, and your service
(because it's such a great name) will be mimicked (with mail sent to
it presumably to end up rejected?) by third parties who don't
understand the scheme you've implemented.

 > > 3.  Mailman can't implement it anyway, because Mailman not only
 > >     isn't the only MTA on the block, it isn't an MTA at all.
 > 
 > It's true, it needs cooperation from whatever MTA receives the
 > rewritten addresses.  The code isn't hard, for people who want to
 > do it.

Code is trivial, except where code is law.  Eg, on hosted cPanel
sites, as alluded to above.

Steve

From ghmerrill at chathamdesign.com  Wed Jan 21 03:59:47 2015
From: ghmerrill at chathamdesign.com (Gary Merrill)
Date: Tue, 20 Jan 2015 21:59:47 -0500
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <54BD8E8D.6050401@msapiro.net>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
Message-ID: <01ba01d03526$51641fd0$f42c5f70$@com>

The suggestions you've offered have been tried (at this point multiple
times).  I was really asking whether there is a way to diagnose command
failures in Mailman, and it's clear at this point that the answer is "No."
This isn't entirely unexpected, but I just wanted to check in case there
happened to be something that I'd missed.

A "diagnosis" of

> Error
> LISTNAME roster authentication failed.

is like the diagnoses you used to see in old compilers that would helpfully
inform you of "Syntax error"  or "Invalid expression"  (sometimes without
even a line number).  One wonders why anyone would ever write a utility with
that sort of "error reporting", but it was quite fashionable for years.
Mostly it came from developers writing things for themselves rather than for
people who would use their products -- or for people whom the developers
thought were like themselves, who mostly didn't make mistakes, and who were
man enough not to need diagnostics when they did.  Those were the days when
men were men.  Whatever.  It is what it is.

Personal consultation and observation appears to be the only approach here
that will be successful.

_______________

Gary H. Merrill
Chatham Design Consultants
+1 919.271.7259


> -----Original Message-----
> From: Mailman-Users [mailto:mailman-users-
> bounces+ghmerrill=chathamdesign.com at python.org] On Behalf Of Mark Sapiro
> Sent: Monday, January 19, 2015 6:09 PM
> To: mailman-users at python.org
> Subject: Re: [Mailman-Users] Diagnosing command failures
> 
> On 01/19/2015 08:30 AM, Gary Merrill wrote:
> >
> > Second, this is a mailing list for a (loosely run) community band,
> > this user is the president of the band and needs access to the mailing
list.
> > Implementing a Mailman list had as its primary goals addressing the
> > problems involved in this user's maintaining his own private copy of
> > his own list -- which was always fraught with error and often out of
> > date.  So having him be able to EASILY get the list is pretty
> > important.  It has taken over six months to get him to switch from his
> > own private list to using the Mailman managed list.  The rest of the
> > band is ecstatic about the Mailman list, since they're now confident
> > that it's always accurate and up to date, and that they won't miss any
messages.
> 
> 
> I suggest the easiest thing is to direct him to the list info page at a
URL like
> http://example.com/mailman/listinfo/LISTNAME, enter his email address and
list
> password in the Address: and Password: boxes near the bottom of the page
and click
> the 'Visit Subscriber List' button.
> 
> Unfortunately, if his address or password is incorrect, all he sees is
> 
> Error
> LISTNAME roster authentication failed.
> 
> 
> > But again, the big GENERAL question here is whether Mailman provides
> > any way of diagnosing such command failures.
> 
> 
> If he is using the email "who" command, he should get an email response.
> Have him forward both his original email and the response email to you.
> Between the two, they contain everything Mailman knows about it. Mailman
is
> designed to help the user find the mistake in this case, not to log
everything for an
> admin.
> 
> You can search the web server and Mail server logs to find if he is
mailing
> LISTNAME-request at ... or POSTing to /mailman/roster/LISTNAME, but you won't
be
> able to see the actual commands or data he's submitting.
> 
> You may ultimately find that actually sitting down with him is the easiest
thing to do. I
> can give you patches to log everything if that's what you want, but
walking him
> through it may be easier assuming he can remember for the next time.
> 
> --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/ghmerrill%40chathamdesign.com


From mark at msapiro.net  Wed Jan 21 05:01:21 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 20 Jan 2015 20:01:21 -0800
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <01ba01d03526$51641fd0$f42c5f70$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com>
Message-ID: <54BF2491.40904@msapiro.net>

On 01/20/2015 06:59 PM, Gary Merrill wrote:
> I was really asking whether there is a way to diagnose command
> failures in Mailman, and it's clear at this point that the answer is "No."
> This isn't entirely unexpected, but I just wanted to check in case there
> happened to be something that I'd missed.


It depends. The user who sends an email command is provided with a
response that tells him what's wrong.

We try to provide diagnostic information that is helpful to the user.
The problem here is we don't anticipate a third party acting at a
distance and unable to get reliable information from his user.


> A "diagnosis" of
> 
>> Error
>> LISTNAME roster authentication failed.


What more would you like to see? Presumably the user knows what he
provided for his email address and password and the response says one or
both is invalid. If the roster is not public, we can't give more
information because if we tell you that it is the password that's
invalid or the email address, this information can be used to fish for
list membership and this is not public information.

You could set Privacy options... -> Subscription rules -> private_roster
(aka Who can view subscription list?) to Anyone and that would simplify
your user's task, but you may not want a public roster.


> Personal consultation and observation appears to be the only approach here
> that will be successful.


As I said,

>> I can give you patches to log everything if that's what you want

Let me know.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From stephen at xemacs.org  Wed Jan 21 05:14:38 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 21 Jan 2015 13:14:38 +0900
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <01ba01d03526$51641fd0$f42c5f70$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com>
 <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com>
Message-ID: <87ppa8vkgh.fsf@uwakimon.sk.tsukuba.ac.jp>

Gary Merrill writes:

 > Personal consultation and observation appears to be the only
 > approach here that will be successful.

If the security implications are acceptable (which I think they are),
you can also provide the user with a precomposed URL that they can put
in their bookmarks list, as Mark mentioned.

We don't provide that kind of thing ourselves because it is a security
risk, and also in some contexts a legal risk (some list owners are
subject to legal requirement to get confirmation for subscription, for
example).

Aside: in this case it's not necessary AFAIK, but in cases where a
CSRF token or similar dynamically generated security token might be
involved, it should be possible to use Java script to acquire and
return the token.


From ghmerrill at chathamdesign.com  Wed Jan 21 15:25:51 2015
From: ghmerrill at chathamdesign.com (Gary Merrill)
Date: Wed, 21 Jan 2015 09:25:51 -0500
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <54BF2491.40904@msapiro.net>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
Message-ID: <01e201d03586$291a1790$7b4e46b0$@com>

Well, let's think about this ...

It's NOT true that "The user who sends an email command is provided with a
response that tells him what's wrong."  The example in question is where a
valid user sends (from his registered address) the command 'who PASSWORD'
but employs the wrong password or mistypes what he thinks is the correct
password.  In that case, the response is

          > You are not allowed to retrieve the list membership

This not only DOESN'T tell him what's wrong (Why am I not allowed to
retrieve the list membership?), but is actually FALSE.  As a registered user
sending from the correct email address, he IS allowed to retrieve the list
membership.  But the message suggests that somehow he (as a registered user)
doesn't have the correct permission to execute the command.  That's just
misleading, confusing, and wrong.

What would I want you to do?  Well, how about a diagnostic of

          > Your request for the list membership has been denied because you
submitted the incorrect password for your account.
         >  The password you submitted was:   PUT_SUBMITTED_PASSWORD_HERE.
         >  This is not your password for the PUT_LIST_NAME_HERE list.

This message is both informative and potentially helpful both to a user and
to a remote administrator, as in the case at hand.  Would it be a "security
risk"?

Now let's look at the claim that "If the roster is not public, we can't give
more information because if we tell you that it is the password that's
invalid or the email address, this information can be used to fish for list
membership and this is not public information."  But this is specious
reasoning.  Why?

An astute user (which we presume  would be the case with someone who's
fishing for list membership) can discover whether the problem is with the
password or the email address.  (Actually the degree of astuteness here is
not high.)   The first thing he needs to do is determine whether he has a
valid email address for a member.  This is simple:  he just fishes on the
email address.  He sends the command

          password

If he somehow manages to send this from the correct email account (or in
some other more sophisticated way manages to send the command and catch the
return message), he's rewarded by the list sending him that password.  Now
he can get the list membership.  If he doesn't send this command from a
member's registered email address, he gets the diagnostic message:

          > You are not a member of the XXXX list.

and he just keeps fishing.  So not telling someone straightforwardly that
they've submitted the wrong password doesn't add any degree of security
against fishing.  Anyone can quickly tell whether an email address is or is
not one for a registered user, and then can quickly tell whether he does or
does not have the correct password -- completely independent of whether you
tell him that explicitly in a diagnostic message.  Or have I missed
something here?  Actually, it seems to me that your response to a 'password'
command from an unregistered email address is unnecessarily informative.  It
would be safer simply to respond with

          > Your request for your password has failed.  Please contact the
list administrator
          > immediately for additional information and to ensure the
security of your account.

This at least doesn't say explicitly to the fisher that he's tried with a
bad email address.  But I think it's splitting hairs since the degree of
security in any case here is fairly low.

So where are we now?  It appears to be pretty clear that providing a more
informative message in this case is both potentially quite helpful (to both
the user and an administrator attempting to help him at a distance), and not
a source of an increased security risk.  So why not do it?

Finally, let's consider "The problem here is we don't anticipate a third
party acting at a distance and unable to get reliable information from his
user."  Why not?  This seems quite a reasonable scenario to anticipate.
Users are notoriously unreliable in what they report and how they report it.
And the user can provide information that's only as reliable and accurate as
what he gets from the list in terms of diagnostics.  I feel a pontificating
lecture coming on about user interaction design, but I'll refrain :-).

At this point it's quite clear that the problem with this user is that he
keeps using the wrong password.  I've told him that, but I somehow have to
(nicely) rub his nose in it.  Without setting up an appointment with him and
travelling about 50 miles round trip (which is going to be unlikely with
him), there's not much I can do.  But the simple change I've suggested in
this one particular diagnostic response would allow me to help him remotely.

_______________

Gary H. Merrill
Chatham Design Consultants
+1 919.271.7259


> -----Original Message-----
> From: Mark Sapiro [mailto:mark at msapiro.net]
> Sent: Tuesday, January 20, 2015 11:01 PM
> To: ghmerrill at chathamdesign.com; mailman-users at python.org
> Subject: Re: [Mailman-Users] Diagnosing command failures
> 
> On 01/20/2015 06:59 PM, Gary Merrill wrote:
> > I was really asking whether there is a way to diagnose command
> > failures in Mailman, and it's clear at this point that the answer is
"No."
> > This isn't entirely unexpected, but I just wanted to check in case
> > there happened to be something that I'd missed.
> 
> 
> It depends. The user who sends an email command is provided with a
response that
> tells him what's wrong.
> 
> We try to provide diagnostic information that is helpful to the user.
> The problem here is we don't anticipate a third party acting at a distance
and unable to
> get reliable information from his user.
> 
> 
> > A "diagnosis" of
> >
> >> Error
> >> LISTNAME roster authentication failed.
> 
> 
> What more would you like to see? Presumably the user knows what he
provided for
> his email address and password and the response says one or both is
invalid. If the
> roster is not public, we can't give more information because if we tell
you that it is the
> password that's invalid or the email address, this information can be used
to fish for
> list membership and this is not public information.
> 
> You could set Privacy options... -> Subscription rules -> private_roster
(aka Who can
> view subscription list?) to Anyone and that would simplify your user's
task, but you
> may not want a public roster.
> 
> 
> > Personal consultation and observation appears to be the only approach
> > here that will be successful.
> 
> 
> As I said,
> 
> >> I can give you patches to log everything if that's what you want
> 
> Let me know.
> 
> --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan


From mark at msapiro.net  Wed Jan 21 17:42:16 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 21 Jan 2015 08:42:16 -0800
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <01e201d03586$291a1790$7b4e46b0$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com>
Message-ID: <54BFD6E8.70804@msapiro.net>

On 01/21/2015 06:25 AM, Gary Merrill wrote:
> 
> Finally, let's consider "The problem here is we don't anticipate a third
> party acting at a distance and unable to get reliable information from his
> user."  Why not?  This seems quite a reasonable scenario to anticipate.
> Users are notoriously unreliable in what they report and how they report it.
> And the user can provide information that's only as reliable and accurate as
> what he gets from the list in terms of diagnostics.  I feel a pontificating
> lecture coming on about user interaction design, but I'll refrain :-).


All this is moot. Mailman 2.1 is over 12 years old and (hopefully) near
the end of it's life cycle. The UI in Mailman 3 is more modular and
completely different.

Maybe the above scenario is reasonable to expect, but it is apparently
infrequent enough that your's is the only such request I've ever seen.


> At this point it's quite clear that the problem with this user is that he
> keeps using the wrong password.  I've told him that, but I somehow have to
> (nicely) rub his nose in it.  Without setting up an appointment with him and
> travelling about 50 miles round trip (which is going to be unlikely with
> him), there's not much I can do.  But the simple change I've suggested in
> this one particular diagnostic response would allow me to help him remotely.


And, you could send him an email with a
<mailto:LISTNAME-request at ...?subject=who%20PASSWORD> link in it hand
have him just click that and send.

I assume you can find his password with something like

bin/dumpdb lists/LISTNAME/config.pck | grep <his email>

since your original request was for logs.

And for the third time, if you want patches, ask and I'll send you
patches. In any case, this will get you something faster than waiting
for a new Mailman release.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From pshute at nuw.org.au  Wed Jan 21 19:14:16 2015
From: pshute at nuw.org.au (Peter Shute)
Date: Thu, 22 Jan 2015 05:14:16 +1100
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <54BFD6E8.70804@msapiro.net>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
Message-ID: <377795FF-F732-4C59-85E5-518C4F5E3722@nuw.org.au>

If he can't get that to work, perhaps you could schedule a script to run it yourself and email him the results, say once a week.

Peter Shute

Sent from my iPad

> On 22 Jan 2015, at 3:42 am, Mark Sapiro <mark at msapiro.net> wrote:
> 
> And, you could send him an email with a
> <mailto:LISTNAME-request at ...?subject=who%20PASSWORD> link in it hand
> have him just click that and send.

From mark at msapiro.net  Thu Jan 22 03:03:58 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 21 Jan 2015 18:03:58 -0800
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <54BFD6E8.70804@msapiro.net>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
Message-ID: <54C05A8E.1000308@msapiro.net>

On 01/21/2015 08:42 AM, Mark Sapiro wrote:
> 
> And, you could send him an email with a
> <mailto:LISTNAME-request at ...?subject=who%20PASSWORD> link in it hand
> have him just click that and send.
> 
> I assume you can find his password with something like
> 
> bin/dumpdb lists/LISTNAME/config.pck | grep <his email>
> 
> since your original request was for logs.


It occurs to me that possibly he is having so much difficulty because
his password contains leading or trailing white space. I don't think
this is possible with recent versions, but there have been bugs in this
area in the past. What is your Mailman version? have you seen his
password with something like the above?

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From ghmerrill at chathamdesign.com  Thu Jan 22 04:44:25 2015
From: ghmerrill at chathamdesign.com (Gary Merrill)
Date: Wed, 21 Jan 2015 22:44:25 -0500
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <54C05A8E.1000308@msapiro.net>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
 <54C05A8E.1000308@msapiro.net>
Message-ID: <01e901d035f5$b864fc70$292ef550$@com>

I don't think this is the problem.  So far as I know he has been using
single-word passwords with only alphabetic characters in them.  I'm really
surprised that there would have been a bug involving initial or terminal
whitespace, but I suppose these things happen.  (Trying to imagine how that
could have been left out of the tokenizer -- can't quite do it :-) ).  We
are using version 2.1.18-1 -- which appears to be the most recent stable
release.

I do appreciate your efforts to help, but you should realize that some of
them are based on assumptions that simply don't hold in this case --
although they pretty universally held when Mailman was originally written,
and for some time afterward.  The primary underlying assumption is that the
list administrator will have access to at least most aspects of the OS and
server environment.  In this case, that isn't true.

We subscribe to web hosting from Webhostingpad.com.  The level of our
service does not give me a virtual machine, doesn't provide me with root
access, doesn't even provide me with a shell, and does not provide me with
direct access to any databases (I can create them and layout the tables, but
that's about it).  So I can't look at server logs and can't run shell
scripts. I can't throw SQL at a db.  I can't see any of the file system
that's outside of my "home" directory tree.  So I can't even see where any
of the usual Mailman files are.  I can only manage things through the
Mailman web interface.  Oddly, I can create cron jobs, but really have no
way of testing/debugging them aside from creating the job and seeing what
happens.  Mailman lists are offered as one of the utilities under the Mail
heading in Cpanel.  It's simple.  It works.

So suggestions about checking server logs, or the database, or running a
shell script just aren't things I'm able to do.  There's really no point in
our having a higher degree of service since (whenever I turn this over to
someone else), the level of knowledge of whomever ends up managing it after
I do will be very low -- and may not include any *NIX experience at all.
I'm trying to create an integrated web site and set of communication
utilities that are virtually self-maintaining, other than having to modify
web pages now and then, and maybe having to manage/configure mailing lists
and users and such.  For this reason, I am not interested in patches or
custom code -- much as I love Python myself.  In our entire band I would
estimate that there are maybe three people who know what Python is, and I'm
one of them.  Any C or C# or C++ programmers?  Maybe one or two others.  Any
really competent ones?  Highly doubtful.  Maybe one other.

Now you might argue that Mailman was never intended to be deployed in such a
lame support environment.  That is almost certainly true.  But it's ALMOST
good enough to stand on its own feet in this environment, and I think that a
number of subscribers to Webhostingpad make use of it.  It's been working
very reliably and well with this one exception -- which is certainly the
problem of this single user.  Since Mailman doesn't log failures and doesn't
return specific enough diagnostics to tell exactly what's going on, I'll
have to deal with it a more direct and personal way.  I think the best thing
to do would be to get one of his buddies to sit down with him and show him
how to do it and what his problem is.

Thanks for the suggestions.

_______________

Gary H. Merrill
Chatham Design Consultants
+1 919.271.7259


> -----Original Message-----
> From: Mailman-Users [mailto:mailman-users-
> bounces+ghmerrill=chathamdesign.com at python.org] On Behalf Of Mark Sapiro
> Sent: Wednesday, January 21, 2015 9:04 PM
> To: mailman-users at python.org
> Subject: Re: [Mailman-Users] Diagnosing command failures
> 
> On 01/21/2015 08:42 AM, Mark Sapiro wrote:
> >
> > And, you could send him an email with a
> > <mailto:LISTNAME-request at ...?subject=who%20PASSWORD> link in it hand
> > have him just click that and send.
> >
> > I assume you can find his password with something like
> >
> > bin/dumpdb lists/LISTNAME/config.pck | grep <his email>
> >
> > since your original request was for logs.
> 
> 
> It occurs to me that possibly he is having so much difficulty because his
password
> contains leading or trailing white space. I don't think this is possible
with recent
> versions, but there have been bugs in this area in the past. What is your
Mailman
> version? have you seen his password with something like the above?
> 
> --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/ghmerrill%40chathamdesign.com


From mark at msapiro.net  Thu Jan 22 05:10:20 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 21 Jan 2015 20:10:20 -0800
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <01e901d035f5$b864fc70$292ef550$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
 <54C05A8E.1000308@msapiro.net> <01e901d035f5$b864fc70$292ef550$@com>
Message-ID: <54C0782C.9060406@msapiro.net>

On 01/21/2015 07:44 PM, Gary Merrill wrote:
> 
> I do appreciate your efforts to help, but you should realize that some of
> them are based on assumptions that simply don't hold in this case --
> although they pretty universally held when Mailman was originally written,
> and for some time afterward.  The primary underlying assumption is that the
> list administrator will have access to at least most aspects of the OS and
> server environment.  In this case, that isn't true.


I normally do not assume that people have access to the underlying file
system. If you check the archives of this list, you'll see that I often
go to extra lengths to help people who don't have that access.

I only thought that you might, because your initial post in this thread
asked about logging of errors, so it seemed you might actually have
access to Mailman's logs.


> We subscribe to web hosting from Webhostingpad.com.  The level of our
> service does not give me a virtual machine, doesn't provide me with root
> access, doesn't even provide me with a shell, and does not provide me with
> direct access to any databases (I can create them and layout the tables, but
> that's about it).  So I can't look at server logs and can't run shell
> scripts. I can't throw SQL at a db.  I can't see any of the file system
> that's outside of my "home" directory tree.  So I can't even see where any
> of the usual Mailman files are.  I can only manage things through the
> Mailman web interface.  Oddly, I can create cron jobs, but really have no
> way of testing/debugging them aside from creating the job and seeing what
> happens.  Mailman lists are offered as one of the utilities under the Mail
> heading in Cpanel.  It's simple.  It works.


I did have a conversation about access to logs with a cPanel developer
at PyCon a couple of years ago. The issue is most cPanel Mailman
installs are at hosting companies, and the logs are global so access to
the logs implies access to information from domains other than yours so
the host doesn't want to give you access. I said that this was a problem
with supporting users of cPanel hosted Mailman because they can't see
relevant log info, and their hosting service a) wouldn't support Mailman
and b) wouldn't even provide them with relevant log info.

cPanel at the time seemed interested in doing something to help with
this, but more recently, it seems they want to help only by giving money
to the GNU Mailman project, not by actually implementing a cPanel solution.

Note that not all cPanel hosting services fail to provide decent Mailman
support. There are some exceptions (at least one principal is active on
this list) that will work with you to help and that actively support
Mailman. Unfortunately, there are a lot of hosts that only offer Mailman
because it "comes with" cPanel and don't want to support it.


> Since Mailman doesn't log failures


Actually, Mailman logs quite a bit. It doesn't log the specific
information you want in this case, but if I told you it did, how would
you know otherwise as you don't have access to Mailman's logs ;)

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From pshute at nuw.org.au  Thu Jan 22 05:13:41 2015
From: pshute at nuw.org.au (Peter Shute)
Date: Thu, 22 Jan 2015 15:13:41 +1100
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <01e901d035f5$b864fc70$292ef550$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
 <54C05A8E.1000308@msapiro.net> <01e901d035f5$b864fc70$292ef550$@com>
Message-ID: <C2F1879073AE7347BAB44065F143E1700184D566F7@nuwvicms2>

Gary Merrill wrote:

> Now you might argue that Mailman was never intended to be 
> deployed in such a lame support environment.  That is almost 

It sounds like a fairly typical mailman support environment.

> certainly true.  But it's ALMOST good enough to stand on its 
> own feet in this environment, and I think that a number of 
> subscribers to Webhostingpad make use of it.  It's been 
> working very reliably and well with this one exception -- 
> which is certainly the problem of this single user.  Since 
> Mailman doesn't log failures and doesn't return specific 
> enough diagnostics to tell exactly what's going on, I'll have 
> to deal with it a more direct and personal way.  I think the 
> best thing to do would be to get one of his buddies to sit 
> down with him and show him how to do it and what his problem is.

A lot of people use the cPanel version and can't do anything complicated for support. Even though this particular case is about trying to help a difficult user to do something that's normally straightforward that's probably pointless anyway, I hope v3 at least gives cPanel users access to more diagnostics than v2 does.

Peter Shute

From brian at emwd.com  Thu Jan 22 05:33:26 2015
From: brian at emwd.com (Brian Carpenter)
Date: Wed, 21 Jan 2015 23:33:26 -0500
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <C2F1879073AE7347BAB44065F143E1700184D566F7@nuwvicms2>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
 <54C05A8E.1000308@msapiro.net> <01e901d035f5$b864fc70$292ef550$@com>
 <C2F1879073AE7347BAB44065F143E1700184D566F7@nuwvicms2>
Message-ID: <22bd01d035fc$90a75320$b1f5f960$@emwd.com>

> Gary Merrill wrote:
> 
> > Now you might argue that Mailman was never intended to be
> > deployed in such a lame support environment.  That is almost
> 
> It sounds like a fairly typical mailman support environment.
> 
> > certainly true.  But it's ALMOST good enough to stand on its
> > own feet in this environment, and I think that a number of
> > subscribers to Webhostingpad make use of it.  It's been
> > working very reliably and well with this one exception --
> > which is certainly the problem of this single user.  Since
> > Mailman doesn't log failures and doesn't return specific
> > enough diagnostics to tell exactly what's going on, I'll have
> > to deal with it a more direct and personal way.  I think the
> > best thing to do would be to get one of his buddies to sit
> > down with him and show him how to do it and what his problem is.
> 
> A lot of people use the cPanel version and can't do anything complicated
for
> support. Even though this particular case is about trying to help a
difficult
> user to do something that's normally straightforward that's probably
> pointless anyway, I hope v3 at least gives cPanel users access to more
> diagnostics than v2 does.
> 
> Peter Shute

This is not limited to mailman on cPanel boxes. Since we offer a mailman
only hosting service (separate from our shared hosting service) that runs on
cPanel servers, we find ourselves often in a position on needing a client to
contact their own web hosting company for help since we can only go so far
in trouble-shooting list delivery issues. This requires the separate hosting
company to go into their own mail logs and that my friends, is where things
seem to go wrong quickly. Too many in my opinion just are not willing to go
into any depth to help their clients. 

Today, I had to help out Godaddy's tech support because they totally wreck
their (and ours) client's ability to post to their own mailman list which
was hosted with us. 

Brian Carpenter
Owner

Providing Cloud and Mailman Hosting Services and more for over 15 years.

E: brian at emwd.com
www.emwd.com
www.mailmanhost.com



From stephen at xemacs.org  Thu Jan 22 11:44:06 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 22 Jan 2015 19:44:06 +0900
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <C2F1879073AE7347BAB44065F143E1700184D566F7@nuwvicms2>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com>
 <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
 <54C05A8E.1000308@msapiro.net>
 <01e901d035f5$b864fc70$292ef550$@com>
 <C2F1879073AE7347BAB44065F143E1700184D566F7@nuwvicms2>
Message-ID: <8761bzumbt.fsf@uwakimon.sk.tsukuba.ac.jp>

Peter Shute writes:

 > A lot of people use the cPanel version and can't do anything
 > complicated for support. Even though this particular case is about
 > trying to help a difficult user to do something that's normally
 > straightforward that's probably pointless anyway, I hope v3 at
 > least gives cPanel users access to more diagnostics than v2 does.

Don't hold your breath.  The problem is hosting services (and to some
extent cPanel itself), not Mailman.  If they wanted to provide the
kind of service you want, they could ask us for help and we'd give it
to them.  (Eg, it probably wouldn't be too hard to grep for specific
vhosts in the logs, and so minimize the probability of cross-vhost
personal information leakage.  Of course, if they wanted to do that
they probably already can.  Evidently they don't care. :-( )  But if
we added an option to (say) display the "smtp" log (or a hypothetical
"auth" log for the current thread) the first thing they'd do is
disable it in Defaults.py for the cPanel version since it would be too
likely to leak personal data across virtual domains.

We do have some work (courtesy Andrew Stuart) ongoing to improve
authentication for access to core databases in Mailman 3.  I don't
know exactly what that work is at the momemnt, but it might be
possible to leverage it so that subscribers and/or list owners could
use Mozilla Persona or OAuth2 to access the information they're
authorized for.  (Postorius already requires, or soon will require,
Persona for authorization IIRC.)  At least then you can pass the buck
for authn/authz issues to Google or Mozilla. ;-)

If you have *specific* diagnostics that don't violate the hosting
services' senses of propriety (and I suppose they normally won't be
problematic), please, *please*, PLEASE *ask* for them by name (a brief
description is fine, too, of course).  "More diagnostics" is not a
requirement we can use to specify and design new features.

Preferably a bug report to Launchpad, tagged "mailman3", but a post to
the list or a request on IRC would probably be picked up, too.


From ghmerrill at chathamdesign.com  Thu Jan 22 17:10:29 2015
From: ghmerrill at chathamdesign.com (Gary Merrill)
Date: Thu, 22 Jan 2015 11:10:29 -0500
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <8761bzumbt.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
 <54C05A8E.1000308@msapiro.net> <01e901d035f5$b864fc70$292ef550$@com>
 <C2F1879073AE7347BAB44065F143E1700184D566F7@nuwvicms2>
 <8761bzumbt.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <01f401d0365d$f1894cf0$d49be6d0$@com>

Again, thanks to all of you for your responses.  There are a number of thorny issues in attempting to "fix" (or at least address) what is "wrong" here.  The original conceptual model of something like Mailman isn't quite right for the situation being faced today in the types of capabilities and support offered to the "general public".  This doesn't mean that that model was wrong, but that's it's not a thoroughly good fit for a certain service/support/marketing model employed by others.  Making things "fit" better is a daunting task because of the numbers and types of players involved, and their varied goals and constraints.  Hey, before I retired, I spent about 13 years developing knowledge representations and software (server and user) for multiple disparate medical coding schemes for the purposes of drug discovery and adverse event detection.  I know the kinds of problems you guys are facing -- although you should be somewhat grateful that you aren't dealing with the FDA, insurance companies, gigantic healthcare organizations, the CDC, and multiple pharma companies. :-)    "Don't hold your breath" is a perfectly apt comment.

The hosting services companies may want to provide certain services (or at least their developers and support staffs may).  They (meaning the their developers and support organization) may in fact care, but they may be severely constrained in what they can do within the economic model of the company and how effectively they can fight their marketing organization.  The issues here often aren't technical, but economic and political (in the sense of company politics).  Sometimes the good guys win, and a lot of times they don't.  And to some degree you get what you pay for (if you're lucky and deal with a reputable provider).  I'm quite happy with the service and support that Webhostingpad has provided me (I have two sites hosted by them).

Prior to running the Mailman list for this community band, I had -- for a year -- been running a phpBB bulletin board.  Of course this is quite different from Mailman, is more feature-rich, employs a completely different conceptual model and architecture, and required that I install and configure it myself.  That gave me a lot more control over it than I have over my Mailman lists that are available through Cpanel.  It was a noble experiment that failed.  While the majority of the band really liked the idea and functionality of forums, there was a contingent that was highly resistant to using that approach.  (These were not always, or even generally, the elder members, but somewhat oddly tend to be in the 45-55-ish age group.)  They didn't like having to go to the site ... they didn't like having to employ a password to access it ... but they wanted to be sure that everything was secure and not visible to outsiders ... the primary people who in fact needed to make postings to the forum on a regular basis "couldn't remember" to do so, etc.  Basically, it was something that a contingent of the organization wasn't familiar with and just didn't want to learn about -- whatever the advantages were.  It gave me a lot of flexibility and control because virtually everything concerning its administration was in "my own space".  As in the case with Mailman, I avoided any patches, custom code, or addition of anything other than the base modules and some images.  I had to abandon it because as a communication mechanism, it just wasn't working for this group of people.  No amount of education or support would solve the problem.

I then recalled the experience I'd had with the listservs used by the National Library of Medicine and thought:  That should do the trick for this group.  Their model of online communication is email.  It's simple.  Of course, 80% of my organization can't distinguish between a privately held and maintained mailing list of contacts and a mailing list managed by something like Mailman -- but it's working out nicely and they're learning the few important fundamentals over time.  By far, most of them have never changed their default password (everyone originally was batch-subscribed) or even used their password or felt the need to.  Many of them have probably forgotten that they even have a password.

>From my point of view, what would be ideal in managing a Mailman list would be to have all the relevant data for the list in "my space", and accessible to me so that on the rare occasions when things don't work I could at least look for what is causing the problem.  Some configurable level of logging (again with the information kept in "my space") would be very helpful so that this could be turned on and off as necessary.  Perhaps administrator-configurable/editable error messages would be nice as well -- and ones not requiring modifying code or central files governing the entire Mailman instance.

That is, some enhanced degree of "local list control" would be very helpful.  Currently this seems to be supported only through the ability to edit "public" HTML and text files (of which there are few) -- so someone has recognized the utility of local list control, but it's just never been taken very far.  This is all to say that I think much would be gained by moving the perspective of "the administrator" from a global perspective to a more list-local perspective in many instances.  Perhaps the upcoming release will include such things; perhaps not.  I don't know your architecture or your constraints, and so I'm not going to start pitching such ideas at you in the form of change requests.

Mailman is currently quite nicely satisfying the needs I have, and I look forward to the next release.

_______________

Gary H. Merrill
Chatham Design Consultants
+1 919.271.7259


> -----Original Message-----
> From: Stephen J. Turnbull [mailto:stephen at xemacs.org]
> Sent: Thursday, January 22, 2015 5:44 AM
> To: Peter Shute
> Cc: 'ghmerrill at chathamdesign.com'; 'Mark Sapiro'; Mailman Users
> Subject: Re: [Mailman-Users] Diagnosing command failures
> 
> Peter Shute writes:
> 
>  > A lot of people use the cPanel version and can't do anything  > complicated for
> support. Even though this particular case is about  > trying to help a difficult user to do
> something that's normally  > straightforward that's probably pointless anyway, I hope
> v3 at  > least gives cPanel users access to more diagnostics than v2 does.
> 
> Don't hold your breath.  The problem is hosting services (and to some extent cPanel
> itself), not Mailman.  If they wanted to provide the kind of service you want, they
> could ask us for help and we'd give it to them.  (Eg, it probably wouldn't be too hard to
> grep for specific vhosts in the logs, and so minimize the probability of cross-vhost
> personal information leakage.  Of course, if they wanted to do that they probably
> already can.  Evidently they don't care. :-( )  But if we added an option to (say) display
> the "smtp" log (or a hypothetical "auth" log for the current thread) the first thing they'd
> do is disable it in Defaults.py for the cPanel version since it would be too likely to leak
> personal data across virtual domains.
> 
> We do have some work (courtesy Andrew Stuart) ongoing to improve authentication
> for access to core databases in Mailman 3.  I don't know exactly what that work is at
> the momemnt, but it might be possible to leverage it so that subscribers and/or list
> owners could use Mozilla Persona or OAuth2 to access the information they're
> authorized for.  (Postorius already requires, or soon will require, Persona for
> authorization IIRC.)  At least then you can pass the buck for authn/authz issues to
> Google or Mozilla. ;-)
> 
> If you have *specific* diagnostics that don't violate the hosting services' senses of
> propriety (and I suppose they normally won't be problematic), please, *please*,
> PLEASE *ask* for them by name (a brief description is fine, too, of course).  "More
> diagnostics" is not a requirement we can use to specify and design new features.
> 
> Preferably a bug report to Launchpad, tagged "mailman3", but a post to the list or a
> request on IRC would probably be picked up, too.



From pknowles at tpnsolutions.com  Thu Jan 22 17:17:33 2015
From: pknowles at tpnsolutions.com (Peter Knowles)
Date: Thu, 22 Jan 2015 08:17:33 -0800
Subject: [Mailman-Users] Digest Volume Frequency
Message-ID: <CAD=__t_wH4v-Bwvd2Fkk7N2+GmvLiRCnmD=iK0VxL7Qb0BFB3A@mail.gmail.com>

Hi,

When I set the "Digest Volume Frequency" to "Weekly" is there a way set the
day which messages are sent out (Sun, Mon, Tue, Wed, Thu, Fri, Sat)?

I'm currently using Mailman 2.1.18-1

Best Regards,
Peter Knowles
TPN Solutions

Email: pknowles at tpnsolutions.com
Phone: 604-782-9342
Skype: tpnsupport
Website: http://www.tpnsolutions.com

From mark at msapiro.net  Thu Jan 22 17:53:36 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 22 Jan 2015 08:53:36 -0800
Subject: [Mailman-Users] Digest Volume Frequency
In-Reply-To: <CAD=__t_wH4v-Bwvd2Fkk7N2+GmvLiRCnmD=iK0VxL7Qb0BFB3A@mail.gmail.com>
References: <CAD=__t_wH4v-Bwvd2Fkk7N2+GmvLiRCnmD=iK0VxL7Qb0BFB3A@mail.gmail.com>
Message-ID: <54C12B10.80005@msapiro.net>

On 01/22/2015 08:17 AM, Peter Knowles wrote:
> Hi,
> 
> When I set the "Digest Volume Frequency" to "Weekly" is there a way set the
> day which messages are sent out (Sun, Mon, Tue, Wed, Thu, Fri, Sat)?


"Digest Volume Frequency" has nothing to do with when digests are sent.
It only controls how often the digest volume number is incremented and
the issue number set back to 1.

If you want to control when periodic digests are sent, you can adjust
Mailman's crontab to run cron/senddigests only say on Wednesdays.

Doing this for a single list is tricky. You could have an entry like, e.g.

0 12 * * 3 /usr/bin/python /usr/local/mailman/cron/senddigests -l list1

to send a periodic digest for list1 at noon on Wednesdays, but then you
would also need a separate entry with '-l list2 -l list3 ...' naming
every other list to send daily digests for those lists, and if you added
a list without updating this, it would get no periodic digests at all,
and you can't run senddigests without -l because that will do all lists
including list1.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From bsfinkel at att.net  Thu Jan 22 23:11:40 2015
From: bsfinkel at att.net (Barry S. Finkel)
Date: Thu, 22 Jan 2015 16:11:40 -0600
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <01f401d0365d$f1894cf0$d49be6d0$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com> <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
 <54C05A8E.1000308@msapiro.net> <01e901d035f5$b864fc70$292ef550$@com>
 <C2F1879073AE7347BAB44065F143E1700184D566F7@nuwvicms2>
 <8761bzumbt.fsf@uwakimon.sk.tsukuba.ac.jp>
 <01f401d0365d$f1894cf0$d49be6d0$@com>
Message-ID: <54C1759C.3060208@att.net>

On 1/22/2015 10:10 AM, Gary Merrill wrote:
 > Again, thanks to all of you for your responses.  There are a number 
of thorny issues in attempting to "fix" (or at least address) what is 
"wrong" here.  The original conceptual model of something like Mailman 
isn't quite right for the situation being faced today in the types of 
capabilities and support offered to the "general public".  This doesn't 
mean that that model was wrong, but that's it's not a thoroughly good 
fit for a certain service/support/marketing model employed by others. 
Making things "fit" better is a daunting task because of the numbers and 
types of players involved, and their varied goals and constraints.  Hey, 
before I retired, I spent about 13 years developing knowledge 
representations and software (server and user) for multiple disparate 
medical coding schemes for the purposes of drug discovery and adverse 
event detection.  I know the kinds of problems you guys are facing -- 
although you should be somewhat grateful that you aren't dealing with 
the FDA, insurance
 >    companies, gigantic healthcare organizations, the CDC, and 
multiple pharma companies. :-)    "Don't hold your breath" is a 
perfectly apt comment.
 >
 > The hosting services companies may want to provide certain services 
(or at least their developers and support staffs may).  They (meaning 
the their developers and support organization) may in fact care, but 
they may be severely constrained in what they can do within the economic 
model of the company and how effectively they can fight their marketing 
organization.  The issues here often aren't technical, but economic and 
political (in the sense of company politics).  Sometimes the good guys 
win, and a lot of times they don't.  And to some degree you get what you 
pay for (if you're lucky and deal with a reputable provider).  I'm quite 
happy with the service and support that Webhostingpad has provided me (I 
have two sites hosted by them).
 >
 > Prior to running the Mailman list for this community band, I had -- 
for a year -- been running a phpBB bulletin board.  Of course this is 
quite different from Mailman, is more feature-rich, employs a completely 
different conceptual model and architecture, and required that I install 
and configure it myself.  That gave me a lot more control over it than I 
have over my Mailman lists that are available through Cpanel.  It was a 
noble experiment that failed.  While the majority of the band really 
liked the idea and functionality of forums, there was a contingent that 
was highly resistant to using that approach.  (These were not always, or 
even generally, the elder members, but somewhat oddly tend to be in the 
45-55-ish age group.)  They didn't like having to go to the site ... 
they didn't like having to employ a password to access it ... but they 
wanted to be sure that everything was secure and not visible to 
outsiders ... the primary people who in fact needed to make postings to 
the for
 >   um on a regular basis "couldn't remember" to do so, etc. 
Basically, it was something that a contingent of the organization wasn't 
familiar with and just didn't want to learn about -- whatever the 
advantages were.  It gave me a lot of flexibility and control because 
virtually everything concerning its administration was in "my own 
space".  As in the case with Mailman, I avoided any patches, custom 
code, or addition of anything other than the base modules and some 
images.  I had to abandon it because as a communication mechanism, it 
just wasn't working for this group of people.  No amount of education or 
support would solve the problem.
 >
 > I then recalled the experience I'd had with the listservs used by the 
National Library of Medicine and thought:  That should do the trick for 
this group.  Their model of online communication is email.  It's simple. 
  Of course, 80% of my organization can't distinguish between a 
privately held and maintained mailing list of contacts and a mailing 
list managed by something like Mailman -- but it's working out nicely 
and they're learning the few important fundamentals over time.  By far, 
most of them have never changed their default password (everyone 
originally was batch-subscribed) or even used their password or felt the 
need to.  Many of them have probably forgotten that they even have a 
password.
 >
 >>From my point of view, what would be ideal in managing a Mailman list 
would be to have all the relevant data for the list in "my space", and 
accessible to me so that on the rare occasions when things don't work I 
could at least look for what is causing the problem.  Some configurable 
level of logging (again with the information kept in "my space") would 
be very helpful so that this could be turned on and off as necessary. 
Perhaps administrator-configurable/editable error messages would be nice 
as well -- and ones not requiring modifying code or central files 
governing the entire Mailman instance.
 >
 > That is, some enhanced degree of "local list control" would be very 
helpful.  Currently this seems to be supported only through the ability 
to edit "public" HTML and text files (of which there are few) -- so 
someone has recognized the utility of local list control, but it's just 
never been taken very far.  This is all to say that I think much would 
be gained by moving the perspective of "the administrator" from a global 
perspective to a more list-local perspective in many instances.  Perhaps 
the upcoming release will include such things; perhaps not.  I don't 
know your architecture or your constraints, and so I'm not going to 
start pitching such ideas at you in the form of change requests.
 >
 > Mailman is currently quite nicely satisfying the needs I have, and I 
look forward to the next release.
 >
 > _______________
 >
 > Gary H. Merrill
 > Chatham Design Consultants
 > +1 919.271.7259


One quick comment on Mailman support - When I was managing a Mailman
installation on Ubuntu, I was told that I had to install a package.
I looked at the Ubuntu package and compared the source therein with
the SourceForge source.  There were many changes, and I could not
determine what they all were.  My boss told me that we could install
the Ubuntu package and then get a support contract with Debian/Ubuntu.
I told him that I was more comfortable with the SourceForge source
and the support I got from this list.  He allowed me to build a Mailman
package from the SourceForge source, and that is what I did.
I never installed the Debian/Ubuntu Mailman package, so I never had to
talk to the Debian/Ubuntu Mailman support staff.

--Barry Finkel


From stephen at xemacs.org  Fri Jan 23 05:36:01 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 23 Jan 2015 13:36:01 +0900
Subject: [Mailman-Users] Diagnosing command failures
In-Reply-To: <01f401d0365d$f1894cf0$d49be6d0$@com>
References: <009501d033fa$12c02fd0$38408f70$@com>
 <201501191609.t0JG9eFw032337@sharky2.deepsoft.com>
 <00d301d03405$46715e20$d3541a60$@com>
 <54BD8E8D.6050401@msapiro.net>
 <01ba01d03526$51641fd0$f42c5f70$@com> <54BF2491.40904@msapiro.net>
 <01e201d03586$291a1790$7b4e46b0$@com> <54BFD6E8.70804@msapiro.net>
 <54C05A8E.1000308@msapiro.net>
 <01e901d035f5$b864fc70$292ef550$@com>
 <C2F1879073AE7347BAB44065F143E1700184D566F7@nuwvicms2>
 <8761bzumbt.fsf@uwakimon.sk.tsukuba.ac.jp>
 <01f401d0365d$f1894cf0$d49be6d0$@com>
Message-ID: <87wq4et8pa.fsf@uwakimon.sk.tsukuba.ac.jp>

Gary Merrill writes:

 > I know the kinds of problems you guys are facing -- although you
 > should be somewhat grateful that you aren't dealing with the FDA,
 > insurance companies, gigantic healthcare organizations, the CDC,
 > and multiple pharma companies. :-)

I don't have to deal with them, but many of my thesis students study
exactly the set of problems you're referring to and I shudder at the
thought of trying to develop for that industry.

 > From my point of view, what would be ideal in managing a Mailman
 > list would be to have all the relevant data for the list in "my
 > space", and accessible to me so that on the rare occasions when
 > things don't work I could at least look for what is causing the
 > problem.

If you have specific requirements, it's actually very likely that they
would be implemented.  For example in another thread somebody was
cloning a list (ie, he wanted a configuration very similar to one he'd
created previously, but with all-new membership, and I casually asked
Mark if he had a script.  He didn't (then :-), but within 48 hours he
had already released a first version and the first upgrade.  Specific
need + fairly well-defined statement (but full spec not required) =
quick response.

But if you just say "all relevant", hey, we can turn the firehose on
you but I don't think you'll like that.  And experience shows that
we're not very good at guessing what *others* mean by "relevant".  We
know what *we* mean by "relevant" -- and have already implemented 99%
of it.

If it's newly collected data, it may take a while to percolate into
the release (and then longer again if you want a package from your
distribution).  But often the data is collected but not collated, and
a script could be written to do that work (several people have such
scripts, but they're often 3rd-party-software-specifc, eg, to a
particular MTA).  That can often be done in a day or seven.

 > I don't know your architecture or your constraints, and so I'm not
 > going to start pitching such ideas at you in the form of change
 > requests.

Speaking only for myself, I wish you would.  (Well, I do suspect the
other devs -- who write a lot more code than I do -- feel the same
way.)  We know the architecture, you know the (for values of "the" ==
"your" :-) requirements.  We can always WONTFIX them, which of course
is frustrating for you, and (here I'm sure I'm speaking for all
Mailman devs) we genuinely regret your frustration.  But if you don't
tell us, there's a very good chance we'll never hit on the idea.

Note that for mail flows, the architecture is extremely flexible.  We
have a *lot* of metadata attached to *each* message, and a pipeline of
"handlers" which use that data in various ways.  An optional enhanced
logging handler could easily be added "immediately" and per-list (for
folks who have access to the Mailman installation, of course).  I
don't think it's that easy in the web interface, but I could be wrong
(and it wouldn't be hard in a future version to install a hook for
user-installed handlers if some provision doesn't exist already).

 > Mailman is currently quite nicely satisfying the needs I have, and
 > I look forward to the next release.

Glad to hear that!


From sandovaledgardo at yahoo.com.ar  Thu Jan 22 17:47:15 2015
From: sandovaledgardo at yahoo.com.ar (Edgardo Sandoval)
Date: Thu, 22 Jan 2015 16:47:15 +0000 (UTC)
Subject: [Mailman-Users] Changing values at header/footer
Message-ID: <1844801153.3083631.1421945235520.JavaMail.yahoo@jws100117.mail.ne1.yahoo.com>

Hello everibody,
This is my first list that I am setting and I wonder if I could add to my footer/header a small line like for example:
Message Ref.: #123456789 ??Date: 22/01/2015 17:10
I was searching to get a list of command in Python, like the original footer, but no good results:
%(real_name)s mailing list%(real_name)s@%(host_name)s%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s?Thanks a lot from Argentina!Best regards,Edgardo

From mark at msapiro.net  Fri Jan 23 19:48:11 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 23 Jan 2015 10:48:11 -0800
Subject: [Mailman-Users] Changing values at header/footer
In-Reply-To: <1844801153.3083631.1421945235520.JavaMail.yahoo@jws100117.mail.ne1.yahoo.com>
References: <1844801153.3083631.1421945235520.JavaMail.yahoo@jws100117.mail.ne1.yahoo.com>
Message-ID: <54C2976B.5090107@msapiro.net>

On 01/22/2015 08:47 AM, Edgardo Sandoval wrote:
> Hello everibody,
> This is my first list that I am setting and I wonder if I could add to my footer/header a small line like for example:
> Message Ref.: #123456789   Date: 22/01/2015 17:10
> I was searching to get a list of command in Python, like the original footer, but no good results:
> %(real_name)s mailing list%(real_name)s@%(host_name)s%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s Thanks a lot from Argentina!Best regards,Edgardo


I'm not sure what you mean by Message Ref.:, but the value of this is
probably not available and neither is the date. If you follow the
'(Details for msg_footer)' link on the list admin Non-digest options
page, you will see what substitutions are available for msg_footer (and
also msg_header).

If you have access to the underlying software and Python skills, one way
to do this is to add a custom handler (see
<http://wiki.list.org/x/l4A9>) in the pipeline ahead of ToOutgoing which
will create or augment a msgdata.decoration-data dictionary to include
key:value replacements for things like the date/time and maybe Message
Ref., but if you intend Message Ref. to refer to the archived message in
some way, it is not possible to do this because archiving and delivery
are asynchronous processes and the message delivery process can't
determine anything about the ultimate location of a message in the archive.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From dap1 at bellsouth.net  Fri Jan 23 22:26:27 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Fri, 23 Jan 2015 16:26:27 -0500
Subject: [Mailman-Users] listinfo_url Wrong
Message-ID: <54C2BC83.1040104@bellsouth.net>

How is listinfo_url used in templates set? I am guessing I have
something configured wrong somewhere because the templates where that is
used has just the host name not the FQDN. Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150123/aa639a83/attachment.sig>

From mark at msapiro.net  Fri Jan 23 22:49:48 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 23 Jan 2015 13:49:48 -0800
Subject: [Mailman-Users] listinfo_url Wrong
In-Reply-To: <54C2BC83.1040104@bellsouth.net>
References: <54C2BC83.1040104@bellsouth.net>
Message-ID: <54C2C1FC.9030304@msapiro.net>

On 01/23/2015 01:26 PM, Dennis Putnam wrote:
> How is listinfo_url used in templates set? I am guessing I have
> something configured wrong somewhere because the templates where that is
> used has just the host name not the FQDN. Thanks.


Each piece of code that uses a template sets the replacement for that
template.

However, the good news is they all get it the same way, via the list
method GetScriptURL('listinfo', absolute=1). This in turn uses the list
attribute web_page_url which is set at list creation time from the
Defaults.py/mm_cfg.py setting for DEFAULT_URL_PATTERN filled in with the
list's url host.

See the FAQ at <http://wiki.list.org/x/mIA9> for more and how to fix it.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150123/0145b39a/attachment.sig>

From dap1 at bellsouth.net  Fri Jan 23 23:56:40 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Fri, 23 Jan 2015 17:56:40 -0500
Subject: [Mailman-Users] listinfo_url Wrong
In-Reply-To: <54C2C1FC.9030304@msapiro.net>
References: <54C2BC83.1040104@bellsouth.net> <54C2C1FC.9030304@msapiro.net>
Message-ID: <54C2D1A8.8000002@bellsouth.net>


Hi Mark,

Thanks. Then the implication is that just changing mm_cfg.py, after list
creation is insufficient. I assume I then need to run 'withlist' and
some parameter to make it recreate those parameters for each list.

On 1/23/2015 4:49 PM, Mark Sapiro wrote:
> On 01/23/2015 01:26 PM, Dennis Putnam wrote:
>> How is listinfo_url used in templates set? I am guessing I have
>> something configured wrong somewhere because the templates where that is
>> used has just the host name not the FQDN. Thanks.
>
> Each piece of code that uses a template sets the replacement for that
> template.
>
> However, the good news is they all get it the same way, via the list
> method GetScriptURL('listinfo', absolute=1). This in turn uses the list
> attribute web_page_url which is set at list creation time from the
> Defaults.py/mm_cfg.py setting for DEFAULT_URL_PATTERN filled in with the
> list's url host.
>
> See the FAQ at <http://wiki.list.org/x/mIA9> for more and how to fix it.
>
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/dap1%40bellsouth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150123/625200fb/attachment.sig>

From mark at msapiro.net  Sat Jan 24 00:15:06 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 23 Jan 2015 15:15:06 -0800
Subject: [Mailman-Users] listinfo_url Wrong
In-Reply-To: <54C2D1A8.8000002@bellsouth.net>
References: <54C2BC83.1040104@bellsouth.net> <54C2C1FC.9030304@msapiro.net>
 <54C2D1A8.8000002@bellsouth.net>
Message-ID: <54C2D5FA.2070507@msapiro.net>

On 01/23/2015 02:56 PM, Dennis Putnam wrote:
> 
> Hi Mark,
> 
> Thanks. Then the implication is that just changing mm_cfg.py, after list
> creation is insufficient. I assume I then need to run 'withlist' and
> some parameter to make it recreate those parameters for each list.


As it says in the FAQ


>> See the FAQ at <http://wiki.list.org/x/mIA9> for more and how to fix it.


if you run bin/fix_url.py it will give you the help on the options and
then you run one of the two withlist commands shown with the appropriate
fix_url options depending on whether you want to do a single list or all
lists with the same options.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150123/bdc8d7df/attachment-0001.sig>

From dap1 at bellsouth.net  Sat Jan 24 01:04:35 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Fri, 23 Jan 2015 19:04:35 -0500
Subject: [Mailman-Users] listinfo_url Wrong
In-Reply-To: <54C2D5FA.2070507@msapiro.net>
References: <54C2BC83.1040104@bellsouth.net> <54C2C1FC.9030304@msapiro.net>
 <54C2D1A8.8000002@bellsouth.net> <54C2D5FA.2070507@msapiro.net>
Message-ID: <54C2E193.9040907@bellsouth.net>

Hi Mark,

I think my ISP munged the link in your first message as it gave me a 404
error. This one seems to work for some reason. Thanks.

On 1/23/2015 6:15 PM, Mark Sapiro wrote:
> On 01/23/2015 02:56 PM, Dennis Putnam wrote:
>> Hi Mark,
>>
>> Thanks. Then the implication is that just changing mm_cfg.py, after list
>> creation is insufficient. I assume I then need to run 'withlist' and
>> some parameter to make it recreate those parameters for each list.
>
> As it says in the FAQ
>
>
>>> See the FAQ at <http://wiki.list.org/x/mIA9> for more and how to fix it.
>
> if you run bin/fix_url.py it will give you the help on the options and
> then you run one of the two withlist commands shown with the appropriate
> fix_url options depending on whether you want to do a single list or all
> lists with the same options.
>
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/dap1%40bellsouth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150123/664c52ef/attachment.sig>

From dap1 at bellsouth.net  Sat Jan 24 12:09:34 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Sat, 24 Jan 2015 06:09:34 -0500
Subject: [Mailman-Users] listinfo_url Wrong
In-Reply-To: <54C2D5FA.2070507@msapiro.net>
References: <54C2BC83.1040104@bellsouth.net> <54C2C1FC.9030304@msapiro.net>
 <54C2D1A8.8000002@bellsouth.net> <54C2D5FA.2070507@msapiro.net>
Message-ID: <54C37D6E.5060600@bellsouth.net>

Hi Mark,

After following the instructions in the FAQ, my mailing list
disappeared. The directory seems in tact but it does not show up on the
admin page. What could I have done wrong and how do I fix it? Thanks.

On 1/23/2015 6:15 PM, Mark Sapiro wrote:
> On 01/23/2015 02:56 PM, Dennis Putnam wrote:
>> Hi Mark,
>>
>> Thanks. Then the implication is that just changing mm_cfg.py, after list
>> creation is insufficient. I assume I then need to run 'withlist' and
>> some parameter to make it recreate those parameters for each list.
> As it says in the FAQ
>
>
>>> See the FAQ at <http://wiki.list.org/x/mIA9> for more and how to fix it.
> if you run bin/fix_url.py it will give you the help on the options and
> then you run one of the two withlist commands shown with the appropriate
> fix_url options depending on whether you want to do a single list or all
> lists with the same options.
>
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/dap1%40bellsouth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150124/4ccc0319/attachment.sig>

From mark at msapiro.net  Sat Jan 24 18:28:20 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 24 Jan 2015 09:28:20 -0800
Subject: [Mailman-Users] listinfo_url Wrong
In-Reply-To: <54C37D6E.5060600@bellsouth.net>
References: <54C2BC83.1040104@bellsouth.net> <54C2C1FC.9030304@msapiro.net>
 <54C2D1A8.8000002@bellsouth.net> <54C2D5FA.2070507@msapiro.net>
 <54C37D6E.5060600@bellsouth.net>
Message-ID: <54C3D634.1090102@msapiro.net>

On 01/24/2015 03:09 AM, Dennis Putnam wrote:
> Hi Mark,
> 
> After following the instructions in the FAQ, my mailing list
> disappeared. The directory seems in tact but it does not show up on the
> admin page. What could I have done wrong and how do I fix it? Thanks.


See this FAQ <http://wiki.list.org/x/lYA9>.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150124/46b59d69/attachment.sig>

From mark at msapiro.net  Sat Jan 24 22:53:38 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 24 Jan 2015 13:53:38 -0800
Subject: [Mailman-Users] Heads up on pending Mailman 2.1.19 release
Message-ID: <54C41462.3000309@msapiro.net>

I will soon be packaging and announcing the first release candidate for
Mailman 2.1.19. The details of changes since the 2.1.18-1 release are in
the attached README.

The reason for this heads up is there are many things in this release
that have i18n impacts and I want to give as much notice as possible of
these changes so that people who are interested in updating templates
and the message catalogs for a particular language can hopefully get
their changes in in time for the final release. If you are interested in
helping with this, whether or not you are a current translator, see
<http://wiki.list.org/x/MQ>.

Many of the changes have to do with the fact that for several years, I
have been maintaining the officially defunct 2.2 branch in parallel with
2.1. This branch had a number of features and fixes that had never been
put in the 2.1 branch because of their i18n impacts. I have now decided
to backport all those changes and finally abandon the 2.2 branch. These
changes affect the message catalog and add a new adminaddrchgack.txt
template and make a minor change to the admindbdetails.html template.

I have also implemented new features that weren't in the 2.2 branch, but
add new strings to the web admin UI.

See the attached README for more on what all these changes are.

The mailman.pot message template has been updated with all these changes
and msgmerged with the various mailman.po files. All of this can be
retrieved from the bazaar branch at
<https://code.launchpad.net/~mailman-coders/mailman/2.1> at rev. 1520
(or later).

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
-------------- next part --------------
2.2 Branch Backports (released in conjunction with 2.1.19)

  The following New Features and Bug Fixes have been in an "unofficial,
  never to be released" Mailman 2.2 branch for several years. Until now,
  they were never implemented on the official 2.1 branch because of their
  i18n impacts.  Given that there have been a number of i18n impacting
  changes due to DMARC mitigations in the last few releases, it has been
  decided to backport these as well.

  All of these changes have been running in production on several lists
  for years without problems other than untranslated strings, so they should
  be reasonably "bug free".

  New Features

    - There is a new list attribute 'subscribe_auto_approval' which is a list
      of email addresses and regular expressions matching email addresses
      whose subscriptions are exempt from admin approval.  (LP: #266609)

    - Confirmed member change of address is logged in the 'subscribe' log,
      and if admin_notify_mchanges is true, a notice is sent to the list
      owner using a new adminaddrchgack.txt template.

    - Added an 'automate' option to bin/newlist to send the notice to the
      admin without the prompt.

    - The processing of Topics regular expressions has changed. Previously the
      Topics regexp was compiled in verbose mode but not documented as such
      which caused some confusion.  Also, the documentation indicated that
      topic keywords could be entered one per line, but these entries were not
      handled properly.  Topics regexps are now compiled in non-verbose mode
      and multi-line entries are 'ored'.  Existing Topics regexps will be
      converted when the list is updated so they will continue to work.

    - Added real name display to the web roster.  (LP: #266754)


  Bug fixes and other patches

    - Changed the response to an invalid confirmation to be more generic.
      Not all confirmations are subscription requests.

    - Changed the default nonmember_rejection_notice to be more user friendly.
      (LP: #418728)

    - Added "If you are a list member" qualification to some messages from the
      options login page.  (LP: #266442)

    - Changed the 'Approve' wording in the admindbdetails.html template to
      'Accept/Approve' for better agreement with the button labels.

    - Added '(by thread)' to the previous and next message links in the
      archive to emphasize that even if you got to the message from a
      subject, date or author index, previous and next are still by thread.

2.1.19 (xx-xxx-xxxx)

  New Features

    - There is a new list attribute dmarc_wrapped_message_text and a
      DEFAULT_DMARC_WRAPPED_MESSAGE_TEXT setting to set the default for new
      lists.  This text is added to a message which is wrapped because of
      dmarc_moderation_action in a separate text/plain part that precedes the
      message/rfc822 part containing the original message.  It can be used to
      provide an explanation of why the message was wrapped or similar info.

    - There is a new list attribute equivalent_domains and a
      DEFAULT_EQUIVALENT_DOMAINS setting to set the default for new lists which
      in turn defaults to the empty string.  This provides a way to specify one
      or more groups of domains, e.g., mac.com, me.com, icloud.com, which are
      considered equivalent for validating list membership for posting and
      moderation purposes.

    - There is a new WEB_HEAD_ADD setting to specify text to be added to the
      <HEAD> section of Mailman's internally generated web pages.  This doesn't
      apply to pages built from templates, but in those cases, custom templates
      can be created.  (LP: #1409396)

    - There is a new DEFAULT_SUBSCRIBE_OR_INVITE setting.  Set this to Yes
      to make the default selection on the admin Mass Subscriptions page
      Invite rather than Subscribe.  (LP: #1404511)

    - There is a new list attribute in the Bounce processing section.
      bounce_notify_owner_on_bounce_increment if set to Yes will cause
      Mailman to notify the list owner on every bounce that increments a
      list member's score but doesn't result in a probe or disable.  There
      is a new configuration setting setting
      DEFAULT_BOUNCE_NOTIFY_OWNER_ON_BOUNCE_INCREMENT to set the default
      for new lists.  This in turn defaults to No.  (LP: #1382150)

  Changed behavior

    - Mailman's log files, request.pck files and heldmsg-* files are no
      longer created world readable to protect against access by untrusted
      local users.  Note that permissions on existing log files won't be
      changed so if you are concerned about this and don't rotate logs or
      have a logrotate process that creates new log files instead of letting
      Mailman create them, you will need to address that.  (LP: #1327404)

  Other changes

    - The Python Powered logo image has been replaced in the misc/ directory
      in the source distribution.  Depending on how you've installed these
      images, you may need to copy PythonPowered.png from the misc/ directory
      in the source or from the $prefix/icons/ installed directory to another
      location for your web server.  (LP: #1408575)

  i18n

    - The Russian templates have been updated by Danil Smirnov.  (LP: #1403462)

    - The Japanese translation has been updated by SATOH Fumiyasu.
      (LP: #1402989)

    - A minor change in the French translation of a listinfo subscribe form
      message has been made.  (LP: #1331194)

  Bug fixes and other patches

    - When applying DMARC mitigations, CookHeaders now adds the original From:
      to Cc: rather than Reply-To: in some cases to make MUA 'reply' and
      'reply all' more consistent with the non-DMARC cases.  (LP: #1407098)

    - The Subject: of the list welcome message wasn't always in the user's
      preferred language.  Fixed.  (LP: #1400988)

    - Accept email command in Subject: prefixed with Re: or similar with no
      intervening space.  (LP: #1400200)

    - Fixed a UnicodeDecodeError that could occur in the web admin interface
      if 'text' valued attributes have unicode values.  (LP: #1397170)

    - We now catch the NotAMemberError exception thrown if an authenticated
      unsubscribe is submitted from the user options page for a nonmember.
      (LP: #1390653)

    - Fixed an archiving bug that would cause messages with 'Subject: Re:'
      only to be indexed in the archives without a link to the message.
      (LP: #1388614)

    - The vette log entry for a message discarded by a handler now includes
      the list name and the name of the handler.  (LP: #558096)

    - The options CGI now rejects all but HTTP GET and POST requests.
      (LP: #1372199)

    - A list's poster password will now be accepted on an Urgent: header.
      (LP: #1371678)

    - Fixed a bug which caused a setting of 2 for REMOVE_DKIM_HEADERS to be
      ignored.  (LP: #1363278)

    - Renamed messages/sr/readme.sr to README.sr.  (LP: #1360616)

    - Moved the dmarc_moderation_action checks from the Moderate handler to
      the SpamDetect handler so that the Reject and Discard actions will be
      done before the message might be held by header_filter_rules, and the
      Wrap Message and Munge From actions will be done on messages held by
      header_filter_rules if the message is approved.  (LP: #1334450)

    - <label> tags have been added around most check boxes and radio buttons
      and their text labels in the admin and admindb web GUI so they can be
      (de)selected by clicking the text.  (LP: #266391)

    - If checking DNS for dmarc_moderation_action and DNS lookup is not
      available, log it.  (LP: #1324541)
 
    - Handle missing From: header addresses for DMARC mitigation actions.
      (LP: #1318025)


From dap1 at bellsouth.net  Sun Jan 25 01:16:22 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Sat, 24 Jan 2015 19:16:22 -0500
Subject: [Mailman-Users] Help Request Returning Nothing
Message-ID: <54C435D6.2000304@bellsouth.net>

I've recently muddled through a migration to a new server and struggled
with setting up a custom URL for templates. However, in trying to set up
the URL on a previously working "help.txt", I've apparently fouled
something up. I now get the correct URL but little else. A help request
is returning the following:

----------------------------------------------------------------------------------------------------------------------------------------------------

The results of your email command are provided below. Attached is your
original message.

- Results:
    Ignoring non-text/plain MIME parts
    You can access your personal options via the following url:
    https://myhost.mydomain.com/mailman/options/cufsalumni/dap1%40bellsouth.net
    
    help
    Help
---------------------------------------------------------------------------------------------------

In addition there is an attachment that is simply my original help request email. Can someone explain what is doing on? TIA.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150124/6b94a7fd/attachment.sig>

From dap1 at bellsouth.net  Sun Jan 25 02:17:30 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Sat, 24 Jan 2015 20:17:30 -0500
Subject: [Mailman-Users] Anther Permissions Problem
Message-ID: <54C4442A.2070607@bellsouth.net>

I've found yet another problem after my migration. When I try to access
the archives, I get this:


  Forbidden

You don't have permission to access /pipermail/cufsalumni/ on this server.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150124/643d92ae/attachment.sig>

From mark at msapiro.net  Sun Jan 25 02:24:27 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 24 Jan 2015 17:24:27 -0800
Subject: [Mailman-Users] Help Request Returning Nothing
In-Reply-To: <54C435D6.2000304@bellsouth.net>
References: <54C435D6.2000304@bellsouth.net>
Message-ID: <54C445CB.7070109@msapiro.net>

On 01/24/2015 04:16 PM, Dennis Putnam wrote:
> I've recently muddled through a migration to a new server and struggled
> with setting up a custom URL for templates. However, in trying to set up
> the URL on a previously working "help.txt", I've apparently fouled
> something up. I now get the correct URL but little else. A help request
> is returning the following:
> 
> ----------------------------------------------------------------------------------------------------------------------------------------------------
> 
> The results of your email command are provided below. Attached is your
> original message.
> 
> - Results:
>     Ignoring non-text/plain MIME parts

This means your original message had more than just a single text/plain
part, probably it was multipart/alternative with both text/plain and
text/html alternatives. This should be OK.

>     You can access your personal options via the following url:
>     https://myhost.mydomain.com/mailman/options/cufsalumni/dap1%40bellsouth.net


This is generated by the 'help' command processor, so you got that far.


>     help
>     Help


And this seems to indicate either Mailman/Commands/cmd_help.py or your
help.txt template is corrupted.

Look for a file named help.txt in the following places if they exist:

1) lists/LISTNAME/en/ where LISTNAME is the name of the list you sent
the request to
2) templates/DOMAIN/en/ where DOMAIN is the domain of the list
3) templates/site/en/
4) templates/en/

The first help.txt template found is the one being used. What does it
contain?

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150124/5b2dd195/attachment.sig>

From mark at msapiro.net  Sun Jan 25 02:30:46 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 24 Jan 2015 17:30:46 -0800
Subject: [Mailman-Users] Anther Permissions Problem
In-Reply-To: <54C4442A.2070607@bellsouth.net>
References: <54C4442A.2070607@bellsouth.net>
Message-ID: <54C44746.6000209@msapiro.net>

On 01/24/2015 05:17 PM, Dennis Putnam wrote:
> I've found yet another problem after my migration. When I try to access
> the archives, I get this:
> 
> 
>   Forbidden
> 
> You don't have permission to access /pipermail/cufsalumni/ on this server.


Either the permissions on the archives/private/ directory itself must be
at least rwxrws--x or, if they are rwxrws--- the owner of the directory
must be the web server user.

See <http://www.list.org/mailman-install/node9.html>.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150124/538d8e96/attachment.sig>

From paul at nangoku-jiyu-jin.net  Sun Jan 25 04:33:41 2015
From: paul at nangoku-jiyu-jin.net (paul at nangoku-jiyu-jin.net)
Date: Sun, 25 Jan 2015 12:33:41 +0900
Subject: [Mailman-Users] Subscriber's reply to my message gets sent to the
	list: how to prevent it
References: <A798D634-5554-4130-85B2-785168C8ADCC@nangoku-jiyu-jin.net>
Message-ID: <3FF10114-09A4-4E65-AAC7-7D2F93474EF9@nangoku-jiyu-jin.net>

Hi

I have a list and recently a subscriber wrote to the list address and asked t be taken off. In face several did. So I sent an email
explaining the best way. Writing from my personal address at the same domain as the list, I said,

 "The best way to be removed from the list would be to follow the instructions at the bottom of the newsletter.  If you have trouble, please let me know and I will be glad to assist you. However, it will take several days as i am now travelling. Follow the directions at the bottom of the screen.Again, if this does not work for you, I will be glad to assist you.?

As far as I recall I cc?d myself at my mac address. She responded to the same list address saying ?thank you? and somehow THAT MESSAGE got sent out to everyone.

Not a big problem, but am trying to figure out how it happened,


Some of my settings are:  

--new members moderated

--hold when a moderated members posts

How is this possible that the subscriber?s email made it through to the list?   I want to make sure this does not happen again.


Thank you very much!



paul arenson

From mark at msapiro.net  Sun Jan 25 07:26:59 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 24 Jan 2015 22:26:59 -0800
Subject: [Mailman-Users] Subscriber's reply to my message gets sent to
 the list: how to prevent it
In-Reply-To: <3FF10114-09A4-4E65-AAC7-7D2F93474EF9@nangoku-jiyu-jin.net>
References: <A798D634-5554-4130-85B2-785168C8ADCC@nangoku-jiyu-jin.net>
 <3FF10114-09A4-4E65-AAC7-7D2F93474EF9@nangoku-jiyu-jin.net>
Message-ID: <54C48CB3.4000800@msapiro.net>

On 01/24/2015 07:33 PM, paul at nangoku-jiyu-jin.net wrote:
> 
> As far as I recall I cc?d myself at my mac address. She responded to the same list address saying ?thank you? and somehow THAT MESSAGE got sent out to everyone.
> 
> Not a big problem, but am trying to figure out how it happened,
> 
> 
> Some of my settings are:  
> 
> --new members moderated
> 
> --hold when a moderated members posts
> 
> How is this possible that the subscriber?s email made it through to the list?   I want to make sure this does not happen again.


Have you looked at her address in the web admin Membership Management...
-> Membership List to verify that her address is moderated?

If it is, is it possible that the copy you received didn't actually come
through the list?

To say any more, I'd need to see the complete raw message with all
headers that you received.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From dap1 at bellsouth.net  Sun Jan 25 16:25:17 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Sun, 25 Jan 2015 10:25:17 -0500
Subject: [Mailman-Users] Anther Permissions Problem
In-Reply-To: <54C44746.6000209@msapiro.net>
References: <54C4442A.2070607@bellsouth.net> <54C44746.6000209@msapiro.net>
Message-ID: <54C50ADD.7050406@bellsouth.net>

Hi Mark,

Thanks for the reply. From the install the group is 'mailman' and the
permissions are as you suggested.

drwxrws--x. 8 root mailman 4096 Nov 20  2012 private
drwxrwsr-x. 2 root mailman 4096 Nov 20  2012 public

For grins I change the group to 'apache' but no joy.

drwxrws--x. 8 root apache 4096 Nov 20  2012 private
drwxrwsr-x. 2 root apache 4096 Nov 20  2012 public

FYI, selinux is disabled.

On 1/24/2015 8:30 PM, Mark Sapiro wrote:
> On 01/24/2015 05:17 PM, Dennis Putnam wrote:
>> I've found yet another problem after my migration. When I try to access
>> the archives, I get this:
>>
>>
>>   Forbidden
>>
>> You don't have permission to access /pipermail/cufsalumni/ on this server.
>
> Either the permissions on the archives/private/ directory itself must be
> at least rwxrws--x or, if they are rwxrws--- the owner of the directory
> must be the web server user.
>
> See <http://www.list.org/mailman-install/node9.html>.
>
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/dap1%40bellsouth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150125/9fca3db6/attachment.sig>

From dap1 at bellsouth.net  Sun Jan 25 16:49:59 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Sun, 25 Jan 2015 10:49:59 -0500
Subject: [Mailman-Users] Help Request Returning Nothing
In-Reply-To: <54C445CB.7070109@msapiro.net>
References: <54C435D6.2000304@bellsouth.net> <54C445CB.7070109@msapiro.net>
Message-ID: <54C510A7.2040303@bellsouth.net>

On 1/24/2015 8:24 PM, Mark Sapiro wrote:
> On 01/24/2015 04:16 PM, Dennis Putnam wrote:
>> I've recently muddled through a migration to a new server and struggled
>> with setting up a custom URL for templates. However, in trying to set up
>> the URL on a previously working "help.txt", I've apparently fouled
>> something up. I now get the correct URL but little else. A help request
>> is returning the following:
>>
>> ----------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> The results of your email command are provided below. Attached is your
>> original message.
>>
>> - Results:
>>     Ignoring non-text/plain MIME parts
> This means your original message had more than just a single text/plain
> part, probably it was multipart/alternative with both text/plain and
> text/html alternatives. This should be OK.
>
>>     You can access your personal options via the following url:
>>     https://myhost.mydomain.com/mailman/options/cufsalumni/dap1%40bellsouth.net
>
> This is generated by the 'help' command processor, so you got that far.
>
>
>>     help
>>     Help
>
> And this seems to indicate either Mailman/Commands/cmd_help.py or your
> help.txt template is corrupted.
>
> Look for a file named help.txt in the following places if they exist:
This is a bit convoluted. I don't know if this is unique to the CentOS 7
implementation or standard but everything is spread out now even more. I
found that /usr/lib/mailman/templates no longer exists. That directory
contains just a README that says the location was changed to
/etc/mailman/templates. In addition, I see there is also an mm_cfg.py in
/etc/mailman which is a sym link to /var/lib/mailman/Mailman/mm_cfg.py.
Nothing like consistency. Why wasn't the templates directory also a
symlink? Sheesh!
>
> 1) lists/LISTNAME/en/ where LISTNAME is the name of the list you sent
> the request to
 This is the one it should be using and looks correct
(/var/lib/mailman/lists/LISTNAME/en/help.txt).
> 2) templates/DOMAIN/en/ where DOMAIN is the domain of the list
Does not exist.
> 3) templates/site/en/
Does not exist.
> 4) templates/en/
The file /etc/mailman/templates/en/help.txt appears to be correct.
>
> The first help.txt template found is the one being used. What does it
> contain?
>
>
(sanitized)
-----------------------------------------------------------------------------------------------------------------
Help for %(listname)s mailing list:

This is email command help for version %(version)s of the "Mailman"
list manager.  The following describes commands you can send to get
information about and control your subscription to Mailman lists at
this site.  A command can be in the subject line or in the body of the
message.

Note that much of the following can also be accomplished via the World
Wide Web, at:

    %(listinfo_url)s

In particular, you can use the Web site to have your password sent to
your delivery address.

List specific commands (subscribe, who, etc) should be sent to the
*-request address for the particular list, e.g. for the 'mailman'
list, use 'mailman-request at ...'.

About the descriptions - words in "<>"s signify REQUIRED items and
words in "[]" denote OPTIONAL items.  Do not include the "<>"s or
"[]"s when you use the commands.

The following commands are valid:

    %(commands)s

Commands should be sent to LISTNAME.request at somemailserver.com

Questions and concerns for the attention of a person should be sent to

    LISTNAME.owner at somemailserver.com
-------------------------------------------------------------------------------------------------------------------------------------

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150125/49b21907/attachment.sig>

From jebva at yahoo.com  Sun Jan 25 22:05:34 2015
From: jebva at yahoo.com (JB)
Date: Sun, 25 Jan 2015 13:05:34 -0800
Subject: [Mailman-Users] Mobing A List To A Ne Server Under The Same Doamin
	Name
Message-ID: <1422219934.95707.YahooMailBasic@web122501.mail.ne1.yahoo.com>

I am having to manually migrate some domains/web site from one server to another, both in a cPanel environment.  The resident backup restore functionality cannot be used for these domains.  Can I move the associated mailman lists by simply copying over the /usr/local/cpanel/3rdparty/mailman/lists files and ensuring that the permissions and ownership are set correctly?

From billc_lists at greenbuilder.com  Mon Jan 26 00:45:31 2015
From: billc_lists at greenbuilder.com (Bill Christensen)
Date: Sun, 25 Jan 2015 17:45:31 -0600
Subject: [Mailman-Users] Archiving problems
Message-ID: <54C5801B.9090704@greenbuilder.com>

Hi folks,

I recently discovered that all my lists stopped archiving back in 
October.  I have no clear idea as to what caused that, but I suspect 
that it may have occurred as part of some hardware and software upgrades 
I did around that time.

I'm still stuck back at Mailman 2.1.13 because the port system I use 
hasn't updated in ages and I haven't had time to tackle it myself.

I was able to bring most of the archives up to date manually, but one 
fairly active one with public archives is still only showing through 
October 2014.   When I run that manually it shows that it's processing 
posts beyond the last one seen in the web-visible archives and updates 
the index for 1st quarter 2015, but still no visibility and the files in 
archive/public aren't updated.  The files in archive/private *are* 
updated...

How do I make the public archives reflect what's in private?

Thanks.

From mark at msapiro.net  Mon Jan 26 01:11:41 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Jan 2015 16:11:41 -0800
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C5801B.9090704@greenbuilder.com>
References: <54C5801B.9090704@greenbuilder.com>
Message-ID: <54C5863D.5030303@msapiro.net>

On 01/25/2015 03:45 PM, Bill Christensen wrote:
> 
> I was able to bring most of the archives up to date manually, but one
> fairly active one with public archives is still only showing through
> October 2014.   When I run that manually it shows that it's processing
> posts beyond the last one seen in the web-visible archives and updates
> the index for 1st quarter 2015, but still no visibility and the files in
> archive/public aren't updated.  The files in archive/private *are*
> updated...
> 
> How do I make the public archives reflect what's in private?


At some point you moved or copied the archives and instead of copying
the symlinks in archives/public as symlinks, you copied the target data
which is never updated.

The ONLY thing that ever should be in archives/public/ is symlinks to
the corresponding items in archives/private/.

The solution is simple:

rm -r archives/private/*

Mailman will automatically recreate the necessary archives/public/
symlinks for each publicly archived list the next time it does anything
to the list.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Mon Jan 26 01:18:00 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Jan 2015 16:18:00 -0800
Subject: [Mailman-Users] Mobing A List To A Ne Server Under The Same
 Doamin Name
In-Reply-To: <1422219934.95707.YahooMailBasic@web122501.mail.ne1.yahoo.com>
References: <1422219934.95707.YahooMailBasic@web122501.mail.ne1.yahoo.com>
Message-ID: <54C587B8.3070407@msapiro.net>

On 01/25/2015 01:05 PM, JB wrote:
> I am having to manually migrate some domains/web site from one server to another, both in a cPanel environment.  The resident backup restore functionality cannot be used for these domains.  Can I move the associated mailman lists by simply copying over the /usr/local/cpanel/3rdparty/mailman/lists files and ensuring that the permissions and ownership are set correctly?

You probably also want to copy
/usr/local/cpanel/3rdparty/mailman/archives/private and, if there are
any held messages you want to keep,
/usr/local/cpanel/3rdparty/mailman/data/heldmsg*.

It is not necessary to copy
/usr/local/cpanel/3rdparty/mailman/archives/public, and if you do, be
sure to copy symlinks as symlinks, not the targets. See the post at
<https://mail.python.org/pipermail/mailman-users/2015-January/078341.html>
and the reply at
<https://mail.python.org/pipermail/mailman-users/2015-January/078342.html>.

Also, see the FAQ at <http://wiki.list.org/x/2oA9> and the first couple
of posts linked therefrom.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Mon Jan 26 01:26:21 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Jan 2015 16:26:21 -0800
Subject: [Mailman-Users] Anther Permissions Problem
In-Reply-To: <54C50ADD.7050406@bellsouth.net>
References: <54C4442A.2070607@bellsouth.net> <54C44746.6000209@msapiro.net>
 <54C50ADD.7050406@bellsouth.net>
Message-ID: <54C589AD.1040504@msapiro.net>

On 01/25/2015 07:25 AM, Dennis Putnam wrote:
> Hi Mark,
> 
> Thanks for the reply. From the install the group is 'mailman' and the
> permissions are as you suggested.
> 
> drwxrws--x. 8 root mailman 4096 Nov 20  2012 private
> drwxrwsr-x. 2 root mailman 4096 Nov 20  2012 public
> 
> For grins I change the group to 'apache' but no joy.
> 
> drwxrws--x. 8 root apache 4096 Nov 20  2012 private
> drwxrwsr-x. 2 root apache 4096 Nov 20  2012 public


This is VERY BAD. The group MUST be mailman. If anything change the
owner only on archives/private, but this is unnecessary with o+x on the
directory which you have.


> FYI, selinux is disabled.


OK.

What's in the apache error_log for these accesses? If the error is
permissions, check that each directory in the path
mailman/archives/private/LISTNAME/* is o+rx except for 'private' itself
which only needs to be o+x.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150125/035f2df1/attachment.sig>

From mark at msapiro.net  Mon Jan 26 01:39:41 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Jan 2015 16:39:41 -0800
Subject: [Mailman-Users] Help Request Returning Nothing
In-Reply-To: <54C510A7.2040303@bellsouth.net>
References: <54C435D6.2000304@bellsouth.net> <54C445CB.7070109@msapiro.net>
 <54C510A7.2040303@bellsouth.net>
Message-ID: <54C58CCD.7090703@msapiro.net>

On 01/25/2015 07:49 AM, Dennis Putnam wrote:
> This is a bit convoluted. I don't know if this is unique to the CentOS 7
> implementation or standard but everything is spread out now even more. I
> found that /usr/lib/mailman/templates no longer exists. That directory
> contains just a README that says the location was changed to
> /etc/mailman/templates. In addition, I see there is also an mm_cfg.py in
> /etc/mailman which is a sym link to /var/lib/mailman/Mailman/mm_cfg.py.
> Nothing like consistency. Why wasn't the templates directory also a
> symlink? Sheesh!



See the FAQ at <http://wiki.list.org/x/KYCB> (these RHEL/CentOS changes
are now over 10 years old).



> The file /etc/mailman/templates/en/help.txt appears to be correct.
>>
>> The first help.txt template found is the one being used. What does it
>> contain?


The file below looks OK, but you should never change a template in
templates/en/. If you want to make a sitewide change, you should put the
edited template in templates/site/en/. If you want to make a list
specific change, you should put the edited template in lists/LISTNAME/en/

See the FAQ at <http://wiki.list.org/x/jYA9>.

Given that the template seems OK, there may be something wrong with the
Mailman/Commands/cmd_help.py module itself. Has this been edited? Is
there anything in Mailman's error log relating to these help commands?


> (sanitized)
> -----------------------------------------------------------------------------------------------------------------
> Help for %(listname)s mailing list:
> 
> This is email command help for version %(version)s of the "Mailman"
> list manager.  The following describes commands you can send to get
> information about and control your subscription to Mailman lists at
> this site.  A command can be in the subject line or in the body of the
> message.
> 
> Note that much of the following can also be accomplished via the World
> Wide Web, at:
> 
>     %(listinfo_url)s
> 
> In particular, you can use the Web site to have your password sent to
> your delivery address.
> 
> List specific commands (subscribe, who, etc) should be sent to the
> *-request address for the particular list, e.g. for the 'mailman'
> list, use 'mailman-request at ...'.
> 
> About the descriptions - words in "<>"s signify REQUIRED items and
> words in "[]" denote OPTIONAL items.  Do not include the "<>"s or
> "[]"s when you use the commands.
> 
> The following commands are valid:
> 
>     %(commands)s
> 
> Commands should be sent to LISTNAME.request at somemailserver.com
> 
> Questions and concerns for the attention of a person should be sent to
> 
>     LISTNAME.owner at somemailserver.com
> -------------------------------------------------------------------------------------------------------------------------------------

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150125/af10a118/attachment.sig>

From mark at msapiro.net  Mon Jan 26 01:50:48 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Jan 2015 16:50:48 -0800
Subject: [Mailman-Users] Anther Permissions Problem
In-Reply-To: <54C589AD.1040504@msapiro.net>
References: <54C4442A.2070607@bellsouth.net> <54C44746.6000209@msapiro.net>
 <54C50ADD.7050406@bellsouth.net> <54C589AD.1040504@msapiro.net>
Message-ID: <54C58F68.2090106@msapiro.net>

On 01/25/2015 04:26 PM, Mark Sapiro wrote:
> 
> What's in the apache error_log for these accesses? If the error is
> permissions, check that each directory in the path
> mailman/archives/private/LISTNAME/* is o+rx except for 'private' itself
> which only needs to be o+x.


I meant to add if the apache error is 'server configuration', see
<http://www.list.org/mailman-install/node10.html>.

You probably need

Require all granted

instead of

Order allow,deny
Allow from all

in the directory block for archives/public.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150125/741f8f61/attachment.sig>

From dap1 at bellsouth.net  Mon Jan 26 02:17:18 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Sun, 25 Jan 2015 20:17:18 -0500
Subject: [Mailman-Users] Help Request Returning Nothing
In-Reply-To: <54C58CCD.7090703@msapiro.net>
References: <54C435D6.2000304@bellsouth.net> <54C445CB.7070109@msapiro.net>
 <54C510A7.2040303@bellsouth.net> <54C58CCD.7090703@msapiro.net>
Message-ID: <54C5959E.4020003@bellsouth.net>

On 1/25/2015 7:39 PM, Mark Sapiro wrote:
> On 01/25/2015 07:49 AM, Dennis Putnam wrote:
>> This is a bit convoluted. I don't know if this is unique to the CentOS 7
>> implementation or standard but everything is spread out now even more. I
>> found that /usr/lib/mailman/templates no longer exists. That directory
>> contains just a README that says the location was changed to
>> /etc/mailman/templates. In addition, I see there is also an mm_cfg.py in
>> /etc/mailman which is a sym link to /var/lib/mailman/Mailman/mm_cfg.py.
>> Nothing like consistency. Why wasn't the templates directory also a
>> symlink? Sheesh!
>
>
> See the FAQ at <http://wiki.list.org/x/KYCB> (these RHEL/CentOS changes
> are now over 10 years old).
Not to be contrary but that was not the case with CentOS 6.  This change
was introduced by CentOS 7 regardless of what that wiki page says.
CentOS 7 is less than a year old.

>
>
>
>> The file /etc/mailman/templates/en/help.txt appears to be correct.
>>> The first help.txt template found is the one being used. What does it
>>> contain?
>
> The file below looks OK, but you should never change a template in
> templates/en/. If you want to make a sitewide change, you should put the
> edited template in templates/site/en/. If you want to make a list
> specific change, you should put the edited template in lists/LISTNAME/en/
Although edited out of this reply, my reply for the first location in
the search order was correct and that is what was posted below.
>
> See the FAQ at <http://wiki.list.org/x/jYA9>.
>
> Given that the template seems OK, there may be something wrong with the
> Mailman/Commands/cmd_help.py module itself. Has this been edited?
Not intentionally.
>  Is
> there anything in Mailman's error log relating to these help commands?
No, that would be too easy. :-)
>
>
>> (sanitized)
>> -----------------------------------------------------------------------------------------------------------------
>> Help for %(listname)s mailing list:
>>
>> This is email command help for version %(version)s of the "Mailman"
>> list manager.  The following describes commands you can send to get
>> information about and control your subscription to Mailman lists at
>> this site.  A command can be in the subject line or in the body of the
>> message.
>>
>> Note that much of the following can also be accomplished via the World
>> Wide Web, at:
>>
>>     %(listinfo_url)s
>>
>> In particular, you can use the Web site to have your password sent to
>> your delivery address.
>>
>> List specific commands (subscribe, who, etc) should be sent to the
>> *-request address for the particular list, e.g. for the 'mailman'
>> list, use 'mailman-request at ...'.
>>
>> About the descriptions - words in "<>"s signify REQUIRED items and
>> words in "[]" denote OPTIONAL items.  Do not include the "<>"s or
>> "[]"s when you use the commands.
>>
>> The following commands are valid:
>>
>>     %(commands)s
>>
>> Commands should be sent to LISTNAME.request at somemailserver.com
>>
>> Questions and concerns for the attention of a person should be sent to
>>
>>     LISTNAME.owner at somemailserver.com
>> -------------------------------------------------------------------------------------------------------------------------------------
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/dap1%40bellsouth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150125/87d6cdbd/attachment-0001.sig>

From stephen at xemacs.org  Mon Jan 26 02:21:31 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 26 Jan 2015 10:21:31 +0900
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C5863D.5030303@msapiro.net>
References: <54C5801B.9090704@greenbuilder.com> <54C5863D.5030303@msapiro.net>
Message-ID: <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp>

Mark Sapiro writes:

 > The solution is simple:
 > 
 > rm -r archives/private/*

You mean "rm -r archives/public/*", don't you?  As given it erases all
the data, no?




From dap1 at bellsouth.net  Mon Jan 26 02:24:07 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Sun, 25 Jan 2015 20:24:07 -0500
Subject: [Mailman-Users] Anther Permissions Problem
In-Reply-To: <54C58F68.2090106@msapiro.net>
References: <54C4442A.2070607@bellsouth.net> <54C44746.6000209@msapiro.net>
 <54C50ADD.7050406@bellsouth.net> <54C589AD.1040504@msapiro.net>
 <54C58F68.2090106@msapiro.net>
Message-ID: <54C59737.5@bellsouth.net>

On 1/25/2015 7:50 PM, Mark Sapiro wrote:
> On 01/25/2015 04:26 PM, Mark Sapiro wrote:
>> What's in the apache error_log for these accesses? If the error is
>> permissions, check that each directory in the path
>> mailman/archives/private/LISTNAME/* is o+rx except for 'private' itself
>> which only needs to be o+x.
>
> I meant to add if the apache error is 'server configuration', see
> <http://www.list.org/mailman-install/node10.html>.
>
> You probably need
>
> Require all granted
>
> instead of
>
> Order allow,deny
> Allow from all
>
> in the directory block for archives/public.
>
>
Yep, that was it. Another error in the distribution package. I should
have noticed that when you had me add the missing directive for cgi-bin.
Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150125/63b96c42/attachment.sig>

From mark at msapiro.net  Mon Jan 26 02:27:15 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Jan 2015 17:27:15 -0800
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <54C5801B.9090704@greenbuilder.com>	<54C5863D.5030303@msapiro.net>
 <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <54C597F3.1010108@msapiro.net>

On 01/25/2015 05:21 PM, Stephen J. Turnbull wrote:
> Mark Sapiro writes:
> 
>  > The solution is simple:
>  > 
>  > rm -r archives/private/*
> 
> You mean "rm -r archives/public/*", don't you?  As given it erases all
> the data, no?


Oh My yes! Absolutely! I hope nobody does the former. Thanks for
catching this Steve.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Mon Jan 26 02:50:27 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 25 Jan 2015 17:50:27 -0800
Subject: [Mailman-Users] Help Request Returning Nothing
In-Reply-To: <54C5959E.4020003@bellsouth.net>
References: <54C435D6.2000304@bellsouth.net> <54C445CB.7070109@msapiro.net>
 <54C510A7.2040303@bellsouth.net> <54C58CCD.7090703@msapiro.net>
 <54C5959E.4020003@bellsouth.net>
Message-ID: <54C59D63.5020501@msapiro.net>

On 01/25/2015 05:17 PM, Dennis Putnam wrote:
> On 1/25/2015 7:39 PM, Mark Sapiro wrote:
>>
>> See the FAQ at <http://wiki.list.org/x/KYCB> (these RHEL/CentOS changes
>> are now over 10 years old).
> Not to be contrary but that was not the case with CentOS 6.  This change
> was introduced by CentOS 7 regardless of what that wiki page says.
> CentOS 7 is less than a year old.


The change was introduced by Red Hat in RHEL 2.1.5-21. The original
author of that FAQ article was John Dennis of Red Hat.

I don't know about CentOS as even though my production server runs
CentOS 5 (hey, it hasn't even been rebooted in over 5 years), I've never
installed or even seen the CentOS Mailman package.

Are you sure you had the CentOS package and not a source or other
install under CentOS 6?

Anyway, this is all a diversion from your actual issue.

If you send me, off list, forwarded as attachment, the help response you
receive from Mailman, I'll see if I can find anything further from that.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150125/fea8e203/attachment.sig>

From barry at list.org  Mon Jan 26 16:10:44 2015
From: barry at list.org (Barry Warsaw)
Date: Mon, 26 Jan 2015 10:10:44 -0500
Subject: [Mailman-Users] Announcing the new wiki.list.org
Message-ID: <20150126101044.50b137fe@limelight.wooz.org>

I am very happy to announce our new wiki!

If you go to wiki.list.org you will see our shiny new Moin-based wiki.  We are
retiring the old Confluence-based wiki at the end of February.  Until then,
you can access it at old-wiki.list.org.

Our very huge thanks go to Paul Boddie who did the amazing conversion work,
almost single-handedly reverse engineering the Confluence dump through several
iterations.  Of course, our thanks also go to John Viega, owner of the
list.org domain and Mailman's inventor for helping us get the DNS flipped
over.  Thanks too to everyone who gave feedback on the new wiki, contributed
to the old wiki, and continue to help edit this important resource for the
Mailman community.

Our thanks also go to the Python Software Foundation and the PSF
infrastructure team for providing us with the virtual machine hosting our
new wiki.

If you had write access to the old wiki and want it again for the new wiki,
you will have to re-submit a request to mailman-cabal at python.org.  Please be
sure to register with wiki.list.org and provide us with your user name.

With this conversion, I am happy to say that GNU Mailman is finally fully
hosted on free software.  While we appreciate the years of service donated to
us by Atlassian and Contegix, it's important that we set an example by
utilizing an entirely free software stack for our development and outreach.
The wiki was our last remaining non-free bits.

Let the gardening begin!

Cheers,
-Barry
(On behalf of the GNU Mailman steering committee)

P.S. We are working on the SSL certificate for the new wiki.  Stay tuned.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150126/b4da1a8e/attachment.sig>

From dap1 at bellsouth.net  Mon Jan 26 17:11:06 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Mon, 26 Jan 2015 11:11:06 -0500
Subject: [Mailman-Users] Help Request Returning Nothing
In-Reply-To: <54C59D63.5020501@msapiro.net>
References: <54C435D6.2000304@bellsouth.net> <54C445CB.7070109@msapiro.net>
 <54C510A7.2040303@bellsouth.net> <54C58CCD.7090703@msapiro.net>
 <54C5959E.4020003@bellsouth.net> <54C59D63.5020501@msapiro.net>
Message-ID: <54C6671A.2060200@bellsouth.net>

On 1/25/2015 8:50 PM, Mark Sapiro wrote:
> On 01/25/2015 05:17 PM, Dennis Putnam wrote:
>> On 1/25/2015 7:39 PM, Mark Sapiro wrote:
>>> See the FAQ at <http://wiki.list.org/x/KYCB> (these RHEL/CentOS changes
>>> are now over 10 years old).
>> Not to be contrary but that was not the case with CentOS 6.  This change
>> was introduced by CentOS 7 regardless of what that wiki page says.
>> CentOS 7 is less than a year old.
>
> The change was introduced by Red Hat in RHEL 2.1.5-21. The original
> author of that FAQ article was John Dennis of Red Hat.
>
> I don't know about CentOS as even though my production server runs
> CentOS 5 (hey, it hasn't even been rebooted in over 5 years), I've never
> installed or even seen the CentOS Mailman package.
>
> Are you sure you had the CentOS package and not a source or other
> install under CentOS 6?
>
> Anyway, this is all a diversion from your actual issue.
>
> If you send me, off list, forwarded as attachment, the help response you
> receive from Mailman, I'll see if I can find anything further from that.
>
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/dap1%40bellsouth.net
Hi Mark,

I am sending it separately now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150126/72f5ef9a/attachment.sig>

From barry at python.org  Mon Jan 26 17:36:13 2015
From: barry at python.org (Barry Warsaw)
Date: Mon, 26 Jan 2015 11:36:13 -0500
Subject: [Mailman-Users] [Mailman-Announce] Announcing the new
	wiki.list.org
In-Reply-To: <20150126101044.50b137fe@limelight.wooz.org>
References: <20150126101044.50b137fe@limelight.wooz.org>
Message-ID: <20150126113613.21fdf6bc@anarchist.wooz.org>

On Jan 26, 2015, at 10:10 AM, Barry Warsaw wrote:

>If you had write access to the old wiki and want it again for the new wiki,
>you will have to re-submit a request to mailman-cabal at python.org.  Please be
>sure to register with wiki.list.org and provide us with your user name.

Paul reminds me that we did copy over the user accounts from the old wiki, but
obviously not the passwords.  You should be able to do a password reset on the
new wiki to recover your account.  Do let us know if you have any problems
with this.

Sumana and I also talked about theming recently.  Both the web site and wiki
could use an update (and I have thoughts about that) but in the meantime it
would be nice if the wiki were themed closer to the website.  If you have an
interest in this, please contact mailman-developers at python.org.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150126/4142209c/attachment.sig>

From billc_lists at greenbuilder.com  Tue Jan 27 03:00:56 2015
From: billc_lists at greenbuilder.com (Bill Christensen)
Date: Mon, 26 Jan 2015 20:00:56 -0600
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C597F3.1010108@msapiro.net>
References: <54C5801B.9090704@greenbuilder.com>	<54C5863D.5030303@msapiro.net>
 <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp> <54C597F3.1010108@msapiro.net>
Message-ID: <54C6F158.1000306@greenbuilder.com>

On 1/25/15 7:27 PM, Mark Sapiro wrote:
> On 01/25/2015 05:21 PM, Stephen J. Turnbull wrote:
>> Mark Sapiro writes:
>>
>>   > The solution is simple:
>>   >
>>   > rm -r archives/private/*
>>
>> You mean "rm -r archives/public/*", don't you?  As given it erases all
>> the data, no?
>
> Oh My yes! Absolutely! I hope nobody does the former. Thanks for
> catching this Steve.
>
Ok, I removed the public archives.  I didn't rm -r, just copied them 
elsewhere in case this didn't work.

Our digest goes out at noon (and did).  I assume that qualifies as "the 
next time it does anything to the list".   Four new messages went 
through the list since then as well.

The public archive folder didn't rebuild.

Tail on the error log says:

  mlist.Save()

   File "/opt/local/share/mailman/Mailman/MailList.py", line 574, in Save

     self.CheckHTMLArchiveDir()

   File "/opt/local/share/mailman/Mailman/Archiver/Archiver.py", line 
241, in CheckHTMLArchiveDir

     makelink(privdir, pubdir)

   File "/opt/local/share/mailman/Mailman/Archiver/Archiver.py", line 
49, in makelink

     os.symlink(old, new)

OSError: [Errno 2] No such file or directory


Your thoughts?  FYI, this is on Mac 10.9.5, non-server version, if that 
makes any difference.




From mark at msapiro.net  Tue Jan 27 03:08:04 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 26 Jan 2015 18:08:04 -0800
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C6F158.1000306@greenbuilder.com>
References: <54C5801B.9090704@greenbuilder.com>	<54C5863D.5030303@msapiro.net>
 <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp> <54C597F3.1010108@msapiro.net>
 <54C6F158.1000306@greenbuilder.com>
Message-ID: <54C6F304.7050802@msapiro.net>

On 01/26/2015 06:00 PM, Bill Christensen wrote:

> Ok, I removed the public archives.  I didn't rm -r, just copied them
> elsewhere in case this didn't work.
...

> The public archive folder didn't rebuild.
> 
> Tail on the error log says:
> 
>  mlist.Save()
> 
>   File "/opt/local/share/mailman/Mailman/MailList.py", line 574, in Save
> 
>     self.CheckHTMLArchiveDir()
> 
>   File "/opt/local/share/mailman/Mailman/Archiver/Archiver.py", line
> 241, in CheckHTMLArchiveDir
> 
>     makelink(privdir, pubdir)
> 
>   File "/opt/local/share/mailman/Mailman/Archiver/Archiver.py", line 49,
> in makelink
> 
>     os.symlink(old, new)
> 
> OSError: [Errno 2] No such file or directory
> 
> 
> Your thoughts?  FYI, this is on Mac 10.9.5, non-server version, if that
> makes any difference.


You weren't supposed to remove/move archives/private, just the
subordinate listname directories.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Tue Jan 27 04:32:29 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 26 Jan 2015 19:32:29 -0800
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C6F304.7050802@msapiro.net>
References: <54C5801B.9090704@greenbuilder.com>	<54C5863D.5030303@msapiro.net>
 <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp> <54C597F3.1010108@msapiro.net>
 <54C6F158.1000306@greenbuilder.com> <54C6F304.7050802@msapiro.net>
Message-ID: <54C706CD.2030208@msapiro.net>

On 01/26/2015 06:08 PM, Mark Sapiro wrote:
> 
> You weren't supposed to remove/move archives/private, just the
> subordinate listname directories.


And once again, I misspoke (mistyped). I again meant the subordinate
listname directories under archives/public, not archives/private.

Mailman expects archives/public to exist, but the subordinates which are
supposed to be symlinks into archives/private are checked and
added/removed if necessary each time the list object is saved because
the list's archive_private setting might have changed necessitating the
addition or removal of symlinks.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From billc_lists at greenbuilder.com  Tue Jan 27 06:12:08 2015
From: billc_lists at greenbuilder.com (Bill Christensen)
Date: Mon, 26 Jan 2015 23:12:08 -0600
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C706CD.2030208@msapiro.net>
References: <54C5801B.9090704@greenbuilder.com>	<54C5863D.5030303@msapiro.net>
 <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp> <54C597F3.1010108@msapiro.net>
 <54C6F158.1000306@greenbuilder.com> <54C6F304.7050802@msapiro.net>
 <54C706CD.2030208@msapiro.net>
Message-ID: <54C71E28.2060602@greenbuilder.com>

On 1/26/15 9:32 PM, Mark Sapiro wrote:
> On 01/26/2015 06:08 PM, Mark Sapiro wrote:
>> You weren't supposed to remove/move archives/private, just the
>> subordinate listname directories.
>
> And once again, I misspoke (mistyped). I again meant the subordinate
> listname directories under archives/public, not archives/private.
>
> Mailman expects archives/public to exist, but the subordinates which are
> supposed to be symlinks into archives/private are checked and
> added/removed if necessary each time the list object is saved because
> the list's archive_private setting might have changed necessitating the
> addition or removal of symlinks.
>
Ok.

I put the archives/public folder back.

Toggling the archives setting on the publicly archived lists from public 
to private and back again created the symlinks.  So far so good.

All the archives work when in private state.  But I had to manually 
change the owner of all the publicly available list archives to _www in 
private in order for them to be readable.  Otherwise they get a big 
"Forbidden" message.  Should *all* the lists be _www? Everything in 
archives/private, or just the archive folders and not the mbox folders?  
The archives/private folder itself is already _www.

Thanks for your continued tolerance and assistance.



From mark at msapiro.net  Tue Jan 27 06:27:54 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 26 Jan 2015 21:27:54 -0800
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C71E28.2060602@greenbuilder.com>
References: <54C5801B.9090704@greenbuilder.com>	<54C5863D.5030303@msapiro.net>
 <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp> <54C597F3.1010108@msapiro.net>
 <54C6F158.1000306@greenbuilder.com> <54C6F304.7050802@msapiro.net>
 <54C706CD.2030208@msapiro.net> <54C71E28.2060602@greenbuilder.com>
Message-ID: <54C721DA.5070706@msapiro.net>

On 01/26/2015 09:12 PM, Bill Christensen wrote:
> 
> All the archives work when in private state.  But I had to manually
> change the owner of all the publicly available list archives to _www in
> private in order for them to be readable.  Otherwise they get a big
> "Forbidden" message.  Should *all* the lists be _www? Everything in
> archives/private, or just the archive folders and not the mbox folders? 
> The archives/private folder itself is already _www.
> 
> Thanks for your continued tolerance and assistance.


For public archives to work, the web server needs to be able to search
the archives/private directory that the archives/public/ symlinks point
into.

Normally this only requires that the archives/private/ directory itself,
not any subordinates, be either o+x or owned by the web server user. The
subordinate LISTNAME and LISTNAME.mbox directories are normally
rwxrwsr-x and Mailman's group so Mailman can read and write them and
subordinates will be created in Mailman's group and the web server can
read and search them.

It's only archives/private itself which is in Mailman's group and either
rwxrws--x or if rwxrws---, owned by the web server user. Otherwise,
ownership doesn't matter.

See <http://www.list.org/mailman-install/node9.html>.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From benfell at parts-unknown.org  Tue Jan 27 11:39:11 2015
From: benfell at parts-unknown.org (David Benfell)
Date: Tue, 27 Jan 2015 02:39:11 -0800
Subject: [Mailman-Users] An oldie but a goodie: Operation not permitted
Message-ID: <20150127103911.GA8949@home.parts-unknown.org>

Hi all,

I'm running on FreeBSD:
FreeBSD home.parts-unknown.org 10.1-STABLE FreeBSD 10.1-STABLE #0 r277524: Thu Jan 22 00:14:29 PST 2015     root at home.parts-unknown.org:/usr/obj/usr/src/sys/GENERIC  amd64

All of a sudden mailman isn't starting:

home# service mailman start                            
No problems found
Traceback (most recent call last):
  File "/usr/local/mailman/bin/mailmanctl", line 556, in <module>
    main()
  File "/usr/local/mailman/bin/mailmanctl", line 391, in main
    lock = acquire_lock(force)
  File "/usr/local/mailman/bin/mailmanctl", line 215, in acquire_lock
    lock = acquire_lock_1(force)
  File "/usr/local/mailman/bin/mailmanctl", line 203, in
acquire_lock_1
    if not force or qrunner_state():
  File "/usr/local/mailman/bin/mailmanctl", line 187, in qrunner_state
    os.kill(pid, 0)
OSError: [Errno 1] Operation not permitted

I ran bin/check_perms ; it found no problems. I ran bin/check_db ; it
found nothing to do.

What now?

-- 
David Benfell <benfell at parts-unknown.org>
See https://parts-unknown.org/node/2 if you don't understand the
attachment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150127/57428922/attachment.sig>

From dap1 at bellsouth.net  Tue Jan 27 14:30:40 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Tue, 27 Jan 2015 08:30:40 -0500
Subject: [Mailman-Users] Admin Requests Not Working
Message-ID: <54C79300.7040803@bellsouth.net>

I'm on to the next layer of the onion for my migration. Now I have
admin/moderator requests to handle. When I click the appropriate radio
buttons and click the submit button, nothing happens. The page refreshes
but the requests remain. TIA.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150127/fd450161/attachment.sig>

From mark at msapiro.net  Tue Jan 27 19:27:52 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 27 Jan 2015 10:27:52 -0800
Subject: [Mailman-Users] An oldie but a goodie: Operation not permitted
In-Reply-To: <20150127103911.GA8949@home.parts-unknown.org>
References: <20150127103911.GA8949@home.parts-unknown.org>
Message-ID: <54C7D8A8.6070309@msapiro.net>

On 01/27/2015 02:39 AM, David Benfell wrote:
> Hi all,
> 
> I'm running on FreeBSD:
> FreeBSD home.parts-unknown.org 10.1-STABLE FreeBSD 10.1-STABLE #0 r277524: Thu Jan 22 00:14:29 PST 2015     root at home.parts-unknown.org:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> All of a sudden mailman isn't starting:
> 
> home# service mailman start                            
> No problems found
> Traceback (most recent call last):
>   File "/usr/local/mailman/bin/mailmanctl", line 556, in <module>
>     main()
>   File "/usr/local/mailman/bin/mailmanctl", line 391, in main
>     lock = acquire_lock(force)
>   File "/usr/local/mailman/bin/mailmanctl", line 215, in acquire_lock
>     lock = acquire_lock_1(force)
>   File "/usr/local/mailman/bin/mailmanctl", line 203, in
> acquire_lock_1
>     if not force or qrunner_state():
>   File "/usr/local/mailman/bin/mailmanctl", line 187, in qrunner_state
>     os.kill(pid, 0)
> OSError: [Errno 1] Operation not permitted
> 
> I ran bin/check_perms ; it found no problems. I ran bin/check_db ; it
> found nothing to do.


If Mailman is actually not running, you have a stale lock. After
verifying that Mailman is not running, remove the master-qrunner* files
from Mailman's locks/ directory.

Notes:
1) It looks like you're running

home# service mailman start

as root (# prompt). I can't imagine why os.kill(pid, 0) is not permitted ???

2) It appears the /etc/init.d/mailman (or wherever it is) script doesn't
have the -s option on its mailmanctl start command. This is both good
and bad. The good side is it prevents starting a second Mailman instance
when Mailman is running. The bad side is it won't clean stale locks.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150127/40988641/attachment.sig>

From mark at msapiro.net  Tue Jan 27 20:06:47 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 27 Jan 2015 11:06:47 -0800
Subject: [Mailman-Users] Admin Requests Not Working
In-Reply-To: <54C79300.7040803@bellsouth.net>
References: <54C79300.7040803@bellsouth.net>
Message-ID: <54C7E1C7.2030601@msapiro.net>

On 01/27/2015 05:30 AM, Dennis Putnam wrote:
> I'm on to the next layer of the onion for my migration. Now I have
> admin/moderator requests to handle. When I click the appropriate radio
> buttons and click the submit button, nothing happens. The page refreshes
> but the requests remain. TIA.


See the FAQ at
<http://wiki.list.org/DOC/4.45%20The%20admin%20web%20interface%20is%20not%20saving%20my%20changes%20and%20may%20or%20may%20not%20ask%20me%20to%20re-enter%20my%20password%20--%20what%20is%20wrong?action=show&redirect=DOC%2F4.45+The+admin+web+interface+is+not+saving+my+changes+and+keeps+asking+me+to+re-enter+my+password+--+what+is+wrong%3F>

If that doesn't help, look at the source of the admindb page in your
browser and verify that the ACTION= attribute in the FORM tag is going
where you want.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150127/580de173/attachment.sig>

From mark at msapiro.net  Tue Jan 27 20:14:25 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 27 Jan 2015 11:14:25 -0800
Subject: [Mailman-Users] Admin Requests Not Working
In-Reply-To: <54C7E1C7.2030601@msapiro.net>
References: <54C79300.7040803@bellsouth.net> <54C7E1C7.2030601@msapiro.net>
Message-ID: <54C7E391.3040909@msapiro.net>

On 01/27/2015 11:06 AM, Mark Sapiro wrote:
> 
> See the FAQ at
> <http://wiki.list.org/DOC/4.45%20The%20admin%20web%20interface%20is%20not%20saving%20my%20changes%20and%20may%20or%20may%20not%20ask%20me%20to%20re-enter%20my%20password%20--%20what%20is%20wrong?action=show&redirect=DOC%2F4.45+The+admin+web+interface+is+not+saving+my+changes+and+keeps+asking+me+to+re-enter+my+password+--+what+is+wrong%3F>

That's a bit too looong...

It works, but this one is a bit better

<http://wiki.list.org/DOC/4.45 The admin web interface is not saving my
changes and may or may not ask me to re-enter my password -- what is wrong?>

We need a way to generate short URLs for this wiki. The old Confluence
tiny URLs work through a remapping process, but we don't yet have a way
to generate new ones. It's on my list ...

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150127/4e43c056/attachment.sig>

From dap1 at bellsouth.net  Tue Jan 27 20:23:35 2015
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Tue, 27 Jan 2015 14:23:35 -0500
Subject: [Mailman-Users] Admin Requests Not Working
In-Reply-To: <54C7E391.3040909@msapiro.net>
References: <54C79300.7040803@bellsouth.net> <54C7E1C7.2030601@msapiro.net>
 <54C7E391.3040909@msapiro.net>
Message-ID: <54C7E5B7.3070505@bellsouth.net>

Hi Mark,

They both worked for me. In any case, yes I did all those things in the
faq. However, all the requests have magically disappeared. I am thinking
it may be a caching problem as they were gone after I logged off and
back on. As long as I kept going to that page without a new login
request, they stayed on the page. Shouldn't there have at least been an
error when it tried to process requests that no longer existed?

On 1/27/2015 2:14 PM, Mark Sapiro wrote:
> On 01/27/2015 11:06 AM, Mark Sapiro wrote:
>> See the FAQ at
>> <http://wiki.list.org/DOC/4.45%20The%20admin%20web%20interface%20is%20not%20saving%20my%20changes%20and%20may%20or%20may%20not%20ask%20me%20to%20re-enter%20my%20password%20--%20what%20is%20wrong?action=show&redirect=DOC%2F4.45+The+admin+web+interface+is+not+saving+my+changes+and+keeps+asking+me+to+re-enter+my+password+--+what+is+wrong%3F>
> That's a bit too looong...
>
> It works, but this one is a bit better
>
> <http://wiki.list.org/DOC/4.45 The admin web interface is not saving my
> changes and may or may not ask me to re-enter my password -- what is wrong?>
>
> We need a way to generate short URLs for this wiki. The old Confluence
> tiny URLs work through a remapping process, but we don't yet have a way
> to generate new ones. It's on my list ...
>
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at 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/dap1%40bellsouth.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150127/dbd2720d/attachment-0001.sig>

From mark at msapiro.net  Tue Jan 27 22:31:59 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 27 Jan 2015 13:31:59 -0800
Subject: [Mailman-Users] Admin Requests Not Working
In-Reply-To: <54C7E5B7.3070505@bellsouth.net>
References: <54C79300.7040803@bellsouth.net> <54C7E1C7.2030601@msapiro.net>
 <54C7E391.3040909@msapiro.net> <54C7E5B7.3070505@bellsouth.net>
Message-ID: <54C803CF.9000907@msapiro.net>

On 01/27/2015 11:23 AM, Dennis Putnam wrote:
> Hi Mark,
> 
> They both worked for me. In any case, yes I did all those things in the
> faq. However, all the requests have magically disappeared. I am thinking
> it may be a caching problem as they were gone after I logged off and
> back on. As long as I kept going to that page without a new login
> request, they stayed on the page. Shouldn't there have at least been an
> error when it tried to process requests that no longer existed?


No. The admindb CGI assumes that another moderator (or this moderator in
another browser tab or ...) handled that message and ignores the fact
that it's 'gone'.

It's hard to understand how caching would return a cached page in lieu
of the page sent by the CGI, but unless you can actually figure out how
to repeat this, we won't know what happened.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150127/f11b875c/attachment.sig>

From benfell at parts-unknown.org  Wed Jan 28 05:54:32 2015
From: benfell at parts-unknown.org (David Benfell)
Date: Tue, 27 Jan 2015 20:54:32 -0800
Subject: [Mailman-Users] SOLVED: Re: An oldie but a goodie: Operation not
 permitted
In-Reply-To: <54C7D8A8.6070309@msapiro.net>
References: <20150127103911.GA8949@home.parts-unknown.org>
 <54C7D8A8.6070309@msapiro.net>
Message-ID: <20150128045432.GA63116@home.parts-unknown.org>

On Tue, Jan 27, 2015 at 10:27:52AM -0800, Mark Sapiro wrote:
> On 01/27/2015 02:39 AM, David Benfell wrote:
> 
> If Mailman is actually not running, you have a stale lock. After
> verifying that Mailman is not running, remove the master-qrunner* files
> from Mailman's locks/ directory.
> 
This was it. I'll try to remember this the next time I hit this.
(Maybe with this thread, Google will be more helpful?)

Thanks!
-- 
David Benfell <benfell at parts-unknown.org>
See https://parts-unknown.org/node/2 if you don't understand the
attachment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150127/a28f0a8a/attachment.sig>

From fpicabia at gmail.com  Wed Jan 28 16:13:34 2015
From: fpicabia at gmail.com (francis picabia)
Date: Wed, 28 Jan 2015 11:13:34 -0400
Subject: [Mailman-Users] Basic requirements for bounce processing
Message-ID: <CA+AKB6FRau2T5nUtQXipC=PMmQYkXMsxJ0PX5EcHRGCHiyieMA@mail.gmail.com>

I'm looking for the high level view on what is
needed for bounce processing to be available.

I'm running mailman 2.1.12-18 from Redhat 6.

Under the Bounce processing heading, we have Yes.
MTA is Postfix.

Now what happens?  I check an email from the list
and I don't see a "-bounces" anywhere in the headers.
Everything is from "-owner".  Am I missing a setting?

From fpicabia at gmail.com  Wed Jan 28 16:42:42 2015
From: fpicabia at gmail.com (francis picabia)
Date: Wed, 28 Jan 2015 11:42:42 -0400
Subject: [Mailman-Users] Basic requirements for bounce processing
In-Reply-To: <CA+AKB6FRau2T5nUtQXipC=PMmQYkXMsxJ0PX5EcHRGCHiyieMA@mail.gmail.com>
References: <CA+AKB6FRau2T5nUtQXipC=PMmQYkXMsxJ0PX5EcHRGCHiyieMA@mail.gmail.com>
Message-ID: <CA+AKB6Edg6Yjjq_-7dZjS+9zxJ5Z-yOyRUuFCR+HNz63J-a0KQ@mail.gmail.com>

Sorry, please ignore. I find the file SMTPDirect.py had been modified
locally
to override the defaults.

On Wed, Jan 28, 2015 at 11:13 AM, francis picabia <fpicabia at gmail.com>
wrote:

>
> I'm looking for the high level view on what is
> needed for bounce processing to be available.
>
> I'm running mailman 2.1.12-18 from Redhat 6.
>
> Under the Bounce processing heading, we have Yes.
> MTA is Postfix.
>
> Now what happens?  I check an email from the list
> and I don't see a "-bounces" anywhere in the headers.
> Everything is from "-owner".  Am I missing a setting?
>
>
>

From billc_lists at greenbuilder.com  Thu Jan 29 04:15:07 2015
From: billc_lists at greenbuilder.com (Bill Christensen)
Date: Wed, 28 Jan 2015 21:15:07 -0600
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C721DA.5070706@msapiro.net>
References: <54C5801B.9090704@greenbuilder.com>	<54C5863D.5030303@msapiro.net>
 <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp> <54C597F3.1010108@msapiro.net>
 <54C6F158.1000306@greenbuilder.com> <54C6F304.7050802@msapiro.net>
 <54C706CD.2030208@msapiro.net> <54C71E28.2060602@greenbuilder.com>
 <54C721DA.5070706@msapiro.net>
Message-ID: <54C9A5BB.2030006@greenbuilder.com>

On 1/26/15 11:27 PM, Mark Sapiro wrote:
> On 01/26/2015 09:12 PM, Bill Christensen wrote:
>> All the archives work when in private state.  But I had to manually
>> change the owner of all the publicly available list archives to _www in
>> private in order for them to be readable.  Otherwise they get a big
>> "Forbidden" message.  Should *all* the lists be _www? Everything in
>> archives/private, or just the archive folders and not the mbox folders?
>> The archives/private folder itself is already _www.
>>
>> Thanks for your continued tolerance and assistance.
>
> For public archives to work, the web server needs to be able to search
> the archives/private directory that the archives/public/ symlinks point
> into.
>
> Normally this only requires that the archives/private/ directory itself,
> not any subordinates, be either o+x or owned by the web server user. The
> subordinate LISTNAME and LISTNAME.mbox directories are normally
> rwxrwsr-x and Mailman's group so Mailman can read and write them and
> subordinates will be created in Mailman's group and the web server can
> read and search them.
>
> It's only archives/private itself which is in Mailman's group and either
> rwxrws--x or if rwxrws---, owned by the web server user. Otherwise,
> ownership doesn't matter.
>
> See <http://www.list.org/mailman-install/node9.html>.
>
Well, I had it all working on Monday night.

I got a report today that someone was getting "Forbidden" again.

The owner of the list in question (and only that one list, not any of 
the other publicly archived lists - which have not seen any posts in the 
last two days) had changed back from _www to root.  CHOWNing it back to 
_www again brings up the archive, but then it was only showing the last 
two days worth of archives (owner of those posts: _mailman, the rest 
were root).  Rebuilding the archives with --wipe and running Check perms 
-f (which is already cron jobbed to run every night) made the rest of 
them visible again.

What do i need to do so that I don't have to jump these hoops daily?

Thanks yet again.






From mark at msapiro.net  Thu Jan 29 04:51:21 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 28 Jan 2015 19:51:21 -0800
Subject: [Mailman-Users] Archiving problems
In-Reply-To: <54C9A5BB.2030006@greenbuilder.com>
References: <54C5801B.9090704@greenbuilder.com>	<54C5863D.5030303@msapiro.net>
 <87zj96s5es.fsf@uwakimon.sk.tsukuba.ac.jp> <54C597F3.1010108@msapiro.net>
 <54C6F158.1000306@greenbuilder.com> <54C6F304.7050802@msapiro.net>
 <54C706CD.2030208@msapiro.net> <54C71E28.2060602@greenbuilder.com>
 <54C721DA.5070706@msapiro.net> <54C9A5BB.2030006@greenbuilder.com>
Message-ID: <54C9AE39.40301@msapiro.net>

On 01/28/2015 07:15 PM, Bill Christensen wrote:

> Well, I had it all working on Monday night.
> 
> I got a report today that someone was getting "Forbidden" again.
> 
> The owner of the list in question (and only that one list, not any of
> the other publicly archived lists - which have not seen any posts in the
> last two days) had changed back from _www to root.  CHOWNing it back to
> _www again brings up the archive, but then it was only showing the last
> two days worth of archives (owner of those posts: _mailman, the rest
> were root).  Rebuilding the archives with --wipe and running Check perms
> -f (which is already cron jobbed to run every night) made the rest of
> them visible again.
> 
> What do i need to do so that I don't have to jump these hoops daily?
>

Have you tried running Mailman's bin/check_perms?

Here's what you should have in the way of ownership and permissions.
Group should be _mailman on everything. 'owner' doesn't matter except in
the one case where I indicate _www. SETGID bits are important.

drwxrwsr-x  owner _mailman  /path/to/mailman

drwxrwsr-x  owner _mailman  /path/to/mailman/archives

drwxrwsr-x  owner _mailman  /path/to/mailman/archives/

drwxrwsr-x  owner _mailman  /path/to/mailman/archives/public
                             and only symlinks in this directory

Either
drwxrws--x  owner _mailman  /path/to/mailman/archives/private
or
drwxrws---  _www  _mailman  /path/to/mailman/archives/private

If you want to protect against access to private archives by local users
of the machine, you want the latter. Otherwise the former is fine.

drwxrwsr-x  owner _mailman  /path/to/mailman/archives/private/*

And similarly for subordinate /path/to/mailman/archives/private/*/*
directories.

-rw-rw-r--  owner _mailman  for most files subordinate to
/path/to/mailman/archives/private/*.


Again, SETGID bits are important.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From danil at smirnov.la  Thu Jan 29 18:13:10 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Thu, 29 Jan 2015 19:13:10 +0200
Subject: [Mailman-Users] how to subscribe users of one list to another when
	they post
Message-ID: <CAMrrXbo_jnWbhiN7zAL4b1ap7KarjFP1mn0QPmnqpOeXjQ7g+g@mail.gmail.com>

Hi Mark, Barry and others!

Could you please advice whether it's possible to automate
situation when users of particular list post to some sibling list
which they are not member of:
- to invite them
- to subscribe them silently
- to subscribe them with moderator approve

Is it possible with 2.x/3.x version?

Danil

From mark at msapiro.net  Thu Jan 29 19:00:43 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 29 Jan 2015 10:00:43 -0800
Subject: [Mailman-Users] how to subscribe users of one list to another
 when they post
In-Reply-To: <CAMrrXbo_jnWbhiN7zAL4b1ap7KarjFP1mn0QPmnqpOeXjQ7g+g@mail.gmail.com>
References: <CAMrrXbo_jnWbhiN7zAL4b1ap7KarjFP1mn0QPmnqpOeXjQ7g+g@mail.gmail.com>
Message-ID: <54CA754B.305@msapiro.net>

On 01/29/2015 09:13 AM, Danil Smirnov wrote:
> Hi Mark, Barry and others!
> 
> Could you please advice whether it's possible to automate
> situation when users of particular list post to some sibling list
> which they are not member of:
> - to invite them
> - to subscribe them silently
> - to subscribe them with moderator approve
> 
> Is it possible with 2.x/3.x version?


For Mailman 2.1, any of the above would require significant custom code.
I suspect the same is true for MM 3. Barry would know for sure. For MM
3, it is best to ask on mailman-developers at python.org.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From mark at msapiro.net  Fri Jan 30 06:58:27 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 29 Jan 2015 21:58:27 -0800
Subject: [Mailman-Users] Mailman 2.1.19 release
Message-ID: <54CB1D83.2010907@msapiro.net>

I am pleased to announce the first release candidate for Mailman 2.1.19.

Python 2.4 is the minimum supported, but Python 2.7 is recommended.

This release has several new features, some newly implemented and some
backported from the now truly defunct 2.2 branch - there is nothing left
in that branch that isn't in this release.

There are also bug fixes.

See the attached README for more details.

Associated with those changes are many things that have i18n impacts
including new and modified strings in the message catalog, a new
adminaddrchgack.txt template and a minor change to the
admindbdetails.html template.

I strongly encourage anyone with an interest in translations of Mailman
to get this release and help with updating the translations.

I plan to release the final 2.1.19 release at the end of February, and
it would be good to have as many i18n updates as possible by then.

Mailman is free software for managing email mailing lists and
e-newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.

For more information, please see:

http://www.list.org
http://www.gnu.org/software/mailman
http://mailman.sourceforge.net/

Mailman 2.1.19rc1 can be downloaded from

https://launchpad.net/mailman/2.1/
http://ftp.gnu.org/gnu/mailman/
https://sourceforge.net/projects/mailman/

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
-------------- next part --------------
2.2 Branch Backports (released in conjunction with 2.1.19rc1)

  The following New Features and Bug Fixes have been in an "unofficial,
  never to be released" Mailman 2.2 branch for several years. Until now,
  they were never implemented on the official 2.1 branch because of their
  i18n impacts.  Given that there have been a number of i18n impacting
  changes due to DMARC mitigations in the last few releases, it has been
  decided to backport these as well.

  All of these changes have been running in production on several lists
  for years without problems other than untranslated strings, so they should
  be reasonably "bug free".

  New Features

    - There is a new list attribute 'subscribe_auto_approval' which is a list
      of email addresses and regular expressions matching email addresses
      whose subscriptions are exempt from admin approval.  (LP: #266609)

    - Confirmed member change of address is logged in the 'subscribe' log,
      and if admin_notify_mchanges is true, a notice is sent to the list
      owner using a new adminaddrchgack.txt template.

    - Added an 'automate' option to bin/newlist to send the notice to the
      admin without the prompt.

    - The processing of Topics regular expressions has changed. Previously the
      Topics regexp was compiled in verbose mode but not documented as such
      which caused some confusion.  Also, the documentation indicated that
      topic keywords could be entered one per line, but these entries were not
      handled properly.  Topics regexps are now compiled in non-verbose mode
      and multi-line entries are 'ored'.  Existing Topics regexps will be
      converted when the list is updated so they will continue to work.

    - Added real name display to the web roster.  (LP: #266754)


  Bug fixes and other patches

    - Changed the response to an invalid confirmation to be more generic.
      Not all confirmations are subscription requests.

    - Changed the default nonmember_rejection_notice to be more user friendly.
      (LP: #418728)

    - Added "If you are a list member" qualification to some messages from the
      options login page.  (LP: #266442)

    - Changed the 'Approve' wording in the admindbdetails.html template to
      'Accept/Approve' for better agreement with the button labels.

    - Added '(by thread)' to the previous and next message links in the
      archive to emphasize that even if you got to the message from a
      subject, date or author index, previous and next are still by thread.

2.1.19rc1 (29-Jan-2015)

  New Features

    - There is a new list attribute dmarc_wrapped_message_text and a
      DEFAULT_DMARC_WRAPPED_MESSAGE_TEXT setting to set the default for new
      lists.  This text is added to a message which is wrapped because of
      dmarc_moderation_action in a separate text/plain part that precedes the
      message/rfc822 part containing the original message.  It can be used to
      provide an explanation of why the message was wrapped or similar info.

    - There is a new list attribute equivalent_domains and a
      DEFAULT_EQUIVALENT_DOMAINS setting to set the default for new lists which
      in turn defaults to the empty string.  This provides a way to specify one
      or more groups of domains, e.g., mac.com, me.com, icloud.com, which are
      considered equivalent for validating list membership for posting and
      moderation purposes.

    - There is a new WEB_HEAD_ADD setting to specify text to be added to the
      <HEAD> section of Mailman's internally generated web pages.  This doesn't
      apply to pages built from templates, but in those cases, custom templates
      can be created.  (LP: #1409396)

    - There is a new DEFAULT_SUBSCRIBE_OR_INVITE setting.  Set this to Yes
      to make the default selection on the admin Mass Subscriptions page
      Invite rather than Subscribe.  (LP: #1404511)

    - There is a new list attribute in the Bounce processing section.
      bounce_notify_owner_on_bounce_increment if set to Yes will cause
      Mailman to notify the list owner on every bounce that increments a
      list member's score but doesn't result in a probe or disable.  There
      is a new configuration setting setting
      DEFAULT_BOUNCE_NOTIFY_OWNER_ON_BOUNCE_INCREMENT to set the default
      for new lists.  This in turn defaults to No.  (LP: #1382150)

  Changed behavior

    - Mailman's log files, request.pck files and heldmsg-* files are no
      longer created world readable to protect against access by untrusted
      local users.  Note that permissions on existing log files won't be
      changed so if you are concerned about this and don't rotate logs or
      have a logrotate process that creates new log files instead of letting
      Mailman create them, you will need to address that.  (LP: #1327404)

  Other changes

    - The Python Powered logo image has been replaced in the misc/ directory
      in the source distribution.  Depending on how you've installed these
      images, you may need to copy PythonPowered.png from the misc/ directory
      in the source or from the $prefix/icons/ installed directory to another
      location for your web server.  (LP: #1408575)

  i18n

    - The Romanian message catalog has been updated.  (LP: #1415489)

    - The Russian templates have been updated by Danil Smirnov.  (LP: #1403462)

    - The Japanese translation has been updated by SATOH Fumiyasu.
      (LP: #1402989)

    - A minor change in the French translation of a listinfo subscribe form
      message has been made.  (LP: #1331194)

  Bug fixes and other patches

    - Fixed a bug in bin/rmlist that would throw an exception or just fail to
      remove held message files for a list with regexp special characters in
      its name.  (LP:#1414864)

    - When applying DMARC mitigations, CookHeaders now adds the original From:
      to Cc: rather than Reply-To: in some cases to make MUA 'reply' and
      'reply all' more consistent with the non-DMARC cases.  (LP: #1407098)

    - The Subject: of the list welcome message wasn't always in the user's
      preferred language.  Fixed.  (LP: #1400988)

    - Accept email command in Subject: prefixed with Re: or similar with no
      intervening space.  (LP: #1400200)

    - Fixed a UnicodeDecodeError that could occur in the web admin interface
      if 'text' valued attributes have unicode values.  (LP: #1397170)

    - We now catch the NotAMemberError exception thrown if an authenticated
      unsubscribe is submitted from the user options page for a nonmember.
      (LP: #1390653)

    - Fixed an archiving bug that would cause messages with 'Subject: Re:'
      only to be indexed in the archives without a link to the message.
      (LP: #1388614)

    - The vette log entry for a message discarded by a handler now includes
      the list name and the name of the handler.  (LP: #558096)

    - The options CGI now rejects all but HTTP GET and POST requests.
      (LP: #1372199)

    - A list's poster password will now be accepted on an Urgent: header.
      (LP: #1371678)

    - Fixed a bug which caused a setting of 2 for REMOVE_DKIM_HEADERS to be
      ignored.  (LP: #1363278)

    - Renamed messages/sr/readme.sr to README.sr.  (LP: #1360616)

    - Moved the dmarc_moderation_action checks from the Moderate handler to
      the SpamDetect handler so that the Reject and Discard actions will be
      done before the message might be held by header_filter_rules, and the
      Wrap Message and Munge From actions will be done on messages held by
      header_filter_rules if the message is approved.  (LP: #1334450)

    - <label> tags have been added around most check boxes and radio buttons
      and their text labels in the admin and admindb web GUI so they can be
      (de)selected by clicking the text.  (LP: #266391)

    - If checking DNS for dmarc_moderation_action and DNS lookup is not
      available, log it.  (LP: #1324541)
 
    - Handle missing From: header addresses for DMARC mitigation actions.
      (LP: #1318025)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20150129/1817f109/attachment.sig>

From andrew at hodgsonfamily.org  Sat Jan 31 00:09:21 2015
From: andrew at hodgsonfamily.org (Andrew Hodgson)
Date: Fri, 30 Jan 2015 23:09:21 +0000
Subject: [Mailman-Users] Moving lists with large archives to new server
Message-ID: <AM3PR04MB0776BB3FC98CBEF584DE50DFC5310@AM3PR04MB0776.eurprd04.prod.outlook.com>

Hi,

I am required by my host to change server hardware as the current hardware is out of support and needs replacing.

I will be going from 32-Bit Debian Wheezy to 64-Bit Jessy when it is released, and will probably upgrade to Mailman 2.1.19 from 2.1.18-1 using my own custom made packages.

All the configs for the system will be pushed via Puppet including ~/Mailman/mm_cfg.py, and ~/lists and ~/data can be copied over very quickly.

My question revolves around the list archives.  If I start Mailman up before they are copied across, it is likely there will be waiting messages and these will get archived to a new mbox file.  I want to reduce downtime in moving the lists, but the mbox files are around 25GB, and there are a couple of lists which take the majority of that.  I was going to index the messages once the mbox files are copied over, but what is the smartest way to get these moved without downing Mailman for too long?

Thanks.
Andrew.