From mark at msapiro.net  Sun May  1 01:08:18 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 30 Apr 2016 22:08:18 -0700
Subject: [Mailman-Users] Seeking Information re: mailman admin page bug
In-Reply-To: <22309.15523.776452.687580@turnbull.sk.tsukuba.ac.jp>
References: <da99a9d621ebcd79f2ace69a36100424@iowashares.org>
 <22309.15523.776452.687580@turnbull.sk.tsukuba.ac.jp>
Message-ID: <57258F42.2070208@msapiro.net>

On 04/30/2016 04:15 PM, Stephen J. Turnbull wrote:
> Holly Hart writes:
> 
>  > I work for an organization that uses several Mailman email lists
>  > which I administer.  Starting a couple weeks ago (apparently), the
>  > admin request page commands have ceased to function: messages held
>  > in the queue remain stuck there, regardless of attempts to discard,
>  > reject or accept.
> 
> Do either of the following resemble your problem?  I doubt it, but
> they're the closest I can recall in the FAQ.  The "list locked"
> problem seems more likely, but I don't understand why you would have
> that problem with all lists at the same time.  Note also that the "-1"
> problem has been fixed in later versions than 2.1.5, and you almost
> certainly do have a more recent version.
> 
> https://wiki.list.org/DOC/4.76%20I%20can%27t%20access%20one%20of%20my%20lists%20via%20the%20web%20interface.%20%20One%20of%20my%20lists%20is%20not%20sending%20mail.%20List%20locked.
> https://wiki.list.org/DOC/Why%20am%20I%20receiving%20moderation%20requests%20that%20read%20...mailing%20list%20has%20-1%20request%28s%29%20waiting...%20%3F


Another FAQ which may be (more?) relevant is
<https://wiki.list.org/x/4030602>.

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

From adamsca at gmail.com  Mon May  2 17:51:46 2016
From: adamsca at gmail.com (Christopher Adams)
Date: Mon, 2 May 2016 14:51:46 -0700
Subject: [Mailman-Users] Problems with getting httpd to play well with new
 Mailman install
Message-ID: <CAA13W+8hEND69QWSOwTH7D_HT0MCtjNuJ-t=t3eHpnHOZMZ89w@mail.gmail.com>

Hello all,

I recently had a server fail and I am rebuilding a new server (CentOS 7 )
for Mailman. I have the server and OS working and Mailman installed. I have
installed Mailman a number of times, so kind of know the routine.

I have Apache running and verified that it is by browsing to the root of
the web server. I created a new mailing list and then tried to navigate to
the admin and listinfo page. The result was '403 Forbidden'.

Looking in the httpd error log, I find this:  "client denied by server
configuration: /usr/local/mailman/cgi-bin/listinfo".

I added a block in the httpd.conf file to allow access to the cgi-bin
directory and restarted httpd. Still, I am being forbidden. Files and
directories are owned by mailman.mailman and they seem like they have
proper permissions. I am assuming that it is

<Directory      "/usr/local/mailman/cgi-bin/">
        Order allow,deny
        Allow from all
</Directory>

I then commented out the directory block that limited access to the entire
file system. I restarted httpd. Now, I get this :
Bug in Mailman version 2.1.22 We're sorry, we hit a bug!

-- 
Christopher Adams
adamsca at gmail.com

From mark at msapiro.net  Mon May  2 23:49:17 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 2 May 2016 20:49:17 -0700
Subject: [Mailman-Users] Problems with getting httpd to play well with
 new Mailman install
In-Reply-To: <CAA13W+8hEND69QWSOwTH7D_HT0MCtjNuJ-t=t3eHpnHOZMZ89w@mail.gmail.com>
References: <CAA13W+8hEND69QWSOwTH7D_HT0MCtjNuJ-t=t3eHpnHOZMZ89w@mail.gmail.com>
Message-ID: <57281FBD.8050306@msapiro.net>

On 05/02/2016 02:51 PM, Christopher Adams wrote:
> 
> Looking in the httpd error log, I find this:  "client denied by server
> configuration: /usr/local/mailman/cgi-bin/listinfo".
> 
> I added a block in the httpd.conf file to allow access to the cgi-bin
> directory and restarted httpd. Still, I am being forbidden. Files and
> directories are owned by mailman.mailman and they seem like they have
> proper permissions. I am assuming that it is
> 
> <Directory      "/usr/local/mailman/cgi-bin/">
>         Order allow,deny
>         Allow from all
> </Directory>


If this is Apache 2.4, instead of

        Order allow,deny
        Allow from all

you need

        Require all granted

See <http://httpd.apache.org/docs/2.4/upgrading.html>.


> I then commented out the directory block that limited access to the entire
> file system. I restarted httpd. Now, I get this :
> Bug in Mailman version 2.1.22 We're sorry, we hit a bug!


And what's in Mailman's error log? We need this info to begin to
understand what the issue might be.

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

From adamsca at gmail.com  Tue May  3 19:33:57 2016
From: adamsca at gmail.com (Christopher Adams)
Date: Tue, 3 May 2016 16:33:57 -0700
Subject: [Mailman-Users] Problems with getting httpd to play well with
 new Mailman install
In-Reply-To: <57281FBD.8050306@msapiro.net>
References: <CAA13W+8hEND69QWSOwTH7D_HT0MCtjNuJ-t=t3eHpnHOZMZ89w@mail.gmail.com>
 <57281FBD.8050306@msapiro.net>
Message-ID: <CAA13W+_YEF36Scp9yxU_LT0E_-8aYW_Xq8Z9htnfeZnC17hgsQ@mail.gmail.com>

Yes, it is Apache 2.4 and I had already taken those measures. I don't know
what was fouled up, but I rebooted the server and can now get to the web
pages and create lists. However, I am still having problems, but will post
that as s different issue.

Thanks.

On Mon, May 2, 2016 at 8:49 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 05/02/2016 02:51 PM, Christopher Adams wrote:
> >
> > Looking in the httpd error log, I find this:  "client denied by server
> > configuration: /usr/local/mailman/cgi-bin/listinfo".
> >
> > I added a block in the httpd.conf file to allow access to the cgi-bin
> > directory and restarted httpd. Still, I am being forbidden. Files and
> > directories are owned by mailman.mailman and they seem like they have
> > proper permissions. I am assuming that it is
> >
> > <Directory      "/usr/local/mailman/cgi-bin/">
> >         Order allow,deny
> >         Allow from all
> > </Directory>
>
>
> If this is Apache 2.4, instead of
>
>         Order allow,deny
>         Allow from all
>
> you need
>
>         Require all granted
>
> See <http://httpd.apache.org/docs/2.4/upgrading.html>.
>
>
> > I then commented out the directory block that limited access to the
> entire
> > file system. I restarted httpd. Now, I get this :
> > Bug in Mailman version 2.1.22 We're sorry, we hit a bug!
>
>
> And what's in Mailman's error log? We need this info to begin to
> understand what the issue might be.
>
> --
> 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/adamsca%40gmail.com
>



-- 
Christopher Adams
adamsca at gmail.com

From adamsca at gmail.com  Tue May  3 19:50:26 2016
From: adamsca at gmail.com (Christopher Adams)
Date: Tue, 3 May 2016 16:50:26 -0700
Subject: [Mailman-Users] Problems using Postfix with Mailman
Message-ID: <CAA13W+8kiqDSnBXk1YDKMRbUMhL0ZoCXNCd4StE7ew9w7pkAuA@mail.gmail.com>

Hello all,

I previously posted a message about a server "migration" of Mailman to a
new CentOS 7 server. It actually is a rebuild and I will be trying to
restore list info from backup.

Anyway, I have Mailman installed and can access web pages and create lists.
I am using Postfix as the MTA and I restored the main.cf file from the old
server. I have indicated MTA ="Postfix"  in mm_cfg.py, which I also moved
over frrom old server backup.

I restarted Postfix and Mailman. Now, when I post to a list, I get a
variety of errors.

In my own mailbox, I get this:

mymailmanserver.com #<mymailmanserver.com#5.1.1 SMTP; 550 5.1.1 <
osltest at mymailmanserver.com <osltest at listsmart.osl.state.or.us>>: Recipient
address rejected: User unknown in local recipient table> #SMTP#

In the maillog file, I get NOQUEUE: reject RCPT from localhost [::1] 454
4.71 <my.address at mydomain.com>: Relay access denied; from=<
mylist-bounces at mymailmanserver.com>

In the Mailman smtp-failure log file, I get: "Relay access denied"

>From all that I have read, it must be a Postfix configuration problem, but
since I just moved the old main.cf to the new server, I am perplexed. Posts
to the Postfix-Users list has not been productive.

If anyone uses Mailman and Postfix, maybe you can share your experiences.

Many thanks.

-- 
Christopher Adams
adamsca at gmail.com

From mark at msapiro.net  Tue May  3 20:55:35 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 3 May 2016 17:55:35 -0700
Subject: [Mailman-Users] Problems using Postfix with Mailman
In-Reply-To: <CAA13W+8kiqDSnBXk1YDKMRbUMhL0ZoCXNCd4StE7ew9w7pkAuA@mail.gmail.com>
References: <CAA13W+8kiqDSnBXk1YDKMRbUMhL0ZoCXNCd4StE7ew9w7pkAuA@mail.gmail.com>
Message-ID: <57294887.8070707@msapiro.net>

On 05/03/2016 04:50 PM, Christopher Adams wrote:

> In the maillog file, I get NOQUEUE: reject RCPT from localhost [::1] 454
> 4.71 <my.address at mydomain.com>: Relay access denied; from=<
> mylist-bounces at mymailmanserver.com>
> 
> In the Mailman smtp-failure log file, I get: "Relay access denied"
> 
>>From all that I have read, it must be a Postfix configuration problem, but
> since I just moved the old main.cf to the new server, I am perplexed. Posts
> to the Postfix-Users list has not been productive.


Right, and the problem is you didn't change the postfix main.cf to match
the RedHat/CentOS change in /etc/hosts.

The issue is that mailman is sending to 'localhost', /etc/hosts is
defining localhost as the IPv6 address [::1], and this is not in
mynetworks in main.cf. There are various ways to fix this including
replacing the localhost entry in /etc/hosts - something like

::1	localhost

with

127.0.0.1  localhost

or adding [::1]/128 to mynetworks in main.cf.

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

From adamsca at gmail.com  Wed May  4 00:58:11 2016
From: adamsca at gmail.com (Christopher Adams)
Date: Tue, 3 May 2016 21:58:11 -0700
Subject: [Mailman-Users] Problems using Postfix with Mailman
In-Reply-To: <57294887.8070707@msapiro.net>
References: <CAA13W+8kiqDSnBXk1YDKMRbUMhL0ZoCXNCd4StE7ew9w7pkAuA@mail.gmail.com>
 <57294887.8070707@msapiro.net>
Message-ID: <CAA13W+8__eh9f6vw0hTB9DvySN_FhZg__L33HHAwxeK9vzAL_g@mail.gmail.com>

Yes, you are so right. I did have an entry for 127.0.0.1  localhost in
/etc/hosts, but also the entry for IPV6, which I didn't need and it
apparently took preference.

So, this did help and I thank you. Additionally, there was some
configuration in the Postfix main.cf that needed updating due to a change
in the version of Postfix.

Many thanks, Mark.
On May 3, 2016 5:56 PM, "Mark Sapiro" <mark at msapiro.net> wrote:

> On 05/03/2016 04:50 PM, Christopher Adams wrote:
>
> > In the maillog file, I get NOQUEUE: reject RCPT from localhost [::1] 454
> > 4.71 <my.address at mydomain.com>: Relay access denied; from=<
> > mylist-bounces at mymailmanserver.com>
> >
> > In the Mailman smtp-failure log file, I get: "Relay access denied"
> >
> >>From all that I have read, it must be a Postfix configuration problem,
> but
> > since I just moved the old main.cf to the new server, I am perplexed.
> Posts
> > to the Postfix-Users list has not been productive.
>
>
> Right, and the problem is you didn't change the postfix main.cf to match
> the RedHat/CentOS change in /etc/hosts.
>
> The issue is that mailman is sending to 'localhost', /etc/hosts is
> defining localhost as the IPv6 address [::1], and this is not in
> mynetworks in main.cf. There are various ways to fix this including
> replacing the localhost entry in /etc/hosts - something like
>
> ::1     localhost
>
> with
>
> 127.0.0.1  localhost
>
> or adding [::1]/128 to mynetworks in main.cf.
>
> --
> 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/adamsca%40gmail.com
>

From day7pettersens at gmail.com  Wed May  4 09:12:05 2016
From: day7pettersens at gmail.com (Craig Pettersen)
Date: Wed, 4 May 2016 20:12:05 +0700
Subject: [Mailman-Users] Stop Backlogged Messages From Going Out
Message-ID: <CAJ1S6yiA=MtUPOE9k+CUZos9Ov6q+C6F6q2jv0K9xtnqPoxJmA@mail.gmail.com>

Hello,
  I inherited a server that has a couple mailman lists that interface with
postfix and was alerted that daily messages from the list haven't been
going out for almost 3 weeks now.  I fixed the problem in postfix, and
before fixing it I checked queues and files in /var/spool/postfix and in
/home/mailman to see if any backlogged messages were set to go out and
didn't find any.
  However after things went back up I've received two messages from the
list and I have no idea where they've been hiding.  Since I can't have
people upset with 20 emails from the list showing up in their inboxes I
shut postfix and mailman down.  Now I need some help figuring out how to
find and stop any old messages from going out and delete them.  Can anyone
help me understand how to do that?
  Thanks,
  Craig

From danny at schmarsel.de  Tue May  3 17:22:28 2016
From: danny at schmarsel.de (Danny Schmarsel)
Date: Tue, 03 May 2016 23:22:28 +0200
Subject: [Mailman-Users] Can users still receive digests when they are
 turned off?
Message-ID: <eb7485b695786c27ac967d4997680335@hirnschwund.net>

Hello guys,

I'm running a mailing list without digests to keep the replies clean.

On the "Membership Management" page I can still enable digests for 
specific users even with digestable turned off.

The question: Will these users still receive digests or does digestable 
override user-specific settings?

Thanks,
-Danny

From curtis at ipv6.occnc.com  Tue May  3 15:26:44 2016
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Tue, 03 May 2016 15:26:44 -0400
Subject: [Mailman-Users] disable DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in
 mailman 2.1
Message-ID: <3qzrlB5RqCzFqQf@mail.python.org>

By default DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL is set to
https://publicsuffix.org/list/public_suffix_list.dat

I have mailman set up on an IPv6 only host and publicsuffix.org has no
IPv6 address.  A near identical configuration is set up on a dual
stack host.  Any email to the IPv6 only host fails with an entry in
logs/error of the form "Unable to retrieve data from
https://publicsuffix.org/list/public_suffix_list.dat: <urlopen error
[Errno 43] Protocol not supported>"

In the mean time I would like to disable the use of
DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL by setting it empty.  To do this
it seems that I would need the following change:

--- Mailman/Utils.py.orig       2016-04-09 04:08:56.000000000 -0400
+++ Mailman/Utils.py    2016-05-03 14:37:12.683904000 -0400
@@ -1205,6 +1205,8 @@
     Domain which may be the same as the input."""
     global s_dict
     if not s_dict:
-        get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
+        if mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL:
+            get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
     hits = []
     d = domain.lower().split('.')

This works for .com, .org, .net, etc but not for things like co.uk,
etc (which in my case is not an issue).

A second question is why does failing to access publicsuffix.org
result in a hard fail rather than a soft fail?  The change I made just
skips over get_suffixes and leaves s_dict empty.  It seems that
get_suffixes does do a try and except which logs and returns, but then
the mail gets rejected and the reason is not clear to me.  In
logs/smtp-failure there is a message of the form "failed with code
554: 5.7.1 <fqdn[ipv6addr]>: Client host rejected: Access denied".

Curtis

From mark at msapiro.net  Wed May  4 10:52:40 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 4 May 2016 07:52:40 -0700
Subject: [Mailman-Users] Stop Backlogged Messages From Going Out
In-Reply-To: <CAJ1S6yiA=MtUPOE9k+CUZos9Ov6q+C6F6q2jv0K9xtnqPoxJmA@mail.gmail.com>
References: <CAJ1S6yiA=MtUPOE9k+CUZos9Ov6q+C6F6q2jv0K9xtnqPoxJmA@mail.gmail.com>
Message-ID: <572A0CB8.308@msapiro.net>

On 05/04/2016 06:12 AM, Craig Pettersen wrote:
>   However after things went back up I've received two messages from the
> list and I have no idea where they've been hiding.  Since I can't have
> people upset with 20 emails from the list showing up in their inboxes I
> shut postfix and mailman down.  Now I need some help figuring out how to
> find and stop any old messages from going out and delete them.  Can anyone
> help me understand how to do that?


They've probably all been sent already, but any messages queued in
Mailman will be in Mailman's qfiles directory. In a source install the
queues are directories like $var_prefix/qfiles/in/,
$var_prefix/qfiles/out/ and so on, and the actual queued messages are
*.pck files in the directories.

Packages may or may not have a 'qfiles' directory. E.g., in the
RedHat/CentOS package the queues are /var/spool/mailman/in/,
/var/spool/mailman/out/, etc.

-- 
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 May  4 11:07:51 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 4 May 2016 08:07:51 -0700
Subject: [Mailman-Users] Can users still receive digests when they are
 turned off?
In-Reply-To: <eb7485b695786c27ac967d4997680335@hirnschwund.net>
References: <eb7485b695786c27ac967d4997680335@hirnschwund.net>
Message-ID: <572A1047.30902@msapiro.net>

On 05/03/2016 02:22 PM, Danny Schmarsel wrote:
> Hello guys,
> 
> I'm running a mailing list without digests to keep the replies clean.
> 
> On the "Membership Management" page I can still enable digests for
> specific users even with digestable turned off.
> 
> The question: Will these users still receive digests or does digestable
> override user-specific settings?


They will receive no mail at all. They are set to 'digest' so they don't
receive individual messages, and the list's digestable is No so no
digests will be produced.

If you change a list from digestable = Yes to No and there are digest
members, you will be warned of this. If the list is already digestable =
No, and you try to set a member to digest via the admin UI "Membership
Management" page, the change is silently ignored.

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

From curtis at ipv6.occnc.com  Wed May  4 12:27:24 2016
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Wed, 04 May 2016 12:27:24 -0400
Subject: [Mailman-Users] resend - mailman 2.1.21 - dmarc check problem
Message-ID: <3r0Njq3R6vzFqKP@mail.python.org>

I'm resending this with a new subject.  The last email just
disappeared (no bounce).  Maybe having
DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in the subject tripped an all
caps in subject test.  (Or the moderator is slacking?)

By default DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL is set to
https://publicsuffix.org/list/public_suffix_list.dat

I have mailman set up on an IPv6 only host and publicsuffix.org has no
IPv6 address.  A near identical configuration is set up on a dual
stack host.  Any email to the IPv6 only host fails with an entry in
logs/error of the form "Unable to retrieve data from
https://publicsuffix.org/list/public_suffix_list.dat: <urlopen error
[Errno 43] Protocol not supported>"

It doesn't look as if publicsuffix.org will be getting an IPv6 address
any time soon.  The alternative github.com also doesn't have an IPv6
address.  In the mean time I would like to disable the use of
DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL by setting it empty.  To do this
it seems that I would need the following change:

- --- Mailman/Utils.py.orig       2016-04-09 04:08:56.000000000 -0400
+++ Mailman/Utils.py    2016-05-03 14:37:12.683904000 -0400
@@ -1205,6 +1205,8 @@
     Domain which may be the same as the input."""
     global s_dict
     if not s_dict:
-        get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
+        if mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL:
+            get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
     hits = []
     d = domain.lower().split('.')

In mm_sfg.py I just set "DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL = ''".

This works for .com, .org, .net, etc but not for things like co.uk,
etc (which in my case is not an issue).

A second question is why does failing to access publicsuffix.org
result in a hard fail rather than a soft fail?  The change I made just
skips over get_suffixes and leaves s_dict empty.  It seems that
get_suffixes does do a "try and except" which logs and returns, but
then the mail gets rejected and the reason is not clear to me by just
reading the code.  In logs/smtp-failure there is a message of the form
"failed with code 554: 5.7.1 <fqdn[ipv6addr]>: Client host rejected:
Access denied".  Skipping get_suffixes throws no error and leaves
s_dict empty.  At most an error in get_suffixes should put the email
in shunt but that seems to be in error handling upstream.

Curtis

From mark at msapiro.net  Wed May  4 21:29:26 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 4 May 2016 18:29:26 -0700
Subject: [Mailman-Users] disable DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in
 mailman 2.1
In-Reply-To: <3qzrlB5RqCzFqQf@mail.python.org>
References: <3qzrlB5RqCzFqQf@mail.python.org>
Message-ID: <572AA1F6.8090807@msapiro.net>

On 05/03/2016 12:26 PM, Curtis Villamizar wrote:
> By default DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL is set to
> https://publicsuffix.org/list/public_suffix_list.dat
> 
> I have mailman set up on an IPv6 only host and publicsuffix.org has no
> IPv6 address.  A near identical configuration is set up on a dual
> stack host.  Any email to the IPv6 only host fails with an entry in
> logs/error of the form "Unable to retrieve data from
> https://publicsuffix.org/list/public_suffix_list.dat: <urlopen error
> [Errno 43] Protocol not supported>"


The log entry seems correct for this situation. The mail delivery
failure is unrelated - see below.


> In the mean time I would like to disable the use of
> DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL by setting it empty.  To do this
> it seems that I would need the following change:
> 
> --- Mailman/Utils.py.orig       2016-04-09 04:08:56.000000000 -0400
> +++ Mailman/Utils.py    2016-05-03 14:37:12.683904000 -0400
> @@ -1205,6 +1205,8 @@
>      Domain which may be the same as the input."""
>      global s_dict
>      if not s_dict:
> -        get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
> +        if mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL:
> +            get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
>      hits = []
>      d = domain.lower().split('.')
> 
> This works for .com, .org, .net, etc but not for things like co.uk,
> etc (which in my case is not an issue).


This is a bug. I've created
<https://bugs.launchpad.net/mailman/+bug/1578450> and have fixed it, but
not as above, although as above should work. The fix is at
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1648>


> A second question is why does failing to access publicsuffix.org
> result in a hard fail rather than a soft fail?  The change I made just
> skips over get_suffixes and leaves s_dict empty.  It seems that
> get_suffixes does do a try and except which logs and returns, but then
> the mail gets rejected and the reason is not clear to me.  In
> logs/smtp-failure there is a message of the form "failed with code
> 554: 5.7.1 <fqdn[ipv6addr]>: Client host rejected: Access denied".


The above message in smtp-failure is saying Mailman is trying to send
mail to the list or whatever and the recipient MX for this delivery does
not allow IPv6 access to its MTA, at least not from you. This has
nothing to do with the changes you made to skip loading
DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL. I think it is going to be a
serious problem if you are trying to send mail in general because not
every recipient domain is going to be listening on port 25 at an IPv6
address.

I think if your outgoing MTA is connecting only to IPv6 addresses, you
will have difficulty delivering mail in general regardless of the source
of the mail.

As for as why it's a 554: 5.7.1 hard fail, That's the status your MTA is
giving to this condition. If you think this should be a 4xx status, you
may be able to configure that in your MTA.

-- 
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 May  4 21:59:00 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 4 May 2016 18:59:00 -0700
Subject: [Mailman-Users] resend - mailman 2.1.21 - dmarc check problem
In-Reply-To: <3r0Njq3R6vzFqKP@mail.python.org>
References: <3r0Njq3R6vzFqKP@mail.python.org>
Message-ID: <572AA8E4.9070405@msapiro.net>

On 05/04/2016 09:27 AM, Curtis Villamizar wrote:
> I'm resending this with a new subject.  The last email just
> disappeared (no bounce).  Maybe having
> DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in the subject tripped an all
> caps in subject test.  (Or the moderator is slacking?)


A moderator (me) approved your post and cleared your mod bit
approximately 2 hours before you posted this. My reply to that post is
at <https://mail.python.org/pipermail/mailman-users/2016-May/080772.html>.

I don't know why you didn't receive it. It was successfully sent per

May  4 10:36:04 mail postfix/smtp[22778]: 3r0LDW0F1DzFqP0:
to=<curtis at ipv6.occnc.com>,
relay=mta2-em1.orleans.occnc.com[50.252.223.140]:25, delay=42,
delays=0.08/0/31/11, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
316BF9DDA)

(time stamp is UTC - 0400)

Maybe the ALL CAPS filtered it at your end.

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

From dnewman at networktest.com  Wed May  4 14:27:08 2016
From: dnewman at networktest.com (David Newman)
Date: Wed, 4 May 2016 11:27:08 -0700
Subject: [Mailman-Users] dnspython not found error
Message-ID: <5b2883ba-360c-3803-ea3f-f62e03b209b8@networktest.com>

Had to reinstall the Mailman port (not pkg) on a FreeBSD 10.3-RELEASE
system after updating some ports due to security vulnerabilities.
Several other packages also required rebuild to point to new shared objects.

The Mailman build failed, saying 'dnspython not found' even though that
port is installed:

root at mail:/usr/ports/mail/mailman # pkg info | grep dnspython
py27-dnspython-1.12.0          DNS toolkit for Python

I've attached the config log, and pasted below the list of installed ports.

How to get Mailman working again?

Thanks!

dn


root at mail:/usr/ports/mail/mailman # /usr/local/sbin/pkg-static info -g
-Ea | cut -d ' ' -f 1
altermime-0.3.11.a1
amavisd-new-2.10.1_1,1
ap24-mod_wsgi3-3.5
apache24-2.4.20_1
apr-1.5.2.1.5.4
arc-5.21p
arj-3.10.22_4
aspell-0.60.6.1_5
autoconf-2.69
autoconf-wrapper-20131203
automake-1.15_1
automake-wrapper-20131203
awstats-7.4,1
bacula-client-7.4.0_2
bash-static-4.3.42_1
bison-2.7.1,1
ca_root_nss-3.22.2
cabextract-1.6
cclient-2007f_2,1
clamav-0.99.1
cmake-3.5.2
cmake-modules-3.5.2
compat9x-amd64-9.3.903000.20160128
curl-7.47.0
cyrus-sasl-2.1.26_12
db5-5.3.28_3
dialog4ports-0.1.5_2
dovecot-pigeonhole-0.4.14
dovecot2-2.2.24
expat-2.1.0_3
fakeroot-1.20.2
file-5.25
freeze-2.5_2
gdbm-1.11_2
gettext-runtime-0.19.7
gettext-tools-0.19.7
gmake-4.1_2
gmake-lite-4.1_1
gnupg1-1.4.20
help2man-1.43.3_1
icu-55.1
indexinfo-0.2.4
json-c-0.12_2
jsoncpp-0.6.0.r2_2
lha-1.14i_6
libarchive-3.1.2_6,1
libcheck-0.10.0
libedit-3.1.20150325_2
libffi-3.2.1
libgcrypt-1.7.0
libgpg-error-1.22
libiconv-1.14_9
libidn-1.31
libltdl-2.4.6
libmcrypt-2.5.8_3
libressl-2.3.4
libssh2-1.7.0,2
libtool-2.4.6
libxml2-2.9.3
libxslt-1.1.28_8
logrotate-3.9.2
logwatch-7.4.0_1
lzo2-2.09
lzop-1.03
m4-1.4.17_1,1
mod_php55-5.5.35
mysql56-client-5.6.30
mysql56-server-5.6.30
nomarch-1.4
oniguruma5-5.9.6_1
p0f-3.09b
p5-Archive-Zip-1.57
p5-Authen-SASL-2.16_1
p5-BerkeleyDB-0.55_1
p5-CPAN-Meta-2.150005
p5-Cache-FastMmap-1.43
p5-Canary-Stability-2011
p5-Config-IniFiles-2.88
p5-Convert-BinHex-1.125
p5-Convert-TNEF-0.18_1
p5-Convert-UUlib-1.50,1
p5-Crypt-CBC-2.33_1
p5-Crypt-DES-2.07_1
p5-Crypt-OpenSSL-Bignum-0.06
p5-Crypt-OpenSSL-RSA-0.28_1
p5-Crypt-OpenSSL-Random-0.11
p5-DBD-SQLite-1.50
p5-DBD-mysql-4.033
p5-DBI-1.636
p5-Digest-HMAC-1.03_1
p5-Digest-SHA1-2.13_1
p5-Encode-Detect-1.01_1
p5-Exporter-Tiny-0.042_1
p5-GSSAPI-0.28_1
p5-HTML-Parser-3.72
p5-HTML-Tagset-3.20_1
p5-HTTP-Date-6.02_1
p5-IO-Multiplex-1.13_1
p5-IO-Socket-INET6-2.72_1
p5-IO-Socket-IP-0.37
p5-IO-Socket-SSL-2.025
p5-IO-stringy-2.111
p5-Locale-gettext-1.06
p5-MIME-Base64-3.15
p5-MIME-Tools-5.507,2
p5-Mail-DKIM-0.40_2
p5-Mail-Tools-2.14
p5-Module-Build-0.4218
p5-Mozilla-CA-20160104
p5-Net-CIDR-0.18
p5-Net-DNS-1.05_1,1
p5-Net-IP-1.26_1
p5-Net-LibIDN-0.12_4
p5-Net-SNMP-6.0.1_1
p5-Net-SSLeay-1.74
p5-Net-Server-2.008_1
p5-Net-XWhois-0.90_5
p5-NetAddr-IP-4.078
p5-Socket-2.021
p5-Socket6-0.27
p5-TimeDate-2.30_2,1
p5-URI-1.71
p5-Unix-Syslog-1.1_1
p7zip-15.14
pcre-8.38_1
pecl-intl-3.0.0_2
perl5-5.20.3_12
php55-5.5.35
php55-bz2-5.5.35
php55-ctype-5.5.35
php55-dom-5.5.35
php55-filter-5.5.35
php55-gettext-5.5.35
php55-hash-5.5.35
php55-iconv-5.5.35
php55-imap-5.5.35
php55-json-5.5.35
php55-mbstring-5.5.35
php55-mcrypt-5.5.35
php55-mysql-5.5.35
php55-mysqli-5.5.35
php55-openssl-5.5.35
php55-pdo-5.5.35
php55-pdo_mysql-5.5.35
php55-pspell-5.5.35
php55-session-5.5.35
php55-simplexml-5.5.35
php55-xml-5.5.35
php55-zip-5.5.35
php55-zlib-5.5.35
pkg-1.7.2
pkgconf-0.9.12_1
popt-1.16_1
portmaster-3.17.9_2
postfix-3.1.0,1
py27-Babel-2.3.3
py27-Jinja2-2.8
py27-MarkupSafe-0.23
py27-MySQLdb-1.2.5
py27-alabaster-0.7.6
py27-bcrypt-0.4_2
py27-beautifulsoup-4.4.1
py27-cffi-1.5.0
py27-dnspython-1.12.0
py27-docutils-0.12
py27-enum34-1.0.4
py27-funcsigs-0.4
py27-idna-2.0
py27-ipaddress-1.0.16
py27-lxml-3.5.0
py27-mock-1.3.0_1
py27-netifaces-0.10.4
py27-pbr-1.8.1
py27-pip-8.0.2
py27-pyasn1-0.1.9
py27-pycparser-2.10
py27-pygments-2.1.3
py27-pystemmer-1.3.0_1
py27-pytz-2016.1,1
py27-setuptools27-20.0
py27-six-1.10.0
py27-snowballstemmer-1.2.0_1
py27-sphinx-1.3.1_2
py27-sphinx_rtd_theme-0.1.9
py27-sqlalchemy-0.7.10_2
py27-werkzeug-0.11.9
py27-zope.event-4.1.0
python2-2_3
python27-2.7.11_2
rar-5.3.0,3
re2c-0.14.3
ripole-0.2.2
roundcube-1.1.4_1,1
rpm2cpio-1.4_2
rsync-3.1.2_3
scons-2.5.0
spamassassin-3.4.1_6
sshguard-1.6.4_1
sudo-1.8.16
tinycdb-0.78_2
tnef-1.4.11
unarj-2.65_2
unrar-5.31,5
unzoo-4.4_2
vim-lite-7.4.1743
webpy-0.37
zoo-2.10.1_3



-------------- next part --------------
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --with-python=/usr/local/bin/python2.7 --with-username=mailman --with-groupname=mailman --with-mail-gid=mailman --with-cgi-gid=www --with-permcheck=no --prefix=/usr/local/mailman --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/mailman/info/ --build=amd64-portbld-freebsd10.3

## --------- ##
## Platform. ##
## --------- ##

hostname = mail.cvcbike.org
uname -m = amd64
uname -r = 10.3-RELEASE
uname -s = FreeBSD
uname -v = FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 UTC 2016     root at releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC 

/usr/bin/uname -p = amd64
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/games
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /root/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2029: loading site script /usr/ports/Templates/config.site
| # $FreeBSD: head/Templates/config.site 400392 2015-10-28 14:23:51Z bdrewery $
| # Do not add:
| #	- toolchain related
| #	- arch-dependent values
| #	- anything "=no" unless guaranteed to never be
| #	  implemented in FreeBSD
| #	- also avoid "working" values
| # This file must reflect the oldest supported Release.
| #
| #MAINTAINER=	portmgr at FreeBSD.org
| 
| # Path
| : ${ac_cv_path_BZIP2=/usr/bin/bzip2}
| : ${ac_cv_path_EGREP=/usr/bin/egrep}
| : ${ac_cv_path_FGREP=/usr/bin/fgrep}
| : ${ac_cv_path_GREP=/usr/bin/grep}
| : ${ac_cv_path_GZIP=/usr/bin/gzip}
| : ${ac_cv_path_MKTEMP_COMMAND=/usr/bin/mktemp}
| : ${ac_cv_path_SED=/usr/bin/sed}
| : ${ac_cv_path_install=/usr/bin/install}
| : ${ac_cv_path_mkdir=/bin/mkdir}
| : ${ac_cv_prog_AWK=/usr/bin/awk}
| : ${ac_cv_prog_SED=/usr/bin/sed}
| : ${am_cv_prog_tar_ustar=/usr/bin/tar}
| : ${cl_cv_prog_LN=/bin/ln}
| : ${cl_cv_prog_cp='/bin/cp -p'}
| : ${lt_cv_path_MAGIC_CMD=/usr/bin/file}
| 
| # Headers
| : ${ac_cv_header_alloca_h=no}
| : ${ac_cv_header_arpa_inet_h=yes}
| : ${ac_cv_header_arpa_nameser_h=yes}
| : ${ac_cv_header_ctype_h=yes}
| : ${ac_cv_header_dirent_h=yes}
| : ${ac_cv_header_dlfcn_h=yes}
| : ${ac_cv_header_elf_h=yes}
| : ${ac_cv_header_errno_h=yes}
| : ${ac_cv_header_fcntl_h=yes}
| : ${ac_cv_header_float_h=yes}
| : ${ac_cv_header_floatingpoint_h=yes}
| : ${ac_cv_header_getopt_h=yes}
| : ${ac_cv_header_glob_h=yes}
| : ${ac_cv_header_inttypes_h=yes}
| : ${ac_cv_header_langinfo_h=yes}
| : ${ac_cv_header_libgen_h=yes}
| : ${ac_cv_header_libutil_h=yes}
| : ${ac_cv_header_limits_h=yes}
| : ${ac_cv_header_login_cap_h=yes}
| : ${ac_cv_header_math_h=yes}
| : ${ac_cv_header_memory_h=yes}
| : ${ac_cv_header_minix_config_h=no}
| : ${ac_cv_header_net_if_h=yes}
| : ${ac_cv_header_net_if_media_h=yes}
| : ${ac_cv_header_net_if_tap_h=yes}
| : ${ac_cv_header_net_if_tun_h=yes}
| : ${ac_cv_header_netdb_h=yes}
| : ${ac_cv_header_netinet_in_h=yes}
| : ${ac_cv_header_paths_h=yes}
| : ${ac_cv_header_poll_h=yes}
| : ${ac_cv_header_pwd_h=yes}
| : ${ac_cv_header_readpassphrase_h=yes}
| : ${ac_cv_header_resolv_h=yes}
| : ${ac_cv_header_rpc_types_h=yes}
| : ${ac_cv_header_sched_h=yes}
| : ${ac_cv_header_search_h=yes}
| : ${ac_cv_header_security_pam_appl_h=yes}
| : ${ac_cv_header_signal_h=yes}
| : ${ac_cv_header_spawn_h=yes}
| : ${ac_cv_header_stdarg_h=yes}
| : ${ac_cv_header_stdbool_h=yes}
| : ${ac_cv_header_stdc=yes}
| : ${ac_cv_header_stddef_h=yes}
| : ${ac_cv_header_stdint_h=yes}
| : ${ac_cv_header_stdio_h=yes}
| : ${ac_cv_header_stdlib_h=yes}
| : ${ac_cv_header_string_h=yes}
| : ${ac_cv_header_strings_h=yes}
| : ${ac_cv_header_sys_acl_h=yes}
| : ${ac_cv_header_sys_cdefs_h=yes}
| : ${ac_cv_header_sys_dir_h=yes}
| : ${ac_cv_header_sys_fcntl_h=yes}
| : ${ac_cv_header_sys_file_h=yes}
| : ${ac_cv_header_sys_ioctl_h=yes}
| : ${ac_cv_header_sys_mman_h=yes}
| : ${ac_cv_header_sys_mount_h=yes}
| : ${ac_cv_header_sys_msg_h=yes}
| : ${ac_cv_header_sys_param_h=yes}
| : ${ac_cv_header_sys_poll_h=yes}
| : ${ac_cv_header_sys_ptrace_h=yes}
| : ${ac_cv_header_sys_select_h=yes}
| : ${ac_cv_header_sys_socket_h=yes}
| : ${ac_cv_header_sys_stat_h=yes}
| : ${ac_cv_header_sys_statvfs_h=yes}
| : ${ac_cv_header_sys_time_h=yes}
| : ${ac_cv_header_sys_timers_h=yes}
| : ${ac_cv_header_sys_times_h=yes}
| : ${ac_cv_header_sys_types_h=yes}
| : ${ac_cv_header_sys_un_h=yes}
| : ${ac_cv_header_sys_wait_h=yes}
| : ${ac_cv_header_time_h=yes}
| : ${ac_cv_header_ttyent_h=yes}
| : ${ac_cv_header_ucontext_h=yes}
| : ${ac_cv_header_unistd_h=yes}
| : ${ac_cv_header_utime_h=yes}
| : ${ac_cv_header_vis_h=yes}
| : ${ac_cv_header_wchar_h=yes}
| : ${ac_cv_header_wctype_h=yes}
| : ${ac_cv_header_zlib_h=yes}
| 
| : ${gl_cv_header_wchar_h_correct_inline=yes}
| 
| : ${ac_cv_header_argz_h=no}
| : ${ac_cv_header_byteswap_h=no}
| : ${ac_cv_header_dl_h=no}
| : ${ac_cv_header_malloc_h=no}
| : ${ac_cv_header_random_h=no}
| : ${ac_cv_header_vfork_h=no}
| 
| # This appears in FreeBSD 10 do not cache it.
| #: ${gl_cv_have_raw_decl_strchrnul=yes}
| : ${gl_cv_have_raw_decl_memcpy=no}
| : ${gl_cv_have_raw_decl_memmem=yes}
| : ${gl_cv_have_raw_decl_memrchr=yes}
| : ${gl_cv_have_raw_decl_rawmemchr=yes}
| : ${gl_cv_have_raw_decl_stpcpy=yes}
| : ${gl_cv_have_raw_decl_stpncpy=yes}
| : ${gl_cv_have_raw_decl_strcasestr=yes}
| : ${gl_cv_have_raw_decl_strdup=yes}
| : ${gl_cv_have_raw_decl_strncat=yes}
| : ${gl_cv_have_raw_decl_strndup=yes}
| : ${gl_cv_have_raw_decl_strnlen=yes}
| : ${gl_cv_have_raw_decl_strpbrk=yes}
| : ${gl_cv_have_raw_decl_strsep=yes}
| : ${gl_cv_have_raw_decl_strsignal=yes}
| : ${gl_cv_have_raw_decl_strtok_r=yes}
| : ${gl_cv_have_raw_decl_strverscmp=no}
| 
| # Type
| : ${ac_cv_c_int16_t=yes}
| : ${ac_cv_c_int32_t=yes}
| : ${ac_cv_c_int64_t=yes}
| : ${ac_cv_c_int8_t=yes}
| : ${ac_cv_c_uint16_t=yes}
| : ${ac_cv_c_uint32_t=yes}
| : ${ac_cv_c_uint64_t=yes}
| : ${ac_cv_c_uint8_t=yes}
| 
| : ${ac_cv_type__Bool=yes}
| : ${ac_cv_type_char=yes}
| : ${ac_cv_type_char_p=yes}
| : ${ac_cv_type_fsblkcnt_t=yes}
| : ${ac_cv_type_fsfilcnt_t=yes}
| : ${ac_cv_type_in_addr_t=yes}
| : ${ac_cv_type_in_port_t=yes}
| : ${ac_cv_type_int16_t=yes}
| : ${ac_cv_type_int32_t=yes}
| : ${ac_cv_type_int=yes}
| : ${ac_cv_type_intmax_t=yes}
| : ${ac_cv_type_long=yes}
| : ${ac_cv_type_long_double=yes}
| : ${ac_cv_type_long_long=yes}
| : ${ac_cv_type_long_long_int=yes}
| : ${ac_cv_type_mbstate_t=yes}
| : ${ac_cv_type_mode_t=yes}
| : ${ac_cv_type_nlink_t=yes}
| : ${ac_cv_type_off_t=yes}
| : ${ac_cv_type_pid_t=yes}
| : ${ac_cv_type_posix_spawn_file_actions_t=yes}
| : ${ac_cv_type_posix_spawnattr_t=yes}
| : ${ac_cv_type_ptrdiff_t=yes}
| : ${ac_cv_type_short=yes}
| : ${ac_cv_type_sig_atomic_t=yes}
| : ${ac_cv_type_sigset_t=yes}
| : ${ac_cv_type_size_t=yes}
| : ${ac_cv_type_socklen_t=yes}
| : ${ac_cv_type_ssize_t=yes}
| : ${ac_cv_type_stack_t=yes}
| : ${ac_cv_type_struct_timespec=yes}
| : ${ac_cv_type_u_char=yes}
| : ${ac_cv_type_u_int16_t=yes}
| : ${ac_cv_type_u_int32_t=yes}
| : ${ac_cv_type_u_int8_t=yes}
| : ${ac_cv_type_u_int=yes}
| : ${ac_cv_type_u_long=yes}
| : ${ac_cv_type_u_short=yes}
| : ${ac_cv_type_uid_t=yes}
| : ${ac_cv_type_uintptr_t=yes}
| : ${ac_cv_type_unsigned_char=yes}
| : ${ac_cv_type_unsigned_int=yes}
| : ${ac_cv_type_unsigned_long=yes}
| : ${ac_cv_type_unsigned_long_long=yes}
| : ${ac_cv_type_unsigned_long_long_int=yes}
| : ${ac_cv_type_unsigned_short=yes}
| : ${ac_cv_type_volatile_sig_atomic_t=yes}
| : ${ac_cv_type_wchar_t=yes}
| : ${ac_cv_type_wint_t=yes}
| 
| : ${gl_cv_sigaltstack_low_base=yes}
| : ${gl_cv_size_max=yes}
| : ${gl_cv_type_sigset_t=yes}
| : ${gl_cv_type_wchar_t_signed=yes}
| : ${gl_cv_type_wctrans_t=yes}
| : ${gl_cv_type_wctype_t=yes}
| : ${gl_cv_type_wint_t_signed=yes}
| : ${gl_cv_var_stdin_large_offset=yes}
| : ${gt_cv_c_intmax_t=yes}
| : ${gt_cv_c_wchar_t=yes}
| : ${gt_cv_c_wint_t=yes}
| : ${gt_cv_func_printf_posix=yes}
| : ${gt_cv_int_divbyzero_sigfpe=yes}
| : ${gt_cv_siginfo_t=yes}
| : ${gt_cv_ssize_t=yes}
| 
| # lib
| : ${ac_cv_lib_crypt_crypt=yes}
| : ${ac_cv_lib_edit_el_init=yes}
| : ${ac_cv_lib_pam_pam_set_item=yes}
| : ${ac_cv_lib_z_deflate=yes}
| : ${ac_cv_libc_defines___progname=yes}
| : ${ac_cv_libc_defines_sys_errlist=yes}
| : ${ac_cv_libc_defines_sys_nerr=yes}
| 
| # Struct
| : ${ac_cv_member_HEADER_ad=yes}
| : ${ac_cv_member_struct___res_state_retrans=yes}
| : ${ac_cv_member_struct_sigaction_sa_sigaction=yes}
| : ${ac_cv_member_struct_sockaddr_in6_sin6_scope_id=yes}
| : ${ac_cv_member_struct_stat_st_blksize=yes}
| 
| : ${gl_cv_sys_struct_timespec_in_time_h=yes}
| : ${gl_cv_sys_struct_timeval=yes}
| 
| # Has appearred in FreeBSD 10
| #: ${ac_cv_func_waitid=yes}
| # Has appearred in FreeBSD 10
| #: ${ac_cv_func_strchrnul=yes}
| # Has appearred in FreeBSD 9
| #: ${ac_cv_func_uselocale=yes}
| #: ${ac_cv_func_newlocale=yes}
| 
| # Functions
| : ${ac_cv_func___b64_ntop=yes}
| : ${ac_cv_func___b64_pton=yes}
| : ${ac_cv_func__getlong=yes}
| : ${ac_cv_func__getshort=yes}
| : ${ac_cv_func__getshort=yes}
| : ${ac_cv_func__stat=yes}
| : ${ac_cv_func_acl_create_entry_np=yes}
| : ${ac_cv_func_acl_delete_def_file=yes}
| : ${ac_cv_func_acl_delete_fd_np=yes}
| : ${ac_cv_func_acl_delete_file_np=yes}
| : ${ac_cv_func_acl_free=yes}
| : ${ac_cv_func_acl_from_text=yes}
| : ${ac_cv_func_acl_get_fd=yes}
| : ${ac_cv_func_acl_get_file=yes}
| : ${ac_cv_func_acl_set_fd=yes}
| : ${ac_cv_func_acl_set_file=yes}
| : ${ac_cv_func_alarm=yes}
| : ${ac_cv_func_alloca=yes}
| : ${ac_cv_func_arc4random=yes}
| : ${ac_cv_func_arc4random_buf=yes}
| : ${ac_cv_func_arc4random_uniform=yes}
| : ${ac_cv_func_asprintf=yes}
| : ${ac_cv_func_atexit=yes}
| : ${ac_cv_func_bcmp=yes}
| : ${ac_cv_func_bcopy=yes}
| : ${ac_cv_func_bindresvport_sa=yes}
| : ${ac_cv_func_btowc=yes}
| : ${ac_cv_func_bzero=yes}
| : ${ac_cv_func_chown=yes}
| : ${ac_cv_func_clock=yes}
| : ${ac_cv_func_clock_gettime=yes}
| : ${ac_cv_func_closedir=yes}
| : ${ac_cv_func_closefrom=yes}
| : ${ac_cv_func_daemon=yes}
| : ${ac_cv_func_dirname=yes}
| : ${ac_cv_func_dlopen=yes}
| : ${ac_cv_func_dup2=yes}
| : ${ac_cv_func_eaccess=yes}
| : ${ac_cv_func_fchmod=yes}
| : ${ac_cv_func_fchown=yes}
| : ${ac_cv_func_fcntl=yes}
| : ${ac_cv_func_fileno=yes}
| : ${ac_cv_func_fork=yes}
| : ${ac_cv_func_fpurge=yes}
| : ${ac_cv_func_freeaddrinfo=yes}
| : ${ac_cv_func_fstatvfs=yes}
| : ${ac_cv_func_fsync=yes}
| : ${ac_cv_func_futimes=yes}
| : ${ac_cv_func_fwprintf=yes}
| : ${ac_cv_func_gai_strerror=yes}
| : ${ac_cv_func_getaddrinfo=yes}
| : ${ac_cv_func_getcwd=yes}
| : ${ac_cv_func_getdelim=yes}
| : ${ac_cv_func_getdtablesize=yes}
| : ${ac_cv_func_getegid=yes}
| : ${ac_cv_func_geteuid=yes}
| : ${ac_cv_func_getgid=yes}
| : ${ac_cv_func_getgrouplist=yes}
| : ${ac_cv_func_gethostbyname=yes}
| : ${ac_cv_func_gethostname=yes}
| : ${ac_cv_func_getline=yes}
| : ${ac_cv_func_getnameinfo=yes}
| : ${ac_cv_func_getopt=yes}
| : ${ac_cv_func_getopt_long_only=yes}
| : ${ac_cv_func_getpagesize=yes}
| : ${ac_cv_func_getpeereid=yes}
| : ${ac_cv_func_getpgid=yes}
| : ${ac_cv_func_getpgrp=yes}
| : ${ac_cv_func_getpgrp_void=yes}
| : ${ac_cv_func_getpid=yes}
| : ${ac_cv_func_getrlimit=yes}
| : ${ac_cv_func_getrusage=yes}
| : ${ac_cv_func_gettimeofday=yes}
| : ${ac_cv_func_getttyent=yes}
| : ${ac_cv_func_getuid=yes}
| : ${ac_cv_func_getwd=yes}
| : ${ac_cv_func_glob=yes}
| : ${ac_cv_func_group_from_gid=yes}
| : ${ac_cv_func_inet_aton=yes}
| : ${ac_cv_func_inet_ntoa=yes}
| : ${ac_cv_func_inet_ntop=yes}
| : ${ac_cv_func_innetgr=yes}
| : ${ac_cv_func_isascii=yes}
| : ${ac_cv_func_isascii=yes}
| : ${ac_cv_func_isblank=yes}
| : ${ac_cv_func_issetugid=yes}
| : ${ac_cv_func_iswblank=yes}
| : ${ac_cv_func_iswcntrl=yes}
| : ${ac_cv_func_iswctype=yes}
| : ${ac_cv_func_link=yes}
| : ${ac_cv_func_localtime=yes}
| : ${ac_cv_func_lstat=yes}
| : ${ac_cv_func_lstat_dereferences_slashed_symlink=yes}
| : ${ac_cv_func_malloc_0_nonnull=yes}
| : ${ac_cv_func_mbrlen=yes}
| : ${ac_cv_func_mbrtowc=yes}
| : ${ac_cv_func_mbsinit=yes}
| : ${ac_cv_func_mbsrtowcs=yes}
| : ${ac_cv_func_memchr=yes}
| : ${ac_cv_func_memcmp=yes}
| : ${ac_cv_func_memcpy=yes}
| : ${ac_cv_func_memmove=yes}
| : ${ac_cv_func_memset=yes}
| : ${ac_cv_func_mkdtemp=yes}
| : ${ac_cv_func_mkstemp=yes}
| : ${ac_cv_func_mktemp=yes}
| : ${ac_cv_func_mlock=yes}
| : ${ac_cv_func_mmap=yes}
| : ${ac_cv_func_mmap_fixed_mapped=yes}
| : ${ac_cv_func_mprotect=yes}
| : ${ac_cv_func_munlock=yes}
| : ${ac_cv_func_munmap=yes}
| : ${ac_cv_func_nl_langinfo=yes}
| : ${ac_cv_func_opendir=yes}
| : ${ac_cv_func_pam_getenvlist=yes}
| : ${ac_cv_func_pam_putenv=yes}
| : ${ac_cv_func_pathconf=yes}
| : ${ac_cv_func_pipe=yes}
| : ${ac_cv_func_poll=yes}
| : ${ac_cv_func_posix_spawn=yes}
| : ${ac_cv_func_pread=yes}
| : ${ac_cv_func_pthread_cond_broadcast=yes}
| : ${ac_cv_func_pthread_cond_destroy=yes}
| : ${ac_cv_func_pthread_cond_init=yes}
| : ${ac_cv_func_pthread_cond_signal=yes}
| : ${ac_cv_func_pthread_cond_timedwait=yes}
| : ${ac_cv_func_pthread_cond_wait=yes}
| : ${ac_cv_func_pthread_equal=yes}
| : ${ac_cv_func_pthread_exit=yes}
| : ${ac_cv_func_pthread_mutex_destroy=yes}
| : ${ac_cv_func_pthread_mutex_init=yes}
| : ${ac_cv_func_pthread_mutex_lock=yes}
| : ${ac_cv_func_pthread_mutex_unlock=yes}
| : ${ac_cv_func_pthread_self=yes}
| : ${ac_cv_func_putenv=yes}
| : ${ac_cv_func_pwrite=yes}
| : ${ac_cv_func_raise=yes}
| : ${ac_cv_func_rand=yes}
| : ${ac_cv_func_random=yes}
| : ${ac_cv_func_readdir=yes}
| : ${ac_cv_func_readlink=yes}
| : ${ac_cv_func_readlinkat=yes}
| : ${ac_cv_func_readpassphrase=yes}
| : ${ac_cv_func_realpath=yes}
| : ${ac_cv_func_recvmsg=yes}
| : ${ac_cv_func_rename=yes}
| : ${ac_cv_func_rresvport_af=yes}
| : ${ac_cv_func_sched_yield=yes}
| : ${ac_cv_func_select=yes}
| : ${ac_cv_func_sendmsg=yes}
| : ${ac_cv_func_setegid=yes}
| : ${ac_cv_func_setenv=yes}
| : ${ac_cv_func_seteuid=yes}
| : ${ac_cv_func_setgroupent=yes}
| : ${ac_cv_func_setgroups=yes}
| : ${ac_cv_func_setlinebuf=yes}
| : ${ac_cv_func_setlocale=yes}
| : ${ac_cv_func_setlogin=yes}
| : ${ac_cv_func_setpassent=yes}
| : ${ac_cv_func_setproctitle=yes}
| : ${ac_cv_func_setregid=yes}
| : ${ac_cv_func_setresgid=yes}
| : ${ac_cv_func_setresuid=yes}
| : ${ac_cv_func_setreuid=yes}
| : ${ac_cv_func_setrlimit=yes}
| : ${ac_cv_func_setsid=yes}
| : ${ac_cv_func_setsockopt=yes}
| : ${ac_cv_func_setvbuf=yes}
| : ${ac_cv_func_shmget=yes}
| : ${ac_cv_func_sigaction=yes}
| : ${ac_cv_func_sigaltstack=yes}
| : ${ac_cv_func_siginterrupt=yes}
| : ${ac_cv_func_sigprocmask=yes}
| : ${ac_cv_func_sigvec=yes}
| : ${ac_cv_func_sleep=yes}
| : ${ac_cv_func_snprintf=yes}
| : ${ac_cv_func_socketpair=yes}
| : ${ac_cv_func_srand=yes}
| : ${ac_cv_func_srandom=yes}
| : ${ac_cv_func_stat=yes}
| : ${ac_cv_func_statfs=yes}
| : ${ac_cv_func_statvfs=yes}
| : ${ac_cv_func_stpcpy=yes}
| : ${ac_cv_func_stpncpy=yes}
| : ${ac_cv_func_strbrk=yes}
| : ${ac_cv_func_strcasecmp=yes}
| : ${ac_cv_func_strcspn=yes}
| : ${ac_cv_func_strdup=yes}
| : ${ac_cv_func_strerror=yes}
| : ${ac_cv_func_strerror_r=yes}
| : ${ac_cv_func_strftime=yes}
| : ${ac_cv_func_strlcat=yes}
| : ${ac_cv_func_strlcpy=yes}
| : ${ac_cv_func_strlen=yes}
| : ${ac_cv_func_strmode=yes}
| : ${ac_cv_func_strncasecmp=yes}
| : ${ac_cv_func_strndup=yes}
| : ${ac_cv_func_strnlen=yes}
| : ${ac_cv_func_strnlen_working=yes}
| : ${ac_cv_func_strpbrk=yes}
| : ${ac_cv_func_strptime=yes}
| : ${ac_cv_func_strsep=yes}
| : ${ac_cv_func_strsignal=yes}
| : ${ac_cv_func_strtol=yes}
| : ${ac_cv_func_strtoll=yes}
| : ${ac_cv_func_strtonum=yes}
| : ${ac_cv_func_strtoul=yes}
| : ${ac_cv_func_strtoull=yes}
| : ${ac_cv_func_symlink=yes}
| : ${ac_cv_func_sysconf=yes}
| : ${ac_cv_func_tcgetpgrp=yes}
| : ${ac_cv_func_time=yes}
| : ${ac_cv_func_towlower=yes}
| : ${ac_cv_func_truncate=yes}
| : ${ac_cv_func_tsearch=yes}
| : ${ac_cv_func_uname=yes}
| : ${ac_cv_func_unsetenv=yes}
| : ${ac_cv_func_user_from_uid=yes}
| : ${ac_cv_func_usleep=yes}
| : ${ac_cv_func_utime=yes}
| : ${ac_cv_func_utimes=yes}
| : ${ac_cv_func_vasprintf=yes}
| : ${ac_cv_func_vfork=yes}
| : ${ac_cv_func_vprintf=yes}
| : ${ac_cv_func_vsnprintf=yes}
| : ${ac_cv_func_vsprintf=yes}
| : ${ac_cv_func_waitpid=yes}
| : ${ac_cv_func_wcrtomb=yes}
| : ${ac_cv_func_wcscoll=yes}
| : ${ac_cv_func_wcslen=yes}
| : ${ac_cv_func_wcsnlen=yes}
| : ${ac_cv_func_wctob=yes}
| : ${ac_cv_func_wcwidth=yes}
| : ${ac_cv_func_wmemchr=yes}
| : ${ac_cv_func_wmemcpy=yes}
| : ${ac_cv_func_yp_match=yes}
| 
| # non existing functions
| : ${ac_cv_func_argz_count=no}
| : ${ac_cv_func_argz_next=no}
| : ${ac_cv_func_argz_stringify=no}
| : ${ac_cv_func_obstacks=no}
| : ${ac_cv_func_pstat_getdynamic=no}
| : ${ac_cv_func_rawmemchr=no}
| : ${ac_cv_func_yield=no}
| 
| : ${ac_cv_have___va_copy=yes}
| : ${ac_cv_have_clock_t=yes}
| : ${ac_cv_have_control_in_msghdr=yes}
| : ${ac_cv_have_getopt_optreset=yes}
| : ${ac_cv_have_int64_t=yes}
| : ${ac_cv_have_intxx_t=yes}
| : ${ac_cv_have_mode_t=yes}
| : ${ac_cv_have_pid_t=yes}
| : ${ac_cv_have_pw_change_in_struct_passwd=yes}
| : ${ac_cv_have_pw_class_in_struct_passwd=yes}
| : ${ac_cv_have_pw_expire_in_struct_passwd=yes}
| : ${ac_cv_have_sa_family_t=yes}
| : ${ac_cv_have_size_t=yes}
| : ${ac_cv_have_ss_family_in_struct_ss=yes}
| : ${ac_cv_have_ssize_t=yes}
| : ${ac_cv_have_struct_addrinfo=yes}
| : ${ac_cv_have_struct_in6_addr=yes}
| : ${ac_cv_have_struct_sockaddr_in6=yes}
| : ${ac_cv_have_struct_sockaddr_storage=yes}
| : ${ac_cv_have_struct_timeval=yes}
| : ${ac_cv_have_u_char=yes}
| : ${ac_cv_have_u_int64_t=yes}
| : ${ac_cv_have_u_int=yes}
| : ${ac_cv_have_u_intxx_t=yes}
| : ${ac_cv_have_va_copy=yes}
| 
| : ${ac_cv_have_decl_GLOB_NOMATCH=yes}
| : ${ac_cv_have_decl_LLONG_MAX=yes}
| : ${ac_cv_have_decl_MAXSYMLINKS=yes}
| : ${ac_cv_have_decl_O_NONBLOCK=yes}
| : ${ac_cv_have_decl_RLIMIT_NPROC=yes}
| : ${ac_cv_have_decl_SHUT_RD=yes}
| : ${ac_cv_have_decl__Exit=yes}
| : ${ac_cv_have_decl_alarm=yes}
| : ${ac_cv_have_decl_alphasort=yes}
| : ${ac_cv_have_decl_atoll=yes}
| : ${ac_cv_have_decl_btowc=yes}
| : ${ac_cv_have_decl_chdir=yes}
| : ${ac_cv_have_decl_chown=yes}
| : ${ac_cv_have_decl_clearerr_unlocked=yes}
| : ${ac_cv_have_decl_closedir=yes}
| : ${ac_cv_have_decl_dprintf=yes}
| : ${ac_cv_have_decl_dup2=yes}
| : ${ac_cv_have_decl_dup=yes}
| : ${ac_cv_have_decl_endusershell=yes}
| : ${ac_cv_have_decl_faccessat=yes}
| : ${ac_cv_have_decl_fchdir=yes}
| : ${ac_cv_have_decl_fchmodat=yes}
| : ${ac_cv_have_decl_fchownat=yes}
| : ${ac_cv_have_decl_fcntl=yes}
| : ${ac_cv_have_decl_fdopendir=yes}
| : ${ac_cv_have_decl_feof_unlocked=yes}
| : ${ac_cv_have_decl_feof_unlocked_fgets_unlocked=yes}
| : ${ac_cv_have_decl_ferror_unlocked=yes}
| : ${ac_cv_have_decl_ffsl=yes}
| : ${ac_cv_have_decl_ffsll=yes}
| : ${ac_cv_have_decl_fpurge=yes}
| : ${ac_cv_have_decl_frexpl=yes}
| : ${ac_cv_have_decl_fseeko=yes}
| : ${ac_cv_have_decl_fstat=yes}
| : ${ac_cv_have_decl_fstatat=yes}
| : ${ac_cv_have_decl_fsync=yes}
| : ${ac_cv_have_decl_ftello=yes}
| : ${ac_cv_have_decl_ftruncate=yes}
| : ${ac_cv_have_decl_getc_unlocked=yes}
| : ${ac_cv_have_decl_getchar_unlocked=yes}
| : ${ac_cv_have_decl_getcwd=yes}
| : ${ac_cv_have_decl_getdelim=yes}
| : ${ac_cv_have_decl_getdomainname=yes}
| : ${ac_cv_have_decl_getdtablesize=yes}
| : ${ac_cv_have_decl_getenv=yes}
| : ${ac_cv_have_decl_getgroups=yes}
| : ${ac_cv_have_decl_gethostname=yes}
| : ${ac_cv_have_decl_getline=yes}
| : ${ac_cv_have_decl_getloadavg=yes}
| : ${ac_cv_have_decl_getlogin=yes}
| : ${ac_cv_have_decl_getlogin_r=yes}
| : ${ac_cv_have_decl_getpagesize=yes}
| : ${ac_cv_have_decl_gets=yes}
| : ${ac_cv_have_decl_getsubopt=yes}
| : ${ac_cv_have_decl_gettimeofday=yes}
| : ${ac_cv_have_decl_getusershell=yes}
| : ${ac_cv_have_decl_grantpt=yes}
| : ${ac_cv_have_decl_h_errno=yes}
| : ${ac_cv_have_decl_imaxabs=yes}
| : ${ac_cv_have_decl_imaxdiv=yes}
| : ${ac_cv_have_decl_initstate=yes}
| : ${ac_cv_have_decl_isatty=yes}
| : ${ac_cv_have_decl_isblank=yes}
| : ${ac_cv_have_decl_iswblank=yes}
| : ${ac_cv_have_decl_iswctype=yes}
| : ${ac_cv_have_decl_lchmod=yes}
| : ${ac_cv_have_decl_lchown=yes}
| : ${ac_cv_have_decl_link=yes}
| : ${ac_cv_have_decl_linkat=yes}
| : ${ac_cv_have_decl_lseek=yes}
| : ${ac_cv_have_decl_lstat=yes}
| : ${ac_cv_have_decl_mbrlen=yes}
| : ${ac_cv_have_decl_mbrtowc=yes}
| : ${ac_cv_have_decl_mbsinit=yes}
| : ${ac_cv_have_decl_mbsnrtowcs=yes}
| : ${ac_cv_have_decl_mbsrtowcs=yes}
| : ${ac_cv_have_decl_memmem=yes}
| : ${ac_cv_have_decl_memrchr=yes}
| : ${ac_cv_have_decl_mkdirat=yes}
| : ${ac_cv_have_decl_mkdtemp=yes}
| : ${ac_cv_have_decl_mkfifo=yes}
| : ${ac_cv_have_decl_mkfifoat=yes}
| : ${ac_cv_have_decl_mknod=yes}
| : ${ac_cv_have_decl_mknodat=yes}
| : ${ac_cv_have_decl_mkstemp=yes}
| : ${ac_cv_have_decl_nl_langinfo=yes}
| : ${ac_cv_have_decl_offsetof=yes}
| : ${ac_cv_have_decl_openat=yes}
| : ${ac_cv_have_decl_opendir=yes}
| : ${ac_cv_have_decl_pclose=yes}
| : ${ac_cv_have_decl_pipe=yes}
| : ${ac_cv_have_decl_popen=yes}
| : ${ac_cv_have_decl_posix_openpt=yes}
| : ${ac_cv_have_decl_posix_spawn=yes}
| : ${ac_cv_have_decl_posix_spawn_file_actions_addclose=yes}
| : ${ac_cv_have_decl_posix_spawn_file_actions_adddup2=yes}
| : ${ac_cv_have_decl_posix_spawn_file_actions_addopen=yes}
| : ${ac_cv_have_decl_posix_spawn_file_actions_destroy=yes}
| : ${ac_cv_have_decl_posix_spawn_file_actions_init=yes}
| : ${ac_cv_have_decl_posix_spawnattr_destroy=yes}
| : ${ac_cv_have_decl_posix_spawnattr_getflags=yes}
| : ${ac_cv_have_decl_posix_spawnattr_getpgroup=yes}
| : ${ac_cv_have_decl_posix_spawnattr_getschedparam=yes}
| : ${ac_cv_have_decl_posix_spawnattr_getschedpolicy=yes}
| : ${ac_cv_have_decl_posix_spawnattr_getsigdefault=yes}
| : ${ac_cv_have_decl_posix_spawnattr_getsigmask=yes}
| : ${ac_cv_have_decl_posix_spawnattr_init=yes}
| : ${ac_cv_have_decl_posix_spawnattr_setflags=yes}
| : ${ac_cv_have_decl_posix_spawnattr_setpgroup=yes}
| : ${ac_cv_have_decl_posix_spawnattr_setschedparam=yes}
| : ${ac_cv_have_decl_posix_spawnattr_setschedpolicy=yes}
| : ${ac_cv_have_decl_posix_spawnattr_setsigdefault=yes}
| : ${ac_cv_have_decl_posix_spawnattr_setsigmask=yes}
| : ${ac_cv_have_decl_posix_spawnp=yes}
| : ${ac_cv_have_decl_pread=yes}
| : ${ac_cv_have_decl_pselect=yes}
| : ${ac_cv_have_decl_pthread_sigmask=yes}
| : ${ac_cv_have_decl_ptsname=yes}
| : ${ac_cv_have_decl_putc_unlocked=yes}
| : ${ac_cv_have_decl_putchar_unlocked=yes}
| : ${ac_cv_have_decl_pwrite=yes}
| : ${ac_cv_have_decl_random=yes}
| : ${ac_cv_have_decl_rawmemchr=yes}
| : ${ac_cv_have_decl_readdir=yes}
| : ${ac_cv_have_decl_readlink=yes}
| : ${ac_cv_have_decl_readlinkat=yes}
| : ${ac_cv_have_decl_realpath=yes}
| : ${ac_cv_have_decl_renameat=yes}
| : ${ac_cv_have_decl_rewinddir=yes}
| : ${ac_cv_have_decl_rmdir=yes}
| : ${ac_cv_have_decl_rpmatch=yes}
| : ${ac_cv_have_decl_scandir=yes}
| : ${ac_cv_have_decl_select=yes}
| : ${ac_cv_have_decl_setenv=yes}
| : ${ac_cv_have_decl_sethostname=yes}
| : ${ac_cv_have_decl_setlocale=yes}
| : ${ac_cv_have_decl_setstate=yes}
| : ${ac_cv_have_decl_setusershell=yes}
| : ${ac_cv_have_decl_sigaction=yes}
| : ${ac_cv_have_decl_sigaddset=yes}
| : ${ac_cv_have_decl_sigaltstack=yes}
| : ${ac_cv_have_decl_sigdelset=yes}
| : ${ac_cv_have_decl_sigemptyset=yes}
| : ${ac_cv_have_decl_sigfillset=yes}
| : ${ac_cv_have_decl_sigismember=yes}
| : ${ac_cv_have_decl_sigpending=yes}
| : ${ac_cv_have_decl_sigprocmask=yes}
| : ${ac_cv_have_decl_sleep=yes}
| : ${ac_cv_have_decl_snprintf=yes}
| : ${ac_cv_have_decl_srandom=yes}
| : ${ac_cv_have_decl_stat=yes}
| : ${ac_cv_have_decl_stpcpy=yes}
| : ${ac_cv_have_decl_stpncpy=yes}
| : ${ac_cv_have_decl_strcasestr=yes}
| : ${ac_cv_have_decl_strdup=yes}
| : ${ac_cv_have_decl_strerror_r=yes}
| : ${ac_cv_have_decl_strncat=yes}
| : ${ac_cv_have_decl_strndup=yes}
| : ${ac_cv_have_decl_strnlen=yes}
| : ${ac_cv_have_decl_strpbrk=yes}
| : ${ac_cv_have_decl_strsep=yes}
| : ${ac_cv_have_decl_strsignal=yes}
| : ${ac_cv_have_decl_strtod=yes}
| : ${ac_cv_have_decl_strtoimax=yes}
| : ${ac_cv_have_decl_strtok_r=yes}
| : ${ac_cv_have_decl_strtoll=yes}
| : ${ac_cv_have_decl_strtoull=yes}
| : ${ac_cv_have_decl_strtoumax=yes}
| : ${ac_cv_have_decl_symlink=yes}
| : ${ac_cv_have_decl_symlinkat=yes}
| : ${ac_cv_have_decl_sys_siglist=yes}
| : ${ac_cv_have_decl_tcsendbreak=yes}
| : ${ac_cv_have_decl_tmpfile=yes}
| : ${ac_cv_have_decl_towctrans=yes}
| : ${ac_cv_have_decl_ttyname_r=yes}
| : ${ac_cv_have_decl_unlink=yes}
| : ${ac_cv_have_decl_unlinkat=yes}
| : ${ac_cv_have_decl_unlockpt=yes}
| : ${ac_cv_have_decl_unsetenv=yes}
| : ${ac_cv_have_decl_usleep=yes}
| : ${ac_cv_have_decl_vdprintf=yes}
| : ${ac_cv_have_decl_vsnprintf=yes}
| : ${ac_cv_have_decl_waitpid=yes}
| : ${ac_cv_have_decl_wcpcpy=yes}
| : ${ac_cv_have_decl_wcpncpy=yes}
| : ${ac_cv_have_decl_wcrtomb=yes}
| : ${ac_cv_have_decl_wcscasecmp=yes}
| : ${ac_cv_have_decl_wcscat=yes}
| : ${ac_cv_have_decl_wcschr=yes}
| : ${ac_cv_have_decl_wcscmp=yes}
| : ${ac_cv_have_decl_wcscoll=yes}
| : ${ac_cv_have_decl_wcscpy=yes}
| : ${ac_cv_have_decl_wcscspn=yes}
| : ${ac_cv_have_decl_wcsdup=yes}
| : ${ac_cv_have_decl_wcslen=yes}
| : ${ac_cv_have_decl_wcsncasecmp=yes}
| : ${ac_cv_have_decl_wcsncat=yes}
| : ${ac_cv_have_decl_wcsncmp=yes}
| : ${ac_cv_have_decl_wcsncpy=yes}
| : ${ac_cv_have_decl_wcsnlen=yes}
| : ${ac_cv_have_decl_wcsnrtombs=yes}
| : ${ac_cv_have_decl_wcspbrk=yes}
| : ${ac_cv_have_decl_wcsrchr=yes}
| : ${ac_cv_have_decl_wcsrtombs=yes}
| : ${ac_cv_have_decl_wcsspn=yes}
| : ${ac_cv_have_decl_wcsstr=yes}
| : ${ac_cv_have_decl_wcstok=yes}
| : ${ac_cv_have_decl_wcswidth=yes}
| : ${ac_cv_have_decl_wcsxfrm=yes}
| : ${ac_cv_have_decl_wctob=yes}
| : ${ac_cv_have_decl_wctrans=yes}
| : ${ac_cv_have_decl_wctype=yes}
| : ${ac_cv_have_decl_wcwidth=yes}
| : ${ac_cv_have_decl_wmemchr=yes}
| : ${ac_cv_have_decl_wmemcmp=yes}
| : ${ac_cv_have_decl_wmemcpy=yes}
| : ${ac_cv_have_decl_wmemmove=yes}
| : ${ac_cv_have_decl_wmemset=yes}
| : ${ac_cv_have_decl_writev=yes}
| 
| # function specific
| 
| : ${gl_cv_func_btowc_eof=yes}
| : ${gl_cv_func_btowc_nul=yes}
| : ${gl_cv_func_fcntl_f_dupfd_cloexec=yes}
| : ${gl_cv_func_fnmatch_posix=yes}
| : ${gl_cv_func_fopen_slash=yes}
| : ${gl_cv_func_frexp_no_libm=yes}
| : ${gl_cv_func_fseeko=yes}
| : ${gl_cv_func_ftello=yes}
| : ${gl_cv_func_getcwd_null=yes}
| : ${gl_cv_func_getcwd_posix_signature=yes}
| : ${gl_cv_func_getopt_posix=yes}
| : ${gl_cv_func_isnand_no_libm=yes}
| : ${gl_cv_func_ldexp_no_libm=yes}
| : ${gl_cv_func_lseek_pipe=yes}
| : ${gl_cv_func_lstat_dereferences_slashed_symlink=yes}
| : ${gl_cv_func_malloc_0_nonnull=1}
| : ${gl_cv_func_malloc_posix=yes}
| : ${gl_cv_func_mbrtowc_incomplete_state=yes}
| : ${gl_cv_func_mbrtowc_nul_retval=yes}
| : ${gl_cv_func_mbrtowc_null_arg1=yes}
| : ${gl_cv_func_mbrtowc_null_arg2=yes}
| : ${gl_cv_func_mbrtowc_retval=yes}
| : ${gl_cv_func_mbrtowc_sanitycheck=yes}
| : ${gl_cv_func_open_slash=yes}
| : ${gl_cv_func_printf_directive_a=yes}
| : ${gl_cv_func_printf_directive_f=yes}
| : ${gl_cv_func_printf_directive_ls=yes}
| : ${gl_cv_func_printf_directive_n=yes}
| : ${gl_cv_func_printf_flag_grouping=yes}
| : ${gl_cv_func_printf_flag_leftadjust=yes}
| : ${gl_cv_func_printf_flag_zero=yes}
| : ${gl_cv_func_printf_infinite=yes}
| : ${gl_cv_func_printf_long_double=yes}
| : ${gl_cv_func_printf_positions=yes}
| : ${gl_cv_func_printf_precision=yes}
| : ${gl_cv_func_printf_sizes_c99=yes}
| : ${gl_cv_func_sigprocmask=1}
| : ${gl_cv_func_snprintf_retval_c99=yes}
| : ${gl_cv_func_snprintf_size1=yes}
| : ${gl_cv_func_snprintf_usable=yes}
| : ${gl_cv_func_spawnattr_setschedparam=yes}
| : ${gl_cv_func_spawnattr_setschedpolicy=yes}
| : ${gl_cv_func_stat_dir_slash=yes}
| : ${gl_cv_func_stat_file_slash=yes}
| : ${gl_cv_func_stpncpy=yes}
| : ${gl_cv_func_va_copy=yes}
| : ${gl_cv_func_wcrtomb_retval=yes}
| : ${gt_cv_func_unsetenv_ret=int}
| 
| : ${gl_cv_have_include_next=yes}
| 
| : ${gl_cv_have_raw_decl_rawmemchr=yes}
| : ${gl_cv_have_raw_decl__Exit=yes}
| : ${gl_cv_have_raw_decl_alphasort=yes}
| : ${gl_cv_have_raw_decl_atoll=yes}
| : ${gl_cv_have_raw_decl_btowc=yes}
| : ${gl_cv_have_raw_decl_chdir=yes}
| : ${gl_cv_have_raw_decl_chown=yes}
| : ${gl_cv_have_raw_decl_closedir=yes}
| : ${gl_cv_have_raw_decl_dprintf=yes}
| : ${gl_cv_have_raw_decl_dup2=yes}
| : ${gl_cv_have_raw_decl_dup=yes}
| : ${gl_cv_have_raw_decl_endusershell=yes}
| : ${gl_cv_have_raw_decl_faccessat=yes}
| : ${gl_cv_have_raw_decl_fchdir=yes}
| : ${gl_cv_have_raw_decl_fchmodat=yes}
| : ${gl_cv_have_raw_decl_fchownat=yes}
| : ${gl_cv_have_raw_decl_fcntl=yes}
| : ${gl_cv_have_raw_decl_fdopendir=yes}
| : ${gl_cv_have_raw_decl_ffsl=yes}
| : ${gl_cv_have_raw_decl_ffsll=yes}
| : ${gl_cv_have_raw_decl_fpurge=yes}
| : ${gl_cv_have_raw_decl_fseeko=yes}
| : ${gl_cv_have_raw_decl_fstat=yes}
| : ${gl_cv_have_raw_decl_fstatat=yes}
| : ${gl_cv_have_raw_decl_fsync=yes}
| : ${gl_cv_have_raw_decl_ftello=yes}
| : ${gl_cv_have_raw_decl_ftruncate=yes}
| : ${gl_cv_have_raw_decl_getcwd=yes}
| : ${gl_cv_have_raw_decl_getdelim=yes}
| : ${gl_cv_have_raw_decl_getdomainname=yes}
| : ${gl_cv_have_raw_decl_getdtablesize=yes}
| : ${gl_cv_have_raw_decl_getgroups=yes}
| : ${gl_cv_have_raw_decl_getdtablesize=yes}
| : ${gl_cv_have_raw_decl_getgroups=yes}
| : ${gl_cv_have_raw_decl_gethostname=yes}
| : ${gl_cv_have_raw_decl_getline=yes}
| : ${gl_cv_have_raw_decl_getloadavg=yes}
| : ${gl_cv_have_raw_decl_getlogin=yes}
| : ${gl_cv_have_raw_decl_getlogin_r=yes}
| : ${gl_cv_have_raw_decl_getpagesize=yes}
| : ${gl_cv_have_raw_decl_gets=yes}
| : ${gl_cv_have_raw_decl_getsubopt=yes}
| : ${gl_cv_have_raw_decl_gettimeofday=yes}
| : ${gl_cv_have_raw_decl_getusershell=yes}
| : ${gl_cv_have_raw_decl_grantpt=yes}
| : ${gl_cv_have_raw_decl_imaxabs=yes}
| : ${gl_cv_have_raw_decl_imaxdiv=yes}
| : ${gl_cv_have_raw_decl_initstate=yes}
| : ${gl_cv_have_raw_decl_isatty=yes}
| : ${gl_cv_have_raw_decl_iswctype=yes}
| : ${gl_cv_have_raw_decl_lchmod=yes}
| : ${gl_cv_have_raw_decl_lchown=yes}
| : ${gl_cv_have_raw_decl_link=yes}
| : ${gl_cv_have_raw_decl_linkat=yes}
| : ${gl_cv_have_raw_decl_lseek=yes}
| : ${gl_cv_have_raw_decl_lstat=yes}
| : ${gl_cv_have_raw_decl_mbrlen=yes}
| : ${gl_cv_have_raw_decl_mbrtowc=yes}
| : ${gl_cv_have_raw_decl_mbsinit=yes}
| : ${gl_cv_have_raw_decl_mbsnrtowcs=yes}
| : ${gl_cv_have_raw_decl_mbsrtowcs=yes}
| : ${gl_cv_have_raw_decl_mkdirat=yes}
| : ${gl_cv_have_raw_decl_mkdtemp=yes}
| : ${gl_cv_have_raw_decl_mkfifo=yes}
| : ${gl_cv_have_raw_decl_mkfifoat=yes}
| : ${gl_cv_have_raw_decl_mknod=yes}
| : ${gl_cv_have_raw_decl_mknodat=yes}
| : ${gl_cv_have_raw_decl_mkstemp=yes}
| : ${gl_cv_have_raw_decl_nl_langinfo=yes}
| : ${gl_cv_have_raw_decl_openat=yes}
| : ${gl_cv_have_raw_decl_opendir=yes}
| : ${gl_cv_have_raw_decl_pclose=yes}
| : ${gl_cv_have_raw_decl_pipe=yes}
| : ${gl_cv_have_raw_decl_popen=yes}
| : ${gl_cv_have_raw_decl_posix_openpt=yes}
| : ${gl_cv_have_raw_decl_posix_spawn=yes}
| : ${gl_cv_have_raw_decl_posix_openpt=yes}
| : ${gl_cv_have_raw_decl_posix_spawn=yes}
| : ${gl_cv_have_raw_decl_posix_spawn_file_actions_addclose=yes}
| : ${gl_cv_have_raw_decl_posix_spawn_file_actions_adddup2=yes}
| : ${gl_cv_have_raw_decl_posix_spawn_file_actions_addopen=yes}
| : ${gl_cv_have_raw_decl_posix_spawn_file_actions_destroy=yes}
| : ${gl_cv_have_raw_decl_posix_spawn_file_actions_init=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_destroy=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_getflags=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_getpgroup=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_getschedparam=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_getschedpolicy=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_getsigdefault=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_getsigmask=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_init=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_setflags=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_setpgroup=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_setschedparam=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_setschedpolicy=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_setsigdefault=yes}
| : ${gl_cv_have_raw_decl_posix_spawnattr_setsigmask=yes}
| : ${gl_cv_have_raw_decl_posix_spawnp=yes}
| : ${gl_cv_have_raw_decl_pread=yes}
| : ${gl_cv_have_raw_decl_pselect=yes}
| : ${gl_cv_have_raw_decl_pthread_sigmask=yes}
| : ${gl_cv_have_raw_decl_ptsname=yes}
| : ${gl_cv_have_raw_decl_pwrite=yes}
| : ${gl_cv_have_raw_decl_random=yes}
| : ${gl_cv_have_raw_decl_readdir=yes}
| : ${gl_cv_have_raw_decl_readlink=yes}
| : ${gl_cv_have_raw_decl_readlinkat=yes}
| : ${gl_cv_have_raw_decl_realpath=yes}
| : ${gl_cv_have_raw_decl_renameat=yes}
| : ${gl_cv_have_raw_decl_rewinddir=yes}
| : ${gl_cv_have_raw_decl_rmdir=yes}
| : ${gl_cv_have_raw_decl_rpmatch=yes}
| : ${gl_cv_have_raw_decl_scandir=yes}
| : ${gl_cv_have_raw_decl_select=yes}
| : ${gl_cv_have_raw_decl_setenv=yes}
| : ${gl_cv_have_raw_decl_sethostname=yes}
| : ${gl_cv_have_raw_decl_setlocale=yes}
| : ${gl_cv_have_raw_decl_setstate=yes}
| : ${gl_cv_have_raw_decl_setusershell=yes}
| : ${gl_cv_have_raw_decl_sigaction=yes}
| : ${gl_cv_have_raw_decl_sigaddset=yes}
| : ${gl_cv_have_raw_decl_sigdelset=yes}
| : ${gl_cv_have_raw_decl_sigemptyset=yes}
| : ${gl_cv_have_raw_decl_sigfillset=yes}
| : ${gl_cv_have_raw_decl_sigismember=yes}
| : ${gl_cv_have_raw_decl_sigpending=yes}
| : ${gl_cv_have_raw_decl_sigprocmask=yes}
| : ${gl_cv_have_raw_decl_sleep=yes}
| : ${gl_cv_have_raw_decl_snprintf=yes}
| : ${gl_cv_have_raw_decl_srandom=yes}
| : ${gl_cv_have_raw_decl_stat=yes}
| : ${gl_cv_have_raw_decl_strerror_r=yes}
| : ${gl_cv_have_raw_decl_strtod=yes}
| : ${gl_cv_have_raw_decl_strtoimax=yes}
| : ${gl_cv_have_raw_decl_strtoll=yes}
| : ${gl_cv_have_raw_decl_strtoull=yes}
| : ${gl_cv_have_raw_decl_strtoumax=yes}
| : ${gl_cv_have_raw_decl_symlink=yes}
| : ${gl_cv_have_raw_decl_symlinkat=yes}
| : ${gl_cv_have_raw_decl_tmpfile=yes}
| : ${gl_cv_have_raw_decl_towctrans=yes}
| : ${gl_cv_have_raw_decl_ttyname_r=yes}
| : ${gl_cv_have_raw_decl_unlink=yes}
| : ${gl_cv_have_raw_decl_unlinkat=yes}
| : ${gl_cv_have_raw_decl_unlockpt=yes}
| : ${gl_cv_have_raw_decl_unsetenv=yes}
| : ${gl_cv_have_raw_decl_usleep=yes}
| : ${gl_cv_have_raw_decl_vdprintf=yes}
| : ${gl_cv_have_raw_decl_vsnprintf=yes}
| : ${gl_cv_have_raw_decl_waitpid=yes}
| : ${gl_cv_have_raw_decl_wcpcpy=yes}
| : ${gl_cv_have_raw_decl_wcpncpy=yes}
| : ${gl_cv_have_raw_decl_wcrtomb=yes}
| : ${gl_cv_have_raw_decl_wcscasecmp=yes}
| : ${gl_cv_have_raw_decl_wcscat=yes}
| : ${gl_cv_have_raw_decl_wcschr=yes}
| : ${gl_cv_have_raw_decl_wcscmp=yes}
| : ${gl_cv_have_raw_decl_wcscoll=yes}
| : ${gl_cv_have_raw_decl_wcscpy=yes}
| : ${gl_cv_have_raw_decl_wcscspn=yes}
| : ${gl_cv_have_raw_decl_wcsdup=yes}
| : ${gl_cv_have_raw_decl_wcslen=yes}
| : ${gl_cv_have_raw_decl_wcsncasecmp=yes}
| : ${gl_cv_have_raw_decl_wcsncat=yes}
| : ${gl_cv_have_raw_decl_wcsncmp=yes}
| : ${gl_cv_have_raw_decl_wcsncpy=yes}
| : ${gl_cv_have_raw_decl_wcsnlen=yes}
| : ${gl_cv_have_raw_decl_wcsnrtombs=yes}
| : ${gl_cv_have_raw_decl_wcspbrk=yes}
| : ${gl_cv_have_raw_decl_wcsrchr=yes}
| : ${gl_cv_have_raw_decl_wcsrtombs=yes}
| : ${gl_cv_have_raw_decl_wcsspn=yes}
| : ${gl_cv_have_raw_decl_wcsstr=yes}
| : ${gl_cv_have_raw_decl_wcstok=yes}
| : ${gl_cv_have_raw_decl_wcswidth=yes}
| : ${gl_cv_have_raw_decl_wcsxfrm=yes}
| : ${gl_cv_have_raw_decl_wctob=yes}
| : ${gl_cv_have_raw_decl_wctrans=yes}
| : ${gl_cv_have_raw_decl_wctype=yes}
| : ${gl_cv_have_raw_decl_wcwidth=yes}
| : ${gl_cv_have_raw_decl_wmemchr=yes}
| : ${gl_cv_have_raw_decl_wmemcmp=yes}
| : ${gl_cv_have_raw_decl_wmemcpy=yes}
| : ${gl_cv_have_raw_decl_wmemmove=yes}
| : ${gl_cv_have_raw_decl_wmemset=yes}
| 
| : ${gl_cv_header_errno_h_complete=yes}
| : ${gl_cv_header_inttypes_h=yes}
| : ${gl_cv_header_langinfo_codeset=yes}
| : ${gl_cv_header_langinfo_era=yes}
| : ${gl_cv_header_langinfo_t_fmt_ampm=yes}
| : ${gl_cv_header_langinfo_yesexpr=yes}
| : ${gl_cv_header_locale_h_posix2001=yes}
| : ${gl_cv_header_signal_h_SIGPIPE=yes}
| : ${gl_cv_header_stdint_h=yes}
| : ${gl_cv_header_sys_select_h_selfcontained=yes}
| 
configure:2132: checking for --with-python
configure:2144: result: /usr/local/bin/python2.7
configure:2192: checking Python interpreter
configure:2204: result: /usr/local/bin/python2.7
configure:2208: checking Python version
configure:2236: result: 2.7.11
configure:2240: checking dnspython
configure:2264: error: 

***** dnspython not found. It is required for the new
***** dmarc_moderation_action featurer. Get it from
***** <http://www.dnspython.org/> or
***** <https://pypi.python.org/pypi/dnspython/>

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_c_int16_t=yes
ac_cv_c_int32_t=yes
ac_cv_c_int64_t=yes
ac_cv_c_int8_t=yes
ac_cv_c_uint16_t=yes
ac_cv_c_uint32_t=yes
ac_cv_c_uint64_t=yes
ac_cv_c_uint8_t=yes
ac_cv_env_CC_set=set
ac_cv_env_CC_value=cc
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-O2 -pipe  -fstack-protector -fno-strict-aliasing'
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value=''
ac_cv_env_CPP_set=set
ac_cv_env_CPP_value=cpp
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value=' -fstack-protector'
ac_cv_env_LIBS_set=set
ac_cv_env_LIBS_value=''
ac_cv_env_build_alias_set=set
ac_cv_env_build_alias_value=amd64-portbld-freebsd10.3
ac_cv_env_host_alias_set=''
ac_cv_env_host_alias_value=''
ac_cv_env_target_alias_set=''
ac_cv_env_target_alias_value=''
ac_cv_func___b64_ntop=yes
ac_cv_func___b64_pton=yes
ac_cv_func__getlong=yes
ac_cv_func__getshort=yes
ac_cv_func__stat=yes
ac_cv_func_acl_create_entry_np=yes
ac_cv_func_acl_delete_def_file=yes
ac_cv_func_acl_delete_fd_np=yes
ac_cv_func_acl_delete_file_np=yes
ac_cv_func_acl_free=yes
ac_cv_func_acl_from_text=yes
ac_cv_func_acl_get_fd=yes
ac_cv_func_acl_get_file=yes
ac_cv_func_acl_set_fd=yes
ac_cv_func_acl_set_file=yes
ac_cv_func_alarm=yes
ac_cv_func_alloca=yes
ac_cv_func_arc4random=yes
ac_cv_func_arc4random_buf=yes
ac_cv_func_arc4random_uniform=yes
ac_cv_func_argz_count=no
ac_cv_func_argz_next=no
ac_cv_func_argz_stringify=no
ac_cv_func_asprintf=yes
ac_cv_func_atexit=yes
ac_cv_func_bcmp=yes
ac_cv_func_bcopy=yes
ac_cv_func_bindresvport_sa=yes
ac_cv_func_btowc=yes
ac_cv_func_bzero=yes
ac_cv_func_chown=yes
ac_cv_func_clock=yes
ac_cv_func_clock_gettime=yes
ac_cv_func_closedir=yes
ac_cv_func_closefrom=yes
ac_cv_func_daemon=yes
ac_cv_func_dirname=yes
ac_cv_func_dlopen=yes
ac_cv_func_dup2=yes
ac_cv_func_eaccess=yes
ac_cv_func_fchmod=yes
ac_cv_func_fchown=yes
ac_cv_func_fcntl=yes
ac_cv_func_fileno=yes
ac_cv_func_fork=yes
ac_cv_func_fpurge=yes
ac_cv_func_freeaddrinfo=yes
ac_cv_func_fstatvfs=yes
ac_cv_func_fsync=yes
ac_cv_func_futimes=yes
ac_cv_func_fwprintf=yes
ac_cv_func_gai_strerror=yes
ac_cv_func_getaddrinfo=yes
ac_cv_func_getcwd=yes
ac_cv_func_getdelim=yes
ac_cv_func_getdtablesize=yes
ac_cv_func_getegid=yes
ac_cv_func_geteuid=yes
ac_cv_func_getgid=yes
ac_cv_func_getgrouplist=yes
ac_cv_func_gethostbyname=yes
ac_cv_func_gethostname=yes
ac_cv_func_getline=yes
ac_cv_func_getnameinfo=yes
ac_cv_func_getopt=yes
ac_cv_func_getopt_long_only=yes
ac_cv_func_getpagesize=yes
ac_cv_func_getpeereid=yes
ac_cv_func_getpgid=yes
ac_cv_func_getpgrp=yes
ac_cv_func_getpgrp_void=yes
ac_cv_func_getpid=yes
ac_cv_func_getrlimit=yes
ac_cv_func_getrusage=yes
ac_cv_func_gettimeofday=yes
ac_cv_func_getttyent=yes
ac_cv_func_getuid=yes
ac_cv_func_getwd=yes
ac_cv_func_glob=yes
ac_cv_func_group_from_gid=yes
ac_cv_func_inet_aton=yes
ac_cv_func_inet_ntoa=yes
ac_cv_func_inet_ntop=yes
ac_cv_func_innetgr=yes
ac_cv_func_isascii=yes
ac_cv_func_isblank=yes
ac_cv_func_issetugid=yes
ac_cv_func_iswblank=yes
ac_cv_func_iswcntrl=yes
ac_cv_func_iswctype=yes
ac_cv_func_link=yes
ac_cv_func_localtime=yes
ac_cv_func_lstat=yes
ac_cv_func_lstat_dereferences_slashed_symlink=yes
ac_cv_func_malloc_0_nonnull=yes
ac_cv_func_mbrlen=yes
ac_cv_func_mbrtowc=yes
ac_cv_func_mbsinit=yes
ac_cv_func_mbsrtowcs=yes
ac_cv_func_memchr=yes
ac_cv_func_memcmp=yes
ac_cv_func_memcpy=yes
ac_cv_func_memmove=yes
ac_cv_func_memset=yes
ac_cv_func_mkdtemp=yes
ac_cv_func_mkstemp=yes
ac_cv_func_mktemp=yes
ac_cv_func_mlock=yes
ac_cv_func_mmap=yes
ac_cv_func_mmap_fixed_mapped=yes
ac_cv_func_mprotect=yes
ac_cv_func_munlock=yes
ac_cv_func_munmap=yes
ac_cv_func_nl_langinfo=yes
ac_cv_func_obstacks=no
ac_cv_func_opendir=yes
ac_cv_func_pam_getenvlist=yes
ac_cv_func_pam_putenv=yes
ac_cv_func_pathconf=yes
ac_cv_func_pipe=yes
ac_cv_func_poll=yes
ac_cv_func_posix_spawn=yes
ac_cv_func_pread=yes
ac_cv_func_pstat_getdynamic=no
ac_cv_func_pthread_cond_broadcast=yes
ac_cv_func_pthread_cond_destroy=yes
ac_cv_func_pthread_cond_init=yes
ac_cv_func_pthread_cond_signal=yes
ac_cv_func_pthread_cond_timedwait=yes
ac_cv_func_pthread_cond_wait=yes
ac_cv_func_pthread_equal=yes
ac_cv_func_pthread_exit=yes
ac_cv_func_pthread_mutex_destroy=yes
ac_cv_func_pthread_mutex_init=yes
ac_cv_func_pthread_mutex_lock=yes
ac_cv_func_pthread_mutex_unlock=yes
ac_cv_func_pthread_self=yes
ac_cv_func_putenv=yes
ac_cv_func_pwrite=yes
ac_cv_func_raise=yes
ac_cv_func_rand=yes
ac_cv_func_random=yes
ac_cv_func_rawmemchr=no
ac_cv_func_readdir=yes
ac_cv_func_readlink=yes
ac_cv_func_readlinkat=yes
ac_cv_func_readpassphrase=yes
ac_cv_func_realpath=yes
ac_cv_func_recvmsg=yes
ac_cv_func_rename=yes
ac_cv_func_rresvport_af=yes
ac_cv_func_sched_yield=yes
ac_cv_func_select=yes
ac_cv_func_sendmsg=yes
ac_cv_func_setegid=yes
ac_cv_func_setenv=yes
ac_cv_func_seteuid=yes
ac_cv_func_setgroupent=yes
ac_cv_func_setgroups=yes
ac_cv_func_setlinebuf=yes
ac_cv_func_setlocale=yes
ac_cv_func_setlogin=yes
ac_cv_func_setpassent=yes
ac_cv_func_setproctitle=yes
ac_cv_func_setregid=yes
ac_cv_func_setresgid=yes
ac_cv_func_setresuid=yes
ac_cv_func_setreuid=yes
ac_cv_func_setrlimit=yes
ac_cv_func_setsid=yes
ac_cv_func_setsockopt=yes
ac_cv_func_setvbuf=yes
ac_cv_func_shmget=yes
ac_cv_func_sigaction=yes
ac_cv_func_sigaltstack=yes
ac_cv_func_siginterrupt=yes
ac_cv_func_sigprocmask=yes
ac_cv_func_sigvec=yes
ac_cv_func_sleep=yes
ac_cv_func_snprintf=yes
ac_cv_func_socketpair=yes
ac_cv_func_srand=yes
ac_cv_func_srandom=yes
ac_cv_func_stat=yes
ac_cv_func_statfs=yes
ac_cv_func_statvfs=yes
ac_cv_func_stpcpy=yes
ac_cv_func_stpncpy=yes
ac_cv_func_strbrk=yes
ac_cv_func_strcasecmp=yes
ac_cv_func_strcspn=yes
ac_cv_func_strdup=yes
ac_cv_func_strerror=yes
ac_cv_func_strerror_r=yes
ac_cv_func_strftime=yes
ac_cv_func_strlcat=yes
ac_cv_func_strlcpy=yes
ac_cv_func_strlen=yes
ac_cv_func_strmode=yes
ac_cv_func_strncasecmp=yes
ac_cv_func_strndup=yes
ac_cv_func_strnlen=yes
ac_cv_func_strnlen_working=yes
ac_cv_func_strpbrk=yes
ac_cv_func_strptime=yes
ac_cv_func_strsep=yes
ac_cv_func_strsignal=yes
ac_cv_func_strtol=yes
ac_cv_func_strtoll=yes
ac_cv_func_strtonum=yes
ac_cv_func_strtoul=yes
ac_cv_func_strtoull=yes
ac_cv_func_symlink=yes
ac_cv_func_sysconf=yes
ac_cv_func_tcgetpgrp=yes
ac_cv_func_time=yes
ac_cv_func_towlower=yes
ac_cv_func_truncate=yes
ac_cv_func_tsearch=yes
ac_cv_func_uname=yes
ac_cv_func_unsetenv=yes
ac_cv_func_user_from_uid=yes
ac_cv_func_usleep=yes
ac_cv_func_utime=yes
ac_cv_func_utimes=yes
ac_cv_func_vasprintf=yes
ac_cv_func_vfork=yes
ac_cv_func_vprintf=yes
ac_cv_func_vsnprintf=yes
ac_cv_func_vsprintf=yes
ac_cv_func_waitpid=yes
ac_cv_func_wcrtomb=yes
ac_cv_func_wcscoll=yes
ac_cv_func_wcslen=yes
ac_cv_func_wcsnlen=yes
ac_cv_func_wctob=yes
ac_cv_func_wcwidth=yes
ac_cv_func_wmemchr=yes
ac_cv_func_wmemcpy=yes
ac_cv_func_yield=no
ac_cv_func_yp_match=yes
ac_cv_have___va_copy=yes
ac_cv_have_clock_t=yes
ac_cv_have_control_in_msghdr=yes
ac_cv_have_decl_GLOB_NOMATCH=yes
ac_cv_have_decl_LLONG_MAX=yes
ac_cv_have_decl_MAXSYMLINKS=yes
ac_cv_have_decl_O_NONBLOCK=yes
ac_cv_have_decl_RLIMIT_NPROC=yes
ac_cv_have_decl_SHUT_RD=yes
ac_cv_have_decl__Exit=yes
ac_cv_have_decl_alarm=yes
ac_cv_have_decl_alphasort=yes
ac_cv_have_decl_atoll=yes
ac_cv_have_decl_btowc=yes
ac_cv_have_decl_chdir=yes
ac_cv_have_decl_chown=yes
ac_cv_have_decl_clearerr_unlocked=yes
ac_cv_have_decl_closedir=yes
ac_cv_have_decl_dprintf=yes
ac_cv_have_decl_dup2=yes
ac_cv_have_decl_dup=yes
ac_cv_have_decl_endusershell=yes
ac_cv_have_decl_faccessat=yes
ac_cv_have_decl_fchdir=yes
ac_cv_have_decl_fchmodat=yes
ac_cv_have_decl_fchownat=yes
ac_cv_have_decl_fcntl=yes
ac_cv_have_decl_fdopendir=yes
ac_cv_have_decl_feof_unlocked=yes
ac_cv_have_decl_feof_unlocked_fgets_unlocked=yes
ac_cv_have_decl_ferror_unlocked=yes
ac_cv_have_decl_ffsl=yes
ac_cv_have_decl_ffsll=yes
ac_cv_have_decl_fpurge=yes
ac_cv_have_decl_frexpl=yes
ac_cv_have_decl_fseeko=yes
ac_cv_have_decl_fstat=yes
ac_cv_have_decl_fstatat=yes
ac_cv_have_decl_fsync=yes
ac_cv_have_decl_ftello=yes
ac_cv_have_decl_ftruncate=yes
ac_cv_have_decl_getc_unlocked=yes
ac_cv_have_decl_getchar_unlocked=yes
ac_cv_have_decl_getcwd=yes
ac_cv_have_decl_getdelim=yes
ac_cv_have_decl_getdomainname=yes
ac_cv_have_decl_getdtablesize=yes
ac_cv_have_decl_getenv=yes
ac_cv_have_decl_getgroups=yes
ac_cv_have_decl_gethostname=yes
ac_cv_have_decl_getline=yes
ac_cv_have_decl_getloadavg=yes
ac_cv_have_decl_getlogin=yes
ac_cv_have_decl_getlogin_r=yes
ac_cv_have_decl_getpagesize=yes
ac_cv_have_decl_gets=yes
ac_cv_have_decl_getsubopt=yes
ac_cv_have_decl_gettimeofday=yes
ac_cv_have_decl_getusershell=yes
ac_cv_have_decl_grantpt=yes
ac_cv_have_decl_h_errno=yes
ac_cv_have_decl_imaxabs=yes
ac_cv_have_decl_imaxdiv=yes
ac_cv_have_decl_initstate=yes
ac_cv_have_decl_isatty=yes
ac_cv_have_decl_isblank=yes
ac_cv_have_decl_iswblank=yes
ac_cv_have_decl_iswctype=yes
ac_cv_have_decl_lchmod=yes
ac_cv_have_decl_lchown=yes
ac_cv_have_decl_link=yes
ac_cv_have_decl_linkat=yes
ac_cv_have_decl_lseek=yes
ac_cv_have_decl_lstat=yes
ac_cv_have_decl_mbrlen=yes
ac_cv_have_decl_mbrtowc=yes
ac_cv_have_decl_mbsinit=yes
ac_cv_have_decl_mbsnrtowcs=yes
ac_cv_have_decl_mbsrtowcs=yes
ac_cv_have_decl_memmem=yes
ac_cv_have_decl_memrchr=yes
ac_cv_have_decl_mkdirat=yes
ac_cv_have_decl_mkdtemp=yes
ac_cv_have_decl_mkfifo=yes
ac_cv_have_decl_mkfifoat=yes
ac_cv_have_decl_mknod=yes
ac_cv_have_decl_mknodat=yes
ac_cv_have_decl_mkstemp=yes
ac_cv_have_decl_nl_langinfo=yes
ac_cv_have_decl_offsetof=yes
ac_cv_have_decl_openat=yes
ac_cv_have_decl_opendir=yes
ac_cv_have_decl_pclose=yes
ac_cv_have_decl_pipe=yes
ac_cv_have_decl_popen=yes
ac_cv_have_decl_posix_openpt=yes
ac_cv_have_decl_posix_spawn=yes
ac_cv_have_decl_posix_spawn_file_actions_addclose=yes
ac_cv_have_decl_posix_spawn_file_actions_adddup2=yes
ac_cv_have_decl_posix_spawn_file_actions_addopen=yes
ac_cv_have_decl_posix_spawn_file_actions_destroy=yes
ac_cv_have_decl_posix_spawn_file_actions_init=yes
ac_cv_have_decl_posix_spawnattr_destroy=yes
ac_cv_have_decl_posix_spawnattr_getflags=yes
ac_cv_have_decl_posix_spawnattr_getpgroup=yes
ac_cv_have_decl_posix_spawnattr_getschedparam=yes
ac_cv_have_decl_posix_spawnattr_getschedpolicy=yes
ac_cv_have_decl_posix_spawnattr_getsigdefault=yes
ac_cv_have_decl_posix_spawnattr_getsigmask=yes
ac_cv_have_decl_posix_spawnattr_init=yes
ac_cv_have_decl_posix_spawnattr_setflags=yes
ac_cv_have_decl_posix_spawnattr_setpgroup=yes
ac_cv_have_decl_posix_spawnattr_setschedparam=yes
ac_cv_have_decl_posix_spawnattr_setschedpolicy=yes
ac_cv_have_decl_posix_spawnattr_setsigdefault=yes
ac_cv_have_decl_posix_spawnattr_setsigmask=yes
ac_cv_have_decl_posix_spawnp=yes
ac_cv_have_decl_pread=yes
ac_cv_have_decl_pselect=yes
ac_cv_have_decl_pthread_sigmask=yes
ac_cv_have_decl_ptsname=yes
ac_cv_have_decl_putc_unlocked=yes
ac_cv_have_decl_putchar_unlocked=yes
ac_cv_have_decl_pwrite=yes
ac_cv_have_decl_random=yes
ac_cv_have_decl_rawmemchr=yes
ac_cv_have_decl_readdir=yes
ac_cv_have_decl_readlink=yes
ac_cv_have_decl_readlinkat=yes
ac_cv_have_decl_realpath=yes
ac_cv_have_decl_renameat=yes
ac_cv_have_decl_rewinddir=yes
ac_cv_have_decl_rmdir=yes
ac_cv_have_decl_rpmatch=yes
ac_cv_have_decl_scandir=yes
ac_cv_have_decl_select=yes
ac_cv_have_decl_setenv=yes
ac_cv_have_decl_sethostname=yes
ac_cv_have_decl_setlocale=yes
ac_cv_have_decl_setstate=yes
ac_cv_have_decl_setusershell=yes
ac_cv_have_decl_sigaction=yes
ac_cv_have_decl_sigaddset=yes
ac_cv_have_decl_sigaltstack=yes
ac_cv_have_decl_sigdelset=yes
ac_cv_have_decl_sigemptyset=yes
ac_cv_have_decl_sigfillset=yes
ac_cv_have_decl_sigismember=yes
ac_cv_have_decl_sigpending=yes
ac_cv_have_decl_sigprocmask=yes
ac_cv_have_decl_sleep=yes
ac_cv_have_decl_snprintf=yes
ac_cv_have_decl_srandom=yes
ac_cv_have_decl_stat=yes
ac_cv_have_decl_stpcpy=yes
ac_cv_have_decl_stpncpy=yes
ac_cv_have_decl_strcasestr=yes
ac_cv_have_decl_strdup=yes
ac_cv_have_decl_strerror_r=yes
ac_cv_have_decl_strncat=yes
ac_cv_have_decl_strndup=yes
ac_cv_have_decl_strnlen=yes
ac_cv_have_decl_strpbrk=yes
ac_cv_have_decl_strsep=yes
ac_cv_have_decl_strsignal=yes
ac_cv_have_decl_strtod=yes
ac_cv_have_decl_strtoimax=yes
ac_cv_have_decl_strtok_r=yes
ac_cv_have_decl_strtoll=yes
ac_cv_have_decl_strtoull=yes
ac_cv_have_decl_strtoumax=yes
ac_cv_have_decl_symlink=yes
ac_cv_have_decl_symlinkat=yes
ac_cv_have_decl_sys_siglist=yes
ac_cv_have_decl_tcsendbreak=yes
ac_cv_have_decl_tmpfile=yes
ac_cv_have_decl_towctrans=yes
ac_cv_have_decl_ttyname_r=yes
ac_cv_have_decl_unlink=yes
ac_cv_have_decl_unlinkat=yes
ac_cv_have_decl_unlockpt=yes
ac_cv_have_decl_unsetenv=yes
ac_cv_have_decl_usleep=yes
ac_cv_have_decl_vdprintf=yes
ac_cv_have_decl_vsnprintf=yes
ac_cv_have_decl_waitpid=yes
ac_cv_have_decl_wcpcpy=yes
ac_cv_have_decl_wcpncpy=yes
ac_cv_have_decl_wcrtomb=yes
ac_cv_have_decl_wcscasecmp=yes
ac_cv_have_decl_wcscat=yes
ac_cv_have_decl_wcschr=yes
ac_cv_have_decl_wcscmp=yes
ac_cv_have_decl_wcscoll=yes
ac_cv_have_decl_wcscpy=yes
ac_cv_have_decl_wcscspn=yes
ac_cv_have_decl_wcsdup=yes
ac_cv_have_decl_wcslen=yes
ac_cv_have_decl_wcsncasecmp=yes
ac_cv_have_decl_wcsncat=yes
ac_cv_have_decl_wcsncmp=yes
ac_cv_have_decl_wcsncpy=yes
ac_cv_have_decl_wcsnlen=yes
ac_cv_have_decl_wcsnrtombs=yes
ac_cv_have_decl_wcspbrk=yes
ac_cv_have_decl_wcsrchr=yes
ac_cv_have_decl_wcsrtombs=yes
ac_cv_have_decl_wcsspn=yes
ac_cv_have_decl_wcsstr=yes
ac_cv_have_decl_wcstok=yes
ac_cv_have_decl_wcswidth=yes
ac_cv_have_decl_wcsxfrm=yes
ac_cv_have_decl_wctob=yes
ac_cv_have_decl_wctrans=yes
ac_cv_have_decl_wctype=yes
ac_cv_have_decl_wcwidth=yes
ac_cv_have_decl_wmemchr=yes
ac_cv_have_decl_wmemcmp=yes
ac_cv_have_decl_wmemcpy=yes
ac_cv_have_decl_wmemmove=yes
ac_cv_have_decl_wmemset=yes
ac_cv_have_decl_writev=yes
ac_cv_have_getopt_optreset=yes
ac_cv_have_int64_t=yes
ac_cv_have_intxx_t=yes
ac_cv_have_mode_t=yes
ac_cv_have_pid_t=yes
ac_cv_have_pw_change_in_struct_passwd=yes
ac_cv_have_pw_class_in_struct_passwd=yes
ac_cv_have_pw_expire_in_struct_passwd=yes
ac_cv_have_sa_family_t=yes
ac_cv_have_size_t=yes
ac_cv_have_ss_family_in_struct_ss=yes
ac_cv_have_ssize_t=yes
ac_cv_have_struct_addrinfo=yes
ac_cv_have_struct_in6_addr=yes
ac_cv_have_struct_sockaddr_in6=yes
ac_cv_have_struct_sockaddr_storage=yes
ac_cv_have_struct_timeval=yes
ac_cv_have_u_char=yes
ac_cv_have_u_int64_t=yes
ac_cv_have_u_int=yes
ac_cv_have_u_intxx_t=yes
ac_cv_have_va_copy=yes
ac_cv_header_alloca_h=no
ac_cv_header_argz_h=no
ac_cv_header_arpa_inet_h=yes
ac_cv_header_arpa_nameser_h=yes
ac_cv_header_byteswap_h=no
ac_cv_header_ctype_h=yes
ac_cv_header_dirent_h=yes
ac_cv_header_dl_h=no
ac_cv_header_dlfcn_h=yes
ac_cv_header_elf_h=yes
ac_cv_header_errno_h=yes
ac_cv_header_fcntl_h=yes
ac_cv_header_float_h=yes
ac_cv_header_floatingpoint_h=yes
ac_cv_header_getopt_h=yes
ac_cv_header_glob_h=yes
ac_cv_header_inttypes_h=yes
ac_cv_header_langinfo_h=yes
ac_cv_header_libgen_h=yes
ac_cv_header_libutil_h=yes
ac_cv_header_limits_h=yes
ac_cv_header_login_cap_h=yes
ac_cv_header_malloc_h=no
ac_cv_header_math_h=yes
ac_cv_header_memory_h=yes
ac_cv_header_minix_config_h=no
ac_cv_header_net_if_h=yes
ac_cv_header_net_if_media_h=yes
ac_cv_header_net_if_tap_h=yes
ac_cv_header_net_if_tun_h=yes
ac_cv_header_netdb_h=yes
ac_cv_header_netinet_in_h=yes
ac_cv_header_paths_h=yes
ac_cv_header_poll_h=yes
ac_cv_header_pwd_h=yes
ac_cv_header_random_h=no
ac_cv_header_readpassphrase_h=yes
ac_cv_header_resolv_h=yes
ac_cv_header_rpc_types_h=yes
ac_cv_header_sched_h=yes
ac_cv_header_search_h=yes
ac_cv_header_security_pam_appl_h=yes
ac_cv_header_signal_h=yes
ac_cv_header_spawn_h=yes
ac_cv_header_stdarg_h=yes
ac_cv_header_stdbool_h=yes
ac_cv_header_stdc=yes
ac_cv_header_stddef_h=yes
ac_cv_header_stdint_h=yes
ac_cv_header_stdio_h=yes
ac_cv_header_stdlib_h=yes
ac_cv_header_string_h=yes
ac_cv_header_strings_h=yes
ac_cv_header_sys_acl_h=yes
ac_cv_header_sys_cdefs_h=yes
ac_cv_header_sys_dir_h=yes
ac_cv_header_sys_fcntl_h=yes
ac_cv_header_sys_file_h=yes
ac_cv_header_sys_ioctl_h=yes
ac_cv_header_sys_mman_h=yes
ac_cv_header_sys_mount_h=yes
ac_cv_header_sys_msg_h=yes
ac_cv_header_sys_param_h=yes
ac_cv_header_sys_poll_h=yes
ac_cv_header_sys_ptrace_h=yes
ac_cv_header_sys_select_h=yes
ac_cv_header_sys_socket_h=yes
ac_cv_header_sys_stat_h=yes
ac_cv_header_sys_statvfs_h=yes
ac_cv_header_sys_time_h=yes
ac_cv_header_sys_timers_h=yes
ac_cv_header_sys_times_h=yes
ac_cv_header_sys_types_h=yes
ac_cv_header_sys_un_h=yes
ac_cv_header_sys_wait_h=yes
ac_cv_header_time_h=yes
ac_cv_header_ttyent_h=yes
ac_cv_header_ucontext_h=yes
ac_cv_header_unistd_h=yes
ac_cv_header_utime_h=yes
ac_cv_header_vfork_h=no
ac_cv_header_vis_h=yes
ac_cv_header_wchar_h=yes
ac_cv_header_wctype_h=yes
ac_cv_header_zlib_h=yes
ac_cv_lib_crypt_crypt=yes
ac_cv_lib_edit_el_init=yes
ac_cv_lib_pam_pam_set_item=yes
ac_cv_lib_z_deflate=yes
ac_cv_libc_defines___progname=yes
ac_cv_libc_defines_sys_errlist=yes
ac_cv_libc_defines_sys_nerr=yes
ac_cv_member_HEADER_ad=yes
ac_cv_member_struct___res_state_retrans=yes
ac_cv_member_struct_sigaction_sa_sigaction=yes
ac_cv_member_struct_sockaddr_in6_sin6_scope_id=yes
ac_cv_member_struct_stat_st_blksize=yes
ac_cv_path_BZIP2=/usr/bin/bzip2
ac_cv_path_EGREP=/usr/bin/egrep
ac_cv_path_FGREP=/usr/bin/fgrep
ac_cv_path_GREP=/usr/bin/grep
ac_cv_path_GZIP=/usr/bin/gzip
ac_cv_path_MKTEMP_COMMAND=/usr/bin/mktemp
ac_cv_path_SED=/usr/bin/sed
ac_cv_path_install=/usr/bin/install
ac_cv_path_mkdir=/bin/mkdir
ac_cv_prog_AWK=/usr/bin/awk
ac_cv_prog_SED=/usr/bin/sed
ac_cv_type__Bool=yes
ac_cv_type_char=yes
ac_cv_type_char_p=yes
ac_cv_type_fsblkcnt_t=yes
ac_cv_type_fsfilcnt_t=yes
ac_cv_type_in_addr_t=yes
ac_cv_type_in_port_t=yes
ac_cv_type_int16_t=yes
ac_cv_type_int32_t=yes
ac_cv_type_int=yes
ac_cv_type_intmax_t=yes
ac_cv_type_long=yes
ac_cv_type_long_double=yes
ac_cv_type_long_long=yes
ac_cv_type_long_long_int=yes
ac_cv_type_mbstate_t=yes
ac_cv_type_mode_t=yes
ac_cv_type_nlink_t=yes
ac_cv_type_off_t=yes
ac_cv_type_pid_t=yes
ac_cv_type_posix_spawn_file_actions_t=yes
ac_cv_type_posix_spawnattr_t=yes
ac_cv_type_ptrdiff_t=yes
ac_cv_type_short=yes
ac_cv_type_sig_atomic_t=yes
ac_cv_type_sigset_t=yes
ac_cv_type_size_t=yes
ac_cv_type_socklen_t=yes
ac_cv_type_ssize_t=yes
ac_cv_type_stack_t=yes
ac_cv_type_struct_timespec=yes
ac_cv_type_u_char=yes
ac_cv_type_u_int16_t=yes
ac_cv_type_u_int32_t=yes
ac_cv_type_u_int8_t=yes
ac_cv_type_u_int=yes
ac_cv_type_u_long=yes
ac_cv_type_u_short=yes
ac_cv_type_uid_t=yes
ac_cv_type_uintptr_t=yes
ac_cv_type_unsigned_char=yes
ac_cv_type_unsigned_int=yes
ac_cv_type_unsigned_long=yes
ac_cv_type_unsigned_long_long=yes
ac_cv_type_unsigned_long_long_int=yes
ac_cv_type_unsigned_short=yes
ac_cv_type_volatile_sig_atomic_t=yes
ac_cv_type_wchar_t=yes
ac_cv_type_wint_t=yes
am_cv_prog_tar_ustar=/usr/bin/tar
cl_cv_prog_LN=/bin/ln
cl_cv_prog_cp='/bin/cp -p'
gl_cv_func_btowc_eof=yes
gl_cv_func_btowc_nul=yes
gl_cv_func_fcntl_f_dupfd_cloexec=yes
gl_cv_func_fnmatch_posix=yes
gl_cv_func_fopen_slash=yes
gl_cv_func_frexp_no_libm=yes
gl_cv_func_fseeko=yes
gl_cv_func_ftello=yes
gl_cv_func_getcwd_null=yes
gl_cv_func_getcwd_posix_signature=yes
gl_cv_func_getopt_posix=yes
gl_cv_func_isnand_no_libm=yes
gl_cv_func_ldexp_no_libm=yes
gl_cv_func_lseek_pipe=yes
gl_cv_func_lstat_dereferences_slashed_symlink=yes
gl_cv_func_malloc_0_nonnull=1
gl_cv_func_malloc_posix=yes
gl_cv_func_mbrtowc_incomplete_state=yes
gl_cv_func_mbrtowc_nul_retval=yes
gl_cv_func_mbrtowc_null_arg1=yes
gl_cv_func_mbrtowc_null_arg2=yes
gl_cv_func_mbrtowc_retval=yes
gl_cv_func_mbrtowc_sanitycheck=yes
gl_cv_func_open_slash=yes
gl_cv_func_printf_directive_a=yes
gl_cv_func_printf_directive_f=yes
gl_cv_func_printf_directive_ls=yes
gl_cv_func_printf_directive_n=yes
gl_cv_func_printf_flag_grouping=yes
gl_cv_func_printf_flag_leftadjust=yes
gl_cv_func_printf_flag_zero=yes
gl_cv_func_printf_infinite=yes
gl_cv_func_printf_long_double=yes
gl_cv_func_printf_positions=yes
gl_cv_func_printf_precision=yes
gl_cv_func_printf_sizes_c99=yes
gl_cv_func_sigprocmask=1
gl_cv_func_snprintf_retval_c99=yes
gl_cv_func_snprintf_size1=yes
gl_cv_func_snprintf_usable=yes
gl_cv_func_spawnattr_setschedparam=yes
gl_cv_func_spawnattr_setschedpolicy=yes
gl_cv_func_stat_dir_slash=yes
gl_cv_func_stat_file_slash=yes
gl_cv_func_stpncpy=yes
gl_cv_func_va_copy=yes
gl_cv_func_wcrtomb_retval=yes
gl_cv_have_include_next=yes
gl_cv_have_raw_decl__Exit=yes
gl_cv_have_raw_decl_alphasort=yes
gl_cv_have_raw_decl_atoll=yes
gl_cv_have_raw_decl_btowc=yes
gl_cv_have_raw_decl_chdir=yes
gl_cv_have_raw_decl_chown=yes
gl_cv_have_raw_decl_closedir=yes
gl_cv_have_raw_decl_dprintf=yes
gl_cv_have_raw_decl_dup2=yes
gl_cv_have_raw_decl_dup=yes
gl_cv_have_raw_decl_endusershell=yes
gl_cv_have_raw_decl_faccessat=yes
gl_cv_have_raw_decl_fchdir=yes
gl_cv_have_raw_decl_fchmodat=yes
gl_cv_have_raw_decl_fchownat=yes
gl_cv_have_raw_decl_fcntl=yes
gl_cv_have_raw_decl_fdopendir=yes
gl_cv_have_raw_decl_ffsl=yes
gl_cv_have_raw_decl_ffsll=yes
gl_cv_have_raw_decl_fpurge=yes
gl_cv_have_raw_decl_fseeko=yes
gl_cv_have_raw_decl_fstat=yes
gl_cv_have_raw_decl_fstatat=yes
gl_cv_have_raw_decl_fsync=yes
gl_cv_have_raw_decl_ftello=yes
gl_cv_have_raw_decl_ftruncate=yes
gl_cv_have_raw_decl_getcwd=yes
gl_cv_have_raw_decl_getdelim=yes
gl_cv_have_raw_decl_getdomainname=yes
gl_cv_have_raw_decl_getdtablesize=yes
gl_cv_have_raw_decl_getgroups=yes
gl_cv_have_raw_decl_gethostname=yes
gl_cv_have_raw_decl_getline=yes
gl_cv_have_raw_decl_getloadavg=yes
gl_cv_have_raw_decl_getlogin=yes
gl_cv_have_raw_decl_getlogin_r=yes
gl_cv_have_raw_decl_getpagesize=yes
gl_cv_have_raw_decl_gets=yes
gl_cv_have_raw_decl_getsubopt=yes
gl_cv_have_raw_decl_gettimeofday=yes
gl_cv_have_raw_decl_getusershell=yes
gl_cv_have_raw_decl_grantpt=yes
gl_cv_have_raw_decl_imaxabs=yes
gl_cv_have_raw_decl_imaxdiv=yes
gl_cv_have_raw_decl_initstate=yes
gl_cv_have_raw_decl_isatty=yes
gl_cv_have_raw_decl_iswctype=yes
gl_cv_have_raw_decl_lchmod=yes
gl_cv_have_raw_decl_lchown=yes
gl_cv_have_raw_decl_link=yes
gl_cv_have_raw_decl_linkat=yes
gl_cv_have_raw_decl_lseek=yes
gl_cv_have_raw_decl_lstat=yes
gl_cv_have_raw_decl_mbrlen=yes
gl_cv_have_raw_decl_mbrtowc=yes
gl_cv_have_raw_decl_mbsinit=yes
gl_cv_have_raw_decl_mbsnrtowcs=yes
gl_cv_have_raw_decl_mbsrtowcs=yes
gl_cv_have_raw_decl_memcpy=no
gl_cv_have_raw_decl_memmem=yes
gl_cv_have_raw_decl_memrchr=yes
gl_cv_have_raw_decl_mkdirat=yes
gl_cv_have_raw_decl_mkdtemp=yes
gl_cv_have_raw_decl_mkfifo=yes
gl_cv_have_raw_decl_mkfifoat=yes
gl_cv_have_raw_decl_mknod=yes
gl_cv_have_raw_decl_mknodat=yes
gl_cv_have_raw_decl_mkstemp=yes
gl_cv_have_raw_decl_nl_langinfo=yes
gl_cv_have_raw_decl_openat=yes
gl_cv_have_raw_decl_opendir=yes
gl_cv_have_raw_decl_pclose=yes
gl_cv_have_raw_decl_pipe=yes
gl_cv_have_raw_decl_popen=yes
gl_cv_have_raw_decl_posix_openpt=yes
gl_cv_have_raw_decl_posix_spawn=yes
gl_cv_have_raw_decl_posix_spawn_file_actions_addclose=yes
gl_cv_have_raw_decl_posix_spawn_file_actions_adddup2=yes
gl_cv_have_raw_decl_posix_spawn_file_actions_addopen=yes
gl_cv_have_raw_decl_posix_spawn_file_actions_destroy=yes
gl_cv_have_raw_decl_posix_spawn_file_actions_init=yes
gl_cv_have_raw_decl_posix_spawnattr_destroy=yes
gl_cv_have_raw_decl_posix_spawnattr_getflags=yes
gl_cv_have_raw_decl_posix_spawnattr_getpgroup=yes
gl_cv_have_raw_decl_posix_spawnattr_getschedparam=yes
gl_cv_have_raw_decl_posix_spawnattr_getschedpolicy=yes
gl_cv_have_raw_decl_posix_spawnattr_getsigdefault=yes
gl_cv_have_raw_decl_posix_spawnattr_getsigmask=yes
gl_cv_have_raw_decl_posix_spawnattr_init=yes
gl_cv_have_raw_decl_posix_spawnattr_setflags=yes
gl_cv_have_raw_decl_posix_spawnattr_setpgroup=yes
gl_cv_have_raw_decl_posix_spawnattr_setschedparam=yes
gl_cv_have_raw_decl_posix_spawnattr_setschedpolicy=yes
gl_cv_have_raw_decl_posix_spawnattr_setsigdefault=yes
gl_cv_have_raw_decl_posix_spawnattr_setsigmask=yes
gl_cv_have_raw_decl_posix_spawnp=yes
gl_cv_have_raw_decl_pread=yes
gl_cv_have_raw_decl_pselect=yes
gl_cv_have_raw_decl_pthread_sigmask=yes
gl_cv_have_raw_decl_ptsname=yes
gl_cv_have_raw_decl_pwrite=yes
gl_cv_have_raw_decl_random=yes
gl_cv_have_raw_decl_rawmemchr=yes
gl_cv_have_raw_decl_readdir=yes
gl_cv_have_raw_decl_readlink=yes
gl_cv_have_raw_decl_readlinkat=yes
gl_cv_have_raw_decl_realpath=yes
gl_cv_have_raw_decl_renameat=yes
gl_cv_have_raw_decl_rewinddir=yes
gl_cv_have_raw_decl_rmdir=yes
gl_cv_have_raw_decl_rpmatch=yes
gl_cv_have_raw_decl_scandir=yes
gl_cv_have_raw_decl_select=yes
gl_cv_have_raw_decl_setenv=yes
gl_cv_have_raw_decl_sethostname=yes
gl_cv_have_raw_decl_setlocale=yes
gl_cv_have_raw_decl_setstate=yes
gl_cv_have_raw_decl_setusershell=yes
gl_cv_have_raw_decl_sigaction=yes
gl_cv_have_raw_decl_sigaddset=yes
gl_cv_have_raw_decl_sigdelset=yes
gl_cv_have_raw_decl_sigemptyset=yes
gl_cv_have_raw_decl_sigfillset=yes
gl_cv_have_raw_decl_sigismember=yes
gl_cv_have_raw_decl_sigpending=yes
gl_cv_have_raw_decl_sigprocmask=yes
gl_cv_have_raw_decl_sleep=yes
gl_cv_have_raw_decl_snprintf=yes
gl_cv_have_raw_decl_srandom=yes
gl_cv_have_raw_decl_stat=yes
gl_cv_have_raw_decl_stpcpy=yes
gl_cv_have_raw_decl_stpncpy=yes
gl_cv_have_raw_decl_strcasestr=yes
gl_cv_have_raw_decl_strdup=yes
gl_cv_have_raw_decl_strerror_r=yes
gl_cv_have_raw_decl_strncat=yes
gl_cv_have_raw_decl_strndup=yes
gl_cv_have_raw_decl_strnlen=yes
gl_cv_have_raw_decl_strpbrk=yes
gl_cv_have_raw_decl_strsep=yes
gl_cv_have_raw_decl_strsignal=yes
gl_cv_have_raw_decl_strtod=yes
gl_cv_have_raw_decl_strtoimax=yes
gl_cv_have_raw_decl_strtok_r=yes
gl_cv_have_raw_decl_strtoll=yes
gl_cv_have_raw_decl_strtoull=yes
gl_cv_have_raw_decl_strtoumax=yes
gl_cv_have_raw_decl_strverscmp=no
gl_cv_have_raw_decl_symlink=yes
gl_cv_have_raw_decl_symlinkat=yes
gl_cv_have_raw_decl_tmpfile=yes
gl_cv_have_raw_decl_towctrans=yes
gl_cv_have_raw_decl_ttyname_r=yes
gl_cv_have_raw_decl_unlink=yes
gl_cv_have_raw_decl_unlinkat=yes
gl_cv_have_raw_decl_unlockpt=yes
gl_cv_have_raw_decl_unsetenv=yes
gl_cv_have_raw_decl_usleep=yes
gl_cv_have_raw_decl_vdprintf=yes
gl_cv_have_raw_decl_vsnprintf=yes
gl_cv_have_raw_decl_waitpid=yes
gl_cv_have_raw_decl_wcpcpy=yes
gl_cv_have_raw_decl_wcpncpy=yes
gl_cv_have_raw_decl_wcrtomb=yes
gl_cv_have_raw_decl_wcscasecmp=yes
gl_cv_have_raw_decl_wcscat=yes
gl_cv_have_raw_decl_wcschr=yes
gl_cv_have_raw_decl_wcscmp=yes
gl_cv_have_raw_decl_wcscoll=yes
gl_cv_have_raw_decl_wcscpy=yes
gl_cv_have_raw_decl_wcscspn=yes
gl_cv_have_raw_decl_wcsdup=yes
gl_cv_have_raw_decl_wcslen=yes
gl_cv_have_raw_decl_wcsncasecmp=yes
gl_cv_have_raw_decl_wcsncat=yes
gl_cv_have_raw_decl_wcsncmp=yes
gl_cv_have_raw_decl_wcsncpy=yes
gl_cv_have_raw_decl_wcsnlen=yes
gl_cv_have_raw_decl_wcsnrtombs=yes
gl_cv_have_raw_decl_wcspbrk=yes
gl_cv_have_raw_decl_wcsrchr=yes
gl_cv_have_raw_decl_wcsrtombs=yes
gl_cv_have_raw_decl_wcsspn=yes
gl_cv_have_raw_decl_wcsstr=yes
gl_cv_have_raw_decl_wcstok=yes
gl_cv_have_raw_decl_wcswidth=yes
gl_cv_have_raw_decl_wcsxfrm=yes
gl_cv_have_raw_decl_wctob=yes
gl_cv_have_raw_decl_wctrans=yes
gl_cv_have_raw_decl_wctype=yes
gl_cv_have_raw_decl_wcwidth=yes
gl_cv_have_raw_decl_wmemchr=yes
gl_cv_have_raw_decl_wmemcmp=yes
gl_cv_have_raw_decl_wmemcpy=yes
gl_cv_have_raw_decl_wmemmove=yes
gl_cv_have_raw_decl_wmemset=yes
gl_cv_header_errno_h_complete=yes
gl_cv_header_inttypes_h=yes
gl_cv_header_langinfo_codeset=yes
gl_cv_header_langinfo_era=yes
gl_cv_header_langinfo_t_fmt_ampm=yes
gl_cv_header_langinfo_yesexpr=yes
gl_cv_header_locale_h_posix2001=yes
gl_cv_header_signal_h_SIGPIPE=yes
gl_cv_header_stdint_h=yes
gl_cv_header_sys_select_h_selfcontained=yes
gl_cv_header_wchar_h_correct_inline=yes
gl_cv_sigaltstack_low_base=yes
gl_cv_size_max=yes
gl_cv_sys_struct_timespec_in_time_h=yes
gl_cv_sys_struct_timeval=yes
gl_cv_type_sigset_t=yes
gl_cv_type_wchar_t_signed=yes
gl_cv_type_wctrans_t=yes
gl_cv_type_wctype_t=yes
gl_cv_type_wint_t_signed=yes
gl_cv_var_stdin_large_offset=yes
gt_cv_c_intmax_t=yes
gt_cv_c_wchar_t=yes
gt_cv_c_wint_t=yes
gt_cv_func_printf_posix=yes
gt_cv_func_unsetenv_ret=int
gt_cv_int_divbyzero_sigfpe=yes
gt_cv_siginfo_t=yes
gt_cv_ssize_t=yes
lt_cv_path_MAGIC_CMD=/usr/bin/file
lt_cv_sys_max_cmd_len=262144

## ----------------- ##
## Output variables. ##
## ----------------- ##

CC='cc'
CFLAGS='-O2 -pipe  -fstack-protector -fno-strict-aliasing'
CGIEXT=''
CGI_GROUP=''
CPP='cpp'
CPPFLAGS=''
DEFS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EMAILPKG=''
EXEEXT=''
GREP=''
INSTALL_DATA='install  -m 0644'
INSTALL_PROGRAM='install  -s -m 555'
INSTALL_SCRIPT='install  -m 555'
JACODECSPKG=''
KOCODECSPKG=''
LDFLAGS=' -fstack-protector'
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
MAILHOST=''
MAILMAN_GROUP=''
MAILMAN_USER=''
MAIL_GROUP=''
OBJEXT=''
OPT=''
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_URL=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
PYTHON='/usr/local/bin/python2.7'
SCRIPTS=''
SET_MAKE=''
SHELL='/bin/sh'
TRUE=''
URLHOST=''
VAR_PREFIX=''
ac_ct_CC=''
bindir='${exec_prefix}/bin'
build_alias='amd64-portbld-freebsd10.3'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE}'
dvidir='${docdir}'
exec_prefix='NONE'
host_alias=''
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='/usr/local/mailman/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='/var'
mandir='/usr/local/man'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='/usr/local/mailman'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''
with_python='/usr/local/bin/python2.7'

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""

configure: exit 1

From ed.beu at alaska.gov  Wed May  4 12:49:20 2016
From: ed.beu at alaska.gov (Beu, Ed (DOA))
Date: Wed, 4 May 2016 16:49:20 +0000
Subject: [Mailman-Users] Order of operation - config files
Message-ID: <77788B6418FB6E4CB10D483D7DAC164CFE59D907@SOAANCEXMB9.soa.alaska.gov>

Hello,

We have a test installation of Mailman 2.1.20 (CSW) running on Solaris 10. Production version will be running on CentOS.

Since most of our lists are 'Announcement' type lists, I have put the following in the mm_cfg.py file:

DEFAULT_DEFAULT_MEMBER_MODERATION = Yes

For the occasional 'discussion' list I have created a config file (discuss.config) to import into the new list to change 'Member Moderation' to No, but it does not take effect.

For example, I'm using this command: .../bin> ./newlist -q testdiscuss ed.beu at alaska.gov 12345678;./config_list -i discuss.config testdiscuss

Is it not possible to override the mm_cfg.py file entries with a config_list -i command?

Thanks in advance for any assistance!

~Ed

Ed Beu , Systems Programmer
Enterprise Technology Services
Department of Administration
619 E Shipcreek Ave., Ste 232
Anchorage, AK 99501-1677
[ETSLogo]----------------------------------------
*Desk:(907)269-6790
?Fax: (907)269-6719
* ed.beu at alaska.gov<mailto:ed.beu at alaska.gov>
" http://www.doa.alaska.gov/ets/
----------------------------------------



From ed.beu at alaska.gov  Wed May  4 13:48:27 2016
From: ed.beu at alaska.gov (Beu, Ed (DOA))
Date: Wed, 4 May 2016 17:48:27 +0000
Subject: [Mailman-Users] Order of operation - config files
Message-ID: <77788B6418FB6E4CB10D483D7DAC164CFE59D9F1@SOAANCEXMB9.soa.alaska.gov>

Hi, I got it working... <comments below>

From: Beu, Ed (DOA)
Sent: Wednesday, May 04, 2016 8:49 AM
To: 'mailman-users at python.org' <mailman-users at python.org>
Subject: Order of operation - config files

Hello,

We have a test installation of Mailman 2.1.20 (CSW) running on Solaris 10. Production version will be running on CentOS.

Since most of our lists are 'Announcement' type lists, I have put the following in the mm_cfg.py file:

DEFAULT_DEFAULT_MEMBER_MODERATION = Yes
>>> The double DEFAULT_DEFAULT on this variable appears to be the only doubled default in the Defaults.py file. And, using it in the same manner in the MM_CFG.py file appears to be the only way to get it to work when creating a new list.

For the occasional 'discussion' list I have created a config file (discuss.config) to import into the new list to change 'Member Moderation' to No, but it does not take effect.

For example, I'm using this command: .../bin> ./newlist -q testdiscuss ed.beu at alaska.gov<mailto:ed.beu at alaska.gov> 12345678;./config_list -i discuss.config testdiscuss
>>> I change the entry in the MM_CFG.py file to:
DEFAULT_DEFAULT_MEMBER_MODERATION = 1            (1 rather than Yes)

>>> used the following statement in my discuss.config file - and it's working now
default_member_moderation = 0

Is it not possible to override the mm_cfg.py file entries with a config_list -i command?
>>> apparently the config_list -i does run after mm_cfg.py!!

Thanks in advance for any assistance!

~Ed

Ed Beu , Systems Programmer
Enterprise Technology Services
Department of Administration
619 E Shipcreek Ave., Ste 232
Anchorage, AK 99501-1677
[ETSLogo]----------------------------------------
*Desk:(907)269-6790
?Fax: (907)269-6719
* ed.beu at alaska.gov<mailto:ed.beu at alaska.gov>
" http://www.doa.alaska.gov/ets/
----------------------------------------



From mark at msapiro.net  Thu May  5 00:50:38 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 4 May 2016 21:50:38 -0700
Subject: [Mailman-Users] Order of operation - config files
In-Reply-To: <77788B6418FB6E4CB10D483D7DAC164CFE59D9F1@SOAANCEXMB9.soa.alaska.gov>
References: <77788B6418FB6E4CB10D483D7DAC164CFE59D9F1@SOAANCEXMB9.soa.alaska.gov>
Message-ID: <572AD11E.90609@msapiro.net>

On 05/04/2016 10:48 AM, Beu, Ed (DOA) wrote:
> 
> DEFAULT_DEFAULT_MEMBER_MODERATION = Yes
>>>> The double DEFAULT_DEFAULT on this variable appears to be the only doubled default in the Defaults.py file. And, using it in the same manner in the MM_CFG.py file appears to be the only way to get it to work when creating a new list.


That is correct. It is called DEFAULT_DEFAULT_MEMBER_MODERATION because
it establishes the new list default for the list attribute
default_member_moderation. For all list attributes named xxx which have
a default setting in Defaults.py, the Defaults.py setting is called
DEFAULT_XXX. For this one, the setting name begins with default... so
the Defaults.py default is DEFAULT_DEFAULT...

mm_cfg.py settings are overrides for the Defaults.py settings. Anything
defined in mm_cfg.py overrides the definition of the setting with the
same name in Defaults.py. Anything defined in mm_cfg.py which is not
defined in Defaults.py is not referenced in the code and is therefore
meaningless.


> For the occasional 'discussion' list I have created a config file (discuss.config) to import into the new list to change 'Member Moderation' to No, but it does not take effect.
> 
> For example, I'm using this command: .../bin> ./newlist -q testdiscuss ed.beu at alaska.gov<mailto:ed.beu at alaska.gov> 12345678;./config_list -i discuss.config testdiscuss
>>>> I change the entry in the MM_CFG.py file to:
> DEFAULT_DEFAULT_MEMBER_MODERATION = 1            (1 rather than Yes)


That doesn't matter. Defaults.py defines Yes = yes = On = on = True and
those things and also 1 are all equivalent in this respect.


>>>> used the following statement in my discuss.config file - and it's working now
> default_member_moderation = 0


But config_list doesn't define things like Yes, yes, On, on, No, no,
Off, off so you can't use them in setting list attributes. You have to
use the actual (lower case) list attribute name, not a name from
Defaults.py and you have to use values like 0, 1, False or True, not
Yes, yes, On, on, No, no, Off or off.


> Is it not possible to override the mm_cfg.py file entries with a config_list -i command?
>>>> apparently the config_list -i does run after mm_cfg.py!!


The Defaults.py/mm_cfg.py DEFAULT settings set list attributes when a
list is created via newlist or the web UI. mm_cfg.py doesn't 'run' at
all in the sense that new_list or config_list run. pretty much
everything in Mailman imports mm_cfg.py (which in turn imports
Defaults.py before setting any of it's overrides. This establishes the
site configuration for Mailman.

When you run newlist, it creates the list and the list creation process
uses the DEFAULT... settings from Defaults.py/mm_cfg.py in establishing
the settings for that list. config_list -i operates on an existing list
and sets those list attributes that are in it's input. So yes,
config_list -i will set anything in it's input. mm_cfg.py DEFAULT
settings do not come into play at this point.

The important thing to note is that once a list is created, changes to
DEFAULT... settings in mm_cfg.py will not affect anything on an existing
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  Thu May  5 01:01:25 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 4 May 2016 22:01:25 -0700
Subject: [Mailman-Users] dnspython not found error
In-Reply-To: <5b2883ba-360c-3803-ea3f-f62e03b209b8@networktest.com>
References: <5b2883ba-360c-3803-ea3f-f62e03b209b8@networktest.com>
Message-ID: <572AD3A5.2000305@msapiro.net>

On 05/04/2016 11:27 AM, David Newman wrote:
> Had to reinstall the Mailman port (not pkg) on a FreeBSD 10.3-RELEASE
> system after updating some ports due to security vulnerabilities.
> Several other packages also required rebuild to point to new shared objects.
> 
> The Mailman build failed, saying 'dnspython not found' even though that
> port is installed:
> 
> root at mail:/usr/ports/mail/mailman # pkg info | grep dnspython
> py27-dnspython-1.12.0          DNS toolkit for Python


what happens when you invoke /usr/local/bin/python2.7 and then do

import dns.resolver

Does that succeed or throw ImportError?

If it succeeds, then configure should too as that's what it's doing and
the python it's using.

If it throws ImportError, then something is wrong in that the python at
/usr/local/bin/python2.7 is not able to access the dnspython package.

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

From curtis at ipv6.occnc.com  Thu May  5 17:39:54 2016
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Thu, 05 May 2016 17:39:54 -0400
Subject: [Mailman-Users] disable DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in
 mailman 2.1
In-Reply-To: Your message of "Wed, 04 May 2016 18:29:26 -0700."
 <572AA1F6.8090807@msapiro.net>
Message-ID: <3r17cG4y7LzFqQ8@mail.python.org>

In message <572AA1F6.8090807 at msapiro.net>
Mark Sapiro writes:
 
> On 05/03/2016 12:26 PM, Curtis Villamizar wrote:
> > By default DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL is set to
> > https://publicsuffix.org/list/public_suffix_list.dat
> > 
> > I have mailman set up on an IPv6 only host and publicsuffix.org has no
> > IPv6 address.  A near identical configuration is set up on a dual
> > stack host.  Any email to the IPv6 only host fails with an entry in
> > logs/error of the form "Unable to retrieve data from
> > https://publicsuffix.org/list/public_suffix_list.dat: <urlopen error
> > [Errno 43] Protocol not supported>"
>  
>  
> The log entry seems correct for this situation. The mail delivery
> failure is unrelated - see below.
>  
>  
> > In the mean time I would like to disable the use of
> > DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL by setting it empty.  To do this
> > it seems that I would need the following change:
> > 
> > --- Mailman/Utils.py.orig       2016-04-09 04:08:56.000000000 -0400
> > +++ Mailman/Utils.py    2016-05-03 14:37:12.683904000 -0400
> > @@ -1205,6 +1205,8 @@
> >      Domain which may be the same as the input."""
> >      global s_dict
> >      if not s_dict:
> > -        get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
> > +        if mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL:
> > +            get_suffixes(mm_cfg.DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL)
> >      hits = []
> >      d = domain.lower().split('.')
> > 
> > This works for .com, .org, .net, etc but not for things like co.uk,
> > etc (which in my case is not an issue).
>  
>  
> This is a bug. I've created
> <https://bugs.launchpad.net/mailman/+bug/1578450> and have fixed it, but
> not as above, although as above should work. The fix is at
> <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1648>

OK.  Same change except in the called function instead of the caller.

> > A second question is why does failing to access publicsuffix.org
> > result in a hard fail rather than a soft fail?  The change I made just
> > skips over get_suffixes and leaves s_dict empty.  It seems that
> > get_suffixes does do a try and except which logs and returns, but then
> > the mail gets rejected and the reason is not clear to me.  In
> > logs/smtp-failure there is a message of the form "failed with code
> > 554: 5.7.1 <fqdn[ipv6addr]>: Client host rejected: Access denied".
>  
>  
> The above message in smtp-failure is saying Mailman is trying to send
> mail to the list or whatever and the recipient MX for this delivery does
> not allow IPv6 access to its MTA, at least not from you. This has
> nothing to do with the changes you made to skip loading
> DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL. I think it is going to be a
> serious problem if you are trying to send mail in general because not
> every recipient domain is going to be listening on port 25 at an IPv6
> address.

I'm not sure what the problem was.

The only thing I'm sure of is testing the config using IPv6 only was
what tripped the bug above.

> I think if your outgoing MTA is connecting only to IPv6 addresses, you
> will have difficulty delivering mail in general regardless of the source
> of the mail.

That's not it.

This was a test mailing list with one recipient - one of my email
addresses.

> As for as why it's a 554: 5.7.1 hard fail, That's the status your MTA is
> giving to this condition. If you think this should be a 4xx status, you
> may be able to configure that in your MTA.

I think this might have been due to a connect to port 25 rather than
running sendmail.  Connect to port 25 would only work if using TLS
(after STARTTLS) and then passing SASL auth.  This host acts as an MDA
and as a MSA for mailman using a dual-stack "smarthost" relay but not
as an MX/MTA (MX points to two DS MTA and the MTA relays to it).

If that is the case it was a config problem in mailman.  I'm still
working on backing up and restoring a complete mailman config.  (That
could be another topic).

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

Thanks for the help.  This was a replacement server, upgraded due to
security advisories, and is now in use.

And BTW - the server was given an IPv4 address before going to
production use but the IPv4 is only needed for apache, not for the
email setup.  The IPv4 may be dropped entirely in the future since I
don't use the web interface anymore.  Recipients are populated from a
database - which is one thing that has always worked fine.

Curtis

From mark at msapiro.net  Thu May  5 18:16:57 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 5 May 2016 15:16:57 -0700
Subject: [Mailman-Users] disable DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in
 mailman 2.1
Message-ID: <572BC659.1070401@msapiro.net>

On 05/05/2016 02:39 PM, Curtis Villamizar wrote:
> 
> And BTW - the server was given an IPv4 address before going to
> production use but the IPv4 is only needed for apache, not for the
> email setup.  The IPv4 may be dropped entirely in the future since I
> don't use the web interface anymore.  Recipients are populated from a
> database - which is one thing that has always worked fine.


If your email address for @python.org email lists is on a server that
only accepts connects at an IPv6 address, you will stop getting all list
mail. The current cloud server for mail.python.org is blocked from
sending to port 25 at IPv6 addresses.

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

From curtis at ipv6.occnc.com  Thu May  5 19:21:33 2016
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Thu, 05 May 2016 19:21:33 -0400
Subject: [Mailman-Users] IPv6 MDA (was Re: disable
 DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL ...)
In-Reply-To: Your message of "Thu, 05 May 2016 15:16:57 -0700."
 <572BC659.1070401@msapiro.net>
Message-ID: <3r19sC5rbrzFqK8@mail.python.org>

In message <572BC659.1070401 at msapiro.net>
Mark Sapiro writes:
 
> On 05/05/2016 02:39 PM, Curtis Villamizar wrote:
> > 
> > And BTW - the server was given an IPv4 address before going to
> > production use but the IPv4 is only needed for apache, not for the
> > email setup.  The IPv4 may be dropped entirely in the future since I
> > don't use the web interface anymore.  Recipients are populated from a
> > database - which is one thing that has always worked fine.
>  
>  
> If your email address for @python.org email lists is on a server that
> only accepts connects at an IPv6 address, you will stop getting all list
> mail. The current cloud server for mail.python.org is blocked from
> sending to port 25 at IPv6 addresses.
>  
> -- 
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan


In pictures (-> is same host, ---> between hosts):

  dual stack        IPv6 only

  mta2 or mta3 ---> mda -> mailman
  
  mta2         <--- mda <- mailman

On the MTA relay_map is used.  On the MDA relayhost is used.

So all mail in or out goes goes by way of one of the dual stack hosts.

It works.  Really.  :-)  Look at the Received headers.

Cutover from an old mailman host to new just means modifying relay_map
file on the mta (old to none, then none to new, where none is a fqdn
with no host so that mail fails and gets spooled, then sent after the
second change).

If the mda/mailman host is also running apache, then I need IPv4 for
people who don't have IPv6 to get to the web interface.  No one seems
to use (or want) the archives on this host.  Subscriptions are from a
database populated by other means.  So the web interface is currently
unused (but take it away and someone is bound to try to use it).

Curtis

From curtis at ipv6.occnc.com  Thu May  5 19:31:33 2016
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Thu, 05 May 2016 19:31:33 -0400
Subject: [Mailman-Users] resend - mailman 2.1.21 - dmarc check problem
Message-ID: <3r1B4l3JZDzFqM6@mail.python.org>

Mark,

Sorry for the duplicate.

In message <572AA8E4.9070405 at msapiro.net>
Mark Sapiro writes:
 
> On 05/04/2016 09:27 AM, Curtis Villamizar wrote:
> > I'm resending this with a new subject.  The last email just
> > disappeared (no bounce).  Maybe having
> > DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in the subject tripped an all
> > caps in subject test.  (Or the moderator is slacking?)
>  
>  
> A moderator (me) approved your post and cleared your mod bit
> approximately 2 hours before you posted this. My reply to that post is
> at <https://mail.python.org/pipermail/mailman-users/2016-May/080772.html>.
>  
> I don't know why you didn't receive it. It was successfully sent per
>  
> May  4 10:36:04 mail postfix/smtp[22778]: 3r0LDW0F1DzFqP0:
> to=<curtis at ipv6.occnc.com>,
> relay=mta2-em1.orleans.occnc.com[50.252.223.140]:25, delay=42,
> delays=0.08/0/31/11, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
> 316BF9DDA)
>  
> (time stamp is UTC - 0400)

Odd that is says 10:36.  The URL in the archive says Wed May 4
21:29:26 EDT 2016 which matches mail headers.

> Maybe the ALL CAPS filtered it at your end.

I got the reply.  I just didn't get any "held by moderator" so wasn't
sure if my first mail went into a black hole.  Did one get sent?

Mail crossed.  Your mail was sent (according to mail headers) at:

  Date: Wed, 4 May 2016 18:29:26 -0700

My duplicate was sent on:

  Date: Wed, 04 May 2016 12:27:24 -0400

which is 15:27 in -0700 land.  My duplicate was sent 3 hours before
your reply.

In any case, sorry for the duplicate.  If this was a "first time only"
moderator action, then it can't happen again.

Either way I appologize for being impatient.

Curtis


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

From curtis at ipv6.occnc.com  Thu May  5 19:33:04 2016
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Thu, 05 May 2016 19:33:04 -0400
Subject: [Mailman-Users] nodupes doesn't seem to be working with aliases
Message-ID: <3r1B6T4yR8zFqGg@mail.python.org>

I'm not sure if this counts as suppressable dupes.  All users have
nodupes set.

  bin/export.py | grep nodupes | wc -l
       183
  bin/export.py | grep nodupes | grep -v True | wc -l
         0

I have a postfix virtual-alias of the form:

  a    b, c, d
  c    e, f
  d    g, h
  g    i, j
  h    k, l

If I send mail to a set of mailing lists then dupes get suppressed but
not if I send to an alias that expands to the same set of mailing
lists.  Mailman gets two copies from postfix but the message-id is the
same for both.  There is a to= and orig_to= in maillog but the
messages should be otherwise identical including the timestamps.

Is there a way to suppress dupes in this situation?

I have 5 such aliases for convenience but if I can't suppress dupes
its an annoyance since some people are on multiple mailing lists.  For
some reason I thought this used to work (but might have imagined it).

I'd rather not send a bunch of cross posted test messages, though if
more info is needed I can create some new "just for test" mailing
lists and aliases (on a just for test server if need be).

Curtis

From mark at msapiro.net  Thu May  5 22:02:32 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 5 May 2016 19:02:32 -0700
Subject: [Mailman-Users] resend - mailman 2.1.21 - dmarc check problem
In-Reply-To: <3r1B4l3JZDzFqM6@mail.python.org>
References: <3r1B4l3JZDzFqM6@mail.python.org>
Message-ID: <572BFB38.7060706@msapiro.net>

On 05/05/2016 04:31 PM, Curtis Villamizar wrote:
> Mark,
> 
> Sorry for the duplicate.
> 
> In message <572AA8E4.9070405 at msapiro.net>
> Mark Sapiro writes:
>  
>> On 05/04/2016 09:27 AM, Curtis Villamizar wrote:
>>> I'm resending this with a new subject.  The last email just
>>> disappeared (no bounce).  Maybe having
>>> DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in the subject tripped an all
>>> caps in subject test.  (Or the moderator is slacking?)
>>  
>>  
>> A moderator (me) approved your post and cleared your mod bit
>> approximately 2 hours before you posted this. My reply to that post is
>> at <https://mail.python.org/pipermail/mailman-users/2016-May/080772.html>.
>>  
>> I don't know why you didn't receive it. It was successfully sent per
>>  
>> May  4 10:36:04 mail postfix/smtp[22778]: 3r0LDW0F1DzFqP0:
>> to=<curtis at ipv6.occnc.com>,
>> relay=mta2-em1.orleans.occnc.com[50.252.223.140]:25, delay=42,
>> delays=0.08/0/31/11, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
>> 316BF9DDA)
>>  
>> (time stamp is UTC - 0400)
> 
> Odd that is says 10:36.  The URL in the archive says Wed May 4
> 21:29:26 EDT 2016 which matches mail headers.


Look at the X-Mailman-Approved-At: header.


>> Maybe the ALL CAPS filtered it at your end.
> 
> I got the reply.  I just didn't get any "held by moderator" so wasn't
> sure if my first mail went into a black hole.  Did one get sent?


No. We don't send them. They create spam backscatter.


> Mail crossed.  Your mail was sent (according to mail headers) at:
> 
>   Date: Wed, 4 May 2016 18:29:26 -0700
> 
> My duplicate was sent on:
> 
>   Date: Wed, 04 May 2016 12:27:24 -0400
> 
> which is 15:27 in -0700 land.  My duplicate was sent 3 hours before
> your reply.


Agreed, but your original was approved and delivered to the list at
10:35 -0400, almost two hours before your follow-up was sent.


> In any case, sorry for the duplicate.  If this was a "first time only"
> moderator action, then it can't happen again.
> 
> Either way I appologize for being impatient.


Apology accepted. No problem. And your mod bit is now cleared so it was
a one time thing.

-- 
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 May  5 22:23:18 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 5 May 2016 19:23:18 -0700
Subject: [Mailman-Users] nodupes doesn't seem to be working with aliases
In-Reply-To: <3r1B6T4yR8zFqGg@mail.python.org>
References: <3r1B6T4yR8zFqGg@mail.python.org>
Message-ID: <572C0016.1080505@msapiro.net>

On 05/05/2016 04:33 PM, Curtis Villamizar wrote:
> 
> I have a postfix virtual-alias of the form:
> 
>   a    b, c, d
>   c    e, f
>   d    g, h
>   g    i, j
>   h    k, l
> 
> If I send mail to a set of mailing lists then dupes get suppressed but
> not if I send to an alias that expands to the same set of mailing
> lists.  Mailman gets two copies from postfix but the message-id is the
> same for both.  There is a to= and orig_to= in maillog but the
> messages should be otherwise identical including the timestamps.
> 
> Is there a way to suppress dupes in this situation?


Mailman's avoid duplicates setting does nothing about posts to multiple
lists. It only suppresses the list copy to a recipient who is also
directly addressed in To: or Cc:.

If I understand correctly, there's nothing you can do in Mailman about
this. Mailman has a Non-digest options -> regular_exclude_lists feature.

Your "If I send mail to a set of mailing lists then dupes get
suppressed" statement tells me you may already be using this. However,
it depends on the "sibling list" being explicit in To: or Cc: which will
not be the case when the post comes via an alias.


> I have 5 such aliases for convenience but if I can't suppress dupes
> its an annoyance since some people are on multiple mailing lists.  For
> some reason I thought this used to work (but might have imagined it).


If what I say above doesn't satisfactorily explain what you see, I'll
try further, but

1) avoid dups whon't affect this.

2) regular_exclude_lists can help but only if lists are explicitly
addressed. For example, if both c at domain and d at domain are in b at domain's
regular_exclude_lists and d at domain is in c at domain's
regular_exclude_lists, and a post is explicitly addressed to all three
of b at domain c at domain and d at domain, then a regular member of all three
lists will receive the post only from d at domain, a member of the two
lists c at domain and d at domain will receive the post only from d at domain, a
member of the two lists b at domain and d at domain will receive the post only
from d at domain and a member of the two lists b at domain and c at domain will
receive the post only from c at domain

However if the post is addressed to a at domain and forwarded to b, c and d
by an alias, none of b at domain, c at domain or d at domain will be an explicit
To: or Cc: addressee of the post so everyone will receieve a copy from
each list of which they are a member.

-- 
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 May  6 04:47:31 2016
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 6 May 2016 17:47:31 +0900
Subject: [Mailman-Users] Problems using Postfix with Mailman
In-Reply-To: <CAA13W+8__eh9f6vw0hTB9DvySN_FhZg__L33HHAwxeK9vzAL_g@mail.gmail.com>
References: <CAA13W+8kiqDSnBXk1YDKMRbUMhL0ZoCXNCd4StE7ew9w7pkAuA@mail.gmail.com>
 <57294887.8070707@msapiro.net>
 <CAA13W+8__eh9f6vw0hTB9DvySN_FhZg__L33HHAwxeK9vzAL_g@mail.gmail.com>
Message-ID: <22316.23075.86808.565274@turnbull.sk.tsukuba.ac.jp>

Christopher Adams writes:

 > Yes, you are so right. I did have an entry for 127.0.0.1  localhost in
 > /etc/hosts, but also the entry for IPV6, which I didn't need and it
 > apparently took preference.

This is a general property of IPv6: where available it takes
precedence.  Unfortunately, the definition of "available" used by the
low-level stack where this preference operates (ie, I can connect to
the port and get a TCP/IP-level response, including rejection) often
fails to conform to the human idea of "available" (ie, the resource
content is delivered).

That's way over-simplified, of course, but it's worth being aware that
enabling IPv6 may require configuration changes throughout your
application stack.  (And the way things are these days, with IPv6
being more and more important, you may get IPv6 without asking for it
in an OS upgrade or something.)




From stephen at xemacs.org  Fri May  6 04:54:24 2016
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 6 May 2016 17:54:24 +0900
Subject: [Mailman-Users]  dnspython not found error
In-Reply-To: <5b2883ba-360c-3803-ea3f-f62e03b209b8@networktest.com>
References: <5b2883ba-360c-3803-ea3f-f62e03b209b8@networktest.com>
Message-ID: <22316.23488.959778.992610@turnbull.sk.tsukuba.ac.jp>

David Newman writes:

 > The Mailman build failed, saying 'dnspython not found' even though that
 > port is installed:

Have you fixed this?  If so, please let us know, if not, here is
something that may be a hint:

Aside from what Mark said, this often indicates that Mailman is using
a different python from the one that the package was installed for.

 > python2-2_3
 > python27-2.7.11_2

The first one may be your system Python, and you may need to fix
up paths or use an explicit configuration directive to specify that
Mailman use python27, not python2.  It's also possible that the first
one is a "meta" package that doesn't actually include a python binary
(I haven't used BSD ports in a long time).  In this case the problem
is elsewhere.


From mark at msapiro.net  Fri May  6 17:49:30 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 6 May 2016 14:49:30 -0700
Subject: [Mailman-Users] disable DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in
 mailman 2.1
Message-ID: <572D116A.30009@msapiro.net>

On 05/05/2016 02:39 PM, Curtis Villamizar wrote:
> In message <572AA1F6.8090807 at msapiro.net>
> Mark Sapiro writes:
> 
>> As for as why it's a 554: 5.7.1 hard fail, That's the status your MTA is
>> giving to this condition. If you think this should be a 4xx status, you
>> may be able to configure that in your MTA.
> 
> I think this might have been due to a connect to port 25 rather than
> running sendmail.  Connect to port 25 would only work if using TLS
> (after STARTTLS) and then passing SASL auth.  This host acts as an MDA
> and as a MSA for mailman using a dual-stack "smarthost" relay but not
> as an MX/MTA (MX points to two DS MTA and the MTA relays to it).
> 
> If that is the case it was a config problem in mailman.  I'm still
> working on backing up and restoring a complete mailman config.  (That
> could be another topic).


I would strongly suggest you not use

DELIVERY_MODULE = 'Sendmail'

If you need TLS and SASL, use

DELIVERY_MODULE = 'SMTPDirect'

in conjunction with the patch at
<https://bugs.launchpad.net/mailman/+bug/558281>.

I have now (finally) applied a version of this patch at
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1649>.

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

From cpz at tuunq.com  Sat May  7 00:51:52 2016
From: cpz at tuunq.com (Carl Zwanzig)
Date: Fri, 6 May 2016 21:51:52 -0700
Subject: [Mailman-Users] dnspython not found error
In-Reply-To: <5b2883ba-360c-3803-ea3f-f62e03b209b8@networktest.com>
References: <5b2883ba-360c-3803-ea3f-f62e03b209b8@networktest.com>
Message-ID: <572D7468.3070606@tuunq.com>

On 5/4/2016 11:27 AM, David Newman wrote:
> Had to reinstall the Mailman port (not pkg) on a FreeBSD 10.3-RELEASE
> system after updating some ports due to security vulnerabilities.
> Several other packages also required rebuild to point to new shared objects.
>
> The Mailman build failed, saying 'dnspython not found' even though that
> port is installed:
>
> root at mail:/usr/ports/mail/mailman # pkg info | grep dnspython
> py27-dnspython-1.12.0          DNS toolkit for Python

I don't think that doesn't say whether it was installed from port or pkg.

FWIW, ports and packages don't always play nice together and many will say 
never to mix then (I do). It sounds like the Makefile is failing. On my 
current freebsd system, I installed mailman from source, not from the port, 
and don't recall any weird problems. All I can say is it's working for me.

Also, Mark's import test will tell you whether it's really there but it 
won't tell you about paths. My ports tree isn't up to date, but it's 
checking PYTHON_PKGNAMEPREFIX which comes from /usr/ports/Mk/Uses/python.mk.

The fix -may- be as simple as uninstalling python2-2_3.

z!
who's back at 10.1-RELEASE-p10


From cpz at tuunq.com  Sat May  7 16:40:55 2016
From: cpz at tuunq.com (Carl Zwanzig)
Date: Sat, 7 May 2016 13:40:55 -0700
Subject: [Mailman-Users] dnspython not found error
In-Reply-To: <572D7468.3070606@tuunq.com>
References: <5b2883ba-360c-3803-ea3f-f62e03b209b8@networktest.com>
 <572D7468.3070606@tuunq.com>
Message-ID: <572E52D7.5030900@tuunq.com>

On 5/6/2016 9:51 PM, Carl Zwanzig wrote:
> On 5/4/2016 11:27 AM, David Newman wrote:
>> root at mail:/usr/ports/mail/mailman # pkg info | grep dnspython
>> py27-dnspython-1.12.0          DNS toolkit for Python
>
> I don't think that doesn't say whether it was installed from port or pkg.

ARRGH! I have seeing things like that hours after writing/sending it.

Should read:
I don't think that says whether it was installed from port or pkg.

z!
"there is no prostitute for proofreading your own work"


From curtis at ipv6.occnc.com  Sun May  8 12:02:22 2016
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Sun, 08 May 2016 12:02:22 -0400
Subject: [Mailman-Users] disable DMARC_ORGANIZATIONAL_DOMAIN_DATA_URL in
 mailman 2.1
In-Reply-To: Your message of "Fri, 06 May 2016 14:49:30 -0700."
 <572D116A.30009@msapiro.net>
Message-ID: <3r2qz43ZyfzFr4Y@mail.python.org>

In message <572D116A.30009 at msapiro.net>
Mark Sapiro writes:
>
> On 05/05/2016 02:39 PM, Curtis Villamizar wrote:
> > In message <572AA1F6.8090807 at msapiro.net>
> > Mark Sapiro writes:
> >
> >> As for as why it's a 554: 5.7.1 hard fail, That's the status your MTA is
> >> giving to this condition. If you think this should be a 4xx status, you
> >> may be able to configure that in your MTA.
> >
> > I think this might have been due to a connect to port 25 rather than
> > running sendmail.  Connect to port 25 would only work if using TLS
> > (after STARTTLS) and then passing SASL auth.  This host acts as an MDA
> > and as a MSA for mailman using a dual-stack "smarthost" relay but not
> > as an MX/MTA (MX points to two DS MTA and the MTA relays to it).
> >
> > If that is the case it was a config problem in mailman.  I'm still
> > working on backing up and restoring a complete mailman config.  (That
> > could be another topic).
>
>
> I would strongly suggest you not use
>
> DELIVERY_MODULE = 'Sendmail'
>
> If you need TLS and SASL, use
>
> DELIVERY_MODULE = 'SMTPDirect'
>
> in conjunction with the patch at
> <https://bugs.launchpad.net/mailman/+bug/558281>.
>
> I have now (finally) applied a version of this patch at
> <http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1649>.


Mark,

Yes I remember reading that.  I did briefly set up to use Sendmail but
I forgot that I then changed it to have mailman use port 587 on the
same host where postfix was set up to only accepted connections from
its own addresses.  I did that before going live and that was a server
ago (rebuild everything from source since).

Thanks for pointing out this patch.  It would be preferable to pick up
the patch and use the MSA directly with TLS and SASL.

I'm rebuilding FreeBSD yet again due to security advisories.  There
are recent advisories on base (openssl and one on ntp that doesn't
apply to me - don't use ntp in that way) and so I'm rebuilding the
base and all the ports I use.  I can use this oportunity to apply this
as a local patch (FreeBSD ports is at mailman-2.1.22 and no mailman3
port yet, not that it would be all that hard to write a ports makefile
and debug it - just don't have the time at this point).

On FreeBSD its a matter of:
   fetch -o /usr/ports/mail/mailman/files/patch-Mailman-TLS+SASL \
   http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/diff/1649?context=3
Edit out or fix the patch to the News file since it doesn't apply
cleanly.  I just deleted that part of the patch.  Then:
  cd /usr/ports/mail/mailman
  make deinstall && rm -rf work && make install
optional:
  make PACKAGES=/usr/packages package

I'm only now starting to use mailman again after a long (decade+)
period of not maintaining any mailing lists.  It might be a while
before I get things right.  Thanks for the help.

Curtis


ps - Mark - sorry for the duplicate.  I forgot to change this to send
from the domain I'm subscribed on.  I need to add another subscribe
with no delivery to fix this.

From curtis at ipv6.occnc.com  Sun May  8 15:07:55 2016
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Sun, 08 May 2016 15:07:55 -0400
Subject: [Mailman-Users] nodupes doesn't seem to be working with aliases
In-Reply-To: Your message of "Thu, 05 May 2016 19:23:18 -0700."
 <572C0016.1080505@msapiro.net>
Message-ID: <3r2w5B5PVFzFqT3@mail.python.org>

trimmed.

In message <572C0016.1080505 at msapiro.net>
Mark Sapiro writes:
> 
> Your "If I send mail to a set of mailing lists then dupes get
> suppressed" statement tells me you may already be using this. However,
> it depends on the "sibling list" being explicit in To: or Cc: which will
> not be the case when the post comes via an alias.

That explains it.  My mistake in setting up this way.

> > I have 5 such aliases for convenience but if I can't suppress dupes
> > its an annoyance since some people are on multiple mailing lists.  For
> > some reason I thought this used to work (but might have imagined it).

I'll have to rework my local solution.  Since all mailman
subscriptions are generated from a database maintained elsewhere, I
just need to replace the aliases with new mailing lists that are
supersets.  A bit of work but doable.  Until then, I'll just manually
expand on the Cc to the set of lists covered by an alias to avoid
sending dups.  These lists go to a set of non-technical volunteers so
best not to annoy them.  Volunteers are already hard to come by.

Curtis

From her at adm.ku.dk  Mon May  9 08:55:55 2016
From: her at adm.ku.dk (Henrik Rasmussen)
Date: Mon, 9 May 2016 12:55:55 +0000
Subject: [Mailman-Users] What is the difference between welcome.msg and
 subscribeack.txt
Message-ID: <6DCC3E5DA06FE346B4DE4876C4F2713D018098C5A8@P2KITMBX06WC03.unicph.domain>

The welcome message that is sent to new subscribers (provided that "General Options -> Send_welcome_msg" is set to Yes) comes from the text file /var/lib/mailman/lists/LISTNAME/en/subscribeack.txt. If this file includes %(welcome)s, the information from the field "General Options -> welcome_msg" is also included.

Both can be edited by the list admin from the admin webinterface in General Options -> welcome_msg and "HTML Page Editing" -> "Welcome email text file", respectively.

What is the difference between the welcome_msg text box and the subscribeack.txt and why would you, as list admin, edit one over the other?

Yours faithfully

Henrik Rasmussen

From kalabalik at gmx.net  Mon May  9 17:04:12 2016
From: kalabalik at gmx.net (Kala Balik)
Date: Mon, 9 May 2016 23:04:12 +0200
Subject: [Mailman-Users] Meaning of "Postfix SMTP server: errors from
 dd11328.otherdomain.tld[ip.ip.ip.ip]"
Message-ID: <5730FB4C.8080304@gmx.net>

Dear List-Members,

today we ran our first mailing over our new Mailman instance. We
received a few bounces and the following email which left me clueless.

Please, what is this message trying to tell me? Is this us sending out,
or is this someone trying to answer to our mailing (and failing to log
in via TLS)? I checked my /var/log/mail logs - to no avail.

Thanks for your answers!

Cordially,
KB


Transcript of session follows.

 Out: 220 lists.domain.tld ESMTP Postfix (Ubuntu)
 In:  EHLO dd11328.otherdomain.tld
 Out: 250-lists.domain.tld
 Out: 250-PIPELINING
 Out: 250-SIZE 10240000
 Out: 250-VRFY
 Out: 250-ETRN
 Out: 250-STARTTLS
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250 DSN
 In:  STARTTLS
 Out: 454 4.7.0 TLS not available due to local problem
 In:  MAIL FROM:<> SIZE=236
 Out: 250 2.1.0 Ok
 In:  RCPT TO:<list-bounces at lists.domain.tld>
     ORCPT=rfc822;list-bounces at lists.domain.tld
 Out: 250 2.1.5 Ok
 In:  RSET
 Out: 250 2.0.0 Ok
 In:  QUIT
 Out: 221 2.0.0 Bye


For other details, see the local mail logfile

From mark at msapiro.net  Tue May 10 11:24:33 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 10 May 2016 08:24:33 -0700
Subject: [Mailman-Users] Meaning of "Postfix SMTP server: errors from
 dd11328.otherdomain.tld[ip.ip.ip.ip]"
In-Reply-To: <5730FB4C.8080304@gmx.net>
References: <5730FB4C.8080304@gmx.net>
Message-ID: <c152b28c-e24e-6aa7-62e6-b2c27d1f095e@msapiro.net>

On 5/9/16 2:04 PM, Kala Balik wrote:
> 
> today we ran our first mailing over our new Mailman instance. We
> received a few bounces and the following email which left me clueless.
> 
> Please, what is this message trying to tell me? Is this us sending out,
> or is this someone trying to answer to our mailing (and failing to log
> in via TLS)? I checked my /var/log/mail logs - to no avail.


This apparently has nothing directly to do with Mailman on your server.


> Transcript of session follows.
> 
>  Out: 220 lists.domain.tld ESMTP Postfix (Ubuntu)
>  In:  EHLO dd11328.otherdomain.tld
>  Out: 250-lists.domain.tld
>  Out: 250-PIPELINING
>  Out: 250-SIZE 10240000
>  Out: 250-VRFY
>  Out: 250-ETRN
>  Out: 250-STARTTLS
>  Out: 250-ENHANCEDSTATUSCODES
>  Out: 250-8BITMIME
>  Out: 250 DSN
>  In:  STARTTLS
>  Out: 454 4.7.0 TLS not available due to local problem
>  In:  MAIL FROM:<> SIZE=236
>  Out: 250 2.1.0 Ok
>  In:  RCPT TO:<list-bounces at lists.domain.tld>
>      ORCPT=rfc822;list-bounces at lists.domain.tld
>  Out: 250 2.1.5 Ok
>  In:  RSET
>  Out: 250 2.0.0 Ok
>  In:  QUIT
>  Out: 221 2.0.0 Bye


It looks to me like the server that identifies itself as
dd11328.otherdomain.tld started to send a message (probably a legitimate
bounce of a list message) to <list-bounces at lists.domain.tld>. It send
the RCPT TO:, was sent an OK in reply and then instead of sending the
DATA, reset the connection and quit. Possibly this is because the
sending server requires TLS which your Postfix says is not available.

Why your Postfix decided to notify you of this is a Postfix question.

I suggest you set both

smtp_tls_security_level = may

and

smtpd_tls_security_level = may

in your Postfix main.cf so that you accept incoming TLS if offered and
offer outgoing TLS. You will also need to set smtpd_tls_cert_file and
smtpd_tls_key_file and maybe others. See
<http://www.postfix.org/TLS_README.html>.

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

From kalabalik at gmx.net  Tue May 10 19:16:28 2016
From: kalabalik at gmx.net (Kala Balik)
Date: Wed, 11 May 2016 01:16:28 +0200
Subject: [Mailman-Users] Meaning of "Postfix SMTP server: errors from
 dd11328.otherdomain.tld[ip.ip.ip.ip]"
In-Reply-To: <c152b28c-e24e-6aa7-62e6-b2c27d1f095e@msapiro.net>
References: <5730FB4C.8080304@gmx.net>
 <c152b28c-e24e-6aa7-62e6-b2c27d1f095e@msapiro.net>
Message-ID: <57326BCC.1050904@gmx.net>

Dear Mark,

thank you for your helpful reply although your answer shows that my
question was off the list topic.

Am 10.05.2016 um 17:24 schrieb Mark Sapiro:
> On 5/9/16 2:04 PM, Kala Balik wrote:
>>
>> today we ran our first mailing over our new Mailman instance. We
>> received a few bounces and the following email which left me clueless.
>>
>> Please, what is this message trying to tell me? Is this us sending out,
>> or is this someone trying to answer to our mailing (and failing to log
>> in via TLS)? I checked my /var/log/mail logs - to no avail.
> 
> 
> This apparently has nothing directly to do with Mailman on your server.
> 
> 
>> Transcript of session follows.
>>
>>  Out: 220 lists.domain.tld ESMTP Postfix (Ubuntu)
>>  In:  EHLO dd11328.otherdomain.tld
>>  Out: 250-lists.domain.tld
>>  Out: 250-PIPELINING
>>  Out: 250-SIZE 10240000
>>  Out: 250-VRFY
>>  Out: 250-ETRN
>>  Out: 250-STARTTLS
>>  Out: 250-ENHANCEDSTATUSCODES
>>  Out: 250-8BITMIME
>>  Out: 250 DSN
>>  In:  STARTTLS
>>  Out: 454 4.7.0 TLS not available due to local problem
>>  In:  MAIL FROM:<> SIZE=236
>>  Out: 250 2.1.0 Ok
>>  In:  RCPT TO:<list-bounces at lists.domain.tld>
>>      ORCPT=rfc822;list-bounces at lists.domain.tld
>>  Out: 250 2.1.5 Ok
>>  In:  RSET
>>  Out: 250 2.0.0 Ok
>>  In:  QUIT
>>  Out: 221 2.0.0 Bye
> 
> 
> It looks to me like the server that identifies itself as
> dd11328.otherdomain.tld started to send a message (probably a legitimate
> bounce of a list message) to <list-bounces at lists.domain.tld>. It send
> the RCPT TO:, was sent an OK in reply and then instead of sending the
> DATA, reset the connection and quit. Possibly this is because the
> sending server requires TLS which your Postfix says is not available.
> 
> Why your Postfix decided to notify you of this is a Postfix question.
> 
> I suggest you set both
> 
> smtp_tls_security_level = may
> 
> and
> 
> smtpd_tls_security_level = may
> 
> in your Postfix main.cf so that you accept incoming TLS if offered and
> offer outgoing TLS. You will also need to set smtpd_tls_cert_file and
> smtpd_tls_key_file and maybe others. See
> <http://www.postfix.org/TLS_README.html>.
> 
Will implement these postfix changes as soon as possible.
Cordially, KB

From heller at deepsoft.com  Thu May 12 13:25:24 2016
From: heller at deepsoft.com (Robert Heller)
Date: Thu, 12 May 2016 13:25:24 -0400
Subject: [Mailman-Users] What am I missing?
Message-ID: <201605121725.u4CHPO11021981@sharky2.deepsoft.com>

I just installed mailman 2.1.16 on a new (CentOS 6) server and copied the data
and configuration data from my old server (CentOS 5) also running mailman
2.1.16. The old server is stil the 'production server' and mailman's page is
mailman.deepsoft.com. I am trying to test things on the new server but I am
having a problem I cannot figure out. I changed the http mailman.conf to have
a ServerName of mailman2.deepsoft.com and changed things in the
/etc/mailman/mm_cfg.py to have the default URL be mailman2.deepsoft.com, but
for some (unknown) reason, when I go to mailman2.deepsoft.com in firefox, it
redirects to mailman.deepsoft.com. If I use lynx, it properly goes to
http://mailman2.deepsoft.com/mailman/listinfo, but displays a bug message.
Why? What config file did I miss?

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

From mark at msapiro.net  Thu May 12 15:26:20 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 12 May 2016 12:26:20 -0700
Subject: [Mailman-Users] What am I missing?
In-Reply-To: <201605121725.u4CHPO11021981@sharky2.deepsoft.com>
References: <201605121725.u4CHPO11021981@sharky2.deepsoft.com>
Message-ID: <164851a7-d06f-787b-bf20-cbc3e6e71f92@msapiro.net>

On 5/12/16 10:25 AM, Robert Heller wrote:
> I just installed mailman 2.1.16 on a new (CentOS 6) server and copied the data
> and configuration data from my old server (CentOS 5) also running mailman
> 2.1.16.


6 releases and over 2.5 years old.


> The old server is stil the 'production server' and mailman's page is
> mailman.deepsoft.com. I am trying to test things on the new server but I am
> having a problem I cannot figure out. I changed the http mailman.conf to have
> a ServerName of mailman2.deepsoft.com and changed things in the
> /etc/mailman/mm_cfg.py to have the default URL be mailman2.deepsoft.com, but
> for some (unknown) reason, when I go to mailman2.deepsoft.com in firefox, it
> redirects to mailman.deepsoft.com. If I use lynx, it properly goes to
> http://mailman2.deepsoft.com/mailman/listinfo, but displays a bug message.
> Why? What config file did I miss?


I just tried going to <http://mailman2.deepsoft.com/mailman/listinfo>
and got the bug page. so that's one issue. What's in Mailman's error log
for these?

The other issue may just be something in your browser or it may be
Mailman. For Mailman, see the FAQ article at
<https://wiki.list.org/x/4030616>.

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

From heller at deepsoft.com  Thu May 12 16:49:11 2016
From: heller at deepsoft.com (Robert Heller)
Date: Thu, 12 May 2016 16:49:11 -0400
Subject: [Mailman-Users] What am I missing?
In-Reply-To: <164851a7-d06f-787b-bf20-cbc3e6e71f92@msapiro.net>
References: <201605121725.u4CHPO11021981@sharky2.deepsoft.com> 
 <164851a7-d06f-787b-bf20-cbc3e6e71f92@msapiro.net>
Message-ID: <201605122049.u4CKnB1E030478@sharky2.deepsoft.com>

At Thu, 12 May 2016 12:26:20 -0700 Mark Sapiro <mark at msapiro.net> wrote:

> 
> On 5/12/16 10:25 AM, Robert Heller wrote:
> > I just installed mailman 2.1.16 on a new (CentOS 6) server and copied the data
> > and configuration data from my old server (CentOS 5) also running mailman
> > 2.1.16.
> 
> 
> 6 releases and over 2.5 years old.

Yeah, but it work.  I may upgrade to 2.1.18 or 2.1.20 -- I have the SRPMs from 
Fedora 21 and I'll bring them home tonight...

> 
> 
> > The old server is stil the 'production server' and mailman's page is
> > mailman.deepsoft.com. I am trying to test things on the new server but I am
> > having a problem I cannot figure out. I changed the http mailman.conf to have
> > a ServerName of mailman2.deepsoft.com and changed things in the
> > /etc/mailman/mm_cfg.py to have the default URL be mailman2.deepsoft.com, but
> > for some (unknown) reason, when I go to mailman2.deepsoft.com in firefox, it
> > redirects to mailman.deepsoft.com. If I use lynx, it properly goes to
> > http://mailman2.deepsoft.com/mailman/listinfo, but displays a bug message.
> > Why? What config file did I miss?
> 
> 
> I just tried going to <http://mailman2.deepsoft.com/mailman/listinfo>
> and got the bug page. so that's one issue. What's in Mailman's error log
> for these?

OK, I discovered it was a file permission issue I chowned the /var/log/mailman 
dir to apache:mailman.  I did the same for /var/lib/mailman as well.

Now the http://mailman2.deepsoft.com/mailman/listinfo 'works', but does not 
list any lists -- they are there and if the lists are manually entered you can 
visit them -- it is *acting* like none of the lists are 'advertized'.

> 
> The other issue may just be something in your browser or it may be
> Mailman. For Mailman, see the FAQ article at
> <https://wiki.list.org/x/4030616>.
> 

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

From mark at msapiro.net  Thu May 12 17:36:23 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 12 May 2016 14:36:23 -0700
Subject: [Mailman-Users] What am I missing?
In-Reply-To: <201605122049.u4CKnB1E030478@sharky2.deepsoft.com>
References: <201605121725.u4CHPO11021981@sharky2.deepsoft.com>
 <164851a7-d06f-787b-bf20-cbc3e6e71f92@msapiro.net>
 <201605122049.u4CKnB1E030478@sharky2.deepsoft.com>
Message-ID: <4a497776-7a32-60fe-2669-f463fed1779f@msapiro.net>

On 5/12/16 1:49 PM, Robert Heller wrote:
> At Thu, 12 May 2016 12:26:20 -0700 Mark Sapiro <mark at msapiro.net> wrote:
> 
> Now the http://mailman2.deepsoft.com/mailman/listinfo 'works', but does not 
> list any lists -- they are there and if the lists are manually entered you can 
> visit them -- it is *acting* like none of the lists are 'advertized'.
> 
>>
>> The other issue may just be something in your browser or it may be
>> Mailman. For Mailman, see the FAQ article at
>> <https://wiki.list.org/x/4030616>.


The answer is in the above FAQ article, or more obviously in the one at
<https://wiki.list.org/x/4030613>.


If you are just testing and plan eventually to change the domain of the
new server to the production domain, then you may not want to change the
lists, but even for testing if you want post URLs to be to the new
server, you have to run 'fix_url' and change the lists.

Otherwise, you can just set VIRTUAL_HOST_OVERVIEW = Off or ignore the issue.

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

From heller at deepsoft.com  Thu May 12 20:26:04 2016
From: heller at deepsoft.com (Robert Heller)
Date: Thu, 12 May 2016 20:26:04 -0400
Subject: [Mailman-Users] What am I missing?
In-Reply-To: <4a497776-7a32-60fe-2669-f463fed1779f@msapiro.net>
References: <201605121725.u4CHPO11021981@sharky2.deepsoft.com> 
 <164851a7-d06f-787b-bf20-cbc3e6e71f92@msapiro.net> 
 <201605122049.u4CKnB1E030478@sharky2.deepsoft.com> 
 <4a497776-7a32-60fe-2669-f463fed1779f@msapiro.net>
Message-ID: <201605130026.u4D0Q4PQ004244@sharky2.deepsoft.com>

At Thu, 12 May 2016 14:36:23 -0700 Mark Sapiro <mark at msapiro.net> wrote:

> 
> On 5/12/16 1:49 PM, Robert Heller wrote:
> > At Thu, 12 May 2016 12:26:20 -0700 Mark Sapiro <mark at msapiro.net> wrote:
> > 
> > Now the http://mailman2.deepsoft.com/mailman/listinfo 'works', but does not 
> > list any lists -- they are there and if the lists are manually entered you can 
> > visit them -- it is *acting* like none of the lists are 'advertized'.
> > 
> >>
> >> The other issue may just be something in your browser or it may be
> >> Mailman. For Mailman, see the FAQ article at
> >> <https://wiki.list.org/x/4030616>.
> 
> 
> The answer is in the above FAQ article, or more obviously in the one at
> <https://wiki.list.org/x/4030613>.
> 
> 
> If you are just testing and plan eventually to change the domain of the
> new server to the production domain, then you may not want to change the
> lists, but even for testing if you want post URLs to be to the new
> server, you have to run 'fix_url' and change the lists.
> 
> Otherwise, you can just set VIRTUAL_HOST_OVERVIEW = Off or ignore the issue.

Yes.  I set VIRTUAL_HOST_OVERVIEW = Off in /etc/mailman/mm_cfg.py and will 
take that out once I make the new server the production server.

> 

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

From mark at msapiro.net  Fri May 13 12:03:25 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 13 May 2016 09:03:25 -0700
Subject: [Mailman-Users] What is the difference between welcome.msg and
 subscribeack.txt
In-Reply-To: <6DCC3E5DA06FE346B4DE4876C4F2713D018098C5A8@P2KITMBX06WC03.unicph.domain>
References: <6DCC3E5DA06FE346B4DE4876C4F2713D018098C5A8@P2KITMBX06WC03.unicph.domain>
Message-ID: <3fb9a5bf-1ca3-5282-2985-b0e4687ee2d0@msapiro.net>

On 5/9/16 5:55 AM, Henrik Rasmussen wrote:
> 
> Both can be edited by the list admin from the admin webinterface in General Options -> welcome_msg and "HTML Page Editing" -> "Welcome email text file", respectively.
> 
> What is the difference between the welcome_msg text box and the subscribeack.txt and why would you, as list admin, edit one over the other?


Historically, the ability to edit the subscribeack.txt template via the
admin UI was added in Mailman 2.1.6. Prior to that there was only the
welcome_msg to customize the welcome message.

The difference is welcome_msg is a list attribute, whereas a custom
subscribeack.txt template is a list and language specific template.

welcome_msg is simpler to edit and is part of the list's configuration,
but is only in the list's preferred language.

subscribeack.txt is more complex to edit, but allows editing of more
that just the 'welcome' paragraph. Also, by changing the list's
preferred_language via the web UI (or directly editing the templates/
directory, see <https://wiki.list.org/x/4030605>), it is possible to
have list specific versions of this template in different languages for
multi-language lists. but these templates are part of the Mailman
instalation itself rather than list attributes.

The bottom line is it probably doesn't matter which you use if the
welcome_msg is sufficient and if you don't need multiple languages, but
if a list is 'moved' to a different installation, the welcome_msg will
go with it ans the subscribeack.txt template(s) won't.

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

From jebva at yahoo.com  Fri May 13 20:10:34 2016
From: jebva at yahoo.com (JB)
Date: Sat, 14 May 2016 00:10:34 +0000 (UTC)
Subject: [Mailman-Users] What is the difference between welcome.msg and
 subscribeack.txt
References: <480255107.1790978.1463184635004.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <480255107.1790978.1463184635004.JavaMail.yahoo@mail.yahoo.com>

I always thought that the difference was that the acknowledge was sent when a new user requested to subscribe (to acknowledge the request and the new user to verify it) and that the welcome message was sent after the new user completed the subscribe process in its entirety as set up by the list owner.  This is what the names would indicate to me anyway.


--------------------------------------------
On Fri, 5/13/16, Mark Sapiro <mark at msapiro.net> wrote:

 Subject: Re: [Mailman-Users] What is the difference between welcome.msg and subscribeack.txt
 To: mailman-users at python.org
 Date: Friday, May 13, 2016, 12:03 PM
 
 On 5/9/16 5:55 AM, Henrik Rasmussen
 wrote:
 > 
 > Both can be edited by the list admin from the admin
 webinterface in General Options -> welcome_msg and "HTML
 Page Editing" -> "Welcome email text file",
 respectively.
 > 
 > What is the difference between the welcome_msg text box
 and the subscribeack.txt and why would you, as list admin,
 edit one over the other?
 
 
 Historically, the ability to edit the subscribeack.txt
 template via the
 admin UI was added in Mailman 2.1.6. Prior to that there was
 only the
 welcome_msg to customize the welcome message.
 
 The difference is welcome_msg is a list attribute, whereas a
 custom
 subscribeack.txt template is a list and language specific
 template.
 
 welcome_msg is simpler to edit and is part of the list's
 configuration,
 but is only in the list's preferred language.
 
 subscribeack.txt is more complex to edit, but allows editing
 of more
 that just the 'welcome' paragraph. Also, by changing the
 list's
 preferred_language via the web UI (or directly editing the
 templates/
 directory, see <https://wiki.list.org/x/4030605>), it
 is possible to
 have list specific versions of this template in different
 languages for
 multi-language lists. but these templates are part of the
 Mailman
 instalation itself rather than list attributes.
 
 The bottom line is it probably doesn't matter which you use
 if the
 welcome_msg is sufficient and if you don't need multiple
 languages, but
 if a list is 'moved' to a different installation, the
 welcome_msg will
 go with it ans the subscribeack.txt template(s) won't.
 
 -- 
 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/jebva%40yahoo.com

From mark at msapiro.net  Sat May 14 01:04:32 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 13 May 2016 22:04:32 -0700
Subject: [Mailman-Users] What is the difference between welcome.msg and
 subscribeack.txt
In-Reply-To: <480255107.1790978.1463184635004.JavaMail.yahoo@mail.yahoo.com>
References: <480255107.1790978.1463184635004.JavaMail.yahoo.ref@mail.yahoo.com>
 <480255107.1790978.1463184635004.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <7971f4a1-32df-9e63-e0a7-79f1864999ab@msapiro.net>

On 5/13/16 5:10 PM, JB via Mailman-Users wrote:
> I always thought that the difference was that the acknowledge was sent when a new user requested to subscribe (to acknowledge the request and the new user to verify it)


This message is the confirmation request sent to the subscriber if the
list's subscribe policy includes confirmation. This is built from the
verify.txt template which is not one that can be edited through the
admin GUI.


and that the welcome message was sent after the new user completed the
subscribe process in its entirety as set up by the list owner.  This is
what the names would indicate to me anyway.


That is correct and the welcome message is built from the GUI editable
subscribeack.txt template, the default of which includes the replacement
%(welcome)s which is replaced by the list's welcome_msg text.

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

From james at dorydesign.com  Mon May 16 00:47:50 2016
From: james at dorydesign.com (Jim Dory)
Date: Sun, 15 May 2016 20:47:50 -0800
Subject: [Mailman-Users] confirm email marked as spam - reduce unique
 identifier length?
Message-ID: <CAKhfoy03JC2jpOrG3nRbeyBPpE1Q69s-0GxQ42z9+yZK5EvJrg@mail.gmail.com>

Hello,

I manage a community list-serv and our host - Hawkhost.com , has had their
servers marking our subscription confirmation emails as spam so the end
user never sees them. They are held at the Hawkhost servers. In a trouble
ticket to them, they have postulated the following possible solution:

"
I believe that the subject of the confirmation email "confirm
40c7fa45251ce14ecd7c26c712648332fa3b326b" is triggering the spam experts
filter. Is it possible to reduce the subject line to something simpler? "

I do not know the answer - if it is possible to reduce that unique
identifier or not, or whether that would even help.

This trouble ticket has been ongoing for the last week and they have
released the held confirmation emails, but every new attempt at subscribing
is still blocked (held at their spam expert software quarantine or
whatever).

Suggestions? I manage the list for the community, but it is hosted by a
local club so would be a bit cumbersome to simply "change hosts". Plus we
have about 4GB of archives.

thanks for reading and any help.. Jim

From mark at msapiro.net  Mon May 16 08:53:27 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 16 May 2016 05:53:27 -0700
Subject: [Mailman-Users] confirm email marked as spam - reduce unique
 identifier length?
In-Reply-To: <CAKhfoy03JC2jpOrG3nRbeyBPpE1Q69s-0GxQ42z9+yZK5EvJrg@mail.gmail.com>
References: <CAKhfoy03JC2jpOrG3nRbeyBPpE1Q69s-0GxQ42z9+yZK5EvJrg@mail.gmail.com>
Message-ID: <3B4EF099-8C1F-49BB-9F64-022F833EF141@msapiro.net>

On May 15, 2016 9:47:50 PM PDT, Jim Dory <james at dorydesign.com> wrote:

>
>I believe that the subject of the confirmation email "confirm
>40c7fa45251ce14ecd7c26c712648332fa3b326b" is triggering the spam
>experts
>filter. Is it possible to reduce the subject line to something simpler?
>

Whoever manages the Mailman installation should set

VERP_CONFIRMATIONS = Yes

In mm_cfg.py. This may or may not require MTA changes to recognize '+' as a recipient delimiter.



-- 
Mark Sapiro <mark at msapiro.net>
Sent from my Not_an_iThing with standards compliant, open source software.

From stephen at xemacs.org  Tue May 17 03:09:52 2016
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 17 May 2016 16:09:52 +0900
Subject: [Mailman-Users] confirm email marked as spam - reduce unique
 identifier length?
In-Reply-To: <3B4EF099-8C1F-49BB-9F64-022F833EF141@msapiro.net>
References: <CAKhfoy03JC2jpOrG3nRbeyBPpE1Q69s-0GxQ42z9+yZK5EvJrg@mail.gmail.com>
 <3B4EF099-8C1F-49BB-9F64-022F833EF141@msapiro.net>
Message-ID: <22330.50112.603295.28965@turnbull.sk.tsukuba.ac.jp>

On May 15, 2016 9:47:50 PM PDT, Jim Dory <james at dorydesign.com> wrote:

 > >I believe that the subject of the confirmation email "confirm
 > >40c7fa45251ce14ecd7c26c712648332fa3b326b" is triggering the spam
 > >experts filter. Is it possible to reduce the subject line to
 > >something simpler?

That depends on your definition of "simple".  From the point of view
of the would-be subscriber, this is as simple as it gets.  Just hit
"reply", then "send", and she's done.  The token itself could be
reduced, but it's still going to be at *least* 5 or 6 characters, and
then it looks like spam to me.  I've gotten lots of spam from people
who put a 4-8 character ticket identifier in the Subject field.

Mark Sapiro writes:

 > Whoever manages the Mailman installation should set
 > 
 > VERP_CONFIRMATIONS = Yes
 > 
 > In mm_cfg.py. This may or may not require MTA changes to recognize
 > '+' as a recipient delimiter.

Note: this works by putting the confirmation token in the return
address after a '+'.  So it is *your* MTA that needs to recognize '+'
as ending the mailbox.  The confirmation message sent to the person
trying to subscribe goes to their usual address, so isn't a problem.
All the necessary configuration can be done at your end.  Whether your
host will help you is up to them, of course, but most sites that
support Mailman already have that configuration.



From t_ronalds at yahoo.com  Mon May 16 15:55:41 2016
From: t_ronalds at yahoo.com (Terence Ronalds)
Date: Mon, 16 May 2016 19:55:41 +0000 (UTC)
Subject: [Mailman-Users] Syntax question using the Web Interface with PHP
References: <1533969218.3506277.1463428541752.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1533969218.3506277.1463428541752.JavaMail.yahoo@mail.yahoo.com>

I'm trying to use the Web Interface from a PHP page and I have a problem when trying to add a person to a list. I can get it to work fine if I just add an email address to the list, however I can't figure out the syntax needed to also include their real name. Here's what I have that works so far:
<?php
$name='Adam B. Tester';
$email=adam at somewhere.com';
$sub_url = "http://lists.XXXX.com/admin.cgi/members-XXXX.com/members/add?subscribe_or_invite=0&send_welcome_msg_to_this_batch=0&notification_to_list_owner=0&adminpw=XXXX&subscribees_upload=";
$content=file_get_contents($sub_url . $email );
echo $content;?>
The page at https://wiki.list.org/DOC/Additional%20web%20administration%20tools doesn't explain well enough how to use the _realname parameter to get the person's name included in the transaction. Can anyone please show me how to change the above coding to do this?
Thanks!

From mark at msapiro.net  Tue May 17 12:32:14 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 17 May 2016 09:32:14 -0700
Subject: [Mailman-Users] Syntax question using the Web Interface with PHP
In-Reply-To: <1533969218.3506277.1463428541752.JavaMail.yahoo@mail.yahoo.com>
References: <1533969218.3506277.1463428541752.JavaMail.yahoo.ref@mail.yahoo.com>
 <1533969218.3506277.1463428541752.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <573B478E.600@msapiro.net>

On 05/16/2016 12:55 PM, Terence Ronalds via Mailman-Users wrote:
> I'm trying to use the Web Interface from a PHP page and I have a problem when trying to add a person to a list. I can get it to work fine if I just add an email address to the list, however I can't figure out the syntax needed to also include their real name. Here's what I have that works so far:
> <?php
> $name='Adam B. Tester';
> $email=adam at somewhere.com';
> $sub_url = "http://lists.XXXX.com/admin.cgi/members-XXXX.com/members/add?subscribe_or_invite=0&send_welcome_msg_to_this_batch=0&notification_to_list_owner=0&adminpw=XXXX&subscribees_upload=";
> $content=file_get_contents($sub_url . $email );
> echo $content;?>


There are a few issues in the above. Some, like the missing ' in
$email=adam at somewhere.com'; and members-XXXX.com instead of
members_XXXX.com in the cPanel list name, I will assume are just typos
introduced when you tried to make a redacted version of a working
script, but for the rest, I don't know what you tried, so I don't know
why it didn't work, but I would use 'subscribees' rather than
'subscribees_upload'[1], and the syntax you need for the name/address is
described at <https://wiki.list.org/x/4030562>.

Also since your real name has a period in it, it needs to be quoted as

$name='"Adam B. Tester"';

Then you can do something like

$content=file_get_contents($sub_url . "$name <" . $email . ">");

I didn't actually try this, so you may find you need to do something like

$content=file_get_contents($sub_url . urlencode("$name <" . $email . ">"));

[1] I didn't write the FAQ at <https://wiki.list.org/x/4030567>, but I
have just edited it to change subscribees_upload to subscribees and to
add a pointer to <https://wiki.list.org/x/4030562>.

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

From james at dorydesign.com  Tue May 17 13:08:53 2016
From: james at dorydesign.com (Jim Dory)
Date: Tue, 17 May 2016 09:08:53 -0800
Subject: [Mailman-Users] confirm email marked as spam - reduce unique
 identifier length?
In-Reply-To: <22330.50112.603295.28965@turnbull.sk.tsukuba.ac.jp>
References: <CAKhfoy03JC2jpOrG3nRbeyBPpE1Q69s-0GxQ42z9+yZK5EvJrg@mail.gmail.com>
 <3B4EF099-8C1F-49BB-9F64-022F833EF141@msapiro.net>
 <22330.50112.603295.28965@turnbull.sk.tsukuba.ac.jp>
Message-ID: <CAKhfoy3BMXzSyedyqN5BQDeysqGY-XE-MrvehEOneLDic9Zpiw@mail.gmail.com>

Thanks much guys, you've given me direction. I seem to only have access to
the /home directory on the server and the trouble ticket guys are saying
they can't make changes.. so pursuing those avenues. This is above my pay
grade as far as understanding MTAs, but can edit files via shell as I have
run linux servers in the past. The list in question has about 2100
subscribers - it is a community announcements and trade list - and I'm the
admin but don't make any money off it - just a volunteer.

Stephen:
The "simpler" was in a line from a quote from the tech support guys at the
host company. I see I didn't make that clear. I've asked them for more
clear directions on accessing the mm_cfg file or at least to verify the
current settings in it, as I don't seem to have permissions for the /etc
directory.
thx, JD

On Mon, May 16, 2016 at 11:09 PM, Stephen J. Turnbull <stephen at xemacs.org>
wrote:

> On May 15, 2016 9:47:50 PM PDT, Jim Dory <james at dorydesign.com> wrote:
>
>  > >I believe that the subject of the confirmation email "confirm
>  > >40c7fa45251ce14ecd7c26c712648332fa3b326b" is triggering the spam
>  > >experts filter. Is it possible to reduce the subject line to
>  > >something simpler?
>
> That depends on your definition of "simple".  From the point of view
> of the would-be subscriber, this is as simple as it gets.  Just hit
> "reply", then "send", and she's done.  The token itself could be
> reduced, but it's still going to be at *least* 5 or 6 characters, and
> then it looks like spam to me.  I've gotten lots of spam from people
> who put a 4-8 character ticket identifier in the Subject field.
>
> Mark Sapiro writes:
>
>  > Whoever manages the Mailman installation should set
>  >
>  > VERP_CONFIRMATIONS = Yes
>  >
>  > In mm_cfg.py. This may or may not require MTA changes to recognize
>  > '+' as a recipient delimiter.
>
> Note: this works by putting the confirmation token in the return
> address after a '+'.  So it is *your* MTA that needs to recognize '+'
> as ending the mailbox.  The confirmation message sent to the person
> trying to subscribe goes to their usual address, so isn't a problem.
> All the necessary configuration can be done at your end.  Whether your
> host will help you is up to them, of course, but most sites that
> support Mailman already have that configuration.
>
>
>

From mark at msapiro.net  Tue May 17 14:16:01 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 17 May 2016 11:16:01 -0700
Subject: [Mailman-Users] confirm email marked as spam - reduce unique
 identifier length?
In-Reply-To: <CAKhfoy3BMXzSyedyqN5BQDeysqGY-XE-MrvehEOneLDic9Zpiw@mail.gmail.com>
References: <CAKhfoy03JC2jpOrG3nRbeyBPpE1Q69s-0GxQ42z9+yZK5EvJrg@mail.gmail.com>
 <3B4EF099-8C1F-49BB-9F64-022F833EF141@msapiro.net>
 <22330.50112.603295.28965@turnbull.sk.tsukuba.ac.jp>
 <CAKhfoy3BMXzSyedyqN5BQDeysqGY-XE-MrvehEOneLDic9Zpiw@mail.gmail.com>
Message-ID: <573B5FE1.6080502@msapiro.net>

On 05/17/2016 10:08 AM, Jim Dory wrote:
> Thanks much guys, you've given me direction. I seem to only have access
> to the /home directory on the server and the trouble ticket guys are
> saying they can't make changes.. so pursuing those avenues. This is
> above my pay grade as far as understanding MTAs, but can edit files via
> shell as I have run linux servers in the past. The list in question has
> about 2100 subscribers - it is a community announcements and trade list
> - and I'm the admin but don't make any money off it - just a volunteer.


Is this a cPanel host? if so, the FAQ article at
<https://wiki.list.org/x/4030641> may help. Also, if it is cPanel, the
MTA is exim and the recipient delimiter stuff is not an issue.

The Mailman installation has a file Mailman/mm_cfg.py
(/usr/local/cpanel/3rdparty/mailman/Mailman/mm_cfg.py in cPanel).

This is the installation wide Mailman installation config file. All that
needs to be done is add the one line

VERP_CONFIRMATIONS = Yes

to the end of that file. If the host won't do this, their competence to
offer Mailman is questionable and you may wish to consider an
alternative for your list host.

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

From rex at rexgoode.com  Tue May 17 21:12:15 2016
From: rex at rexgoode.com (rex at rexgoode.com)
Date: Tue, 17 May 2016 18:12:15 -0700
Subject: [Mailman-Users] Error
Message-ID: <1323fde42dd91c7cd71181b4216df369@rexgoode.com>

The last time I posted here, my hosting company said that my newly 
upgraded plan did not support Mailman. I've been wrangling with them 
over that for a few weeks. They finally got it working, they said. All 
of my lists became active again, but now I can't send mail to them. I've 
sent this error to them, but I'm hoping someone here can help me.

When I hit send, I get:

SMTP Error (550): Failed to add recipient "listname at mydomain.com" (5.1.1 
<listname at mydomain.com>: Recipient address rejected: User unknown in 
virtual mailbox table).

This happens on all of my mailman lists. Substitute listname and 
mydomain.com appropriately, of course, but every list gets it.

Any advice I can give to my hosting company?

Rex

From mark at msapiro.net  Tue May 17 21:37:56 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 17 May 2016 18:37:56 -0700
Subject: [Mailman-Users] Error
In-Reply-To: <1323fde42dd91c7cd71181b4216df369@rexgoode.com>
References: <1323fde42dd91c7cd71181b4216df369@rexgoode.com>
Message-ID: <573BC774.5050401@msapiro.net>

On 05/17/2016 06:12 PM, rex at rexgoode.com wrote:
> 
> When I hit send, I get:
> 
> SMTP Error (550): Failed to add recipient "listname at mydomain.com" (5.1.1
> <listname at mydomain.com>: Recipient address rejected: User unknown in
> virtual mailbox table).
> 
> This happens on all of my mailman lists. Substitute listname and
> mydomain.com appropriately, of course, but every list gets it.
> 
> Any advice I can give to my hosting company?


This is an issue with the incoming MTA for mydomain.com. It does not
know how to deliver Mailman's mail. Typically with MTAs Sendmail and
Postfix, delivery is via aliases. There is info on configuring these and
also Exim and Qmail at
<http://www.list.org/mailman-install/mail-server.html>.

There is other info I could provide if I knew what the MTA is.

If they are actually willing to work on this, eliminate yourself from
the middle and refer them here. We will help as best as we can.

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

From guest2 at sgeinc.com  Fri May 20 08:35:07 2016
From: guest2 at sgeinc.com (Richard Shetron)
Date: Fri, 20 May 2016 08:35:07 -0400
Subject: [Mailman-Users] turn on tracing?
In-Reply-To: <571E31F5.80309@msapiro.net>
References: <571DA745.8080005@bradakis.com> <571E31F5.80309@msapiro.net>
Message-ID: <bae257de-ea35-4a17-b611-42312d42ae0b@sgeinc.com>

How do I turn on tracing to find the source of this error.  The 
interface worked until I told check_perms to fix permissions so I'm sure 
there is a permission issue.  Also the qrunner won't run, which I also 
suspect is a permission error.  My partner who did the install has 
retired for medical reasons so I'm trying to learn how to do all sorts 
of things in too little time :(  I tried to look in both the mailman 
logs and the apache logs for errors and didn't find anything.

Bug in Mailman version 2.1.21rc2

We're sorry, we hit a bug!

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.

From kross at vrcis.com  Fri May 20 11:18:15 2016
From: kross at vrcis.com (Caulfield Kevin Ross)
Date: Fri, 20 May 2016 08:18:15 -0700
Subject: [Mailman-Users] Lost GNU Web mgmg interface after MAC OSX update
Message-ID: <087001d1b2aa$d52b8a80$7f829f80$@vrcis.com>

Hi gang :

 

Silly question, during a MAC  OSX update we lost the ability to manage our
mailman GNU system using the http interface. 

Has anyone else encountered this ? Can you steer me in the direction of a
solution? I suspect the upgrade replaced the conf file or dropped 

Custom stanza's somewhere,  OSX is a bit of hybrid BSD flavor, and is not my
specialty. I will be submitting to an OSX board also.

 

Thanks in advance

 

Kevin Ross

 

 

 



 


From john at cibolo.com  Thu May 19 23:20:45 2016
From: john at cibolo.com (John Griessen)
Date: Thu, 19 May 2016 22:20:45 -0500
Subject: [Mailman-Users] mailman postfix connection on debian
Message-ID: <573E828D.6030706@cibolo.com>

I am setting up 2.1 on debian and get no receive of a mail to the server that is not a virtual_mailbox_domain address in postfix.
For instance, a reply to a subscribe request doesn't get received or even mentioned much by the MTA logs in /var/log/mail.log,
but a email to a virtual address, not local to the server, goes fine.

There are so many uids and gids I can't figure it:

This is  ll /run/dovecot    -->

srw------- 1 root    root       0 May 20 02:26 anvil
srw------- 1 root    root       0 May 20 02:26 anvil-auth-penalty
srw------- 1 dovecot root       0 May 20 02:26 auth-client
srw------- 1 dovecot root       0 May 20 02:26 auth-login
srw------- 1 root    root       0 May 20 02:26 auth-master
-rw------- 1 root    root      32 May 20 02:18 auth-token-secret.dat
srw------- 1 vmail   root       0 May 20 02:26 auth-userdb
srw------- 1 dovecot root       0 May 20 02:26 auth-worker
srw------- 1 root    root       0 May 20 02:26 config
srw------- 1 root    root       0 May 20 02:26 dict
srw------- 1 root    root       0 May 20 02:26 director-admin
srw-rw-rw- 1 root    root       0 May 20 02:26 dns-client
srw------- 1 root    root       0 May 20 02:26 doveadm-server
lrwxrwxrwx 1 root    root      25 May 20 02:26 dovecot.conf -> /etc/dovecot/dovecot.conf
drwxr-xr-x 2 root    root      40 May 20 02:18 empty
srw-rw-rw- 1 root    root       0 May 20 02:26 imap-urlauth
srw------- 1 dovecot root       0 May 20 02:26 imap-urlauth-worker
srw-rw-rw- 1 root    root       0 May 20 02:26 indexer
srw------- 1 dovecot root       0 May 20 02:26 indexer-worker
srw------- 1 root    root       0 May 20 02:26 ipc


  ll /run/mailman/

rw-rw---- 1 list list 4 May 20 02:18 mailman.pid


There's no telling what postfix is running as...


I tried a simplifying test and it seems not simple enough:

I wanted to send a test email, so I could see it in the logs:
I have a list called catjuggling for testing things out.  No users in it but me, no one to bother...

$ sudo echo "test email" | /var/lib/mailman/mail/mailman post catjuggling
Group mismatch error.  Mailman expected the mail
wrapper script to be executed as group "daemon", but
the system's mail server executed the mail script as
group "cibolo".  Try tweaking the mail server to run the
script as group "daemon", or re-run configure,
providing the command line option `--with-mail-gid=cibolo'.

If I su root I can send a message, and get a reponse from mailman that it is from no one, so needs approval,
so that tests that mailmanis intalled somewhat, and postfix is the hangup.

list and vmail are no login users, so can't test this that way...


$ postconf -n
-bash: postconf: command not found
cibolo at mail1:/etc/dovecot$ sudo postconf -n
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
mailbox_size_limit = 0
mydestination = cibolo.us, mail1.cibolo.us, localhost
mydomain = cibolo.us
myhostname = mail1
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = $mydomain
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/xxxxxxxxxxxxxxxxxxxxxxxxxx
smtpd_tls_key_file = /etc/xxxxxxxxxxxxxxxxxxxxxxx
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
virtual_alias_maps = hash:/etc/postfix/virtual_aliases
virtual_mailbox_domains = casaxxxxxxxxxx.com, casitaxxxxxxxxxxxx.com, etc.com
virtual_mailbox_maps = hash:/etc/postfix/vmailboxes
virtual_transport = lmtp:unix:private/dovecot-lmtp

====================mm_cfg.py changes===============
MTA='Postfix'
# Default domain for email addresses of newly created MLs
DEFAULT_EMAIL_HOST = 'cibolo.us'
#-------------------------------------------------------------
# Default host for web interface of newly created MLs
DEFAULT_URL_HOST   = 'mail1.cibolo.us'

Thanks,

John Griessen

From john at cibolo.com  Fri May 20 06:11:57 2016
From: john at cibolo.com (John Griessen)
Date: Fri, 20 May 2016 05:11:57 -0500
Subject: [Mailman-Users] mailman postfix connection on debian
In-Reply-To: <573E828D.6030706@cibolo.com>
References: <573E828D.6030706@cibolo.com>
Message-ID: <573EE2ED.50507@cibolo.com>

On 05/19/2016 10:20 PM, John Griessen wrote:
> I am setting up 2.1 on debian and get no receive of a mail to the server that is not a virtual_mailbox_domain address in postfix.

More specifically, I am replying to the confirmation message ( to catjuggling-request at cibolo.us)  after inviting a user to the list.
It seems to not work -- no hint of it in the logs.

I can send a message to a different related address, and see in the logs -- ( to catjuggling at cibolo.us)
(delivered to command: /var/lib/mailman/mail/mailman post catjuggling)
I can use the link to start a subscription via the web interface.

/etc/aliases has these lines:

# STANZA START: catjuggling
# CREATED: Thu May 19 23:07:53 2016
catjuggling:             "|/var/lib/mailman/mail/mailman post catjuggling"
catjuggling-admin:       "|/var/lib/mailman/mail/mailman admin catjuggling"
catjuggling-bounces:     "|/var/lib/mailman/mail/mailman bounces catjuggling"
catjuggling-confirm:     "|/var/lib/mailman/mail/mailman confirm catjuggling"
catjuggling-join:        "|/var/lib/mailman/mail/mailman join catjuggling"
catjuggling-leave:       "|/var/lib/mailman/mail/mailman leave catjuggling"
catjuggling-owner:       "|/var/lib/mailman/mail/mailman owner catjuggling"
catjuggling-request:     "|/var/lib/mailman/mail/mailman request catjuggling"
catjuggling-subscribe:   "|/var/lib/mailman/mail/mailman subscribe catjuggling"
catjuggling-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe catjuggling"
# STANZA END: catjuggling

/etc/aliases has been updated with
sudo newaliases

Any ideas what would cause catjuggling-request: to fail where
catjuggling: "|/var/lib/mailman/mail/mailman post catjuggling"
works?

From john at cibolo.com  Fri May 20 06:26:03 2016
From: john at cibolo.com (John Griessen)
Date: Fri, 20 May 2016 05:26:03 -0500
Subject: [Mailman-Users] mailman postfix connection on debian
In-Reply-To: <573EE2ED.50507@cibolo.com>
References: <573E828D.6030706@cibolo.com> <573EE2ED.50507@cibolo.com>
Message-ID: <573EE63B.3090008@cibolo.com>

On 05/20/2016 05:11 AM, John Griessen wrote:
>
> Any ideas what would cause catjuggling-request: to fail where
> catjuggling: "|/var/lib/mailman/mail/mailman post catjuggling"
> works?

Here is the log from starting a new invite to john at griessen.com.  the mail arrives as usual
from catjuggling-request at cibolo.us, and says "just reply".

May 20 10:12:32 localhost dovecot: lmtp(3639): Disconnect from local: Successful quit
May 20 10:12:32 localhost postfix/qmgr[1066]: 067D2618FF: removed
May 20 10:12:32 localhost postfix/smtpd[3632]: disconnect from mail-lb0-f191.google.com[209.85.217.191]
May 20 10:13:05 localhost postfix/smtpd[3636]: connect from localhost[::1]
May 20 10:13:05 localhost postfix/smtpd[3636]: 11BCC618FF: client=localhost[::1]
May 20 10:13:05 localhost postfix/cleanup[3637]: 11BCC618FF: message-id=<mailman.0.1463739184.3643.catjuggling at cibolo.us>
May 20 10:13:05 localhost postfix/qmgr[1066]: 11BCC618FF: from=<catjuggling-bounces at cibolo.us>, size=1855, nrcpt=1 (queue active)
May 20 10:13:05 localhost dovecot: lmtp(3639): Connect from local
May 20 10:13:05 localhost postfix/smtpd[3636]: disconnect from localhost[::1]
May 20 10:13:05 localhost dovecot: lmtp(3639, john at griessen.com): wnEeIg3jPlc3DgAA0J78UA: 
msgid=<mailman.0.1463739184.3643.catjuggling at cibolo.us>: saved mail to INBOX
May 20 10:13:05 localhost dovecot: lmtp(3639): Disconnect from local: Successful quit
May 20 10:13:05 localhost postfix/lmtp[3638]: 11BCC618FF: to=<john at griessen.com>, relay=mail1[private/dovecot-lmtp], delay=0.02, 
delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (250 2.0.0 <john at griessen.com> wnEeIg3jPlc3DgAA0J78UA Saved)
May 20 10:13:05 localhost postfix/qmgr[1066]: 11BCC618FF: removed

When I reply I see nothing in the log.

Soon after, I send another list mail from  an established subscriber and see it immediately

May 20 10:21:39 localhost postfix/qmgr[1066]: B787C61956: from=<bounces+2655086-814c-john=cottagematic.com at sendgrid.net>, 
size=1986, nrcpt=1 (queue active)
May 20 10:21:39 localhost dovecot: lmtp(3695): Connect from local
May 20 10:21:39 localhost dovecot: lmtp(3695, john at cottagematic.com): aDfeMzPlPldvDgAA0J78UA: 
msgid=<573EE531.2050201 at kitmatic.com>: saved mail to INBOX
May 20 10:21:39 localhost postfix/lmtp[3694]: B787C61956: to=<john at cottagematic.com>, relay=mail1[private/dovecot-lmtp], 
delay=0.19, delays=0.17/0.01/0/0.01, dsn=2.0.0, status=sent (250 2.0.0 <john at cottagematic.com> aDfeMzPlPldvDgAA0J78UA Saved)
May 20 10:21:39 localhost dovecot: lmtp(3695): Disconnect from local: Successful quit
May 20 10:21:39 localhost postfix/qmgr[1066]: B787C61956: removed


Could sendgrid ahve something to do with this?   Are they filtering my mails of a pattern that has been failing before?

From mark at msapiro.net  Fri May 20 11:54:47 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 08:54:47 -0700
Subject: [Mailman-Users] turn on tracing?
In-Reply-To: <bae257de-ea35-4a17-b611-42312d42ae0b@sgeinc.com>
References: <571DA745.8080005@bradakis.com> <571E31F5.80309@msapiro.net>
 <bae257de-ea35-4a17-b611-42312d42ae0b@sgeinc.com>
Message-ID: <573F3347.1030305@msapiro.net>

On 05/20/2016 05:35 AM, Richard Shetron wrote:
> How do I turn on tracing to find the source of this error.  The
> interface worked until I told check_perms to fix permissions so I'm sure
> there is a permission issue.  Also the qrunner won't run, which I also
> suspect is a permission error.  My partner who did the install has
> retired for medical reasons so I'm trying to learn how to do all sorts
> of things in too little time :(  I tried to look in both the mailman
> logs and the apache logs for errors and didn't find anything.
> 
> Bug in Mailman version 2.1.21rc2
> 
> We're sorry, we hit a bug!


There should be a traceback and other information about this error in
Mailman's error log. If it's not there, there is probably a permission
issue in writing the log.

You can at least temporarily ensure that Mailman's logs are writable by
anyone and see if that helps.

Also, you can edit $prefix/scripts/driver and at line 33 set

STEALTH_MODE = 0

and the traceback will be included on the "we hit a bug" page.

Also, if check_perms -f broke things, permissions must have been set in
some non-standard way to begin with. See the FAQ article at
<https://wiki.list.org/x/4030645>.

-- 
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 May 20 12:17:58 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 09:17:58 -0700
Subject: [Mailman-Users] Lost GNU Web mgmg interface after MAC OSX update
In-Reply-To: <087001d1b2aa$d52b8a80$7f829f80$@vrcis.com>
References: <087001d1b2aa$d52b8a80$7f829f80$@vrcis.com>
Message-ID: <573F38B6.1010404@msapiro.net>

On 05/20/2016 08:18 AM, Caulfield Kevin Ross wrote:
> 
> Silly question, during a MAC  OSX update we lost the ability to manage our
> mailman GNU system using the http interface. 


What happens when you try to go to the Mailman web GUI?

What is your web server?

What is in it's logs?

-- 
Mark Sapiro <mark 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 May 20 13:00:16 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 10:00:16 -0700
Subject: [Mailman-Users] mailman postfix connection on debian
In-Reply-To: <573E828D.6030706@cibolo.com>
References: <573E828D.6030706@cibolo.com>
Message-ID: <573F42A0.70601@msapiro.net>

On 05/19/2016 08:20 PM, John Griessen wrote:

> 
> I tried a simplifying test and it seems not simple enough:
> 
> I wanted to send a test email, so I could see it in the logs:
> I have a list called catjuggling for testing things out.  No users in it
> but me, no one to bother...
> 
> $ sudo echo "test email" | /var/lib/mailman/mail/mailman post catjuggling
> Group mismatch error.  Mailman expected the mail
> wrapper script to be executed as group "daemon", but
> the system's mail server executed the mail script as
> group "cibolo".  Try tweaking the mail server to run the
> script as group "daemon", or re-run configure,
> providing the command line option `--with-mail-gid=cibolo'.


You need to do

sudo -u daemon echo "test email" | /var/lib/mailman/mail/mailman post
catjuggling


> If I su root I can send a message, and get a reponse from mailman that
> it is from no one, so needs approval,
> so that tests that mailmanis intalled somewhat, and postfix is the hangup.
> 
> list and vmail are no login users, so can't test this that way...
> 
> 
> cibolo at mail1:/etc/dovecot$ sudo postconf -n
> alias_maps = hash:/etc/aliases

I can't tell how you expect to deliver to Mailman, but I see npo Mailman
aliases here?


> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> inet_interfaces = all
> mailbox_size_limit = 0
> mydestination = cibolo.us, mail1.cibolo.us, localhost
> mydomain = cibolo.us
> myhostname = mail1
> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
> myorigin = $mydomain
> readme_directory = no
> recipient_delimiter = +
> relayhost =
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
> defer_unauth_destination
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_path = private/auth
> smtpd_sasl_type = dovecot
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/xxxxxxxxxxxxxxxxxxxxxxxxxx
> smtpd_tls_key_file = /etc/xxxxxxxxxxxxxxxxxxxxxxx
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> virtual_alias_maps = hash:/etc/postfix/virtual_aliases
> virtual_mailbox_domains = casaxxxxxxxxxx.com, casitaxxxxxxxxxxxx.com,
> etc.com
> virtual_mailbox_maps = hash:/etc/postfix/vmailboxes
> virtual_transport = lmtp:unix:private/dovecot-lmtp


And Dovecot usually doesn't know how to deliver to Mailman


> ====================mm_cfg.py changes===============
> MTA='Postfix'
> # Default domain for email addresses of newly created MLs
> DEFAULT_EMAIL_HOST = 'cibolo.us'
> #-------------------------------------------------------------
> # Default host for web interface of newly created MLs
> DEFAULT_URL_HOST   = 'mail1.cibolo.us'


With the above you are generating aliases in Mailman's data/aliases, but
you aren't using them in Postfix. You have no
POSTFIX_STYLE_VIRTUAL_DOMAINS setting so you aren't generating virtual
mappings.

These FAQ articles may help:

<https://wiki.list.org/x/4030645>
<https://wiki.list.org/x/10715238>

and if you are trying to use postfix_to_mailman.py

<https://wiki.list.org/x/15564817>

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

From steve at tunedinweb.com  Fri May 20 12:57:38 2016
From: steve at tunedinweb.com (Steve Wehr)
Date: Fri, 20 May 2016 12:57:38 -0400
Subject: [Mailman-Users] Valid emails being unsubscribed?
Message-ID: <C3F57B50-8803-4739-A5EE-05E5EFF2E330@tunedinweb.com>

Hi Mark and friends,

I host about 100 mailing lists for clients, and have recently moved to a new installation of mailman. My clients are telling me they get lots of notices of people being unsubscribed from their lists, that they never got before, on the older version of mailman.

I've been trying to validate the unsubscribes, but I'm not sure how to do it. I look in mailman's bounce log, and see that bounces are being received and users are being unsubscribe. I looked in the postfix maillog, and I see successful sends to these users, then a bounce would be returned. 

I've done some spot checks by sending an email from my personal email account to a few of the users who have been unsubscribed, and all those emails go through successfully and are not bounced back to me. The users tell me they are not unsubscribing from the list. I've also see some emails being unsubscribed in the bounce log, that I personally sent to and know that those are valid email addresses.

Where could I go to learn more about why bounces are received, and try to debug this problem? Does the community have any suggestions for me? Thanks.

---------------
Steve Wehr 
Tunedin Web Design
www.Tunedinweb.com

From mark at msapiro.net  Fri May 20 13:08:35 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 10:08:35 -0700
Subject: [Mailman-Users] mailman postfix connection on debian
In-Reply-To: <573EE2ED.50507@cibolo.com>
References: <573E828D.6030706@cibolo.com> <573EE2ED.50507@cibolo.com>
Message-ID: <573F4493.7030202@msapiro.net>

On 05/20/2016 03:11 AM, John Griessen wrote:
> 
> More specifically, I am replying to the confirmation message ( to
> catjuggling-request at cibolo.us)  after inviting a user to the list.
> It seems to not work -- no hint of it in the logs.


Not even a message the the sending server connected in the postfix log?


> I can send a message to a different related address, and see in the logs
> -- ( to catjuggling at cibolo.us)
> (delivered to command: /var/lib/mailman/mail/mailman post catjuggling)
> I can use the link to start a subscription via the web interface.
> 
> /etc/aliases has these lines:
> 
> # STANZA START: catjuggling
> # CREATED: Thu May 19 23:07:53 2016
> catjuggling:             "|/var/lib/mailman/mail/mailman post catjuggling"
> catjuggling-admin:       "|/var/lib/mailman/mail/mailman admin catjuggling"
> catjuggling-bounces:     "|/var/lib/mailman/mail/mailman bounces
> catjuggling"
> catjuggling-confirm:     "|/var/lib/mailman/mail/mailman confirm
> catjuggling"
> catjuggling-join:        "|/var/lib/mailman/mail/mailman join catjuggling"
> catjuggling-leave:       "|/var/lib/mailman/mail/mailman leave catjuggling"
> catjuggling-owner:       "|/var/lib/mailman/mail/mailman owner catjuggling"
> catjuggling-request:     "|/var/lib/mailman/mail/mailman request
> catjuggling"
> catjuggling-subscribe:   "|/var/lib/mailman/mail/mailman subscribe
> catjuggling"
> catjuggling-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe
> catjuggling"
> # STANZA END: catjuggling


And how did they get there? You have MTA = 'Postfix' which generates
aliases automatically in Mailman's data/aliases which is not referenced
in alias_maps in Postfix main.cf.


> Any ideas what would cause catjuggling-request: to fail where
> catjuggling: "|/var/lib/mailman/mail/mailman post catjuggling"
> works?


There may be something missing in Dovecot or who knows. What is the
complete set of postfix log messages for the mail that ends up with
"(delivered to command: /var/lib/mailman/mail/mailman post catjuggling)"

-- 
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 May 20 13:28:42 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 10:28:42 -0700
Subject: [Mailman-Users] mailman postfix connection on debian
In-Reply-To: <573EE63B.3090008@cibolo.com>
References: <573E828D.6030706@cibolo.com> <573EE2ED.50507@cibolo.com>
 <573EE63B.3090008@cibolo.com>
Message-ID: <573F494A.6020601@msapiro.net>

On 05/20/2016 03:26 AM, John Griessen wrote:
> On 05/20/2016 05:11 AM, John Griessen wrote:
>>
>> Any ideas what would cause catjuggling-request: to fail where
>> catjuggling: "|/var/lib/mailman/mail/mailman post catjuggling"
>> works?
> 
> Here is the log from starting a new invite to john at griessen.com.  the
> mail arrives as usual
> from catjuggling-request at cibolo.us, and says "just reply".
> 
> May 20 10:12:32 localhost dovecot: lmtp(3639): Disconnect from local:
> Successful quit
> May 20 10:12:32 localhost postfix/qmgr[1066]: 067D2618FF: removed
> May 20 10:12:32 localhost postfix/smtpd[3632]: disconnect from
> mail-lb0-f191.google.com[209.85.217.191]
> May 20 10:13:05 localhost postfix/smtpd[3636]: connect from localhost[::1]
> May 20 10:13:05 localhost postfix/smtpd[3636]: 11BCC618FF:
> client=localhost[::1]
> May 20 10:13:05 localhost postfix/cleanup[3637]: 11BCC618FF:
> message-id=<mailman.0.1463739184.3643.catjuggling at cibolo.us>
> May 20 10:13:05 localhost postfix/qmgr[1066]: 11BCC618FF:
> from=<catjuggling-bounces at cibolo.us>, size=1855, nrcpt=1 (queue active)
> May 20 10:13:05 localhost dovecot: lmtp(3639): Connect from local
> May 20 10:13:05 localhost postfix/smtpd[3636]: disconnect from
> localhost[::1]
> May 20 10:13:05 localhost dovecot: lmtp(3639, john at griessen.com):
> wnEeIg3jPlc3DgAA0J78UA:
> msgid=<mailman.0.1463739184.3643.catjuggling at cibolo.us>: saved mail to
> INBOX
> May 20 10:13:05 localhost dovecot: lmtp(3639): Disconnect from local:
> Successful quit

So Dovecot delivered this mail to you.


> May 20 10:13:05 localhost postfix/lmtp[3638]: 11BCC618FF:
> to=<john at griessen.com>, relay=mail1[private/dovecot-lmtp], delay=0.02,
> delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (250 2.0.0
> <john at griessen.com> wnEeIg3jPlc3DgAA0J78UA Saved)
> May 20 10:13:05 localhost postfix/qmgr[1066]: 11BCC618FF: removed
> 
> When I reply I see nothing in the log.


Not even one like

 May 20 10:13:05 localhost postfix/smtpd[3636]: connect from localhost[::1]


> Soon after, I send another list mail from  an established subscriber and
> see it immediately
> 
> May 20 10:21:39 localhost postfix/qmgr[1066]: B787C61956:
> from=<bounces+2655086-814c-john=cottagematic.com at sendgrid.net>,
> size=1986, nrcpt=1 (queue active)
> May 20 10:21:39 localhost dovecot: lmtp(3695): Connect from local
> May 20 10:21:39 localhost dovecot: lmtp(3695, john at cottagematic.com):
> aDfeMzPlPldvDgAA0J78UA: msgid=<573EE531.2050201 at kitmatic.com>: saved
> mail to INBOX
> May 20 10:21:39 localhost postfix/lmtp[3694]: B787C61956:
> to=<john at cottagematic.com>, relay=mail1[private/dovecot-lmtp],
> delay=0.19, delays=0.17/0.01/0/0.01, dsn=2.0.0, status=sent (250 2.0.0
> <john at cottagematic.com> aDfeMzPlPldvDgAA0J78UA Saved)
> May 20 10:21:39 localhost dovecot: lmtp(3695): Disconnect from local:
> Successful quit
> May 20 10:21:39 localhost postfix/qmgr[1066]: B787C61956: removed
> 
> 
> Could sendgrid ahve something to do with this?   Are they filtering my
> mails of a pattern that has been failing before?


Possibly.

Your confirmations are

Reply-To: catjuggling-request at cibolo.us
Subject: confirm <long_hex_string>

There have been reports, e.g.,
<https://mail.python.org/pipermail/mailman-users/2016-May/080805.html>,
that this Subject: triggers spam filters.

Try setting

VERP_CONFIRMATIONS = Yes

in mm_cfg.py. this will make the message have

Reply-To: catjuggling-confirm+<<long_hex_string>@cibolo.us
Subject: Your confirmation is required to join the catjuggling mailing list

That may help.

-- 
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 May 20 13:40:24 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 10:40:24 -0700
Subject: [Mailman-Users] Valid emails being unsubscribed?
In-Reply-To: <C3F57B50-8803-4739-A5EE-05E5EFF2E330@tunedinweb.com>
References: <C3F57B50-8803-4739-A5EE-05E5EFF2E330@tunedinweb.com>
Message-ID: <573F4C08.5070308@msapiro.net>

On 05/20/2016 09:57 AM, Steve Wehr wrote:
> 
> Where could I go to learn more about why bounces are received, and try to debug this problem? Does the community have any suggestions for me? Thanks.


You need to see what the bounces are:

Ensure that the list's bounce processing settings
bounce_notify_owner_on_disable and if available (2.1.19 or later)
bounce_notify_owner_on_bounce_increment are set to Yes. Then the list
owner will get notices containing the actual bounce DSN and you can see
what the reasons are.

It is possible that recipients do not like the IP address or mail
configuration in your new installation, but normally this results in a
refusal at SMTP time rather than acceptance and return of a DSN

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

From Richard at Damon-Family.org  Fri May 20 13:43:42 2016
From: Richard at Damon-Family.org (Richard Damon)
Date: Fri, 20 May 2016 13:43:42 -0400
Subject: [Mailman-Users] Valid emails being unsubscribed?
In-Reply-To: <C3F57B50-8803-4739-A5EE-05E5EFF2E330@tunedinweb.com>
References: <C3F57B50-8803-4739-A5EE-05E5EFF2E330@tunedinweb.com>
Message-ID: <90574ac1-8662-83ef-6e1c-27baaba76801@Damon-Family.org>

On 5/20/16 12:57 PM, Steve Wehr wrote:
> Hi Mark and friends,
>
> I host about 100 mailing lists for clients, and have recently moved to a new installation of mailman. My clients are telling me they get lots of notices of people being unsubscribed from their lists, that they never got before, on the older version of mailman.
>
> I've been trying to validate the unsubscribes, but I'm not sure how to do it. I look in mailman's bounce log, and see that bounces are being received and users are being unsubscribe. I looked in the postfix maillog, and I see successful sends to these users, then a bounce would be returned.
>
> I've done some spot checks by sending an email from my personal email account to a few of the users who have been unsubscribed, and all those emails go through successfully and are not bounced back to me. The users tell me they are not unsubscribing from the list. I've also see some emails being unsubscribed in the bounce log, that I personally sent to and know that those are valid email addresses.
>
> Where could I go to learn more about why bounces are received, and try to debug this problem? Does the community have any suggestions for me? Thanks.
>
> ---------------
> Steve Wehr
> Tunedin Web Design
> www.Tunedinweb.com
>
Under Bounce Processing, you want Mailman to send a notification of the 
Subscribed Account being Disabled, that should include a copy of the 
last bounce that caused the subscriber to be disabled (and eventually 
unsubscribed). from that information you can start to trace the problem. 
Often it is caused by your list (or the server processing the list) to 
somehow having been placed on a blacklist.

You need to see a copy of the bounce message to see what the problem is, 
just the fact that a bounce occurred is rarely enough (It would be like 
going to the doctor and saying 'I'm sick, fix me' and not letting them 
examine you).


-- 
Richard Damon


From guest2 at sgeinc.com  Fri May 20 14:22:56 2016
From: guest2 at sgeinc.com (Richard Shetron)
Date: Fri, 20 May 2016 14:22:56 -0400
Subject: [Mailman-Users] turn on tracing?
In-Reply-To: <573F317D.2000809@msapiro.net>
References: <571DA745.8080005@bradakis.com> <571E31F5.80309@msapiro.net>
 <bae257de-ea35-4a17-b611-42312d42ae0b@sgeinc.com>
 <573F317D.2000809@msapiro.net>
Message-ID: <a1ec1d8c-82d1-6044-6416-14188cdb203e@sgeinc.com>

How do I find out what uid:gid the programs are running with?
Would I be better downloading a fresh copy of mailman and doing a 
reinstall over the broken copy?  The initial version was installed back 
in ubuntu 8.04 days when mailman wasn't a ubuntu package.  Since then 
for Ubuntu they changed some of the default groups for things, like 
mailing lists.

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

From mark at msapiro.net  Fri May 20 14:59:54 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 11:59:54 -0700
Subject: [Mailman-Users] turn on tracing?
In-Reply-To: <a1ec1d8c-82d1-6044-6416-14188cdb203e@sgeinc.com>
References: <571DA745.8080005@bradakis.com> <571E31F5.80309@msapiro.net>
 <bae257de-ea35-4a17-b611-42312d42ae0b@sgeinc.com>
 <573F317D.2000809@msapiro.net>
 <a1ec1d8c-82d1-6044-6416-14188cdb203e@sgeinc.com>
Message-ID: <573F5EAA.6090304@msapiro.net>

On 05/20/2016 11:22 AM, Richard Shetron wrote:
> How do I find out what uid:gid the programs are running with?

See 'man ps'

e.g.

ps -ewwo pid,euser,user,group,comm|egrep 'pickup|apache|python'

However, 'pickup' is a Postfix worker probably running as 'postfix', but
this is not the user/group under which Postfix will deliver to Mailman.
See the 'DELIVERY RIGHTS' paragraph in 'man local'. Note that the group
used is not the group of the aliases.db in which the alias was found. It
is the primary group of the owner of that file.


> Would I be better downloading a fresh copy of mailman and doing a
> reinstall over the broken copy?  The initial version was installed back
> in ubuntu 8.04 days when mailman wasn't a ubuntu package.  Since then
> for Ubuntu they changed some of the default groups for things, like
> mailing lists.


If your original install was from the tarball, and you still have the
directory into which you unpacked and configured it. I suggest you
download the latest release (2.1.22) from, e.g.,
<https://launchpad.net/mailman/+download>, configure it the same way and
install that.

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

From kross at vrcis.com  Fri May 20 15:08:26 2016
From: kross at vrcis.com (Kevin Ross)
Date: Fri, 20 May 2016 12:08:26 -0700
Subject: [Mailman-Users] Lost GNU Web mgmt interface after MAC OSX update
Message-ID: <019f01d1b2ca$fcaab980$f6002c80$@vrcis.com>

The url is : http://mail.vrcis.com/mailman/admindb/vip

The response is:

Not Found

The requested URL /mailman/admindb/vip was not found on this server.

Apache Server at mail.vrcis.com Port 80


The URL http://mail.vrcis.com

Works fine, however

Mailman logs are empty, /var/apache2 logs have the usual minimal stuff, no
primary website, no webmail, this is just an OSX server running postfix,
clamav and mailman.
We can still execute commandline mailman commands, I have a feeeling its in
the apache httpd conf  possibly where the ./mailman/admindb/...  is added
..?


Thank 

Kevin


-----Original Message-----
From: Mailman-Users
[mailto:mailman-users-bounces+kross=vrcis.com at python.org] On Behalf Of Mark
Sapiro
Sent: Friday, May 20, 2016 9:18 AM
To: mailman-users at python.org
Subject: Re: [Mailman-Users] Lost GNU Web mgmg interface after MAC OSX
update

On 05/20/2016 08:18 AM, Caulfield Kevin Ross wrote:
> 
> Silly question, during a MAC  OSX update we lost the ability to manage 
> our mailman GNU system using the http interface.


What happens when you try to go to the Mailman web GUI?

What is your web server?

What is in it's logs?

-- 
Mark Sapiro <mark 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/kross%40vrcis.com

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7597 / Virus Database: 4568/12265 - Release Date: 05/20/16


From mark at msapiro.net  Fri May 20 16:12:39 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 13:12:39 -0700
Subject: [Mailman-Users] turn on tracing?
In-Reply-To: <7b83db58-5bd1-ae4f-8bdd-4834260b7163@sgeinc.com>
References: <571DA745.8080005@bradakis.com> <571E31F5.80309@msapiro.net>
 <bae257de-ea35-4a17-b611-42312d42ae0b@sgeinc.com>
 <573F317D.2000809@msapiro.net>
 <a1ec1d8c-82d1-6044-6416-14188cdb203e@sgeinc.com>
 <573F5E1F.8090509@msapiro.net>
 <7b83db58-5bd1-ae4f-8bdd-4834260b7163@sgeinc.com>
Message-ID: <573F6FB7.8050108@msapiro.net>

On 05/20/2016 12:04 PM, Richard Shetron wrote:
> That only tells me about long running processes, not ones that start and
> stop/die very quickly.  There are programs that aren't starting due to
> permission problems like qrunner.


The qrunners are started by mailmanctl which shoud be started as root
but then sets itself to the user:group that were configured with the
configure options --with-username and --with-groupname. These default to
'mailman'. You can find the values in Defaults.py in the settings for
MAILMAN_USER and MAILMAN_GROUP

> The latest web page now says (which
> doesn't tell me what the eid/gid were when the problem occured):


The web server is a persistent process, it's user:group on Ubuntu are
usually www_data, however, the web server invokes a CGI wrapper, e.g.
/var/lib/mailman/cgi-bin/admin which should be SETGID and group =
Mailman's group.


> Bug in Mailman version 2.1.21rc2
> 
> We're sorry, we hit a bug!
> 
> If you would like to help us identify the problem, please email a copy
> of this page to the webmaster for this site with a description of what
> happened. Thanks!
> Traceback:
> 
> Traceback (most recent call last):
>   File "/var/lib/mailman/scripts/driver", line 86, in run_main
>     immediate=1)
>   File "/var/lib/mailman/Mailman/Logging/StampedLogger.py", line 52, in
> __init__
>     Logger.__init__(self, category, nofail, immediate)
>   File "/var/lib/mailman/Mailman/Logging/Logger.py", line 50, in __init__
>     self.__get_f()
>   File "/var/lib/mailman/Mailman/Logging/Logger.py", line 68, in __get_f
>     1)
>   File "/usr/lib/python2.7/codecs.py", line 878, in open
>     file = __builtin__.open(filename, mode, buffering)
> IOError: [Errno 13] Permission denied: '/var/lib/mailman/logs/error'


This is a secondary error because of the inability to write the real
error to the error log. Is the error log writable by Mailman's group?

Is there something like apparmor preventing access?

-- 
Mark Sapiro <mark 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 May 20 16:19:36 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 13:19:36 -0700
Subject: [Mailman-Users] Lost GNU Web mgmt interface after MAC OSX update
In-Reply-To: <019f01d1b2ca$fcaab980$f6002c80$@vrcis.com>
References: <019f01d1b2ca$fcaab980$f6002c80$@vrcis.com>
Message-ID: <573F7158.1060802@msapiro.net>

On 05/20/2016 12:08 PM, Kevin Ross wrote:
> The url is : http://mail.vrcis.com/mailman/admindb/vip
> 
> The response is:
> 
> Not Found


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

at a minimum you will need something like

ScriptAlias /mailman/       /var/lib/mailman/cgi-bin/

or where ever the cgi-bin directory containing Mailman's wrappers is.

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

From jdd at dodin.org  Fri May 20 13:29:25 2016
From: jdd at dodin.org (jdd)
Date: Fri, 20 May 2016 19:29:25 +0200
Subject: [Mailman-Users] mailman to inn gateway
Message-ID: <573F4975.4050908@dodin.org>

Hello,

I'm moving a server from openSUSE 13.1 to openSUSE Leap 42.1. Simply 
coping the config files do not get the expected result.

It's probably something small, but I can't put my finger on it.

list manager works fine with mailman + postfix.

I use to have a news server (inn) as mail<>gateway and it worked

my last notes said that mailman do all the job and is simple to configure.

http://dodin.info/wiki/pmwiki.php?n=Doc.Mailman#toc13
but now it's chaotic.

for the list "test", it works from list to news, but not the other way round

for the list linux-31, no result for any way

any hint?



thanks
jdd

From mark at msapiro.net  Fri May 20 23:23:00 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 20 May 2016 20:23:00 -0700
Subject: [Mailman-Users] mailman to inn gateway
In-Reply-To: <573F4975.4050908@dodin.org>
References: <573F4975.4050908@dodin.org>
Message-ID: <573FD494.7010403@msapiro.net>

On 05/20/2016 10:29 AM, jdd wrote:
> 
> I use to have a news server (inn) as mail<>gateway and it worked
> 
> my last notes said that mailman do all the job and is simple to configure.
> 
> http://dodin.info/wiki/pmwiki.php?n=Doc.Mailman#toc13
> but now it's chaotic.
> 
> for the list "test", it works from list to news, but not the other way
> round


Is Mailman's cron/gatenews being run? The default crontab runs it every
5 minutes. It is required to gate from usenet to mail.


> for the list linux-31, no result for any way


Are the Mail<->News gateways settings other than linked_newsgroup the
same for both lists? Does the linked_newsgroup exist on nntp_host?

Are gateway_to_news and gateway_to_mail both set to Yes for both lists?

Are any NNTP errors being logged in Mailman's error log?

What's in Mailman's fromusenet log?

If you are using a different nntp_host than before, it's likely the
message numbers are lower on the new host and haven't caught up to the
list's usenet_watermark. If this is the case, setting the list's
Mail<->News gateways -> mass_catchup to Yes and Submitting changes will
start gating with the next new message.

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

From jdd at dodin.org  Sat May 21 03:40:42 2016
From: jdd at dodin.org (jdd)
Date: Sat, 21 May 2016 09:40:42 +0200
Subject: [Mailman-Users] mailman to inn gateway
In-Reply-To: <573FD494.7010403@msapiro.net>
References: <573F4975.4050908@dodin.org> <573FD494.7010403@msapiro.net>
Message-ID: <574010FA.7080506@dodin.org>

Le 21/05/2016 05:23, Mark Sapiro a ?crit :

> Is Mailman's cron/gatenews being run? The default crontab runs it every
> 5 minutes. It is required to gate from usenet to mail.

the documentation is ambiguous

https://wiki.list.org/DOC/Configuring%20cron%20to%20run%20with%20the%20correct%20privileges%2C%20troubleshoot%20cron%20error.

says that this is needed only with 2.0, I have 2.1.21

I used:

http://www.yolinux.com/TUTORIALS/LinuxTutorialMailman.html

that is:

[root prompt]# cd /usr/lib/mailman/cron
[root prompt]# crontab -u mailman crontab.in

now the test list works both ways. good. I completed my doc

>
>
>> for the list linux-31, no result for any way
>
>
> Are the Mail<->News gateways settings other than linked_newsgroup the
> same for both lists? Does the linked_newsgroup exist on nntp_host?

yes for both

>
> Are gateway_to_news and gateway_to_mail both set to Yes for both lists?

surprisingly not. for linux-31 it was set to no. bad :-(. corrected

> Mail<->News gateways -> mass_catchup to Yes and Submitting changes will
> start gating with the next new message.
>
no result.

I could find a fix creating an other newsgroup (other name), and this 
one I could sync it with mailman.

thanks
jdd

From stephen at xemacs.org  Sat May 21 03:48:22 2016
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 21 May 2016 16:48:22 +0900
Subject: [Mailman-Users] FWD: [dmarc-ietf] Last Call:
 <draft-ietf-dmarc-interoperability-15.txt> (Interoperability Issues Between
 DMARC and Indirect Email Flows) to Informational RFC
In-Reply-To: <20160520134205.328.49041.idtracker@ietfa.amsl.com>
References: <20160520134205.328.49041.idtracker@ietfa.amsl.com>
Message-ID: <22336.4806.101166.450996@turnbull.sk.tsukuba.ac.jp>

Hi, all

This IETF work affects us all, so I'm reposting here so those with the
interest can participate.

"Indirect mail flows" includes but is not limited to mailing lists.
"DMARC" is the protocol which Yahoo! and AOL used to unsubscribe
thousands of innocent list members in April 2014.  This Internet Draft
is about to be promoted to RFC, so this is really the last chance to
get any changes made.  (You can comment on a Request for Comments, but
you'll never get one changed. :-)  For our purposes,
"interoperability" means best practices for both email providers and
mailing list operators to avoid reoccurance of that "April Fool's Joke".

If you haven't participated in IETF work before, you might want to run
your comments by us (or me personally, if you prefer) before sending
them off to the IESG.  RFC-ese is not really English. ;-)  I'll be happy
to provide translation of portions of interest on request.

My personal opinion is that the last draft I looked at (#12) was very
good, but the more eyes the better.

Reply-To set to mailman-users, but personal replies to me also
welcome.  Please don't reply-all.  Also, there is no chance that DMARC
"p=reject" itself is going away, so let's not rehash that issue.

Standards-geek-ily y'rs,

The IESG writes:
 > 
 > The IESG has received a request from the Domain-based Message
 > Authentication, Reporting & Conformance WG (dmarc) to consider the
 > following document:
 > - 'Interoperability Issues Between DMARC and Indirect Email Flows'
 >   <draft-ietf-dmarc-interoperability-15.txt> as Informational RFC
 > 
 > The IESG plans to make a decision in the next few weeks, and solicits
 > final comments on this action. Please send substantive comments to the
 > ietf at ietf.org mailing lists by 2016-06-03. Exceptionally, comments may be
 > sent to iesg at ietf.org instead. In either case, please retain the
 > beginning of the Subject line to allow automated sorting.
 > 
 > Abstract
 > 
 > 
 >    DMARC introduces a mechanism for expressing domain-level policies and
 >    preferences for email message validation, disposition, and reporting.
 >    The DMARC mechanism can encounter interoperability issues when
 >    messages do not flow directly from the author's administrative domain
 >    to the final recipients.  Collectively these email flows are referred
 >    to as indirect email flows.  This document describes interoperability
 >    issues between DMARC and indirect email flows.  Possible methods for
 >    addressing interoperability issues are presented.
 > 
 > 
 > 
 > 
 > The file can be obtained via
 > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/
 > 
 > IESG discussion can be tracked via
 > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ballot/
 > 
 > 
 > No IPR declarations have been submitted directly on this I-D.
 > 
 > 
 > _______________________________________________
 > dmarc mailing list
 > dmarc at ietf.org
 > https://www.ietf.org/mailman/listinfo/dmarc
 > 

From Hagedorn at uni-koeln.de  Sat May 21 03:47:24 2016
From: Hagedorn at uni-koeln.de (Sebastian Hagedorn)
Date: Sat, 21 May 2016 09:47:24 +0200
Subject: [Mailman-Users] Pending subscription request weirdness
Message-ID: <2F8783E7E9DEFB0D7DBF3301@Sebbis-iMac.local>

Hi,

I have a problem that looks like this FAQ, but I'm pretty sure it's not:

<http://wiki.list.org/x/EoCE>

There is only one Mailman instance in play, and I can actually see the 
subscription request in /var/lib/mailman/lists/LISTNAME/request.pck. I've 
been getting the email notification for a few days, but in the GUI there 
are "no pending requests".

dumpdb shows this:

dumpdb -p request.pck
[----- start pickle file -----]
<----- start object 1 ----->
{   18: (   2,
            (   1463673214.732806,
                'redacted at ukmuenster.de',
                u'Universit\xe4tsklinikum M\xfcnster',
                'redacted',
                0,
                'de')),
    'version': (0, 1)}
[----- end pickle file -----]

This is Mailman 2.1.18. Any ideas?

Cheers
Sebastian
--
Sebastian Hagedorn - Weyertal 121, Zimmer 2.02
Regionales Rechenzentrum (RRZK)
Universit?t zu K?ln / Cologne University - Tel. +49-221-470-89578

From mark at msapiro.net  Sat May 21 12:54:06 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 21 May 2016 09:54:06 -0700
Subject: [Mailman-Users] Pending subscription request weirdness
In-Reply-To: <2F8783E7E9DEFB0D7DBF3301@Sebbis-iMac.local>
References: <2F8783E7E9DEFB0D7DBF3301@Sebbis-iMac.local>
Message-ID: <abd5c6c5-5182-610a-8aec-7633dba5cac1@msapiro.net>

On 5/21/16 12:47 AM, Sebastian Hagedorn wrote:
> 
> There is only one Mailman instance in play, and I can actually see the
> subscription request in /var/lib/mailman/lists/LISTNAME/request.pck.
> I've been getting the email notification for a few days, but in the GUI
> there are "no pending requests".
> 
> dumpdb shows this:
> 
> dumpdb -p request.pck
> [----- start pickle file -----]
> <----- start object 1 ----->
> {   18: (   2,
>            (   1463673214.732806,
>                'redacted at ukmuenster.de',
>                u'Universit\xe4tsklinikum M\xfcnster',
>                'redacted',
>                0,
>                'de')),
>    'version': (0, 1)}
> [----- end pickle file -----]


Is there anything in Mailman's error log when you go to the admindb page?

If you get the script at <https://www.msapiro.net/scripts/list_requests>
and run it, does it show the request?

-- 
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 May 21 13:02:21 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 21 May 2016 10:02:21 -0700
Subject: [Mailman-Users] mailman to inn gateway
In-Reply-To: <574010FA.7080506@dodin.org>
References: <573F4975.4050908@dodin.org> <573FD494.7010403@msapiro.net>
 <574010FA.7080506@dodin.org>
Message-ID: <2bd677c3-0ed5-e992-3088-ff662f6fcd5b@msapiro.net>

On 5/21/16 12:40 AM, jdd wrote:
> Le 21/05/2016 05:23, Mark Sapiro a ?crit :
> 
>> Is Mailman's cron/gatenews being run? The default crontab runs it every
>> 5 minutes. It is required to gate from usenet to mail.
> 
> the documentation is ambiguous
> 
> https://wiki.list.org/DOC/Configuring%20cron%20to%20run%20with%20the%20correct%20privileges%2C%20troubleshoot%20cron%20error.
> 
> 
> says that this is needed only with 2.0, I have 2.1.21


That refers to running the qrunners via cron which was MM 2.0 only. It
doesn't mean that there aren't any cron jobs needed with MM 2.1


> I used:
> 
> http://www.yolinux.com/TUTORIALS/LinuxTutorialMailman.html
> 
> that is:
> 
> [root prompt]# cd /usr/lib/mailman/cron
> [root prompt]# crontab -u mailman crontab.in
> 
> now the test list works both ways. good. I completed my doc


OK


>>> for the list linux-31, no result for any way
>>
>>
>> Are the Mail<->News gateways settings other than linked_newsgroup the
>> same for both lists? Does the linked_newsgroup exist on nntp_host?
> 
> yes for both
> 
>>
>> Are gateway_to_news and gateway_to_mail both set to Yes for both lists?
> 
> surprisingly not. for linux-31 it was set to no. bad :-(. corrected
> 
>> Mail<->News gateways -> mass_catchup to Yes and Submitting changes will
>> start gating with the next new message.
>>
> no result.


This action produces no result until a subsequent post arrives at the
news server.

What does Mailman's fromusenet log say?

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

From jdd at dodin.org  Sat May 21 13:09:13 2016
From: jdd at dodin.org (jdd)
Date: Sat, 21 May 2016 19:09:13 +0200
Subject: [Mailman-Users] mailman to inn gateway
In-Reply-To: <2bd677c3-0ed5-e992-3088-ff662f6fcd5b@msapiro.net>
References: <573F4975.4050908@dodin.org> <573FD494.7010403@msapiro.net>
 <574010FA.7080506@dodin.org>
 <2bd677c3-0ed5-e992-3088-ff662f6fcd5b@msapiro.net>
Message-ID: <57409639.5010706@dodin.org>

Le 21/05/2016 19:02, Mark Sapiro a ?crit :
> On 5/21/16 12:40 AM, jdd wrote:

>>> Mail<->News gateways -> mass_catchup to Yes and Submitting changes will
>>> start gating with the next new message.
>>>
>> no result.
>
>
> This action produces no result until a subsequent post arrives at the
> news server.
>
> What does Mailman's fromusenet log say?
>

no error

May 21 19:00:03 2016 (7857) nothing new for list linux-31
May 21 19:00:03 2016 (7857) linux-31 watermark: 7

but something was wrong on the inn side, I couldn't even post to the 
group. Since I changed to group for a new one (new name), all works fine

As I have mailman archives, I don't need news archives, so the group 
name is not really important

but thanks to your notes I could make the system work. Your help is 
always very good

thanks a lot
jdd

From Hagedorn at uni-koeln.de  Sat May 21 14:53:40 2016
From: Hagedorn at uni-koeln.de (Sebastian Hagedorn)
Date: Sat, 21 May 2016 20:53:40 +0200
Subject: [Mailman-Users] Pending subscription request weirdness
In-Reply-To: <abd5c6c5-5182-610a-8aec-7633dba5cac1@msapiro.net>
References: <2F8783E7E9DEFB0D7DBF3301@Sebbis-iMac.local>
 <abd5c6c5-5182-610a-8aec-7633dba5cac1@msapiro.net>
Message-ID: <BEA745420FF443B154B5A026@Sebbis-iMac.local>

Hi Mark,

> On 5/21/16 12:47 AM, Sebastian Hagedorn wrote:
>>
>> There is only one Mailman instance in play, and I can actually see the
>> subscription request in /var/lib/mailman/lists/LISTNAME/request.pck.
>> I've been getting the email notification for a few days, but in the GUI
>> there are "no pending requests".
>>
>> dumpdb shows this:
>>
>> dumpdb -p request.pck
>> [----- start pickle file -----]
>> <----- start object 1 ----->
>> {   18: (   2,
>>            (   1463673214.732806,
>>                'redacted at ukmuenster.de',
>>                u'Universit\xe4tsklinikum M\xfcnster',
>>                'redacted',
>>                0,
>>                'de')),
>>    'version': (0, 1)}
>> [----- end pickle file -----]
>
>
> Is there anything in Mailman's error log when you go to the admindb page?

no.

> If you get the script at <https://www.msapiro.net/scripts/list_requests>
> and run it, does it show the request?

Yes:

1 LISTNAME moderator request(s) waiting

Noch offene Abonnementantr?ge:
    redacted at ukmuenster.de (Universit?tsklinikum M?nster) Thu May 19 
17:53:34 2016
        18
--
Sebastian Hagedorn - Weyertal 121, Zimmer 2.02
Regionales Rechenzentrum (RRZK)
Universit?t zu K?ln / Cologne University - Tel. +49-221-470-89578

From john at cibolo.com  Sat May 21 19:28:52 2016
From: john at cibolo.com (John Griessen)
Date: Sat, 21 May 2016 18:28:52 -0500
Subject: [Mailman-Users] mailman postfix connection on debian
In-Reply-To: <573F494A.6020601@msapiro.net>
References: <573E828D.6030706@cibolo.com> <573EE2ED.50507@cibolo.com>
 <573EE63B.3090008@cibolo.com> <573F494A.6020601@msapiro.net>
Message-ID: <5740EF34.9010006@cibolo.com>

On 05/20/2016 12:28 PM, Mark Sapiro wrote:
>> Could sendgrid ahve something to do with this?   Are they filtering my
>> >mails of a pattern that has been failing before?
>
> Possibly.
>
> Your confirmations are
>
> Reply-To:catjuggling-request at cibolo.us
> Subject: confirm <long_hex_string>
>
> There have been reports, e.g.,
> <https://mail.python.org/pipermail/mailman-users/2016-May/080805.html>,
> that this Subject: triggers spam filters.
>
> Try setting
>
> VERP_CONFIRMATIONS = Yes
>
> in mm_cfg.py. this will make the message have
>
> Reply-To: catjuggling-confirm+<<long_hex_string>@cibolo.us
> Subject: Your confirmation is required to join the catjuggling mailing list
>
> That may help.

I have not changed VERP_CONFIRMATIONS yet, but I enabled smtp sending via dovecot sasl authorization
and the mail was handled, delivered, and the list state updated to having that new member.

The new member was one of the virtual mailbox users on the same server with postfix, mailman, dovecot
so there was not much chance of catjuggling-request behaving differently than a catjuggling post.

I'll try VERP_CONFIRMATIONS = Yes and send via sendgrid again to test that.

Thanks,

John Griessen

From john at cibolo.com  Sat May 21 19:38:21 2016
From: john at cibolo.com (John Griessen)
Date: Sat, 21 May 2016 18:38:21 -0500
Subject: [Mailman-Users] mailman postfix connection on debian
In-Reply-To: <5740EF34.9010006@cibolo.com>
References: <573E828D.6030706@cibolo.com> <573EE2ED.50507@cibolo.com>
 <573EE63B.3090008@cibolo.com> <573F494A.6020601@msapiro.net>
 <5740EF34.9010006@cibolo.com>
Message-ID: <5740F16D.1030009@cibolo.com>

On 05/21/2016 06:28 PM, John Griessen wrote:
> Try setting
>
> VERP_CONFIRMATIONS = Yes
>
> in mm_cfg.py. this will make the message have
>
> Reply-To: catjuggling-confirm+<<long_hex_string>@cibolo.us
> Subject: Your confirmation is required to join the catjuggling mailing list
>
> That may help.

That works when I do a list mass subscription invite, reply via smtp.sendgrid.net,
otherwise sendgrid.net silently drops it, and I don't
even see it in bounce logs when logged into sendgrid.net.

So sendgrid.net is anti mailman.
Sendgrid.net is a consolidator like we are seeing so many of in web services vs. DIY internet
servers operated by people like us.  Could be bad for DIY internet.

From mark at msapiro.net  Sat May 21 22:06:14 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 21 May 2016 19:06:14 -0700
Subject: [Mailman-Users] Pending subscription request weirdness
In-Reply-To: <BEA745420FF443B154B5A026@Sebbis-iMac.local>
References: <2F8783E7E9DEFB0D7DBF3301@Sebbis-iMac.local>
 <abd5c6c5-5182-610a-8aec-7633dba5cac1@msapiro.net>
 <BEA745420FF443B154B5A026@Sebbis-iMac.local>
Message-ID: <4c20ae7a-b746-923e-be2f-eb3f34c039f0@msapiro.net>

On 5/21/16 11:53 AM, Sebastian Hagedorn wrote:
> 
>> If you get the script at <https://www.msapiro.net/scripts/list_requests>
>> and run it, does it show the request?
> 
> Yes:
> 
> 1 LISTNAME moderator request(s) waiting
> 
> Noch offene Abonnementantr?ge:
>    redacted at ukmuenster.de (Universit?tsklinikum M?nster) Thu May 19
> 17:53:34 2016
>        18


I can only think of three possibilities. Either your
Mailman/Cgi/admindb.py script is broken or the web server you wind up at
(after possible, behind the scenes redirects, proxying, whatever) is not
looking at the same Mailman installation or you are somehow looking at
an old page which is cached somewhere.

If you think it not either of the latter two, please send me off list
copies of both the lists/LISTNAME/request.pck file and the
Mailman/Cgi/admindb.py file and I will check further.

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

From franckmailing at gmail.com  Mon May 23 08:57:40 2016
From: franckmailing at gmail.com (Franck Aerts)
Date: Mon, 23 May 2016 14:57:40 +0200
Subject: [Mailman-Users] accept_these_nonmembers and Reg Expression
Message-ID: <etPan.5742fe54.20ea7cc8.1cf2@Ultron.local>

Hello everyone,

I am sorry to bother you with this question, but even though the question has been asked on this list and a answer has been gaven, it doesn?t work for me.

I want any email coming from a particular domain to be accepted without moderation.?

I added a regular expression to accept_these_nonmembers which goes :?

^?@domain\.com$
and?
^.*@asana\.com$


but with no success : the emails are still moderated.?

Is there an option I should change somewhere that overrule the settings in ??accept_these_nonmembers?? ??

The reason i want to have to accept any email from that domain is that the ??user?? part of the email is a token that changes all the time.

Thanks in advance,

Franck

From rnewton at digium.com  Mon May 23 16:57:01 2016
From: rnewton at digium.com (Rusty Newton)
Date: Mon, 23 May 2016 15:57:01 -0500
Subject: [Mailman-Users] Mailman suddenly passing through spam from the
 -bounces addresses
Message-ID: <CAGWDFcsfJGKAJL2oaWs==gvPapQZhEWXq0NOwANwEZ0_9kMYNg@mail.gmail.com>

Hi!

New to the list! I'm the community support manager at the Asterisk project.

We've used mailman for ages and we are on 2.1.14 at the moment. I
rarely get too deep with mailman other than the administration
interface. It mostly works and we don't touch much underneath.

Recently I started receiving a lot of spam on the mailman-bounces@
addresses where the From address no longer contains the
mailman-bounces@ address and instead contains the spammer's address.

In this case the spam doesn't look like bounce traffic. I'm wondering
if someone can help me identify why mailman might let it through? From
reading documentation and the mailman mail archives I get the
impression that it should be discarding this traffic. However I can't
identify why it isn't discarding this non-bounce traffic.

Here is one example of the spam that comes to the owners addresses via
mailman-bounces:

http://pastebin.com/u2HyNLw6

The list in question has all three bounce notification options set to *no*.

That is:

bounce_unrecognized_goes_to_list_owner
bounce_notify_owner_on_disable
bounce_notify_owner_on_removal

With these three options disabled - should I expect mailman to relay
spam like this to the list owners through mailman-bounces@ ?

Is there a way to tell mailman to not send anything from mailman-bounces?

Preferably I'd like to have mailman only pass through legitimate
bounce messages. If that isn't possible then I'd like to find out how
to disable the traffic from mailman-bounces completely.

If I haven't provided enough information, let me know and I'll do my
best to get it for you. Thanks in advance.

-- 
Rusty Newton

From ed.beu at alaska.gov  Mon May 23 20:24:55 2016
From: ed.beu at alaska.gov (Beu, Ed (DOA))
Date: Tue, 24 May 2016 00:24:55 +0000
Subject: [Mailman-Users] Mm_cfg.py not setting attribute
Message-ID: <77788B6418FB6E4CB10D483D7DAC164C0101B3C0AC@SOAANCEXMB9.soa.alaska.gov>

Hi,

We currently have two instances of Mailman running for test purposes. The newlist command along with a customized mm_cfg.py file is producing different results on the two systems.

Configurations are as follows on these two test systems.

T1
Solaris 10
Mailman 2.1.20 (csw package)

T2
CentOS 6.7 (Final)
Mailman 2.1.12 (yum package)

On the T1 system I am adding the following statement to the mm_cfg.py file:
DEFAULT_RESPOND_TO_POST_REQUESTS = No

Then, when I run "./newlist -q listname my.email at domain.com<mailto:my.email at domain.com> 12345678" the list setting is as desired (respond_to_post_request = No).

On the T2 system using the same scenario above, the "respond_to_post_request" attribute does not change from the Defaults.py setting of Yes.

On the T2 system I have tried changing the attribute from  DEFAULT_RESPOND_TO_POST_REQUESTS to just RESPOND_TO_POST_REQUESTS, changed No to Zero (0) and tried DEFAULT_RESPOND_TO_POST_REQUESTS = 0. A number of combinations, and none work on the CentOS machine.

Do you have any suggestions or recommendations? Our goal is to use the CentOS system for production, so getting this worked out will be very helpful.

Thx, Ed



Ed Beu , Systems Programmer
Enterprise Technology Services
Department of Administration
619 E Shipcreek Ave., Ste 232
Anchorage, AK 99501-1677
[ETSLogo]----------------------------------------
*Desk:(907)269-6790
?Fax: (907)269-6719
* ed.beu at alaska.gov<mailto:ed.beu at alaska.gov>
" http://www.doa.alaska.gov/ets/
----------------------------------------



From mark at msapiro.net  Mon May 23 21:39:53 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 23 May 2016 18:39:53 -0700
Subject: [Mailman-Users] accept_these_nonmembers and Reg Expression
In-Reply-To: <etPan.5742fe54.20ea7cc8.1cf2@Ultron.local>
References: <etPan.5742fe54.20ea7cc8.1cf2@Ultron.local>
Message-ID: <5743B0E9.3090609@msapiro.net>

On 05/23/2016 05:57 AM, Franck Aerts wrote:
> 
> I added a regular expression to accept_these_nonmembers which goes : 
> 
> ^?@domain\.com$

I'm not sure exactly what you put for this one, but in your email, the
three dots is an elipsis character which won't match any email address.


> and 
> ^.*@asana\.com$


This should match any local part @asana\.com.

I typically use '^.*[@.]asana\.com$' to match xxx at subdomain.asana.com as
well as xxx at asana.com, but you may not want that.


> but with no success : the emails are still moderated. 


What actually is the first regexp? For what reason are the messages
held? What is the sender of the held message shown in the admindb interface


> Is there an option I should change somewhere that overrule the settings in ? accept_these_nonmembers ? ??


No.

-- 
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 May 23 22:06:03 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 23 May 2016 19:06:03 -0700
Subject: [Mailman-Users] Mailman suddenly passing through spam from the
 -bounces addresses
In-Reply-To: <CAGWDFcsfJGKAJL2oaWs==gvPapQZhEWXq0NOwANwEZ0_9kMYNg@mail.gmail.com>
References: <CAGWDFcsfJGKAJL2oaWs==gvPapQZhEWXq0NOwANwEZ0_9kMYNg@mail.gmail.com>
Message-ID: <5743B70B.1020106@msapiro.net>

On 05/23/2016 01:57 PM, Rusty Newton wrote:
> 
> Recently I started receiving a lot of spam on the mailman-bounces@
> addresses where the From address no longer contains the
> mailman-bounces@ address and instead contains the spammer's address.
> 
> In this case the spam doesn't look like bounce traffic. I'm wondering
> if someone can help me identify why mailman might let it through? From
> reading documentation and the mailman mail archives I get the
> impression that it should be discarding this traffic. However I can't
> identify why it isn't discarding this non-bounce traffic.
> 
> Here is one example of the spam that comes to the owners addresses via
> mailman-bounces:
> 
> http://pastebin.com/u2HyNLw6
>
> The list in question has all three bounce notification options set to *no*.
> 
> That is:
> 
> bounce_unrecognized_goes_to_list_owner
> bounce_notify_owner_on_disable
> bounce_notify_owner_on_removal
> 
> With these three options disabled - should I expect mailman to relay
> spam like this to the list owners through mailman-bounces@ ?


Not unless the mailman-bounces address is set to deliver two 'owner'
instead of 'bounces. Is it?


> Is there a way to tell mailman to not send anything from mailman-bounces?


If you mean not to send anything with envelope from a listname-bounces
address, No.

If you mean not to forward or relay any mail sent to a listname-bounces
address, the settings you have should do it.


> Preferably I'd like to have mailman only pass through legitimate
> bounce messages. If that isn't possible then I'd like to find out how
> to disable the traffic from mailman-bounces completely.
> 
> If I haven't provided enough information, let me know and I'll do my
> best to get it for you. Thanks in advance.


I would like to see what's in Mailman's 'bounce' log from around Tue, 19
Apr 2016 11:57:42 -0700 (PDT). I would also like to see what's in the
MTA log from the arrival of the original to the delivery if the message
to you.

That may not be necessary. Upon closer inspection of the message in the
pastebin, it looks most like a message which was sent to the list-owner
address. You could check your MTA logs and find the incoming message. I
expect you'll find the envelope was to the list-owner address.

-- 
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 May 23 22:20:06 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 23 May 2016 19:20:06 -0700
Subject: [Mailman-Users] Mm_cfg.py not setting attribute
In-Reply-To: <77788B6418FB6E4CB10D483D7DAC164C0101B3C0AC@SOAANCEXMB9.soa.alaska.gov>
References: <77788B6418FB6E4CB10D483D7DAC164C0101B3C0AC@SOAANCEXMB9.soa.alaska.gov>
Message-ID: <5743BA56.3080503@msapiro.net>

On 05/23/2016 05:24 PM, Beu, Ed (DOA) wrote:
> 
> We currently have two instances of Mailman running for test purposes. The newlist command along with a customized mm_cfg.py file is producing different results on the two systems.
> 
> Configurations are as follows on these two test systems.
> 
> T1
> Solaris 10
> Mailman 2.1.20 (csw package)
> 
> T2
> CentOS 6.7 (Final)
> Mailman 2.1.12 (yum package)
> 
> On the T1 system I am adding the following statement to the mm_cfg.py file:
> DEFAULT_RESPOND_TO_POST_REQUESTS = No
> 
> Then, when I run "./newlist -q listname my.email at domain.com<mailto:my.email at domain.com> 12345678" the list setting is as desired (respond_to_post_request = No).
> 
> On the T2 system using the same scenario above, the "respond_to_post_request" attribute does not change from the Defaults.py setting of Yes.


It should if you spelled it correctly.


> On the T2 system I have tried changing the attribute from  DEFAULT_RESPOND_TO_POST_REQUESTS to just RESPOND_TO_POST_REQUESTS, changed No to Zero (0) and tried DEFAULT_RESPOND_TO_POST_REQUESTS = 0. A number of combinations, and none work on the CentOS machine.


No, no, 0 and False are all essentially equivalent in mm_cfg.py.

Changing the name is the same as commenting it or leaving it out. Every
setting that Mailman references is defined in Defaults.py. Anything you
set in mm_cfg.py that is not a setting mentioned in Defaults.py is ignored.


> Do you have any suggestions or recommendations? Our goal is to use the CentOS system for production, so getting this worked out will be very helpful.


Exactly what mm_cfg.py file are you editing on CentOS. I *think* the
CentOS package has an mm_cfg.py in /etc/mailman and there is a symlink
from /usr/lib/mailman/Mailman/mm_cfg.py to /etc/mailman/mm_cfg.py, but I
may be mistaken about that which is why you should see the FAQ article
at <https://wiki.list.org/x/12812344>.

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

From ed.beu at alaska.gov  Tue May 24 17:51:29 2016
From: ed.beu at alaska.gov (Beu, Ed (DOA))
Date: Tue, 24 May 2016 21:51:29 +0000
Subject: [Mailman-Users] Mm_cfg.py not setting attribute
In-Reply-To: <5743BA56.3080503@msapiro.net>
References: <77788B6418FB6E4CB10D483D7DAC164C0101B3C0AC@SOAANCEXMB9.soa.alaska.gov>
 <5743BA56.3080503@msapiro.net>
Message-ID: <77788B6418FB6E4CB10D483D7DAC164C0101B3D84B@SOAANCEXMB9.soa.alaska.gov>

FWIW... the Defaults.py files for Mailman 2.1.20 and 2.1.12 are not identical.



The following statements, including the one I was troubleshooting, do not exist in version 2.1.12.


DEFAULT_BOUNCE_NOTIFY_OWNER_ON_BOUNCE_INCREMENT = No

DEFAULT_DMARC_WRAPPED_MESSAGE_TEXT = ''

DEFAULT_EQUIVALENT_DOMAINS = ''

DEFAULT_REGULAR_EXCLUDE_IGNORE = True

DEFAULT_RESPOND_TO_POST_REQUESTS = Yes

DEFAULT_SUBSCRIBE_AUTO_APPROVAL = []

DEFAULT_SUBSCRIBE_OR_INVITE = No




~Ed



-----Original Message-----
From: Mailman-Users [mailto:mailman-users-bounces+ed.beu=alaska.gov at python.org] On Behalf Of Mark Sapiro
Sent: Monday, May 23, 2016 6:20 PM
To: mailman-users at python.org
Subject: Re: [Mailman-Users] Mm_cfg.py not setting attribute



On 05/23/2016 05:24 PM, Beu, Ed (DOA) wrote:

>

> We currently have two instances of Mailman running for test purposes. The newlist command along with a customized mm_cfg.py file is producing different results on the two systems.

>

> Configurations are as follows on these two test systems.

>

> T1

> Solaris 10

> Mailman 2.1.20 (csw package)

>

> T2

> CentOS 6.7 (Final)

> Mailman 2.1.12 (yum package)

>

> On the T1 system I am adding the following statement to the mm_cfg.py file:

> DEFAULT_RESPOND_TO_POST_REQUESTS = No

>

> Then, when I run "./newlist -q listname my.email at domain.com<mailto:my.email at domain.com<mailto:my.email at domain.com%3cmailto:my.email at domain.com>> 12345678" the list setting is as desired (respond_to_post_request = No).

>

> On the T2 system using the same scenario above, the "respond_to_post_request" attribute does not change from the Defaults.py setting of Yes.





It should if you spelled it correctly.





> On the T2 system I have tried changing the attribute from  DEFAULT_RESPOND_TO_POST_REQUESTS to just RESPOND_TO_POST_REQUESTS, changed No to Zero (0) and tried DEFAULT_RESPOND_TO_POST_REQUESTS = 0. A number of combinations, and none work on the CentOS machine.





No, no, 0 and False are all essentially equivalent in mm_cfg.py.



Changing the name is the same as commenting it or leaving it out. Every

setting that Mailman references is defined in Defaults.py. Anything you

set in mm_cfg.py that is not a setting mentioned in Defaults.py is ignored.





> Do you have any suggestions or recommendations? Our goal is to use the CentOS system for production, so getting this worked out will be very helpful.





Exactly what mm_cfg.py file are you editing on CentOS. I *think* the

CentOS package has an mm_cfg.py in /etc/mailman and there is a symlink

from /usr/lib/mailman/Mailman/mm_cfg.py to /etc/mailman/mm_cfg.py, but I

may be mistaken about that which is why you should see the FAQ article

at <https://wiki.list.org/x/12812344>.



--

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

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

Mailman-Users mailing list Mailman-Users at python.org<mailto: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/ed.beu%40alaska.gov

From mark at msapiro.net  Tue May 24 19:09:31 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 24 May 2016 16:09:31 -0700
Subject: [Mailman-Users] Mm_cfg.py not setting attribute
In-Reply-To: <77788B6418FB6E4CB10D483D7DAC164C0101B3D84B@SOAANCEXMB9.soa.alaska.gov>
References: <77788B6418FB6E4CB10D483D7DAC164C0101B3C0AC@SOAANCEXMB9.soa.alaska.gov>
 <5743BA56.3080503@msapiro.net>
 <77788B6418FB6E4CB10D483D7DAC164C0101B3D84B@SOAANCEXMB9.soa.alaska.gov>
Message-ID: <5744DF2B.6000900@msapiro.net>

On 05/24/2016 02:51 PM, Beu, Ed (DOA) wrote:
> FWIW... the Defaults.py files for Mailman 2.1.20 and 2.1.12 are not
> identical.
> 
> The following statements, including the one I was troubleshooting, do
> not exist in version 2.1.12.
> 
> *DEFAULT_*BOUNCE_NOTIFY_OWNER_ON_BOUNCE_INCREMENT = No**
> *DEFAULT_*DMARC_WRAPPED_MESSAGE_TEXT = ''**
> *DEFAULT_*EQUIVALENT_DOMAINS = ''**
> *DEFAULT_*REGULAR_EXCLUDE_IGNORE = True**
> *DEFAULT_*RESPOND_TO_POST_REQUESTS = Yes**
> *DEFAULT_*SUBSCRIBE_AUTO_APPROVAL = []**
> *DEFAULT_*SUBSCRIBE_OR_INVITE = No**


You are correct. If your 2.1.20 package includes a NEWS file, you can
see in that file that DEFAULT_RESPOND_TO_POST_REQUESTS was added in
2.1.15. The other 'DEFAULT' settings you mention were added even more
recently.

Sorry for not picking this up in my first reply.

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

From karl at freefriends.org  Tue May 24 17:47:48 2016
From: karl at freefriends.org (Karl Berry)
Date: Tue, 24 May 2016 21:47:48 GMT
Subject: [Mailman-Users] per-list email at munging?
Message-ID: <201605242147.u4OLlmET013049@freefriends.org>

I just set up some mailman lists for commit archives.  I'd like to avoid
the "@" -> " at " munging for them (at least in the bodies, though also
in the headers is fine/expected), while retaining that minimal munging
for the other lists on the server.

Looking at HyperArch.py (and Defaults.py), it seems
ARCHIVER_OBSCURES_EMAILADDRS is server-wide.  Any viable way to make it
per-list?  I couldn't find anything in web searches or at
http://fog.ccsf.cc.ca.us/~msapiro/scripts/ but always easy to miss stuff.

It's not so much that I myself think the " at " munging is so
wonderfully effective at antispam, but I feel sure that if I turn it off
now, my users will complain vociferously and constantly.  Such is life.

Thanks,
Karl

P.S. It seems the original author (Richard Barrett) offered to make it
per-list back in 2003 but no one asked for it :).
https://sourceforge.net/p/mailman/patches/273/

From mark at msapiro.net  Thu May 26 02:09:29 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 25 May 2016 23:09:29 -0700
Subject: [Mailman-Users] per-list email at munging?
In-Reply-To: <201605242147.u4OLlmET013049@freefriends.org>
References: <201605242147.u4OLlmET013049@freefriends.org>
Message-ID: <57469319.9060106@msapiro.net>

On 05/24/2016 02:47 PM, Karl Berry wrote:
> 
> Looking at HyperArch.py (and Defaults.py), it seems
> ARCHIVER_OBSCURES_EMAILADDRS is server-wide.  Any viable way to make it
> per-list?  I couldn't find anything in web searches or at
> http://fog.ccsf.cc.ca.us/~msapiro/scripts/ but always easy to miss stuff.


That depends what you mean by viable. There is no existing list
configuration that will do it directly.

Of course it can be done. Doing it right is not difficult, but is
somewhat involved because there are a lot of pieces involved. The
complete job includes:

modifying Mailman/versions.py to add the attribute with a default value
for lists whose data_version is < mm_cfg.DATA_FILE_VERSION.

modifying Mailman/Version.py to increase DATA_FILE_VERSION ideally by
0.1 because a new release will always increment when necessary by a
whole number.

modifying Mailman/MailList.py to add the attribute with a default value
to new lists.

modifying Mailman/Defaults.py.in and maybe Mailman/Defaults.py to
provide a setting for the default value.

modifying Mailman/Cgi/admin.py to display and update the attribute in
the admin GUI, and of course

modifying Mailman/Archiver/HyperArch.py to test the list attribute
rather than mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS.

Pieces of that can be skipped such as hard coding a default instead of
making it a Defaults.py/mm_cfg.py setting.

There are other ways that are less involved. For example, one could just
modify Mailman/Archiver/HyperArch.py, and everywhere it has

    if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:

replace that with something like

    if (mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS and
        not hasattr(xxxx, 'skip_obscure')):

where xxxx is self._mlist for the 4 occurrences in the Article class and
self.maillist for the 2 occurrences in the HyperArchive class.

Then lists that don't have a skip_obscure attribute will be processed
according to ARCHIVER_OBSCURES_EMAILADDRS and those that have it will
not have addresses obscured. Then for those lists that you want to skip
obfuscation, create a lists/LISTNAME/extend.py file with content

def extend(mlist):
    mlist.skip_obscure = True

to set the attribute for those lists.


> P.S. It seems the original author (Richard Barrett) offered to make it
> per-list back in 2003 but no one asked for it :).
> https://sourceforge.net/p/mailman/patches/273/


Actually, that patch, also in the current tracker at
<https://bugs.launchpad.net/mailman/+bug/558097>, is not the
implementation of ARCHIVER_OBSCURES_EMAILADDRS but rather a modification
of same to do a more aggressive obfuscation of email addresses in the
archive than the '@' -> ' at ' that is currently done.

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

From rstasel at uoregon.edu  Fri May 27 13:38:07 2016
From: rstasel at uoregon.edu (Ryan Stasel)
Date: Fri, 27 May 2016 17:38:07 +0000
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
Message-ID: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>

All, 

Just a quick question that I?m sure the answer is ?not possible?. I have several lists that are subsets of users (faculty, staff, etc). Then we have a list of lists called ?everyone?. But that ?everyone? list gets abused by members sending out crap that people really don?t care to see. 

So, I?ve had some requests to remove people from ?everyone? but obviously keep them in their respective ?child list?. Is this possible? 

The everyone list is set up with the child lists being members, then also setting regular_include_lists so that people that are part of multiple child lists don?t get duplicates. 

btw, running mailman 2.1.14. 

Thanks! 

-Ryan Stasel

From mark at msapiro.net  Fri May 27 14:17:05 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 27 May 2016 11:17:05 -0700
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
In-Reply-To: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
References: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
Message-ID: <57488F21.9030401@msapiro.net>

On 05/27/2016 10:38 AM, Ryan Stasel wrote:
> 
> So, I?ve had some requests to remove people from ?everyone? but obviously keep them in their respective ?child list?. Is this possible? 


I need more specifics to answer.


> The everyone list is set up with the child lists being members, then also setting regular_include_lists so that people that are part of multiple child lists don?t get duplicates. 


If a child list is a member and also in regular_include_lists, I think
this would create rather than avoid duplicates.

Anyway, to say more, I need more details of the list configurations such
as for the "everyone" list, are there individuals and lists as members
or just lists, what's in accept_these_nonmembers, what's in
regular_*_lists, and for the children, what's in regular_*_lists?

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

From rstasel at uoregon.edu  Fri May 27 14:23:50 2016
From: rstasel at uoregon.edu (Ryan Stasel)
Date: Fri, 27 May 2016 18:23:50 +0000
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
In-Reply-To: <57488F21.9030401@msapiro.net>
References: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
 <57488F21.9030401@msapiro.net>
Message-ID: <8D25A5DF-74D4-4FFB-8AC9-F0056AA43A9B@uoregon.edu>

Hi Mark,
 
Sorry, you?re right, while the lists are members, they?re all set to ?nomail?.

The list does have a couple individuals, but not many. They?re really only there so they can send. But obviously I could put them in non-members. 

Nothing is in regular_exclude_lists. regular_include_lists is as I said, more lists. A lot of individual emails is n accept_these_nonmembers. Basically everyone that can send to the list. 

For the children, they have nothing set in regular_*_lists. So really, the ?tree? is only 2 high. staff, faculty, gtfs, admins, etc, then the everyone list that contains those. 

Thanks! 

-Ryan Stasel

> On May 27, 2016, at 11:17 , Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 05/27/2016 10:38 AM, Ryan Stasel wrote:
>> 
>> So, I?ve had some requests to remove people from ?everyone? but obviously keep them in their respective ?child list?. Is this possible? 
> 
> 
> I need more specifics to answer.
> 
> 
>> The everyone list is set up with the child lists being members, then also setting regular_include_lists so that people that are part of multiple child lists don?t get duplicates. 
> 
> 
> If a child list is a member and also in regular_include_lists, I think
> this would create rather than avoid duplicates.
> 
> Anyway, to say more, I need more details of the list configurations such
> as for the "everyone" list, are there individuals and lists as members
> or just lists, what's in accept_these_nonmembers, what's in
> regular_*_lists, and for the children, what's in regular_*_lists?
> 
> -- 
> 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/rstasel%40uoregon.edu


From mark at msapiro.net  Fri May 27 15:38:15 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 27 May 2016 12:38:15 -0700
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
In-Reply-To: <8D25A5DF-74D4-4FFB-8AC9-F0056AA43A9B@uoregon.edu>
References: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
 <57488F21.9030401@msapiro.net>
 <8D25A5DF-74D4-4FFB-8AC9-F0056AA43A9B@uoregon.edu>
Message-ID: <5748A227.2020705@msapiro.net>

On 05/27/2016 11:23 AM, Ryan Stasel wrote:
>  
> Sorry, you?re right, while the lists are members, they?re all set to ?nomail?.


Why are the list's members at all?


> The list does have a couple individuals, but not many. They?re really only there so they can send. But obviously I could put them in non-members. 


It's probably fine if they are members.


> Nothing is in regular_exclude_lists. regular_include_lists is as I said, more lists. A lot of individual emails is n accept_these_nonmembers. Basically everyone that can send to the list. 


So, as long as you don't have things like @child_listname in the
"everyone" list's accept_these_nonmembers, you can just remove the
problem posters from that setting and their posts will then be handled
according to generic_nonmember_action.

They will still receive posts to "everyone" via their
regular_include_lists membership and will still be able to post to their
lists of which they are members, but not to the "everyone" list.


> For the children, they have nothing set in regular_*_lists.


OK

-- 
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 May 27 15:43:10 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 27 May 2016 12:43:10 -0700
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
In-Reply-To: <5748A227.2020705@msapiro.net>
References: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
 <57488F21.9030401@msapiro.net>
 <8D25A5DF-74D4-4FFB-8AC9-F0056AA43A9B@uoregon.edu>
 <5748A227.2020705@msapiro.net>
Message-ID: <5748A34E.90907@msapiro.net>

On 05/27/2016 12:38 PM, Mark Sapiro wrote:
> On 05/27/2016 11:23 AM, Ryan Stasel wrote:
>>  
>> Sorry, you?re right, while the lists are members, they?re all set to ?nomail?.
> 
> 
> Why are the list's members at all?


I see that's not correctly punctuated. I meant "why are the sublists
members of the everyone list?". It seems it just creates issues with
things like password reminders for no reason.

-- 
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 May 27 15:57:06 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 27 May 2016 12:57:06 -0700
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
In-Reply-To: <B1697C87-8074-4EC6-8194-0F50D853B2BC@uoregon.edu>
References: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
 <57488F21.9030401@msapiro.net>
 <8D25A5DF-74D4-4FFB-8AC9-F0056AA43A9B@uoregon.edu>
 <5748A227.2020705@msapiro.net>
 <B1697C87-8074-4EC6-8194-0F50D853B2BC@uoregon.edu>
Message-ID: <5748A692.2040807@msapiro.net>

On 05/27/2016 12:40 PM, Ryan Stasel wrote:
> 
> Sorry, it?s not wanting to remove problem posters, sadly, that?s not currently an option. The question is can I remove people from receiving emails to the everyone list, but NOT remove them from the child lists they?re on. I?m guessing the answer is ?no? without converting the ?everyone? list over to just a normal list of users, as opposed to a list of lists. 
> 
> Does that make sense? Basically, people want to opt-out of the everyone list. 


OK. I misunderstood.

I actually think that using regular_include_lists in the way you are is
the right approach, but as you suspect, it does not allow regular
members of the included lists to opt out of the "everyone" list mail.

There are two options. Those people who are digest members of all the
sub-lists of which they are members (i.e. not a non-digest member of any
of the sub-lists) will not receive "everyone" list mail. This is
probably not a good solution for most as they probably don't want to be
digest members of the sub-lists if the sub-lists are even digestable.

The other option is if they have a "decent" mail client, just set a
filter so any mail which is To: or Cc: the everyone list (and maybe not
To: or Cc: any of the sublists of which they are a member) is moved
immediately to the trash.

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

From rstasel at uoregon.edu  Fri May 27 16:00:00 2016
From: rstasel at uoregon.edu (Ryan Stasel)
Date: Fri, 27 May 2016 20:00:00 +0000
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
In-Reply-To: <5748A692.2040807@msapiro.net>
References: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
 <57488F21.9030401@msapiro.net>
 <8D25A5DF-74D4-4FFB-8AC9-F0056AA43A9B@uoregon.edu>
 <5748A227.2020705@msapiro.net>
 <B1697C87-8074-4EC6-8194-0F50D853B2BC@uoregon.edu>
 <5748A692.2040807@msapiro.net>
Message-ID: <A3D49958-BB82-4F86-A7EF-37DE7DA10966@uoregon.edu>


> On May 27, 2016, at 12:57 , Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 05/27/2016 12:40 PM, Ryan Stasel wrote:
>> 
>> Sorry, it?s not wanting to remove problem posters, sadly, that?s not currently an option. The question is can I remove people from receiving emails to the everyone list, but NOT remove them from the child lists they?re on. I?m guessing the answer is ?no? without converting the ?everyone? list over to just a normal list of users, as opposed to a list of lists. 
>> 
>> Does that make sense? Basically, people want to opt-out of the everyone list. 
> 
> 
> OK. I misunderstood.
> 
> I actually think that using regular_include_lists in the way you are is
> the right approach, but as you suspect, it does not allow regular
> members of the included lists to opt out of the "everyone" list mail.
> 
> There are two options. Those people who are digest members of all the
> sub-lists of which they are members (i.e. not a non-digest member of any
> of the sub-lists) will not receive "everyone" list mail. This is
> probably not a good solution for most as they probably don't want to be
> digest members of the sub-lists if the sub-lists are even digestable.
> 
> The other option is if they have a "decent" mail client, just set a
> filter so any mail which is To: or Cc: the everyone list (and maybe not
> To: or Cc: any of the sublists of which they are a member) is moved
> immediately to the trash.

Mark, 

No worries. It?s a weird request? and is really a bandaid until we actually fix our mailing lists. 

Thanks for the tips. I, for whatever reason, hadn?t considered a simple Exchange rule. 

Thanks! 

-Ryan Stasel

From rstasel at uoregon.edu  Fri May 27 15:40:40 2016
From: rstasel at uoregon.edu (Ryan Stasel)
Date: Fri, 27 May 2016 19:40:40 +0000
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
In-Reply-To: <5748A227.2020705@msapiro.net>
References: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
 <57488F21.9030401@msapiro.net>
 <8D25A5DF-74D4-4FFB-8AC9-F0056AA43A9B@uoregon.edu>
 <5748A227.2020705@msapiro.net>
Message-ID: <B1697C87-8074-4EC6-8194-0F50D853B2BC@uoregon.edu>

> 
> 
> So, as long as you don't have things like @child_listname in the
> "everyone" list's accept_these_nonmembers, you can just remove the
> problem posters from that setting and their posts will then be handled
> according to generic_nonmember_action.
> 
> They will still receive posts to "everyone" via their
> regular_include_lists membership and will still be able to post to their
> lists of which they are members, but not to the "everyone" list.

Hi Mark, 

Sorry, it?s not wanting to remove problem posters, sadly, that?s not currently an option. The question is can I remove people from receiving emails to the everyone list, but NOT remove them from the child lists they?re on. I?m guessing the answer is ?no? without converting the ?everyone? list over to just a normal list of users, as opposed to a list of lists. 

Does that make sense? Basically, people want to opt-out of the everyone list. 

-Ryan Stasel

From luscheina at yahoo.de  Sat May 28 15:44:10 2016
From: luscheina at yahoo.de (Christian F Buser)
Date: Sat, 28 May 2016 21:44:10 +0200
Subject: [Mailman-Users] Getting Yahoo to accept Mailman list messages
In-Reply-To: <5749F10D.1010900.ref@yahoo.de>
References: <5749F10D.1010900.ref@yahoo.de>
Message-ID: <5749F50A.4070304@yahoo.de>

Hi all

I got an error message below from Yahoo:

> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
> xxxxxxxxx at yahoo.com
> host mta7.am0.yahoodns.net [63.250.192.46]
> SMTP error from remote mail server after end of data:
> 554 5.7.9 Message not accepted for policy reasons. See 
> https://help.yahoo.com/kb/postmaster/SLN7253.html
> xxxxxxxxxxxxx at yahoo.com
> host mta7.am0.yahoodns.net [63.250.192.46]
> SMTP error from remote mail server after end of data:
> 554 5.7.9 Message not accepted for policy reasons. See 
> https://help.yahoo.com/kb/postmaster/SLN7253.html
I asked the provider and here is his answer (which does not help me too 
much since I have not sufficient knowledge about these techniques):

> Hi Christian,
>
> The messages were rejected because they weren't properly 
> authenticated. By default, all outgoing messages from xxxx.ch are DKIM 
> and SPF authenticated. Not sure about the mailing list messages, 
> though. Perhaps the Mailman needs authentication on its own.
This is a cPanel (56.0.21) installation of Mailman 2.1.20.

I have looked into the list settings but did not find anything about 
DKIM or SPF, and I also did not really understand the explanations in 
<https://wiki.list.org/DEV/DKIM>. And also, I did not find any settings 
for DKIM or SPF in the list administration pages.

Any ideas are most welcome!

Thank you, Christian


-- 
Christian F. Buser, Hohle Gasse 6, CH-5507 Mellingen (Switzerland)
Hilfe fuer Strassenkinder in Ghana: http://www.chance-for-children.org

From mark at msapiro.net  Sat May 28 16:01:20 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 28 May 2016 13:01:20 -0700
Subject: [Mailman-Users] Getting Yahoo to accept Mailman list messages
In-Reply-To: <5749F50A.4070304@yahoo.de>
References: <5749F10D.1010900.ref@yahoo.de> <5749F50A.4070304@yahoo.de>
Message-ID: <5749F910.8020206@msapiro.net>

On 05/28/2016 12:44 PM, Christian F Buser via Mailman-Users wrote:
> 
> I got an error message below from Yahoo:
> 
>> This message was created automatically by mail delivery software.
>>
>> A message that you sent could not be delivered to one or more of its
>> recipients. This is a permanent error. The following address(es) failed:
>>
>> xxxxxxxxx at yahoo.com
>> host mta7.am0.yahoodns.net [63.250.192.46]
>> SMTP error from remote mail server after end of data:
>> 554 5.7.9 Message not accepted for policy reasons. See
>> https://help.yahoo.com/kb/postmaster/SLN7253.html
...
> I asked the provider and here is his answer (which does not help me too
> much since I have not sufficient knowledge about these techniques):
> 
>> Hi Christian,
>>
>> The messages were rejected because they weren't properly
>> authenticated. By default, all outgoing messages from xxxx.ch are DKIM
>> and SPF authenticated. Not sure about the mailing list messages,
>> though. Perhaps the Mailman needs authentication on its own.
> This is a cPanel (56.0.21) installation of Mailman 2.1.20.
> 
> I have looked into the list settings but did not find anything about
> DKIM or SPF, and I also did not really understand the explanations in
> <https://wiki.list.org/DEV/DKIM>. And also, I did not find any settings
> for DKIM or SPF in the list administration pages.



The reply you received is somewhat misleading. It seems the issue is
DMARC policy rejection. Your provider says the outgoing mail is DKIM
signed and passes SPF, and there is no reason to believe that is not the
case, so the rejection must be DMARC related. The relevant FAQs are
<https://wiki.list.org/x/17891458> and <https://wiki.list.org/DEV/DMARC>.

All the mitigations mentioned in the Mailman 2 section of
<https://wiki.list.org/DEV/DMARC> should be available. The recommended
method is to set Privacy options - Sender filters ->
dmarc_moderation_action to Munge From.

-- 
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  Sat May 28 16:57:25 2016
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 29 May 2016 05:57:25 +0900
Subject: [Mailman-Users] Remove someone from list of lists but not from
 child lists?
In-Reply-To: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
References: <05F26743-2B8E-4691-B966-9CDEF74AF86E@uoregon.edu>
Message-ID: <22346.1589.49667.979270@turnbull.sk.tsukuba.ac.jp>

Ryan Stasel writes:

 > So, I?ve had some requests to remove people from ?everyone? but
 > obviously keep them in their respective ?child list?. Is this
 > possible?

I think this might be possible in Mailman 3 (but would be a new
feature, not implemented yet), but not in Mailman 2.

I suppose it's not socially possible to moderate (or even temporary
remove posting privileges) from the folks who abuse "everyone"?

Another possibility would be to create a garbage list, and set
reply-to to the garbage list on everyone.  Then people who just
reply-to the nearest list post will see their posts disappear into a
black hole, and you can tell people who complain to "check the
archives of Blackhole, if it's there, you abused 'reply-to everyone'
-- don't do that".  People who intentionally write to everyone ...
maybe a quick whack with a 2x4 would help?


From mark at msapiro.net  Sat May 28 18:01:01 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 28 May 2016 15:01:01 -0700
Subject: [Mailman-Users] Getting Yahoo to accept Mailman list messages
In-Reply-To: <5749F910.8020206@msapiro.net>
References: <5749F10D.1010900.ref@yahoo.de> <5749F50A.4070304@yahoo.de>
 <5749F910.8020206@msapiro.net>
Message-ID: <574A151D.1030901@msapiro.net>

On 05/28/2016 01:01 PM, Mark Sapiro wrote:
> On 05/28/2016 12:44 PM, Christian F Buser via Mailman-Users wrote:
>>>
>>> The messages were rejected because they weren't properly
>>> authenticated. By default, all outgoing messages from xxxx.ch are DKIM
>>> and SPF authenticated. Not sure about the mailing list messages,
>>> though. Perhaps the Mailman needs authentication on its own.
>> This is a cPanel (56.0.21) installation of Mailman 2.1.20.
...
> It seems the issue is
> DMARC policy rejection. Your provider says the outgoing mail is DKIM
> signed and passes SPF


Actually, I see the provider is not sure about list mail. It is not
clear how mail is being DKIM signed, but if OpenDKIM is being used, your
provider should see the "MAILING LISTS" section near the bottom of
<http://www.opendkim.org/opendkim-README>.

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