From bryan at skiblack.com  Mon Oct  3 10:46:26 2016
From: bryan at skiblack.com (Bryan Blackwell)
Date: Mon, 3 Oct 2016 10:46:26 -0400
Subject: [Mailman-Users] Configure admin mail Return-Path
Message-ID: <EE7A4E1A-044E-4526-B3FC-C9F3EA21D7F2@skiblack.com>

Greetings,

I have a functional Mailman 2.1.20 environment on Fedora 22 (I own and built the box).  The native domain is skiblack.com, and I host corvair.org.  The config and archives were copied over from the old server and normal list delivery works fine. I've had trouble delivering moderator request e-mail and found this error:

Oct  3 08:00:29 tiger postfix/smtp[1851]: B63BC16541: to=<patiomatt at aol.com>, orig_to=<vv-help at corvair.org>, relay=mailin-04.mx.aol.com[152.163.0.100]:25, delay=25, delays=0/0/25/0.39, dsn=5.7.1, status=bounced (host mailin-04.mx.aol.com[152.163.0.100] said: 554 5.7.1 <mailman-bounces at localhost.localdomain>: Sender address rejected: Access denied (in reply to MAIL FROM command))

vv-help is a local alias that points to three separate addresses, we are the admins for the lists.  Sending mail directly to the alias works fine.  I think the issue is localhost.localdomain in the sender header, can someone tell me where that's configured?I've pasted the headers from a moderator e-mail below.

Return-Path: <mailman-bounces at localhost.localdomain>
X-Original-To: bryan at skiblack.com
Delivered-To: bryan at skiblack.com
Received: from tiger.skiblack.com (localhost [127.0.0.1])
	by tiger.skiblack.com (Postfix) with ESMTP id 8EE6B1654B;
	Mon,  3 Oct 2016 08:00:03 -0400 (EDT)
Received: from tiger.skiblack.com (localhost [127.0.0.1])
	by tiger.skiblack.com (Postfix) with ESMTP id 8E1A916541;
	Mon,  3 Oct 2016 08:00:03 -0400 (EDT)
X-Original-To: virtualvairs-owner at corvair.org
Delivered-To: virtualvairs-owner at corvair.org
Received: from tiger.skiblack.com (localhost [127.0.0.1])
by tiger.skiblack.com (Postfix) with ESMTP id 2E7E316542
for <virtualvairs-owner at corvair.org>; Mon,  3 Oct 2016 08:00:02 -0400 (EDT)
Received: from tiger.skiblack.com (localhost [127.0.0.1])
by tiger.skiblack.com (Postfix) with ESMTP id 2D4C812877
for <virtualvairs-owner at corvair.org>; Mon,  3 Oct 2016 08:00:02 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: 2 VirtualVairs moderator request(s) waiting
From: virtualvairs-bounces at corvair.org
To: virtualvairs-owner at corvair.org
Message-ID: <mailman.4.1475496001.1805.virtualvairs at corvair.org>
Date: Mon, 03 Oct 2016 08:00:01 -0400
Precedence: list
X-BeenThere: virtualvairs at corvair.org
X-Mailman-Version: 2.1.20
List-Id: Corvair discussion <virtualvairs.corvair.org>
X-List-Administrivia: yes
X-Virus-Scanned: ClamAV using ClamSMTP
Errors-To: mailman-bounces at localhost.localdomain
Sender: "VirtualVairs" <mailman-bounces at localhost.localdomain>
X-Virus-Scanned: ClamAV using ClamSMTP



From mark at msapiro.net  Mon Oct  3 12:32:44 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 3 Oct 2016 09:32:44 -0700
Subject: [Mailman-Users] Configure admin mail Return-Path
In-Reply-To: <EE7A4E1A-044E-4526-B3FC-C9F3EA21D7F2@skiblack.com>
References: <EE7A4E1A-044E-4526-B3FC-C9F3EA21D7F2@skiblack.com>
Message-ID: <42ec06bd-fdf7-f091-3826-25338fcef09c@msapiro.net>

On 10/03/2016 07:46 AM, Bryan Blackwell wrote:
> 
> I think the issue is localhost.localdomain in the sender header, can someone tell me where that's configured?I've pasted the headers from a moderator e-mail below.


Look at things like DEFAULT_URL_HOST and add_virtualhost(...) in
Defaults.py and mm_cfg.py. Note that the Defaults.py settings are based
on the --with-mailhost and --with-urlhost values in the 'configure'
command that originally configured Mailman and subsequent changes should
only be made in mm_cfg.py.

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

From mailman-users at fongaboo.com  Mon Oct  3 16:01:33 2016
From: mailman-users at fongaboo.com (Fongaboo)
Date: Mon, 3 Oct 2016 16:01:33 -0400 (EDT)
Subject: [Mailman-Users] Relaying issues with Mailman and Postfix
Message-ID: <alpine.BSF.2.20.1610031600170.41749@h4lix.wtfayla.net>


Running Postfix 2.11.7 on FreeBSD 10.2-RELEASE. I am migrating a listserv 
on an older box to this one, running newly-installed Mailman 2.1.20.

I found a one-pager that showed me what to tar up and move over to migrate 
my lists to the new instance of Mailman. Hostname is not changing, so that 
made this part fairly painless.

However I think I'm not even getting that far yet. I'm running into a roadblock 
that I believe is strictly Postfix. So I take it that messages aren't even 
touching the new Mailman daemon yet.

No matter what I do, I am getting relay errors when I send a message with the 
Subject 'help' to <listname>-request at lists.domain.tld, as such:

Oct  3 14:12:20 <servername> postfix/smtpd[67338]: connect from mail.outsidedomain.tld[x.x.x.x]
Oct  3 14:12:20 <servername> postfix/smtpd[67338]: NOQUEUE: reject: RCPT frommail.outsidedomain.tld[x.x.x.x]: 454 4.7.1 <listname-request at lists.domain.tld>: Relay access denied; from=<outsideuser at outsidedomain.tld> to=<listname-request at lists.domain.tld> proto=ESMTP helo=<mail.outsidedomain.tld>

But then additionally I'm noticing these entries as well:

Oct  3 14:09:13 <servername> postfix/qmgr[49782]: warning: connect to transport private/mailman: No such file or directory
Oct  3 14:09:14 <servername> postfix/error[67292]: E587C642A5F: to=<listname-bounces at lists.domain.tld>, relay=none, delay=4801, delays=4801/0.02/0/0.03, dsn=4.3.0, status=deferred (mail transport unavailable)


I tried adding the following, but to no avail:

main.cf:

relay_recipient_maps = hash:/usr/local/etc/postfix/relay_recipients

transport_maps = hash:/usr/local/etc/postfix/transport


relay_recipients:

(for each list)
listname at lists.domain.tld OK
listname-listname at lists.domain.tld OK
listname-bounces at lists.domain.tld OK
listname-confirm at lists.domain.tld OK
listname-join at lists.domain.tld OK
listname-leave at lists.domain.tld OK
listname-owner at lists.domain.tld OK
listname-request at lists.domain.tld OK
listname-subscribe at lists.domain.tld OK
listname-unsubscribe at lists.domain.tld OK


transport:

lists.domain.tld mailman:


I then postmap'ed relay_recipients and transport and restarted postfix. Even 
restarted mailman for good measure. But no such luck.


My only suspicion is that maybe in Postfix 2.11.7, I need to do something in 
MySQL/PostfixAdmin concerning this line in main.cf?:

relay_domains = proxy:mysql:/usr/local/etc/postfix/mysql_relay_domains_maps.cf



Any assistance or advice, as always, would be greatly appreciated!



Thanx

From her at adm.ku.dk  Mon Oct  3 10:06:12 2016
From: her at adm.ku.dk (Henrik Rasmussen)
Date: Mon, 3 Oct 2016 14:06:12 +0000
Subject: [Mailman-Users] Personalised mails,
 content very depending on mail client
Message-ID: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75B4D6@P2KITMBX06WC03.unicph.domain>

As I am testing personalized mails from Mailman (2.1.12) I was wondering why various email clients display the content different.


*         If I send an HTML mail containing only text, both Gmail and Outlook includes personalization in msg_header "Hello %(user_name)s . This is a test"

*         If I send an HTML mail containing an image, Gmail shows "Hello [member's name]. This is a test" on top and the rest of the mail, including image, but Outlook only show the e-mail (including the image), NOT the msg_header not msg_footer.

*         If I use Outlook to email received on Gmail, using IMAP connection, "Hello [member's name]. This is a test" is displayed at the top of the received mail, but the content from the sender and the image is attached.

My content filtering -> pass_mime_types are
multipart/mixed
multipart/alternative
text/plain
text/html

but pass_mime_types shouldn't affect the mail as content filtering -> filter_content if off. Also collapse_alternatives or convert_html_to_plaintext doesn't change a thing (as content filtering -> filter_content if off).

Is there something I, as site admin, or the list-admins can do, to get personalized HTML mails, even to Outlook users?

Henrik Rasmussen

From mark at msapiro.net  Wed Oct  5 00:18:56 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 4 Oct 2016 21:18:56 -0700
Subject: [Mailman-Users] Personalised mails,
 content very depending on mail client
In-Reply-To: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75B4D6@P2KITMBX06WC03.unicph.domain>
References: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75B4D6@P2KITMBX06WC03.unicph.domain>
Message-ID: <42849170-dd7c-b77c-7bea-5c5f2470ca13@msapiro.net>

On 10/03/2016 07:06 AM, Henrik Rasmussen wrote:
> 
> Is there something I, as site admin, or the list-admins can do, to get personalized HTML mails, even to Outlook users?


You can set Non-digest options -> personalize to Full Personalization
which will cause delivered non-digest messages to be addressed To: the
recipient, and not try to use msg_header for this purpose.

As far as brain dead MUAs not properly rendering multipart messages with
msg_header and or msg_footer added, see <https://wiki.list.org/x/4030707>.

-- 
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 Oct  5 00:46:14 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 4 Oct 2016 21:46:14 -0700
Subject: [Mailman-Users] Relaying issues with Mailman and Postfix
In-Reply-To: <alpine.BSF.2.20.1610031600170.41749@h4lix.wtfayla.net>
References: <alpine.BSF.2.20.1610031600170.41749@h4lix.wtfayla.net>
Message-ID: <48c9ce7b-865a-c423-0d88-5d9e232fd88f@msapiro.net>

On 10/03/2016 01:01 PM, Fongaboo wrote:
> 
> However I think I'm not even getting that far yet. I'm running into a
> roadblock that I believe is strictly Postfix. So I take it that messages
> aren't even touching the new Mailman daemon yet.
> 
> No matter what I do, I am getting relay errors when I send a message
> with the Subject 'help' to <listname>-request at lists.domain.tld, as such:
> 
> Oct  3 14:12:20 <servername> postfix/smtpd[67338]: connect from
> mail.outsidedomain.tld[x.x.x.x]
> Oct  3 14:12:20 <servername> postfix/smtpd[67338]: NOQUEUE: reject: RCPT
> frommail.outsidedomain.tld[x.x.x.x]: 454 4.7.1
> <listname-request at lists.domain.tld>: Relay access denied;
> from=<outsideuser at outsidedomain.tld>
> to=<listname-request at lists.domain.tld> proto=ESMTP
> helo=<mail.outsidedomain.tld>


I'm not sure about the above, but the below says


> But then additionally I'm noticing these entries as well:
> 
> Oct  3 14:09:13 <servername> postfix/qmgr[49782]: warning: connect to
> transport private/mailman: No such file or directory
> Oct  3 14:09:14 <servername> postfix/error[67292]: E587C642A5F:
> to=<listname-bounces at lists.domain.tld>, relay=none, delay=4801,
> delays=4801/0.02/0/0.03, dsn=4.3.0, status=deferred (mail transport
> unavailable)


you have an incomplete postfix_to_mailman.py configuration.

See <https://wiki.list.org/x/15564817> and be sure to read all of the
linked
<https://mail.python.org/pipermail/mailman-users/2012-September/074017.html>


> I tried adding the following, but to no avail:
> 
> main.cf:
> 
> relay_recipient_maps = hash:/usr/local/etc/postfix/relay_recipients
> 
> transport_maps = hash:/usr/local/etc/postfix/transport
> 
> 
> relay_recipients:
> 
> (for each list)
> listname at lists.domain.tld OK
> listname-listname at lists.domain.tld OK
> listname-bounces at lists.domain.tld OK
> listname-confirm at lists.domain.tld OK
> listname-join at lists.domain.tld OK
> listname-leave at lists.domain.tld OK
> listname-owner at lists.domain.tld OK
> listname-request at lists.domain.tld OK
> listname-subscribe at lists.domain.tld OK
> listname-unsubscribe at lists.domain.tld OK
> 
> 
> transport:
> 
> lists.domain.tld mailman:


This says use the 'mailman' transport for ALL mail to the
lists.domain.tld domain. Per the above logs, this transport is probably
not completely defined in master.cf[1]. If this is a Debian/Ubuntu
Mailman package, read all the Debian documentation about the choice of
delivering to Mailman via aliases or via postfix_to_mailman.py and keep
in mind everything in the above referenced wiki article and the things
linked therefrom.

In case you haven't figured it out yet, postfix_to_mailman.py is a hot
button issue for me. Debian distributes it; people fail to comprehend
the Debian documentation and mis-configure it and then come here for
help. Read what I said 4 years ago. I don't really blame you. You're
certainly not alone, but if Debian had to deal with all the
postfix_to_mailman.py issues I've been dealing with for years, I suspect
they'd stop distributing it.

[1] This is what you should have in master.cf it you really insist on
using postfix_to_mailman.py

mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}

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

From turnbull.stephen.fw at u.tsukuba.ac.jp  Wed Oct  5 02:27:36 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Wed, 5 Oct 2016 15:27:36 +0900
Subject: [Mailman-Users]  Personalised mails,
 content very depending on mail client
In-Reply-To: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75B4D6@P2KITMBX06WC03.unicph.domain>
References: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75B4D6@P2KITMBX06WC03.unicph.domain>
Message-ID: <22516.40280.792757.281396@turnbull.sk.tsukuba.ac.jp>

Henrik Rasmussen writes:

 > Is there something I, as site admin, or the list-admins can do, to
 > get personalized HTML mails, even to Outlook users?

There is nothing you can do about the header/footer as admin.  Mailman
is not changing the mail since you can see the expected in GMail.  See
Mark's post for other aspects of personalization.

As sender, you can change the MIME structure of the email.  Why some
MUAs are happy with it but Outlook is not, you would best ask on an
Outlook channel.  One hint: If you are using Apple Mail, stop that.
Apple Mail uses a perfectly conforming MIME structure that makes it
difficult for some MUAs to extract attachments anyway, and would
probably aggravate this issue, too.  Specifically, it uses structure
like this:

    multipart/alternative
        text/plain
        multipart/related    # or something like that
            text/html        # refers to content-ids of inline MIME parts
            image/jpeg; content-id=1
            audio/mpeg-3; content-id=2

so that people who have text/plain-only MUAs (or settings) won't "see"
the attachments at all in many cases.

I'm not sure what wrapping that in a multipart/mixed:

    multipart/mixed              # Mailman wrapper for header/body/footer
        text/plain               # Mailman header text
        multipart/alternative
            text/plain
            multipart/related    # or something like that
                text/html        # refers to content-ids of attachments
                image/jpeg; content-id=1
                audio/mpeg-3; content-id=2
        text/plain               # Mailman footer text

should be interpreted as.  I know what *I* would do (display the text
parts like HTML <P> elements with some default style, and the HTML as
HTML), but Microsoft. *shrug*

Good luck, and may your next year have no Microsoft mail software in
it!

Steve


From her at adm.ku.dk  Wed Oct  5 04:44:02 2016
From: her at adm.ku.dk (Henrik Rasmussen)
Date: Wed, 5 Oct 2016 08:44:02 +0000
Subject: [Mailman-Users] Personalised mails,
 content very depending on mail client
In-Reply-To: <42849170-dd7c-b77c-7bea-5c5f2470ca13@msapiro.net>
References: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75B4D6@P2KITMBX06WC03.unicph.domain>
 <42849170-dd7c-b77c-7bea-5c5f2470ca13@msapiro.net>
Message-ID: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75E94C@P2KITMBX06WC03.unicph.domain>

Thank you. 

According to the article paragraph "Patching Mailman to solve this problem", a user found a solution to the problem in version 2.1.5, but would Mailman 3 handle this in a better way to work around the problem with some MUAs? Would upgrading be a better option to solve this?

Med venlig hilsen
?
Henrik Rasmussen
Systemadministrator, Core Services
?
K?BENHAVNS UNIVERSITET
Koncern-it, Drift & Support, Infrastruktur
N?rregade 10, postboks 2177
1017 K?benhavn K

Tel: 35322626
Dir 35322704
Fax 35322707
Email: her at adm.ku.dk
Web: it.ku.dk



Har du brug for hj?lp eller har sp?rgsm?l af enten faglig og teknisk karakter, er du velkommen til at hendende dig til Servicedesk ved at oprette en sag i KUnet?s selvbetjeningssystem: "KUnet ? Selvbetjening ? It-service ? Min Servicedesk ? Opret Sag", eller ringe til Servicedesk p? telefon 35 32 27 00. Du er ogs? velkommen til at sende en mail til it-service at adm.ku.dk. KUnet?s selvbetjening findes p? adressen http://sd.ku.dk.

 



-----Oprindelig meddelelse-----
Fra: Mailman-Users [mailto:mailman-users-bounces+her=adm.ku.dk at python.org] P? vegne af Mark Sapiro
Sendt: 5. oktober 2016 06:19
Til: mailman-users at python.org
Emne: Re: [Mailman-Users] Personalised mails, content very depending on mail client

On 10/03/2016 07:06 AM, Henrik Rasmussen wrote:
> 
> Is there something I, as site admin, or the list-admins can do, to get personalized HTML mails, even to Outlook users?


You can set Non-digest options -> personalize to Full Personalization
which will cause delivered non-digest messages to be addressed To: the
recipient, and not try to use msg_header for this purpose.

As far as brain dead MUAs not properly rendering multipart messages with
msg_header and or msg_footer added, see <https://wiki.list.org/x/4030707>.

-- 
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/her%40adm.ku.dk

From mark at msapiro.net  Wed Oct  5 11:10:03 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 5 Oct 2016 08:10:03 -0700
Subject: [Mailman-Users] Personalised mails,
 content very depending on mail client
In-Reply-To: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75E94C@P2KITMBX06WC03.unicph.domain>
References: <6DCC3E5DA06FE346B4DE4876C4F2713D019B75B4D6@P2KITMBX06WC03.unicph.domain>
 <42849170-dd7c-b77c-7bea-5c5f2470ca13@msapiro.net>
 <6DCC3E5DA06FE346B4DE4876C4F2713D019B75E94C@P2KITMBX06WC03.unicph.domain>
Message-ID: <c24ce88a-936a-9618-b554-6e33d668b74d@msapiro.net>

On 10/05/2016 01:44 AM, Henrik Rasmussen wrote:
> 
> According to the article paragraph "Patching Mailman to solve this problem", a user found a solution to the problem in version 2.1.5, but would Mailman 3 handle this in a better way to work around the problem with some MUAs? Would upgrading be a better option to solve this?


Our position is this patch in particular, and probably any patch, is not
robust enough for general use. Adding msg_header and msg_footer to a
MIME multipart message with possibly multiple text/plain and text/html
parts by merging the msg_header and msg_footer into existing text/plain
and text/html parts is very difficult to get right which is why we only
do it if there is only a single text/plain part to merge into.

Just as MUAs (Outlook) have difficulty determining what's the message
body and what's an attachment, we would have the same difficulty in
determining to which part(s) to add the header and footer, plus the fact
that in general, determining how to add the header and/or footer to an
HTML part with styles and multiple <div>s is not easy.

Mailman 3 is not going to be significantly different from Mailman 2.1 is
this respect.

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

From gerald.niel at gegeweb.eu  Fri Oct  7 12:44:18 2016
From: gerald.niel at gegeweb.eu (=?utf-8?Q?G=C3=A9rald_Niel?=)
Date: Fri, 7 Oct 2016 18:44:18 +0200
Subject: [Mailman-Users] moderated usenet newsgroup gateway
Message-ID: <340BB780-28D1-4E0A-B095-58E2EA6B6EE6@gegeweb.eu>

(repost, first post with a wrong address, sorry for the adminstrators/moderators)

Hi to all,

I?m new member of this liste.
But no new user of mailman.

I?m the administrator of public Usenet grisbi hierarchy <http://news.grisbi.org <http://news.grisbi.org/>> and the administrator of the grisbi?s mailing lists.
I successfully use the mail to news gateway since a long time.
I recently move both services to a new server and disable the news -> mail mailman?s gateway (via cron) for use news2mail feeds, then i preserve the original message-id.
And gateway mail -> news with mailman.
Everything works fine, except for the grisbi.info <http://grisbi.info/> moderated group.
The moderation address is the mailing list hosted on the mailman.
When message are approved for posting and published on the list it is not posted on the newsgroups.
I?ve tried the both setting :
Open list, moderated group
or
Moderated

but nothing working.

I don?t see connexion from mailman on the news server on approval.
And message not relayed to the group.

What i?m missing?

I?ve look at the archive but don?t find anything can help me.
Do I change something on the code?

? 
G?rald Niel

From gerald.niel at gegeweb.eu  Sat Oct  8 11:14:10 2016
From: gerald.niel at gegeweb.eu (=?UTF-8?B?R8OpcmFsZCBOaWVs?=)
Date: Sat, 08 Oct 2016 17:14:10 +0200
Subject: [Mailman-Users] moderated usenet newsgroup gateway
In-Reply-To: <340BB780-28D1-4E0A-B095-58E2EA6B6EE6@gegeweb.eu>
References: <340BB780-28D1-4E0A-B095-58E2EA6B6EE6@gegeweb.eu>
Message-ID: <57F90D42.4090909@gegeweb.eu>

Hi,

Le 07/10/2016 18:44, G?rald Niel a ?crit :
> but nothing working.
> 
> I don?t see connexion from mailman on the news server on approval.
> And message not relayed to the group.
> 
> What i?m missing?
> 
> I?ve look at the archive but don?t find anything can help me.
> Do I change something on the code?

sorry for the noise, it was a mistake on the hostname of the newsserver.
Find de solution after look at the logs !

Everything works fine now.

-- 
G?rald Niel
<gerald.niel at gegeweb.eu>

From jimpop at gmail.com  Mon Oct 10 16:30:51 2016
From: jimpop at gmail.com (Jim Popovitch)
Date: Mon, 10 Oct 2016 16:30:51 -0400
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
Message-ID: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>

SO... I've digging further into Mailman code looking to further
improve problems with DMARC.   I've noticed that Mailman "hold"
notifications (to:list-owner@) fail DMARC (if the mailing list domain
has a _dmarc RR) because of a simple code issue..... (not calling it a
bug at this point)

In Handlers/Hold.py, "held for moderation" notices to posters
correctly uses Message.UserNotification() to craft and send the poster
a notification.   However, notification to list-owners (it really
should be list moderators...) also uses Message.UserNotification()
rather than Message.OwnerNotification(tomoderators=1).

Any thoughts on why?

From jimpop at gmail.com  Mon Oct 10 17:32:38 2016
From: jimpop at gmail.com (Jim Popovitch)
Date: Mon, 10 Oct 2016 17:32:38 -0400
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
In-Reply-To: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
References: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
Message-ID: <CAGfsgR1k3VNxF5vJZiQSTAo+OGaVxUwJBA7MKj99bZUYrbq45g@mail.gmail.com>

On Mon, Oct 10, 2016 at 4:30 PM, Jim Popovitch <jimpop at gmail.com> wrote:
> SO... I've digging further into Mailman code looking to further
> improve problems with DMARC.   I've noticed that Mailman "hold"
> notifications (to:list-owner@) fail DMARC (if the mailing list domain
> has a _dmarc RR) because of a simple code issue..... (not calling it a
> bug at this point)
>
> In Handlers/Hold.py, "held for moderation" notices to posters
> correctly uses Message.UserNotification() to craft and send the poster
> a notification.   However, notification to list-owners (it really
> should be list moderators...) also uses Message.UserNotification()
> rather than Message.OwnerNotification(tomoderators=1).
>
> Any thoughts on why?

Further data.  The same "problem" exists with Bouncer.py using
UserNotification() instead of OwnerNotification()

To be clear, using UserNotification() , for some strange reason, sends
"owner-" notices in such a fashion that "Sender:" is set to sitelist
rather than mlist.host_name.

-Jim P.

From jimpop at gmail.com  Mon Oct 10 18:15:16 2016
From: jimpop at gmail.com (Jim Popovitch)
Date: Mon, 10 Oct 2016 18:15:16 -0400
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
In-Reply-To: <CAGfsgR1k3VNxF5vJZiQSTAo+OGaVxUwJBA7MKj99bZUYrbq45g@mail.gmail.com>
References: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
 <CAGfsgR1k3VNxF5vJZiQSTAo+OGaVxUwJBA7MKj99bZUYrbq45g@mail.gmail.com>
Message-ID: <CAGfsgR0-4=30-HO96VMwyqkzdbq0_zE6UN9tWmWcrj=JayoivA@mail.gmail.com>

On Mon, Oct 10, 2016 at 5:32 PM, Jim Popovitch <jimpop at gmail.com> wrote:
> On Mon, Oct 10, 2016 at 4:30 PM, Jim Popovitch <jimpop at gmail.com> wrote:
>> SO... I've digging further into Mailman code looking to further
>> improve problems with DMARC.   I've noticed that Mailman "hold"
>> notifications (to:list-owner@) fail DMARC (if the mailing list domain
>> has a _dmarc RR) because of a simple code issue..... (not calling it a
>> bug at this point)
>>
>> In Handlers/Hold.py, "held for moderation" notices to posters
>> correctly uses Message.UserNotification() to craft and send the poster
>> a notification.   However, notification to list-owners (it really
>> should be list moderators...) also uses Message.UserNotification()
>> rather than Message.OwnerNotification(tomoderators=1).
>>
>> Any thoughts on why?
>
> Further data.  The same "problem" exists with Bouncer.py using
> UserNotification() instead of OwnerNotification()
>
> To be clear, using UserNotification() , for some strange reason, sends
> "owner-" notices in such a fashion that "Sender:" is set to sitelist
> rather than mlist.host_name.

And to wrap it all up, here's what I propose to fix what I see as
coding problems that result in DMARC failures for list notifications.
 Like it or not, DMARC is the way forward (and the current way in many
places) to get your list's notifications into the inboxes of your
owners and admins.  I'm not talking about mailinglist traffic, I'm
talking about admin/owner notices.

http://bazaar.launchpad.net/~jimpop/mailman/virtual-notices/revision/1378?&compare_revid=1374

-Jim P.

From lists at damorris.com  Mon Oct 10 20:44:57 2016
From: lists at damorris.com (Adam Morris)
Date: Tue, 11 Oct 2016 11:44:57 +1100
Subject: [Mailman-Users] stopping cross posting?
Message-ID: <42a6b887-7eed-4066-9b00-fe85be766879@damorris.com>

Hi all,

Not sure if I'm using the correct terminology.


People send messages to a list I run as well as other lists that I have 
nothing to do with.


When people reply to the message sent to other lists the replies go to 
my list as well as the list they replied to.

Is there a way to stop this apart from asking people to only send the 
message to one list at a time?




-- 


Adam Morris
Jaws certified 2016
email:
adam at damorris.com


		


From mark at msapiro.net  Mon Oct 10 21:56:30 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 10 Oct 2016 18:56:30 -0700
Subject: [Mailman-Users] stopping cross posting?
In-Reply-To: <42a6b887-7eed-4066-9b00-fe85be766879@damorris.com>
References: <42a6b887-7eed-4066-9b00-fe85be766879@damorris.com>
Message-ID: <f42c8a5b-2b87-751f-521c-ff50f6835c38@msapiro.net>

On 10/10/2016 05:44 PM, Adam Morris wrote:
> 
> Not sure if I'm using the correct terminology.


You are.


> People send messages to a list I run as well as other lists that I have
> nothing to do with.
> 
> 
> When people reply to the message sent to other lists the replies go to
> my list as well as the list they replied to.


If the person replying does a reply-all and doesn't remove the lists of
which she is not a member from the recipients.


> Is there a way to stop this apart from asking people to only send the
> message to one list at a time?


Attempting to train your list members is futile[1]. What you can do is
set Privacy options... -> Recipient filters -> max_num_recipients to 2.
This will cause any post with 2 or more direct (To: and Cc:) recipients
to be held and then you can reject those posts. Whether this is more or
less burdensome than rejecting the non-member replies from the
cross-posted lists is something only you can decide.

Also this creates another problem. If, as we strongly recommend, your
list doesn't munge Reply-To:, and your user's MUAs don't offer a
reply-list option, they probably want to reply-all to list posts which
will cause their replies to be held too.

Bottom line: I feel your pain, but I don't have a satisfactory solution.

[1] My experience with lists whose members are not email wonks is that
attempts to alter member's behavior only result in their thinking you're
a jerk and don't modify their behavior.

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

From turnbull.stephen.fw at u.tsukuba.ac.jp  Mon Oct 10 23:31:44 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Tue, 11 Oct 2016 12:31:44 +0900
Subject: [Mailman-Users] moderated usenet newsgroup gateway
In-Reply-To: <57F90D42.4090909@gegeweb.eu>
References: <340BB780-28D1-4E0A-B095-58E2EA6B6EE6@gegeweb.eu>
 <57F90D42.4090909@gegeweb.eu>
Message-ID: <22524.23840.693636.126501@turnbull.sk.tsukuba.ac.jp>

G?rald Niel writes:
 > Le 07/10/2016 18:44, G?rald Niel a ?crit :
 > > but nothing working.
 > 
 > sorry for the noise, it was a mistake on the hostname of the newsserver.
 > Find de solution after look at the logs !

No need for an apology, sometimes even Mark needs to look twice! :-)

And thank you very much for following up with the "problem solved" and
how you did it.  Not to mention describing your Mailman use case --
always nice to hear about creative ways to use our software!

Steve



From turnbull.stephen.fw at u.tsukuba.ac.jp  Mon Oct 10 23:32:01 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Tue, 11 Oct 2016 12:32:01 +0900
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
In-Reply-To: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
References: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
Message-ID: <22524.23857.268693.971327@turnbull.sk.tsukuba.ac.jp>

Jim Popovitch writes:

 > I've noticed that Mailman "hold" notifications (to:list-owner@)
 > fail DMARC (if the mailing list domain has a _dmarc RR) because of
 > a simple code issue..... (not calling it a bug at this point)

I don't see how direct mail can fail DMARC if the list's host MTA is
correctly configured for SPF and DKIM.  Can you give example headers
showing the problem?

Steve


From jimpop at gmail.com  Tue Oct 11 11:37:16 2016
From: jimpop at gmail.com (Jim Popovitch)
Date: Tue, 11 Oct 2016 11:37:16 -0400
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
In-Reply-To: <22524.23857.268693.971327@turnbull.sk.tsukuba.ac.jp>
References: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
 <22524.23857.268693.971327@turnbull.sk.tsukuba.ac.jp>
Message-ID: <CAGfsgR15i95AQgVZCFxdL78WvcbiUtqU0am9CYkcQGpLmM=cSg@mail.gmail.com>

On Mon, Oct 10, 2016 at 11:32 PM, Stephen J. Turnbull
<turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
> Jim Popovitch writes:
>
>  > I've noticed that Mailman "hold" notifications (to:list-owner@)
>  > fail DMARC (if the mailing list domain has a _dmarc RR) because of
>  > a simple code issue..... (not calling it a bug at this point)
>
> I don't see how direct mail can fail DMARC if the list's host MTA is
> correctly configured for SPF and DKIM.  Can you give example headers
> showing the problem?
>
> Steve
>

I provided headers to Steven offline.

The emails fail DMARC because the From: is the virtual list domain,
but the Sender is set to the site-list (often a neutral domain used
for the MTA that hosts the virtual lists).   OpenDKIM signs based on
the Sender (see: "MAILING LISTS" at
http://www.opendkim.org/opendkim-README), so the sig is NOT aligned
with From, thus failing DMARC...and getting notification emails
de-prioritized or worse.

I've discovered 4 more places that needed "adjustments", the totality
of the most recent changes are detailed here:

http://bazaar.launchpad.net/~jimpop/mailman/virtual-notices/revision/1379?&compare_revid=1374

-Jim P.

From mark at msapiro.net  Tue Oct 11 12:11:21 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 11 Oct 2016 09:11:21 -0700
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
In-Reply-To: <CAGfsgR15i95AQgVZCFxdL78WvcbiUtqU0am9CYkcQGpLmM=cSg@mail.gmail.com>
References: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
 <22524.23857.268693.971327@turnbull.sk.tsukuba.ac.jp>
 <CAGfsgR15i95AQgVZCFxdL78WvcbiUtqU0am9CYkcQGpLmM=cSg@mail.gmail.com>
Message-ID: <b29ed395-f3be-40b1-f844-2cae2f09ff49@msapiro.net>

On 10/11/2016 08:37 AM, Jim Popovitch wrote:
> 
> The emails fail DMARC because the From: is the virtual list domain,
> but the Sender is set to the site-list (often a neutral domain used
> for the MTA that hosts the virtual lists).   OpenDKIM signs based on
> the Sender (see: "MAILING LISTS" at
> http://www.opendkim.org/opendkim-README), so the sig is NOT aligned
> with From, thus failing DMARC...and getting notification emails
> de-prioritized or worse.


I haven't yet looked at your suggested changes, and I will.

I know that there is some inconsistency and some confusion over the fact
that some owner notifications are sent using the
Message.OwnerNotification method and some are sent to the -owner address
using the Message.UserNotification method.

I haven't been around Mailman long enough to know the history of this,
but I do know that in some cases there are bounce processing reasons for
why the sender is the site list.

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

From willi.uebelherr at gmail.com  Tue Oct 11 13:37:49 2016
From: willi.uebelherr at gmail.com (willi uebelherr)
Date: Tue, 11 Oct 2016 14:37:49 -0300
Subject: [Mailman-Users] stopping cross posting?
In-Reply-To: <f42c8a5b-2b87-751f-521c-ff50f6835c38@msapiro.net>
References: <42a6b887-7eed-4066-9b00-fe85be766879@damorris.com>
 <f42c8a5b-2b87-751f-521c-ff50f6835c38@msapiro.net>
Message-ID: <CAAy8aXjGH+BaN6u0=ffddeXx34r478DYFHveCkHhhy3ngrSOKQ@mail.gmail.com>

Dear friends,

this discussion is mostly negative oriented. I will add a positive
consideration.

The cross-posting is very important to open the spaces, to connect
different areas.

For the list server is not a big problem. If senders are not
subscribed, they blocked. Simple.

The sender get this information. She/he can check the receiver list
the next time. We can make a short information in the list. Not as
supervision, but as help.

many greetings, willi
Asuncion, Paraguay


2016-10-10 22:56 GMT-03:00 Mark Sapiro <mark at msapiro.net>:
> On 10/10/2016 05:44 PM, Adam Morris wrote:
>>
>> Not sure if I'm using the correct terminology.
>
>
> You are.
>
>
>> People send messages to a list I run as well as other lists that I have
>> nothing to do with.
>>
>>
>> When people reply to the message sent to other lists the replies go to
>> my list as well as the list they replied to.
>
>
> If the person replying does a reply-all and doesn't remove the lists of
> which she is not a member from the recipients.
>
>
>> Is there a way to stop this apart from asking people to only send the
>> message to one list at a time?
>
>
> Attempting to train your list members is futile[1]. What you can do is
> set Privacy options... -> Recipient filters -> max_num_recipients to 2.
> This will cause any post with 2 or more direct (To: and Cc:) recipients
> to be held and then you can reject those posts. Whether this is more or
> less burdensome than rejecting the non-member replies from the
> cross-posted lists is something only you can decide.
>
> Also this creates another problem. If, as we strongly recommend, your
> list doesn't munge Reply-To:, and your user's MUAs don't offer a
> reply-list option, they probably want to reply-all to list posts which
> will cause their replies to be held too.
>
> Bottom line: I feel your pain, but I don't have a satisfactory solution.
>
> [1] My experience with lists whose members are not email wonks is that
> attempts to alter member's behavior only result in their thinking you're
> a jerk and don't modify their behavior.
>
> --
> 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/willi.uebelherr%40gmail.com

From jhs at berklix.com  Tue Oct 11 16:54:03 2016
From: jhs at berklix.com (Julian H. Stacey)
Date: Tue, 11 Oct 2016 22:54:03 +0200
Subject: [Mailman-Users] stopping cross posting?
In-Reply-To: Your message "Mon, 10 Oct 2016 18:56:30 -0700."
 <f42c8a5b-2b87-751f-521c-ff50f6835c38@msapiro.net>
Message-ID: <201610112054.u9BKs3cU043840@fire.js.berklix.net>

Mark Sapiro wrote:
> On 10/10/2016 05:44 PM, Adam Morris wrote:
> > 
> > Not sure if I'm using the correct terminology.
> 
> 
> You are.
> 
> 
> > People send messages to a list I run as well as other lists that I have
> > nothing to do with.
> > 
> > 
> > When people reply to the message sent to other lists the replies go to
> > my list as well as the list they replied to.
> 
> 
> If the person replying does a reply-all and doesn't remove the lists of
> which she is not a member from the recipients.
> 
> 
> > Is there a way to stop this apart from asking people to only send the
> > message to one list at a time?
> 
> 
> Attempting to train your list members is futile[1]. What you can do is
> set Privacy options... -> Recipient filters -> max_num_recipients to 2.
> This will cause any post with 2 or more direct (To: and Cc:) recipients
> to be held and then you can reject those posts. Whether this is more or
> less burdensome than rejecting the non-member replies from the
> cross-posted lists is something only you can decide.
> 
> Also this creates another problem. If, as we strongly recommend, your
> list doesn't munge Reply-To:, and your user's MUAs don't offer a
> reply-list option, they probably want to reply-all to list posts which
> will cause their replies to be held too.
> 
> Bottom line: I feel your pain, but I don't have a satisfactory solution.
> 
> [1] My experience with lists whose members are not email wonks is that
> attempts to alter member's behavior only result in their thinking you're
> a jerk and don't modify their behavior.

max_num_recipients is an an interesting option
	(not in majordomo-1.94.5_8 I used before Mailman)

Re. [1] - Yes !!  I use:
   Privacy Options > Sender Filters > generic_nonmember_action: Discard

Draconian, but stops spammers & wasters, help avoids need for list
moderators, & saves list owner time - some list members can be truly awful.

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#stolen_votes

From turnbull.stephen.fw at u.tsukuba.ac.jp  Wed Oct 12 02:01:59 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Wed, 12 Oct 2016 15:01:59 +0900
Subject: [Mailman-Users] stopping cross posting?
In-Reply-To: <f42c8a5b-2b87-751f-521c-ff50f6835c38@msapiro.net>
References: <42a6b887-7eed-4066-9b00-fe85be766879@damorris.com>
 <f42c8a5b-2b87-751f-521c-ff50f6835c38@msapiro.net>
Message-ID: <22525.53719.747911.754481@turnbull.sk.tsukuba.ac.jp>

Mark Sapiro writes:
 > On 10/10/2016 05:44 PM, Adam Morris wrote:

 > > People send messages to a list I run as well as other lists that I have
 > > nothing to do with.
 > > 
 > > When people reply to the message sent to other lists the replies go to
 > > my list as well as the list they replied to.
 > 
 > If the person replying does a reply-all and doesn't remove the lists of
 > which she is not a member from the recipients.
 > 
 > > Is there a way to stop this apart from asking people to only send the
 > > message to one list at a time?

Aside from Mark's suggestion:

 > Attempting to train your list members is futile[1]. What you can do is
 > set Privacy options... -> Recipient filters -> max_num_recipients
 > to 2.

I agree about training members.  It's not worth the grief.  Most MUAs
have poor user interfaces, but once people get used to them, they can
be really efficient about the things they do 20 times per session.
Asking them to change *anything* in their habits is quite painful for
them, because it really slows things down and they feel bad about
forgetting (or "forgetting") to do the right thing, which they do
frequently.  Some get really upset about moderation delays and
"discrimination".

(1) If there are lists which are consistent offenders, you can put
    them in Privacy options... -> Spam -> Header filter rules, with

    ^(to|cc):.*\botherlist at example.com

(2) If you aren't restricting posting to members, use 
    Privacy options... -> Sender filters -> Generic nonmember action
    to prevent members of otherlist who aren't members of your list
    from posting.

(I see you're already doing the latter from a later post.)

 > Also this creates another problem.

The "filter out otherlist using filter rules" solution doesn't cause a
problem for users who reply-all because there are several addressees
who aren't on the list or whatever.  Of course it does require you to
know the lists that frequently cause issues, and it also causes delays
for "legitimate" cross-posts, if your list policy recognizes any.

The "restrict to members" solution isn't appropriate if there are more
than a few nonmembers, or there are unknown nonmembers, who should be
allowed to post.  (It's possible to have exceptions for some
nonmembers, but this gets annoying fast if there a more than a
handful, or you don't know who they are until they get held and
complain or worse go away.)

Steve

From dhoffmann at uwalumni.com  Tue Oct 11 16:46:22 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Tue, 11 Oct 2016 16:46:22 -0400
Subject: [Mailman-Users] =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan--?=
 =?utf-8?q?can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/s?=
 =?utf-8?q?hare/mailman/mail/mailman?=
Message-ID: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>

Hi:

I have followed Allan Herman's March 29, 2013, instructions for installing Mailman on OS X Mountain Lion. The difference is that my system is OS X El Capitan running Server 5.2. Nonetheless, I have not run into any contradictions. It appears that the choices for the locations of the various configuration files made when transitioning from Mac OS X Snow Leopard to Mac OS X Lion to OS X Mountain Lion have remained stable.

However, I am now banging my head against the wall, because my server's SMTP logs contain these lines:

Oct 11 16:04:04 i----on local[56963]: fatal: execvp /usr/share/mailman/mail/mailman: No such file or directory

Allan installs his Mailman deployment in /usr/local/, and I have learned that in one of the more recent iterations of OS X, Apple chose to lock down /usr/share/, so that even the sudo command does not make modifications possible, which I learned, when I tried to create a simlink there. I kept getting the "Operation not permitted." error. I learned that this is due to System Integrity Protection (SIP), introduced in OS X El Capitan.

I am now on a quest to locate from where the call to mailman originates, so that I can edit the corresponding configuration file, replacing "/usr/share/" with "/usr/local/".

Any pointers would be much appreciated.

Dominik Hoffmann



From dhoffmann at uwalumni.com  Wed Oct 12 00:01:32 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Wed, 12 Oct 2016 00:01:32 -0400
Subject: [Mailman-Users] Update mailman MacServer5
Message-ID: <12598EE7-0DEC-41A5-A67C-333553ED3DB1@uwalumni.com>

On 09/04/2016 12:53 AM, Matthias Schmidt via Mailman-Users wrote:

> Hello,
> 
> now I?m stuck here:
> 
> local[74919]: fatal: execvp /usr/share/mailman/mail/mailman: No such file or directory
> 
> local is owned by postfix so far I found out.
> What I can?t find is where this line is to be able to correct it (Spotlight also finds nothing)
> 
> thanks
> Matthias 

Hallo, Matthias,

How did you solve your problem. I have the same issue, but the mailing list thread doesn't show, what you did to address this, only that it evidently ceased to be broken.

Yours,

Dominik Hoffmann

From mark at msapiro.net  Wed Oct 12 11:16:01 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 12 Oct 2016 08:16:01 -0700
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
Message-ID: <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>

On 10/11/2016 01:46 PM, Dominik Hoffmann wrote:
> 
> I have followed Allan Herman's March 29, 2013, instructions for installing Mailman on OS X Mountain Lion. The difference is that my system is OS X El Capitan running Server 5.2. Nonetheless, I have not run into any contradictions. It appears that the choices for the locations of the various configuration files made when transitioning from Mac OS X Snow Leopard to Mac OS X Lion to OS X Mountain Lion have remained stable.
> 
> However, I am now banging my head against the wall, because my server's SMTP logs contain these lines:
> > Oct 11 16:04:04 i----on local[56963]: fatal: execvp /usr/share/mailman/mail/mailman: No such file or directory
> 
> Allan installs his Mailman deployment in /usr/local/, and I have learned that in one of the more recent iterations of OS X, Apple chose to lock down /usr/share/, so that even the sudo command does not make modifications possible, which I learned, when I tried to create a simlink there. I kept getting the "Operation not permitted." error. I learned that this is due to System Integrity Protection (SIP), introduced in OS X El Capitan.
> 
> I am now on a quest to locate from where the call to mailman originates, so that I can edit the corresponding configuration file, replacing "/usr/share/" with "/usr/local/".


It comes from PID 56963 which looks like a Postfix 'local' delivery
agent instance. I.e., it's in your Postfix aliases.

I don't know how these aliases are generated in your setup, but assuming
you have Mailman's Postfix integration, that path comes from the
WRAPPER_DIR setting in Mailman/Defaults.py. That in turn is based on
EXEC_PREFIX which is often the same as PREFIX. These things are set from
options to configure when Mailman is configured.

Did you start your installation by running configure? If so, what is the
configure command from config.log, is there a --prefix= option or a
--exec-prefix= option - the defaults for these are
--prefix=/usr/local/mailman and --exec-prefix=(the prefix value).

-- 
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 Oct 12 11:24:02 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 12 Oct 2016 08:24:02 -0700
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
 <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>
Message-ID: <f2d3209d-ea31-4713-caeb-adc14ec55c9d@msapiro.net>

On 10/12/2016 08:16 AM, Mark Sapiro wrote:
> 
> I don't know how these aliases are generated in your setup, but assuming
> you have Mailman's Postfix integration, that path comes from the
> WRAPPER_DIR setting in Mailman/Defaults.py. That in turn is based on
> EXEC_PREFIX which is often the same as PREFIX. These things are set from
> options to configure when Mailman is configured.
> 
> Did you start your installation by running configure? If so, what is the
> configure command from config.log, is there a --prefix= option or a
> --exec-prefix= option - the defaults for these are
> --prefix=/usr/local/mailman and --exec-prefix=(the prefix value).
> 


Or perhaps everything is configured correctly but your Postfix aliases
are just left from a prior install and all you need do is run Mailman's
bin/genaliases.

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

From timothy.d at jasionow.ski  Wed Oct 12 11:16:03 2016
From: timothy.d at jasionow.ski (Timothy Jasionowski)
Date: Wed, 12 Oct 2016 11:16:03 -0400
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
Message-ID: <2BFD6088-463B-45F7-AB4C-9E09313CA09C@jasionow.ski>

I?m one of the few people who has blazed this trail on the newer versions of OS X Server, mainly using the macports installation method with a few modifications.  If you want to email me off the list, I can share my insights.  Alternately, search the archives for my previous posts/fixes for this, as I?ve tried to document my challenges.

Timothy

> On Oct 11, 2016 (Wk 42), at 4:46 PM, Dominik Hoffmann <dhoffmann at uwalumni.com> wrote:
> 
> Hi:
> 
> I have followed Allan Herman's March 29, 2013, instructions for installing Mailman on OS X Mountain Lion. The difference is that my system is OS X El Capitan running Server 5.2. Nonetheless, I have not run into any contradictions. It appears that the choices for the locations of the various configuration files made when transitioning from Mac OS X Snow Leopard to Mac OS X Lion to OS X Mountain Lion have remained stable.
> 
> However, I am now banging my head against the wall, because my server's SMTP logs contain these lines:
> 
> Oct 11 16:04:04 i----on local[56963]: fatal: execvp /usr/share/mailman/mail/mailman: No such file or directory
> 
> Allan installs his Mailman deployment in /usr/local/, and I have learned that in one of the more recent iterations of OS X, Apple chose to lock down /usr/share/, so that even the sudo command does not make modifications possible, which I learned, when I tried to create a simlink there. I kept getting the "Operation not permitted." error. I learned that this is due to System Integrity Protection (SIP), introduced in OS X El Capitan.
> 
> I am now on a quest to locate from where the call to mailman originates, so that I can edit the corresponding configuration file, replacing "/usr/share/" with "/usr/local/".
> 
> Any pointers would be much appreciated.
> 
> Dominik Hoffmann
> 
> 
> ------------------------------------------------------
> 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/timothy.d%40jasionow.ski


From dhoffmann at uwalumni.com  Wed Oct 12 11:34:58 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Wed, 12 Oct 2016 11:34:58 -0400
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
 <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>
Message-ID: <6E79129E-628F-4BF2-89E4-A62CFAF91789@uwalumni.com>

Thanks very much!

I looked through Defaults.py and found

PYTHON          = '/usr/bin/python'
PREFIX          = '/usr/local/mailman'
EXEC_PREFIX     = '${prefix}'
VAR_PREFIX      = '/usr/local/mailman'

This looks normal to me and is verbatim from Allan Herman's instructions, which get their configure call from Larry Stone's May 1, 2010, instructions (also on this mailing list):

./configure --prefix=/usr/local/mailman --with-cgi-gid=_www --with-mail-gid=_mailman

I can't find any reference to "--exec-prefix=" in config.log.

Dominik

> On Oct 12, 2016, at 11:16 AM, Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 10/11/2016 01:46 PM, Dominik Hoffmann wrote:
>> 
>> I have followed Allan Herman's March 29, 2013, instructions for installing Mailman on OS X Mountain Lion. The difference is that my system is OS X El Capitan running Server 5.2. Nonetheless, I have not run into any contradictions. It appears that the choices for the locations of the various configuration files made when transitioning from Mac OS X Snow Leopard to Mac OS X Lion to OS X Mountain Lion have remained stable.
>> 
>> However, I am now banging my head against the wall, because my server's SMTP logs contain these lines:
>>> Oct 11 16:04:04 i----on local[56963]: fatal: execvp /usr/share/mailman/mail/mailman: No such file or directory
>> 
>> Allan installs his Mailman deployment in /usr/local/, and I have learned that in one of the more recent iterations of OS X, Apple chose to lock down /usr/share/, so that even the sudo command does not make modifications possible, which I learned, when I tried to create a simlink there. I kept getting the "Operation not permitted." error. I learned that this is due to System Integrity Protection (SIP), introduced in OS X El Capitan.
>> 
>> I am now on a quest to locate from where the call to mailman originates, so that I can edit the corresponding configuration file, replacing "/usr/share/" with "/usr/local/".
> 
> 
> It comes from PID 56963 which looks like a Postfix 'local' delivery
> agent instance. I.e., it's in your Postfix aliases.
> 
> I don't know how these aliases are generated in your setup, but assuming
> you have Mailman's Postfix integration, that path comes from the
> WRAPPER_DIR setting in Mailman/Defaults.py. That in turn is based on
> EXEC_PREFIX which is often the same as PREFIX. These things are set from
> options to configure when Mailman is configured.
> 
> Did you start your installation by running configure? If so, what is the
> configure command from config.log, is there a --prefix= option or a
> --exec-prefix= option - the defaults for these are
> --prefix=/usr/local/mailman and --exec-prefix=(the prefix value).
> 
> -- 
> 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/dhoffmann%40uwalumni.com


From mark at msapiro.net  Wed Oct 12 11:49:09 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 12 Oct 2016 08:49:09 -0700
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <6E79129E-628F-4BF2-89E4-A62CFAF91789@uwalumni.com>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
 <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>
 <6E79129E-628F-4BF2-89E4-A62CFAF91789@uwalumni.com>
Message-ID: <0d24cd09-6fae-b9cd-ae65-d5dbcd272421@msapiro.net>

On 10/12/16 8:34 AM, Dominik Hoffmann wrote:
> Thanks very much!
> 
> I looked through Defaults.py and found
> 
> PYTHON          = '/usr/bin/python'
> PREFIX          = '/usr/local/mailman'
> EXEC_PREFIX     = '${prefix}'
> VAR_PREFIX      = '/usr/local/mailman'


See my follow-up at
<https://mail.python.org/pipermail/mailman-users/2016-October/081436.html>.

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

From dhoffmann at uwalumni.com  Wed Oct 12 11:18:24 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Wed, 12 Oct 2016 11:18:24 -0400
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <2BFD6088-463B-45F7-AB4C-9E09313CA09C@jasionow.ski>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
 <2BFD6088-463B-45F7-AB4C-9E09313CA09C@jasionow.ski>
Message-ID: <F92997E4-D92F-4E7B-945E-52AB4374C693@uwalumni.com>

Thanks for the offer! I don't think, I want to go the MacPorts route at this point. I am thinking about it, though!

> On Oct 12, 2016, at 11:16 AM, Timothy Jasionowski <timothy.d at jasionow.ski> wrote:
> 
> I?m one of the few people who has blazed this trail on the newer versions of OS X Server, mainly using the macports installation method with a few modifications.  If you want to email me off the list, I can share my insights.  Alternately, search the archives for my previous posts/fixes for this, as I?ve tried to document my challenges.
> 
> Timothy
> 
>> On Oct 11, 2016 (Wk 42), at 4:46 PM, Dominik Hoffmann <dhoffmann at uwalumni.com> wrote:
>> 
>> Hi:
>> 
>> I have followed Allan Herman's March 29, 2013, instructions for installing Mailman on OS X Mountain Lion. The difference is that my system is OS X El Capitan running Server 5.2. Nonetheless, I have not run into any contradictions. It appears that the choices for the locations of the various configuration files made when transitioning from Mac OS X Snow Leopard to Mac OS X Lion to OS X Mountain Lion have remained stable.
>> 
>> However, I am now banging my head against the wall, because my server's SMTP logs contain these lines:
>> 
>> Oct 11 16:04:04 i----on local[56963]: fatal: execvp /usr/share/mailman/mail/mailman: No such file or directory
>> 
>> Allan installs his Mailman deployment in /usr/local/, and I have learned that in one of the more recent iterations of OS X, Apple chose to lock down /usr/share/, so that even the sudo command does not make modifications possible, which I learned, when I tried to create a simlink there. I kept getting the "Operation not permitted." error. I learned that this is due to System Integrity Protection (SIP), introduced in OS X El Capitan.
>> 
>> I am now on a quest to locate from where the call to mailman originates, so that I can edit the corresponding configuration file, replacing "/usr/share/" with "/usr/local/".
>> 
>> Any pointers would be much appreciated.
>> 
>> Dominik Hoffmann
>> 
>> 
>> ------------------------------------------------------
>> 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/timothy.d%40jasionow.ski
> 


From dhoffmann at uwalumni.com  Wed Oct 12 11:36:47 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Wed, 12 Oct 2016 11:36:47 -0400
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <f2d3209d-ea31-4713-caeb-adc14ec55c9d@msapiro.net>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
 <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>
 <f2d3209d-ea31-4713-caeb-adc14ec55c9d@msapiro.net>
Message-ID: <C2BFB510-2996-405C-87EB-B5F7D9E31237@uwalumni.com>

/usr/local/mailman/bin/genaliases did not produce any output. Does this mean that it didn't change anything or simply did so silently?

> On Oct 12, 2016, at 11:24 AM, Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 10/12/2016 08:16 AM, Mark Sapiro wrote:
>> 
>> I don't know how these aliases are generated in your setup, but assuming
>> you have Mailman's Postfix integration, that path comes from the
>> WRAPPER_DIR setting in Mailman/Defaults.py. That in turn is based on
>> EXEC_PREFIX which is often the same as PREFIX. These things are set from
>> options to configure when Mailman is configured.
>> 
>> Did you start your installation by running configure? If so, what is the
>> configure command from config.log, is there a --prefix= option or a
>> --exec-prefix= option - the defaults for these are
>> --prefix=/usr/local/mailman and --exec-prefix=(the prefix value).
>> 
> 
> 
> Or perhaps everything is configured correctly but your Postfix aliases
> are just left from a prior install and all you need do is run Mailman's
> bin/genaliases.
> 
> -- 
> 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/dhoffmann%40uwalumni.com


From dhoffmann at uwalumni.com  Wed Oct 12 15:10:30 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Wed, 12 Oct 2016 15:10:30 -0400
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <C2BFB510-2996-405C-87EB-B5F7D9E31237@uwalumni.com>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
 <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>
 <f2d3209d-ea31-4713-caeb-adc14ec55c9d@msapiro.net>
 <C2BFB510-2996-405C-87EB-B5F7D9E31237@uwalumni.com>
Message-ID: <E128BA84-BC47-4A50-8912-B23CE1DA7F52@uwalumni.com>

I think, actually, that that may have done the trick. I started getting some test messages I had sent to the list earlier, which must have been queued. I will have to do more testing later, when I have time.

> On Oct 12, 2016, at 11:36 AM, Dominik Hoffmann <dhoffmann at uwalumni.com> wrote:
> 
> /usr/local/mailman/bin/genaliases did not produce any output. Does this mean that it didn't change anything or simply did so silently?

From dhoffmann at uwalumni.com  Thu Oct 13 11:12:06 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Thu, 13 Oct 2016 11:12:06 -0400
Subject: [Mailman-Users] 
 =?utf-8?q?Installing_Mailman_on_OS_X_El_Capitan-?=
 =?utf-8?q?-can=E2=80=99t_find_source_of_erroneous_call_of_binary_at_/usr/?=
 =?utf-8?q?share/mailman/mail/mailman?=
In-Reply-To: <E128BA84-BC47-4A50-8912-B23CE1DA7F52@uwalumni.com>
References: <2B617D1E-0CA5-4ED7-BAC3-FBCCCB4BFF2B@uwalumni.com>
 <0b2a3a08-9f91-a5d5-51c1-d74452ccc3b9@msapiro.net>
 <f2d3209d-ea31-4713-caeb-adc14ec55c9d@msapiro.net>
 <C2BFB510-2996-405C-87EB-B5F7D9E31237@uwalumni.com>
 <E128BA84-BC47-4A50-8912-B23CE1DA7F52@uwalumni.com>
Message-ID: <BFD88A2A-D119-483C-BB05-C421799B1AB3@uwalumni.com>

/usr/local/mailman/bin/genaliases did do the trick. Thanks so much, Mark!

> On Oct 12, 2016, at 3:10 PM, Dominik Hoffmann <dhoffmann at uwalumni.com> wrote:
> 
> I think, actually, that that may have done the trick. I started getting some test messages I had sent to the list earlier, which must have been queued. I will have to do more testing later, when I have time.
> 
>> On Oct 12, 2016, at 11:36 AM, Dominik Hoffmann <dhoffmann at uwalumni.com> wrote:
>> 
>> /usr/local/mailman/bin/genaliases did not produce any output. Does this mean that it didn't change anything or simply did so silently?
> ------------------------------------------------------
> 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/dhoffmann%40uwalumni.com


From dhoffmann at uwalumni.com  Thu Oct 13 11:43:46 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Thu, 13 Oct 2016 11:43:46 -0400
Subject: [Mailman-Users] Cron has issues with gate_news
Message-ID: <A88B0EDD-290F-4BF9-9621-A8C908D1AC3A@uwalumni.com>

There are still a few of things to mop up, after an otherwise successful installation of Mailman on OS X El Capitan with Server 5.2.

Every 5 min my admin user account on the server gets an email from the Cron Daemon that has this line:

IOError: [Errno 13] Permission denied: '/usr/local/mailman/locks/gate_news.lock.ipheion.hoffmann.homeunix.net.54220.0'

Here are my observations:

1. I currently have no file at /usr/local/mailman/locks/ whose name starts with "gate_news".

2. My root Crontab has these lines:

	# Every 5 mins, try to gate news to mail. You can comment this one out
	# if you don't want to allow gating, or don't have any going on right now,
	# or want to exclusively use a callback strategy instead of polling.
	# 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/python -S /usr/local/mailman/cron/gate_news

   In other words, the gate_news cron job is commented out.

3. I have run /usr/local/mailman/bin/check_perms -f, but that has had no impact.

From dhoffmann at uwalumni.com  Thu Oct 13 11:56:22 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Thu, 13 Oct 2016 11:56:22 -0400
Subject: [Mailman-Users] Cron has issues with gate_news
In-Reply-To: <A88B0EDD-290F-4BF9-9621-A8C908D1AC3A@uwalumni.com>
References: <A88B0EDD-290F-4BF9-9621-A8C908D1AC3A@uwalumni.com>
Message-ID: <7019B7AE-5C4D-48CF-9B9B-8949FE077AD4@uwalumni.com>

Another observation:

4. Moving the Crontab from root to _mailman had no effect.

> On Oct 13, 2016, at 11:43 AM, Dominik Hoffmann <dhoffmann at uwalumni.com> wrote:
> 
> There are still a few of things to mop up, after an otherwise successful installation of Mailman on OS X El Capitan with Server 5.2.
> 
> Every 5 min my admin user account on the server gets an email from the Cron Daemon that has this line:
> 
> IOError: [Errno 13] Permission denied: '/usr/local/mailman/locks/gate_news.lock.ipheion.hoffmann.homeunix.net.54220.0'
> 
> Here are my observations:
> 
> 1. I currently have no file at /usr/local/mailman/locks/ whose name starts with "gate_news".
> 
> 2. My root Crontab has these lines:
> 
> 	# Every 5 mins, try to gate news to mail. You can comment this one out
> 	# if you don't want to allow gating, or don't have any going on right now,
> 	# or want to exclusively use a callback strategy instead of polling.
> 	# 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/python -S /usr/local/mailman/cron/gate_news
> 
>   In other words, the gate_news cron job is commented out.
> 
> 3. I have run /usr/local/mailman/bin/check_perms -f, but that has had no impact.


From mark at msapiro.net  Thu Oct 13 12:52:11 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 13 Oct 2016 09:52:11 -0700
Subject: [Mailman-Users] Cron has issues with gate_news
In-Reply-To: <7019B7AE-5C4D-48CF-9B9B-8949FE077AD4@uwalumni.com>
References: <A88B0EDD-290F-4BF9-9621-A8C908D1AC3A@uwalumni.com>
 <7019B7AE-5C4D-48CF-9B9B-8949FE077AD4@uwalumni.com>
Message-ID: <0d34ab9f-48ea-ea40-06ed-919aa70592a8@msapiro.net>

On 10/13/2016 08:56 AM, Dominik Hoffmann wrote:
> Another observation:
> 
> 4. Moving the Crontab from root to _mailman had no effect.


Good you moved it, but see below.


>> On Oct 13, 2016, at 11:43 AM, Dominik Hoffmann <dhoffmann at uwalumni.com> wrote:
>>
>> There are still a few of things to mop up, after an otherwise successful installation of Mailman on OS X El Capitan with Server 5.2.
>>
>> Every 5 min my admin user account on the server gets an email from the Cron Daemon that has this line:
>>
>> IOError: [Errno 13] Permission denied: '/usr/local/mailman/locks/gate_news.lock.ipheion.hoffmann.homeunix.net.54220.0'


cron/gate_news is trying to create the lock and has no permission to do so.


>> Here are my observations:
>>
>> 1. I currently have no file at /usr/local/mailman/locks/ whose name starts with "gate_news".


Normally, the lock would only exist during the few (milli)seconds that
gate_news was running, but in your case it isn't even created.


>> 2. My root Crontab has these lines:
>>
>> 	# Every 5 mins, try to gate news to mail. You can comment this one out
>> 	# if you don't want to allow gating, or don't have any going on right now,
>> 	# or want to exclusively use a callback strategy instead of polling.
>> 	# 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/python -S /usr/local/mailman/cron/gate_news
>>
>>   In other words, the gate_news cron job is commented out.


OK, but there is another crontab somewhere running gate_news.

Also, Mailman's cron jobs should run as the Mailman user (usually
_mailman in FreeBSD/Darwin), not as root.

Since the gate_news entry in the crontab entry you are looking at is
commented out, there must be another crontab somewhere.

You may have a system crontab in /etc/cron.d/ or another user crontab.
Note that the format of system crontabs is different. There is an
additional field between the times/days and the command for the user to
run as.


>> 3. I have run /usr/local/mailman/bin/check_perms -f, but that has had no impact.

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

From esknight at samford.edu  Thu Oct 13 12:51:04 2016
From: esknight at samford.edu (Knight, Eric)
Date: Thu, 13 Oct 2016 16:51:04 +0000
Subject: [Mailman-Users] one mailing list shunting messages
Message-ID: <DM2PR0801MB09442CD0CF813815ED16D970C1DC0@DM2PR0801MB0944.namprd08.prod.outlook.com>

I am not sure what to do about this message in error log, any help appreciated.


Oct 13 11:47:30 2016 (12368) SHUNTING: 1476372076.1651051+54a50f9eb22730094aba33728b8cee7136dad7e2
Oct 13 11:47:30 2016 (12368) Uncaught runner exception: local variable 'bodylen' referenced before assignment
Oct 13 11:47:30 2016 (12368) Traceback (most recent call last):
  File "/usr/server/sulists/Mailman/Queue/Runner.py", line 119, in _oneloop
    self._onefile(msg, msgdata)
  File "/usr/server/sulists/Mailman/Queue/Runner.py", line 190, in _onefile
    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/server/sulists/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
    more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/usr/server/sulists/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline
    sys.modules[modname].process(mlist, msg, msgdata)
  File "/usr/server/sulists/Mailman/Handlers/Hold.py", line 187, in process
    if bodylen/1024.0 > mlist.max_message_size:
UnboundLocalError: local variable 'bodylen' referenced before assignment

Oct 13 11:47:30 2016 (12368) SHUNTING: 1476376331.709368+f252c549b5b457fe876963e4dba623dd2047e456




E.S. Knight
Sr. Systems Programmer
Technology Services
205-726-2594 | office
esknight at samford.edu
www.samford.edu
800 Lakeshore Drive, Birmingham, AL 35229


From mark at msapiro.net  Thu Oct 13 13:28:01 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 13 Oct 2016 10:28:01 -0700
Subject: [Mailman-Users] one mailing list shunting messages
In-Reply-To: <DM2PR0801MB09442CD0CF813815ED16D970C1DC0@DM2PR0801MB0944.namprd08.prod.outlook.com>
References: <DM2PR0801MB09442CD0CF813815ED16D970C1DC0@DM2PR0801MB0944.namprd08.prod.outlook.com>
Message-ID: <efacb7ef-d9c6-ca86-6840-0c74cf0aeabc@msapiro.net>

On 10/13/2016 09:51 AM, Knight, Eric wrote:
> I am not sure what to do about this message in error log, any help appreciated.
> 
> 
> Oct 13 11:47:30 2016 (12368) SHUNTING: 1476372076.1651051+54a50f9eb22730094aba33728b8cee7136dad7e2
> Oct 13 11:47:30 2016 (12368) Uncaught runner exception: local variable 'bodylen' referenced before assignment
> Oct 13 11:47:30 2016 (12368) Traceback (most recent call last):
>   File "/usr/server/sulists/Mailman/Queue/Runner.py", line 119, in _oneloop
>     self._onefile(msg, msgdata)
>   File "/usr/server/sulists/Mailman/Queue/Runner.py", line 190, in _onefile
>     keepqueued = self._dispose(mlist, msg, msgdata)
>   File "/usr/server/sulists/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
>     more = self._dopipeline(mlist, msg, msgdata, pipeline)
>   File "/usr/server/sulists/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline
>     sys.modules[modname].process(mlist, msg, msgdata)
>   File "/usr/server/sulists/Mailman/Handlers/Hold.py", line 187, in process
>     if bodylen/1024.0 > mlist.max_message_size:
> UnboundLocalError: local variable 'bodylen' referenced before assignment
> 
> Oct 13 11:47:30 2016 (12368) SHUNTING: 1476376331.709368+f252c549b5b457fe876963e4dba623dd2047e456


What Mailman version is this? Are there any local modifications to
/usr/server/sulists/Mailman/Handlers/Hold.py?

You can run Mailman's bin/unshunt to process the shunted messages, but
only after fixing the issue in Hold.py (I'm sure this issue doesn't
exist in any version distributed by the GNU Mailman project). Or, you
can set the list's max_message_size to 0 (meaning unlimited) to avoid this.

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

From dhoffmann at uwalumni.com  Thu Oct 13 15:19:13 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Thu, 13 Oct 2016 15:19:13 -0400
Subject: [Mailman-Users] Administrative requests page for migrated lists
 uses wrong old server fqdn for data submission
Message-ID: <69DE2E0D-EABD-4145-9E4C-736156CD1E57@uwalumni.com>

My mailing lists were migrated from a machine running Mac OS X Server 10.6 (Snow Leopard) [let's refer to it by the fdqn old-server.domain.com], where mailman was supplied and supported out of the box. The destination was an OS X Server 10.11 (El Capitan) system running Server 5.2 [let's refer to it by the fdqn new-server.domain.com], which required the manual installation of mailman from source.

I copied the requisite directories archives, data, lists and qfiles from /var/mailman/ to /usr/local/mailman/. I then ran

	/usr/local/mailman/bin/check_perms -f

which made sure that these were given the proper permissions for the new system.

Let's say my mailing list is named "family." I can now bring up

	https://new-server.domain.com/mailman/admin/family

I can change all settings to my heart's content, and they all take. However, when I try to "Tend to pending moderator requests" and click on the Submit All Data button on

	https://new-server.domain.com/mailman/admindb/family

it directs me to

	http://old-server.domain.com/mailman/admindb/family

which has been decommissioned.

When editing the list settings, there were references to "old-server.domain.com" in the host_name field on the General Options page, and I changed that to "new-server.domain.com".

What do I need to fix, in order for the button submission to go through properly?

From mark at msapiro.net  Thu Oct 13 16:38:13 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 13 Oct 2016 13:38:13 -0700
Subject: [Mailman-Users] Administrative requests page for migrated lists
 uses wrong old server fqdn for data submission
In-Reply-To: <69DE2E0D-EABD-4145-9E4C-736156CD1E57@uwalumni.com>
References: <69DE2E0D-EABD-4145-9E4C-736156CD1E57@uwalumni.com>
Message-ID: <a676fbe7-5d13-500a-4baa-974123aba74c@msapiro.net>

On 10/13/2016 12:19 PM, Dominik Hoffmann wrote:
> 
> When editing the list settings, there were references to "old-server.domain.com" in the host_name field on the General Options page, and I changed that to "new-server.domain.com".
> 
> What do I need to fix, in order for the button submission to go through properly?


You need to run Mailman's fix_url. See this FAQ
<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 dhoffmann at uwalumni.com  Thu Oct 13 16:51:58 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Thu, 13 Oct 2016 16:51:58 -0400
Subject: [Mailman-Users] Administrative requests page for migrated lists
 uses wrong old server fqdn for data submission
In-Reply-To: <a676fbe7-5d13-500a-4baa-974123aba74c@msapiro.net>
References: <69DE2E0D-EABD-4145-9E4C-736156CD1E57@uwalumni.com>
 <a676fbe7-5d13-500a-4baa-974123aba74c@msapiro.net>
Message-ID: <AC25116D-FC8C-43CD-9F2E-007ADF17F90F@uwalumni.com>

Great! Thanks, Mark!

I ran

	/usr/local/mailman/bin/withlist -l -a -r fix_url

and now all my lists actually show up on the "Overview of all new-server.domain.com mailing lists" page.

One thing that still doesn't work is submission of the pending moderator requests. When I hit Submit All Data, the page simply reloads without any of the moderation directives having been taken into account.

Getting really close to having this thing up and running completely.

> On Oct 13, 2016, at 4:38 PM, Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 10/13/2016 12:19 PM, Dominik Hoffmann wrote:
>> 
>> When editing the list settings, there were references to "old-server.domain.com" in the host_name field on the General Options page, and I changed that to "new-server.domain.com".
>> 
>> What do I need to fix, in order for the button submission to go through properly?
> 
> 
> You need to run Mailman's fix_url. See this FAQ
> <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 mark at msapiro.net  Thu Oct 13 18:09:24 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 13 Oct 2016 15:09:24 -0700
Subject: [Mailman-Users] Administrative requests page for migrated lists
 uses wrong old server fqdn for data submission
In-Reply-To: <AC25116D-FC8C-43CD-9F2E-007ADF17F90F@uwalumni.com>
References: <69DE2E0D-EABD-4145-9E4C-736156CD1E57@uwalumni.com>
 <a676fbe7-5d13-500a-4baa-974123aba74c@msapiro.net>
 <AC25116D-FC8C-43CD-9F2E-007ADF17F90F@uwalumni.com>
Message-ID: <10305feb-54a4-9543-8b22-c0bdb760e7ba@msapiro.net>

On 10/13/2016 01:51 PM, Dominik Hoffmann wrote:
> 
> One thing that still doesn't work is submission of the pending moderator requests. When I hit Submit All Data, the page simply reloads without any of the moderation directives having been taken into account.


See <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 her at adm.ku.dk  Fri Oct 14 05:11:38 2016
From: her at adm.ku.dk (Henrik Rasmussen)
Date: Fri, 14 Oct 2016 09:11:38 +0000
Subject: [Mailman-Users] Understanding the flow of outgoing mails
Message-ID: <6DCC3E5DA06FE346B4DE4876C4F2713D019B77222A@P2KITMBX06WC03.unicph.domain>

I am trying to understand the Mailman mailflow and I am aware that stopping a mail from being distributed is not a trivial task. I've looked around and found this*) ,but it doesn't really explain the problem I am facing.

By accident, a list admin released a bunch of mail-replies to the list-address from people wanting to unsubscribe. The list contains 9000+ members.

To quickly work around the problem, I set a filter in Postfix rejecting all mails containing the particular subject and moved all outgoing mails from /var/spool/mailman/out to out.org, and thought I was home safe, but it seems that the list keeps putting mails with subject Unsubscribe in the out directory.

Does Mailman have another queue that I need to empty or filter out?

*) https://mail.python.org/pipermail/mailman-users/2014-September/077857.html

Henrik Rasmussen

From mark at msapiro.net  Fri Oct 14 11:05:10 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 14 Oct 2016 08:05:10 -0700
Subject: [Mailman-Users] Understanding the flow of outgoing mails
In-Reply-To: <6DCC3E5DA06FE346B4DE4876C4F2713D019B77222A@P2KITMBX06WC03.unicph.domain>
References: <6DCC3E5DA06FE346B4DE4876C4F2713D019B77222A@P2KITMBX06WC03.unicph.domain>
Message-ID: <2ecc2764-045b-322f-a4a3-23c8d8d27f7d@msapiro.net>

On 10/14/2016 02:11 AM, Henrik Rasmussen wrote:
> 
> ... it seems that the list keeps putting mails with subject Unsubscribe in the out directory.
> 
> Does Mailman have another queue that I need to empty or filter out?


So these are messages that were originally held (as administrivia or ?)
and "approved" by a moderator.

When a message is held, the message itself is placed in a
heldmsg-listname-nnn.ext file in mailman's data/ directory. (.ext is
normally .pck unless mm_cfg.HOLD_MESSAGES_AS_PICKLES is set False in
which case it is .txt). An entry is placed in the list's request.pck
file which is the basis for the moderator listing in the admindb
interface, and an entry is placed in the lists pending.pck file used to
process 'confirm' actions.

When such a message is approved, the heldmsg file is removed, the
message is marked in its metadata as approved and it is requeued in the
in/ queue for processing by the rest of the pipeline. This and logging
the approval in the vette log occur immediately, i.e. before the admindb
page refreshes).

Thus, the approved message is either in the in/ queue or the out/ queue
or it's been delivered to the MTA.

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

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

From mark at msapiro.net  Fri Oct 14 12:32:37 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 14 Oct 2016 09:32:37 -0700
Subject: [Mailman-Users] Understanding the flow of outgoing mails
In-Reply-To: <6DCC3E5DA06FE346B4DE4876C4F2713D019B772DFB@P2KITMBX06WC03.unicph.domain>
References: <6DCC3E5DA06FE346B4DE4876C4F2713D019B77222A@P2KITMBX06WC03.unicph.domain>
 <2ecc2764-045b-322f-a4a3-23c8d8d27f7d@msapiro.net>
 <6DCC3E5DA06FE346B4DE4876C4F2713D019B772DFB@P2KITMBX06WC03.unicph.domain>
Message-ID: <61895a74-9da7-9fd0-f625-37a681388df4@msapiro.net>

On 10/14/2016 08:39 AM, Henrik Rasmussen wrote:
> 
> Regarding Mailman keep posting messages to the MTA despite the out directory had been emptied, it appeared that the qrunner was still active even after running mailmanctl stop (and mailmanctl -s stop). Killing the qrunner by kill -9 only spawned a new qrunner. I had to kill -9 the mailmanctl process too, to make Mailman stop posting mails to the MTA.


That seems strange. 'mailmanctl stop' should stop all the idle qrunners.
For the running qrunners, they won't stop until they finish processing
the one currently processing message - the one named with a .bak
extension, but they should stop after that one, even if there are others
in the queue, and if you've removed .pck files from the queue, they
should not return by themselves.

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

From dhoffmann at uwalumni.com  Fri Oct 14 15:31:34 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Fri, 14 Oct 2016 15:31:34 -0400
Subject: [Mailman-Users] Administrative requests page for migrated lists
 uses wrong old server fqdn for data submission
In-Reply-To: <10305feb-54a4-9543-8b22-c0bdb760e7ba@msapiro.net>
References: <69DE2E0D-EABD-4145-9E4C-736156CD1E57@uwalumni.com>
 <a676fbe7-5d13-500a-4baa-974123aba74c@msapiro.net>
 <AC25116D-FC8C-43CD-9F2E-007ADF17F90F@uwalumni.com>
 <10305feb-54a4-9543-8b22-c0bdb760e7ba@msapiro.net>
Message-ID: <F1CA4574-0675-49F5-93F6-0E12821C6652@uwalumni.com>

Thanks very much, Mark, for the pointer to the FAQ! In particular, it seemed like FAQ 4.27 (cf. <https://wiki.list.org/x/4030702>) was most relevant.

Accordingly, I added the lines

	RewriteEngine on
	RewriteCond %{HTTPS}        off [NC]
	RewriteRule ^/mailman(/.*)  https://%{HTTP_HOST}/mailman$1   [L,R=permanent]

to

	/etc/apache2/extra/httpd-mailman.conf

which is included in

	/Library/Server/Web/Config/apache2/httpd_server_app.conf

on the line

	Include /private/etc/apache2/extra/httpd-mailman.conf


I also edited

	/usr/local/mailman/Mailman/mm_cfg.py

to include the line

	DEFAULT_URL_PATTERN = 'https://%s/mailman/'

Finally, I ran

	/usr/local/mailman/bin/withlist -l -a -r fix_url

again.

This made it all work!

> On Oct 13, 2016, at 6:09 PM, Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 10/13/2016 01:51 PM, Dominik Hoffmann wrote:
>> 
>> One thing that still doesn't work is submission of the pending moderator requests. When I hit Submit All Data, the page simply reloads without any of the moderation directives having been taken into account.
> 
> 
> See <https://wiki.list.org/x/4030602>.


From her at adm.ku.dk  Fri Oct 14 11:39:36 2016
From: her at adm.ku.dk (Henrik Rasmussen)
Date: Fri, 14 Oct 2016 15:39:36 +0000
Subject: [Mailman-Users] Understanding the flow of outgoing mails
In-Reply-To: <2ecc2764-045b-322f-a4a3-23c8d8d27f7d@msapiro.net>
References: <6DCC3E5DA06FE346B4DE4876C4F2713D019B77222A@P2KITMBX06WC03.unicph.domain>
 <2ecc2764-045b-322f-a4a3-23c8d8d27f7d@msapiro.net>
Message-ID: <6DCC3E5DA06FE346B4DE4876C4F2713D019B772DFB@P2KITMBX06WC03.unicph.domain>

> On 10/14/2016 05:05 PM, Mark Sapiro wrote:
> So these are messages that were originally held (as administrivia or ?) and "approved" by a moderator.

Correct. Moderator mistake.

Regarding Mailman keep posting messages to the MTA despite the out directory had been emptied, it appeared that the qrunner was still active even after running mailmanctl stop (and mailmanctl -s stop). Killing the qrunner by kill -9 only spawned a new qrunner. I had to kill -9 the mailmanctl process too, to make Mailman stop posting mails to the MTA.

Problem solved. Now I just have to find the "Unsubscribe!" mails, before re-moving the others back into the out directory.

Thank you for the explaination.

Henrik

From dhoffmann at uwalumni.com  Fri Oct 14 18:56:31 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Fri, 14 Oct 2016 18:56:31 -0400
Subject: [Mailman-Users] What log file do I check for successful
 transmission to the SMTP server?
Message-ID: <4578261F-4B83-4CDB-8FE4-26C5973C4D46@uwalumni.com>

So, all of my testing has so far been with email addresses that have their destination on the same system as the one, on which Mailman is running. I just tried a list that has all external destinations.

What log files should I look at to see, what might be going wrong?

From mark at msapiro.net  Fri Oct 14 19:12:00 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 14 Oct 2016 16:12:00 -0700
Subject: [Mailman-Users] What log file do I check for successful
 transmission to the SMTP server?
In-Reply-To: <4578261F-4B83-4CDB-8FE4-26C5973C4D46@uwalumni.com>
References: <4578261F-4B83-4CDB-8FE4-26C5973C4D46@uwalumni.com>
Message-ID: <1f351170-63d5-8a6c-25af-b5a7c1018f76@msapiro.net>

On 10/14/2016 03:56 PM, Dominik Hoffmann wrote:
> So, all of my testing has so far been with email addresses that have their destination on the same system as the one, on which Mailman is running. I just tried a list that has all external destinations.
> 
> What log files should I look at to see, what might be going wrong?


If there are problems in Mailman's SMTP delivery to the MTA, they will
be logged in Mailman's smtp-failure log. Also, whether the message is
rejected by the MTA at SMTP time or accepted and then rejected later
there should be an entry in Mailman's bounce log, although this doesn't
contain diagnostic info.

Also the MTA's logs should have complete info.

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

From dhoffmann at uwalumni.com  Fri Oct 14 22:30:03 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Fri, 14 Oct 2016 22:30:03 -0400
Subject: [Mailman-Users] What log file do I check for successful
 transmission to the SMTP server?
In-Reply-To: <1f351170-63d5-8a6c-25af-b5a7c1018f76@msapiro.net>
References: <4578261F-4B83-4CDB-8FE4-26C5973C4D46@uwalumni.com>
 <1f351170-63d5-8a6c-25af-b5a7c1018f76@msapiro.net>
Message-ID: <3BCD6285-3B93-4351-AA09-4D710C128736@uwalumni.com>

Does the fact that I don't have a file called smtp-failure at /usr/local/mailman/logs/ mean that no SMTP errors have occurred, as far as Mailman is concerned?

> On Oct 14, 2016, at 7:12 PM, Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 10/14/2016 03:56 PM, Dominik Hoffmann wrote:
>> So, all of my testing has so far been with email addresses that have their destination on the same system as the one, on which Mailman is running. I just tried a list that has all external destinations.
>> 
>> What log files should I look at to see, what might be going wrong?
> 
> 
> If there are problems in Mailman's SMTP delivery to the MTA, they will
> be logged in Mailman's smtp-failure log. Also, whether the message is
> rejected by the MTA at SMTP time or accepted and then rejected later
> there should be an entry in Mailman's bounce log, although this doesn't
> contain diagnostic info.
> 
> Also the MTA's logs should have complete info.
> 
> -- 
> 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/dhoffmann%40uwalumni.com


From mark at msapiro.net  Sat Oct 15 00:09:48 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 14 Oct 2016 21:09:48 -0700
Subject: [Mailman-Users] What log file do I check for successful
 transmission to the SMTP server?
In-Reply-To: <3BCD6285-3B93-4351-AA09-4D710C128736@uwalumni.com>
References: <4578261F-4B83-4CDB-8FE4-26C5973C4D46@uwalumni.com>
 <1f351170-63d5-8a6c-25af-b5a7c1018f76@msapiro.net>
 <3BCD6285-3B93-4351-AA09-4D710C128736@uwalumni.com>
Message-ID: <15eb7e72-18b1-8d53-159a-8abcc382d330@msapiro.net>

On 10/14/2016 07:30 PM, Dominik Hoffmann wrote:
> Does the fact that I don't have a file called smtp-failure at /usr/local/mailman/logs/ mean that no SMTP errors have occurred, as far as Mailman is concerned?


Yes. Assuming that that is the directory that contains at least the
qrunner and error logs and probably also smtp, post, subscribe, etc., it
means that log has never been written and Mailman has not had any
failures in it's SMTP transactions.

This means that everything Mailman tried to deliver to the MTA was
successfully delivered. It doesn't mean the MTA successfully delivered
the message(s) to the next relay. For that kind of failure, there should
be bounces recorded in the bounce log, but they won't say why. For that
you need the MTA log (maybe /var/log/mail.log or
/private/var/log/mail.log - my Macbook has a symlink /var ->
/private/var, but I may have created that).

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

From dhoffmann at uwalumni.com  Sat Oct 15 11:44:29 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Sat, 15 Oct 2016 11:44:29 -0400
Subject: [Mailman-Users] What log file do I check for successful
 transmission to the SMTP server?
In-Reply-To: <15eb7e72-18b1-8d53-159a-8abcc382d330@msapiro.net>
References: <4578261F-4B83-4CDB-8FE4-26C5973C4D46@uwalumni.com>
 <1f351170-63d5-8a6c-25af-b5a7c1018f76@msapiro.net>
 <3BCD6285-3B93-4351-AA09-4D710C128736@uwalumni.com>
 <15eb7e72-18b1-8d53-159a-8abcc382d330@msapiro.net>
Message-ID: <48F776E9-B758-42F2-BE06-B6EB4425A548@uwalumni.com>


> On Oct 15, 2016, at 12:09 AM, Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 10/14/2016 07:30 PM, Dominik Hoffmann wrote:
>> Does the fact that I don't have a file called smtp-failure at /usr/local/mailman/logs/ mean that no SMTP errors have occurred, as far as Mailman is concerned?
> 
> 
> Yes. Assuming that that is the directory that contains at least the
> qrunner and error logs and probably also smtp, post, subscribe, etc., it
> means that log has never been written and Mailman has not had any
> failures in it's SMTP transactions.
> 
> This means that everything Mailman tried to deliver to the MTA was
> successfully delivered. It doesn't mean the MTA successfully delivered
> the message(s) to the next relay. For that kind of failure, there should
> be bounces recorded in the bounce log, but they won't say why. For that
> you need the MTA log (maybe /var/log/mail.log or
> /private/var/log/mail.log - my Macbook has a symlink /var ->
> /private/var, but I may have created that).
> 
> -- 
> 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/dhoffmann%40uwalumni.com


From dhoffmann at uwalumni.com  Sat Oct 15 11:46:16 2016
From: dhoffmann at uwalumni.com (Dominik Hoffmann)
Date: Sat, 15 Oct 2016 11:46:16 -0400
Subject: [Mailman-Users] What log file do I check for successful
 transmission to the SMTP server?
In-Reply-To: <15eb7e72-18b1-8d53-159a-8abcc382d330@msapiro.net>
References: <4578261F-4B83-4CDB-8FE4-26C5973C4D46@uwalumni.com>
 <1f351170-63d5-8a6c-25af-b5a7c1018f76@msapiro.net>
 <3BCD6285-3B93-4351-AA09-4D710C128736@uwalumni.com>
 <15eb7e72-18b1-8d53-159a-8abcc382d330@msapiro.net>
Message-ID: <2F423205-0052-46A2-95CB-DA4A5E6B932C@uwalumni.com>

From the earliest days of Mac OS X, possibly even on the NextStep OS, /etc/ and /var/ have been really located inside of /private/ with simlinks putting them in the root directory.

> On Oct 15, 2016, at 12:09 AM, Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 10/14/2016 07:30 PM, Dominik Hoffmann wrote:
>> Does the fact that I don't have a file called smtp-failure at /usr/local/mailman/logs/ mean that no SMTP errors have occurred, as far as Mailman is concerned?
> 
> 
> Yes. Assuming that that is the directory that contains at least the
> qrunner and error logs and probably also smtp, post, subscribe, etc., it
> means that log has never been written and Mailman has not had any
> failures in it's SMTP transactions.
> 
> This means that everything Mailman tried to deliver to the MTA was
> successfully delivered. It doesn't mean the MTA successfully delivered
> the message(s) to the next relay. For that kind of failure, there should
> be bounces recorded in the bounce log, but they won't say why. For that
> you need the MTA log (maybe /var/log/mail.log or
> /private/var/log/mail.log - my Macbook has a symlink /var ->
> /private/var, but I may have created that).
> 
> -- 
> 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/dhoffmann%40uwalumni.com


From beta at admilon.net  Tue Oct 18 04:57:32 2016
From: beta at admilon.net (Matthias Schmidt)
Date: Tue, 18 Oct 2016 17:57:32 +0900
Subject: [Mailman-Users] Start qrunner on ElCapitan (MacOS X Server)
Message-ID: <A535C02A-FB41-459B-9B36-EB7B77230543@admilon.net>

Hello,
I?m trying to start mailman on startup with ElCapitan.

I tried a plist in LaunchDaemons - that was working in the past with the command:
/usr/local/mailman/bin/mailmanctl -s start

this produces now the error:
Service only ran for 2 seconds. Pushing respawn out by 8 seconds

the error log says:
The master qrunner lock could not be acquired because it appears as if another
master qrunner is already running

So it starts, creates a lock as localhost ? and then it tries to start again.

than I created a startup script as described here:
https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/StartupItems.html#//apple_ref/doc/uid/10000172i-SW9-CJBBHDII

and it does ? nothing

the only thing which works currently is starting it manually with sudo
and this is kind of inconvenient

I installed mailman manually without using macports or something like that.

I hope someone on the list can share some insight here.

thanks
Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20161018/b0c75ac7/attachment.sig>

From mailman-admin at uni-konstanz.de  Tue Oct 18 09:50:42 2016
From: mailman-admin at uni-konstanz.de (mailman-admin)
Date: Tue, 18 Oct 2016 15:50:42 +0200
Subject: [Mailman-Users] Start qrunner on ElCapitan (MacOS X Server)
In-Reply-To: <A535C02A-FB41-459B-9B36-EB7B77230543@admilon.net>
References: <A535C02A-FB41-459B-9B36-EB7B77230543@admilon.net>
Message-ID: <1a7c5d14-380d-f28f-4b34-e054662ad253@uni-konstanz.de>

Am 18.10.2016 um 10:57 schrieb Matthias Schmidt via Mailman-Users:
> Hello,
> I?m trying to start mailman on startup with ElCapitan.
> 
> I tried a plist in LaunchDaemons - that was working in the past with the command:
> /usr/local/mailman/bin/mailmanctl -s start
> 
> this produces now the error:
> Service only ran for 2 seconds. Pushing respawn out by 8 seconds
> 
> the error log says:
> The master qrunner lock could not be acquired because it appears as if another
> master qrunner is already running
> 
> So it starts, creates a lock as localhost ? and then it tries to start again.
> 
> than I created a startup script as described here:
> https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/StartupItems.html#//apple_ref/doc/uid/10000172i-SW9-CJBBHDII
> 
> and it does ? nothing
> 
> the only thing which works currently is starting it manually with sudo
> and this is kind of inconvenient
> 
> I installed mailman manually without using macports or something like that.
> 
> I hope someone on the list can share some insight here.
> 

Do you shutdown mailman cleanly?
If not, you leave a pid file behind, which will prevent mailman from
starting.


Kind regards,
Christian Mack



From beta at admilon.net  Tue Oct 18 10:39:27 2016
From: beta at admilon.net (Matthias Schmidt)
Date: Tue, 18 Oct 2016 23:39:27 +0900
Subject: [Mailman-Users] Start qrunner on ElCapitan (MacOS X Server)
In-Reply-To: <1a7c5d14-380d-f28f-4b34-e054662ad253@uni-konstanz.de>
References: <A535C02A-FB41-459B-9B36-EB7B77230543@admilon.net>
 <1a7c5d14-380d-f28f-4b34-e054662ad253@uni-konstanz.de>
Message-ID: <47BA4943-D209-4A32-979A-9F2F207460A0@admilon.net>


> Am 18.10.2016 um 22:50 schrieb mailman-admin <mailman-admin at uni-konstanz.de>:
> 
> Am 18.10.2016 um 10:57 schrieb Matthias Schmidt via Mailman-Users:
>> Hello,
>> I?m trying to start mailman on startup with ElCapitan.
>> 
>> I tried a plist in LaunchDaemons - that was working in the past with the command:
>> /usr/local/mailman/bin/mailmanctl -s start
>> 
>> this produces now the error:
>> Service only ran for 2 seconds. Pushing respawn out by 8 seconds
>> 
>> the error log says:
>> The master qrunner lock could not be acquired because it appears as if another
>> master qrunner is already running
>> 
>> So it starts, creates a lock as localhost ? and then it tries to start again.
>> 
>> than I created a startup script as described here:
>> https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/StartupItems.html#//apple_ref/doc/uid/10000172i-SW9-CJBBHDII
>> 
>> and it does ? nothing
>> 
>> the only thing which works currently is starting it manually with sudo
>> and this is kind of inconvenient
>> 
>> I installed mailman manually without using macports or something like that.
>> 
>> I hope someone on the list can share some insight here.
>> 
> 
> Do you shutdown mailman cleanly?

mailman was not running before startup and for the test I made sure that there are no pid files present

> If not, you leave a pid file behind, which will prevent mailman from
> starting.


the -s option should fix that problem ;-)
but if mailman is started as local then -s doesn?t remove a stray pid file.

cheers
Matthias


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20161018/eb65a8a2/attachment.sig>

From mark at msapiro.net  Wed Oct 19 00:04:26 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 18 Oct 2016 21:04:26 -0700
Subject: [Mailman-Users] Start qrunner on ElCapitan (MacOS X Server)
In-Reply-To: <47BA4943-D209-4A32-979A-9F2F207460A0@admilon.net>
References: <A535C02A-FB41-459B-9B36-EB7B77230543@admilon.net>
 <1a7c5d14-380d-f28f-4b34-e054662ad253@uni-konstanz.de>
 <47BA4943-D209-4A32-979A-9F2F207460A0@admilon.net>
Message-ID: <bfa1214f-a47a-294c-a561-923102a0dcd6@msapiro.net>

On 10/18/2016 07:39 AM, Matthias Schmidt via Mailman-Users wrote:
> 
> the -s option should fix that problem ;-)


If it can determine that the lock is stale.


> but if mailman is started as local then -s doesn?t remove a stray pid file.


What do you mean by "if mailman is started as local"?

What is the output from 'mailmanctl -s start'?

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

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

From beta at admilon.net  Wed Oct 19 05:51:10 2016
From: beta at admilon.net (Matthias Schmidt)
Date: Wed, 19 Oct 2016 18:51:10 +0900
Subject: [Mailman-Users] Start qrunner on ElCapitan (MacOS X Server)
In-Reply-To: <bfa1214f-a47a-294c-a561-923102a0dcd6@msapiro.net>
References: <A535C02A-FB41-459B-9B36-EB7B77230543@admilon.net>
 <1a7c5d14-380d-f28f-4b34-e054662ad253@uni-konstanz.de>
 <47BA4943-D209-4A32-979A-9F2F207460A0@admilon.net>
 <bfa1214f-a47a-294c-a561-923102a0dcd6@msapiro.net>
Message-ID: <51F9163E-BBD8-42B5-B2C3-68B914E7B4E3@admilon.net>

Mark,

> Am 19.10.2016 um 13:04 schrieb Mark Sapiro <mark at msapiro.net>:
> 
> On 10/18/2016 07:39 AM, Matthias Schmidt via Mailman-Users wrote:
>> 
>> the -s option should fix that problem ;-)
> 
> 
> If it can determine that the lock is stale.
> 
> 
>> but if mailman is started as local then -s doesn?t remove a stray pid file.
> 
> 
> What do you mean by ?if mailman is started as local"?

oh I had that before, it was starting as localhost, that was at least the message.

Now I get in the system log:
com.apple.xpc.launchd[1] (org.mailman): Service only ran for 1 seconds. Pushing respawn out by 9 seconds.

and after that I get:
The master qrunner lock could not be acquired because it appears as if another
master qrunner is already running.
in mailman?s error log

after unloading the plist and running mailmanctl -s start again, I get the same error as output.
When I delete these 2 lock files and run mailmanctl start as sudo all is fine.

So starting mailman manually is not a problem.
I just don?t get it started via a plist with launchd.

I also created a  script like this and pointed the plist to the script:
#!/bin/sh
function fstartup()
{
    /usr/local/mailman/bin/mailmanctl -s start
}
function fshutdown()
{
    /usr/local/mailman/bin/mailmanctl stop
    tail -f /dev/null &
	wait $!
}

trap fshutdown SIGTERM
trap fshutdown SIGKILL
fstartup;

this seams to do nothing at all ?at least there?s nothing in the logs.

cheers
Matthias


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20161019/b36f1ee9/attachment.sig>

From mark at msapiro.net  Wed Oct 19 10:55:04 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 19 Oct 2016 07:55:04 -0700
Subject: [Mailman-Users] Start qrunner on ElCapitan (MacOS X Server)
In-Reply-To: <51F9163E-BBD8-42B5-B2C3-68B914E7B4E3@admilon.net>
References: <A535C02A-FB41-459B-9B36-EB7B77230543@admilon.net>
 <1a7c5d14-380d-f28f-4b34-e054662ad253@uni-konstanz.de>
 <47BA4943-D209-4A32-979A-9F2F207460A0@admilon.net>
 <bfa1214f-a47a-294c-a561-923102a0dcd6@msapiro.net>
 <51F9163E-BBD8-42B5-B2C3-68B914E7B4E3@admilon.net>
Message-ID: <fb9f9f0c-0ee2-6535-1cf2-9977d19a5157@msapiro.net>

On 10/19/2016 02:51 AM, Matthias Schmidt wrote:
> 
> Now I get in the system log:
> com.apple.xpc.launchd[1] (org.mailman): Service only ran for 1 seconds. Pushing respawn out by 9 seconds.
> 
> and after that I get:
> The master qrunner lock could not be acquired because it appears as if another
> master qrunner is already running.
> in mailman?s error log


Because the original master IS still running. The PID in the lockfile
exists. The problem is 'mailmanctl start' forks a watcher process. The
original mailmanctl exits so launchd thinks it only ran for 1 second,
but it's child and all the qrunners are still running.


> after unloading the plist and running mailmanctl -s start again, I get the same error as output.
> When I delete these 2 lock files and run mailmanctl start as sudo all is fine.


All is not fine. You have 2 Mailman instances running. See
<https://wiki.list.org/x/4030715>.

I don't know how to set up plist's for launchd. There may be some sort
of daemon option to account for processes that fork a daemon and then exit.

See <https://wiki.list.org/x/4030523> and posts linked therefrom, in
particular
<http://www.mail-archive.com/mailman-users at python.org/msg56923.html>.
This is for 10.6, and I don't know if 10.11 is different in this respect
or not. I think there is more recent discussion in this list's archives
which you may find by searching at
<http://www.mail-archive.com/mailman-users at python.org/>.

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

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

From mark at msapiro.net  Wed Oct 19 20:59:38 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 19 Oct 2016 17:59:38 -0700
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
In-Reply-To: <b29ed395-f3be-40b1-f844-2cae2f09ff49@msapiro.net>
References: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
 <22524.23857.268693.971327@turnbull.sk.tsukuba.ac.jp>
 <CAGfsgR15i95AQgVZCFxdL78WvcbiUtqU0am9CYkcQGpLmM=cSg@mail.gmail.com>
 <b29ed395-f3be-40b1-f844-2cae2f09ff49@msapiro.net>
Message-ID: <300996f5-cc80-ce06-a02e-1072931ba6a5@msapiro.net>

On 10/11/2016 09:11 AM, Mark Sapiro wrote:
> On 10/11/2016 08:37 AM, Jim Popovitch wrote:
>>
>> The emails fail DMARC because the From: is the virtual list domain,
>> but the Sender is set to the site-list (often a neutral domain used
>> for the MTA that hosts the virtual lists).   OpenDKIM signs based on
>> the Sender (see: "MAILING LISTS" at
>> http://www.opendkim.org/opendkim-README), so the sig is NOT aligned
>> with From, thus failing DMARC...and getting notification emails
>> de-prioritized or worse.
> 
> 
> I haven't yet looked at your suggested changes, and I will.


I haven't forgotten. I still have only briefly looked at your changes,
but I'm concerned about your rev 1381 in light of the two comment lines
that precede the change.

The issue is if owner notifications come from the list-bounces rather
than the site email bounces. Then if an owner notice bounces, the owner
is sent a notice of the bounce and it bounces again and so on in a
bounce loop.

I don't understand why you are making this change as the sender
originally is Utils.get_site_email(mlist.host_name, 'bounces'), so it
already has the list's domain.

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

From jimpop at gmail.com  Thu Oct 20 05:10:22 2016
From: jimpop at gmail.com (Jim Popovitch)
Date: Thu, 20 Oct 2016 05:10:22 -0400
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
In-Reply-To: <300996f5-cc80-ce06-a02e-1072931ba6a5@msapiro.net>
References: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
 <22524.23857.268693.971327@turnbull.sk.tsukuba.ac.jp>
 <CAGfsgR15i95AQgVZCFxdL78WvcbiUtqU0am9CYkcQGpLmM=cSg@mail.gmail.com>
 <b29ed395-f3be-40b1-f844-2cae2f09ff49@msapiro.net>
 <300996f5-cc80-ce06-a02e-1072931ba6a5@msapiro.net>
Message-ID: <CAGfsgR2YLZX0n1PmGhC_J1s_6a9mpkSLjaFzk7TUMfo-R+45jg@mail.gmail.com>

On Wed, Oct 19, 2016 at 8:59 PM, Mark Sapiro <mark at msapiro.net> wrote:
> On 10/11/2016 09:11 AM, Mark Sapiro wrote:
>> On 10/11/2016 08:37 AM, Jim Popovitch wrote:
>>>
>>> The emails fail DMARC because the From: is the virtual list domain,
>>> but the Sender is set to the site-list (often a neutral domain used
>>> for the MTA that hosts the virtual lists).   OpenDKIM signs based on
>>> the Sender (see: "MAILING LISTS" at
>>> http://www.opendkim.org/opendkim-README), so the sig is NOT aligned
>>> with From, thus failing DMARC...and getting notification emails
>>> de-prioritized or worse.
>>
>>
>> I haven't yet looked at your suggested changes, and I will.
>
>
> I haven't forgotten. I still have only briefly looked at your changes,
> but I'm concerned about your rev 1381 in light of the two comment lines
> that precede the change.

Hi Mark, I'll be the first to say that a lot of these changes still
aren't clearly vetted and/or necessary.   That said, my process has
been simple.   I set a DMARC quarantine on a virtual mailinglist, and
then started to look at the mod/owner/password/bounce messages that
failed DMARC.  One by one I dug into the code to try and figure out
where/how the sitelist hostname was being used.   Rev 1380 and 1381
deal with "Bounce action notification" messages... and to be honest
I'm not 100% sure those changes are all that complete.  :-)

Note: this also assumes that one is following the point #3 under
"MAILING LISTS" advice on http://www.opendkim.org/opendkim-README
which says:

             In opendkim.conf(5), configure the option SenderHeaders
to "Sender,From".

The above statement makes sense for mailinglist traffic, BUT no so
much for mailinglist notifications.... but if DKIM is configure as
stated, then Mailman list notifications (owner/bounces/passwords/etc)
need to set Sender: headers that align with the virtual domain not the
sitelist domain.  That looked be the default intention of using
Message.OwnerNotification()

> The issue is if owner notifications come from the list-bounces rather
> than the site email bounces. Then if an owner notice bounces, the owner
> is sent a notice of the bounce and it bounces again and so on in a
> bounce loop.

But that would be a general MTA/config issue, whereas clearly mixing
From:list-owner at virtual with Sender:mailman-bounces at site is going to
break DMARC.

> I don't understand why you are making this change as the sender
> originally is Utils.get_site_email(mlist.host_name, 'bounces'), so it
> already has the list's domain.
>

The change baffled me too.  It wasn't visually necessary by looking at
the code, but in practice it needed to be changed.   I verified list
settings to make sure mlist.host_name was the virtual, I dug into
Utils.get_site_email(), and everything seemed to be coded correctly.
But it was only after I removed the call to Utils.get_site_email(...)
and replaced it with mlist.getListAddress('bounces') that the "Bounce
action notification" emails started to be delivered as
From:list-bounces at virtal, Sender:list-bounces at virtual,
To:list-owner at virtual.

I'm not in over my head on this, I'm literally floating on the bottom :-)

-Jim P.

From minxmertzmomo at gmail.com  Thu Oct 20 12:56:35 2016
From: minxmertzmomo at gmail.com (Matt Morgan)
Date: Thu, 20 Oct 2016 12:56:35 -0400
Subject: [Mailman-Users] deleting an accidentally accepted spam posting
Message-ID: <CABTRqU5Vwja4bTAvop4_JjBSqQuYNDZZmpHDmbBS5Vra112sQQ@mail.gmail.com>

When moderating posts, I forwarded several to myself all at once, saw they
were fine, then went back and "accepted" them all at once. Just as I
clicked Submit, I saw that one was a new message I hadn't reviewed, and it
looked like spam. Too late; I clicked Submit.

Fortunately, this list is 100% digest-only with the exception of
mail-archive.com, and their spam filtering seems to have killed it there.

I loaded digest.mbox with mutt and deleted the offending message, so (I
believe) it won't be in the next digest. Is that all I have to do to wipe
this from my server? What else?

Thanks!
Matt

From mark at msapiro.net  Thu Oct 20 13:26:27 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 20 Oct 2016 10:26:27 -0700
Subject: [Mailman-Users] Message.UserNotification vs
 Message.OwnerNotification in Handlers/Hold.py
In-Reply-To: <CAGfsgR2YLZX0n1PmGhC_J1s_6a9mpkSLjaFzk7TUMfo-R+45jg@mail.gmail.com>
References: <CAGfsgR1-=wXcy8ayos_9X+ygUe+-6EEW5LoMu_1H7N8Uq40g+A@mail.gmail.com>
 <22524.23857.268693.971327@turnbull.sk.tsukuba.ac.jp>
 <CAGfsgR15i95AQgVZCFxdL78WvcbiUtqU0am9CYkcQGpLmM=cSg@mail.gmail.com>
 <b29ed395-f3be-40b1-f844-2cae2f09ff49@msapiro.net>
 <300996f5-cc80-ce06-a02e-1072931ba6a5@msapiro.net>
 <CAGfsgR2YLZX0n1PmGhC_J1s_6a9mpkSLjaFzk7TUMfo-R+45jg@mail.gmail.com>
Message-ID: <5adab782-4c36-0078-8f3d-c7ca7bc17d30@msapiro.net>

Just a few quick remarks:

On 10/20/2016 02:10 AM, Jim Popovitch wrote:
> On Wed, Oct 19, 2016 at 8:59 PM, Mark Sapiro <mark at msapiro.net> wrote:
> 
> Note: this also assumes that one is following the point #3 under
> "MAILING LISTS" advice on http://www.opendkim.org/opendkim-README
> which says:
> 
>              In opendkim.conf(5), configure the option SenderHeaders
> to "Sender,From".


I use

SenderHeaders           List-Post,Sender,From

This probably doesn't help here because notices don't have a List-Post:
header.


> The above statement makes sense for mailinglist traffic, BUT no so
> much for mailinglist notifications.... but if DKIM is configure as
> stated, then Mailman list notifications (owner/bounces/passwords/etc)
> need to set Sender: headers that align with the virtual domain not the
> sitelist domain.  That looked be the default intention of using
> Message.OwnerNotification()


Agreed.


>> I don't understand why you are making this change as the sender
>> originally is Utils.get_site_email(mlist.host_name, 'bounces'), so it
>> already has the list's domain.
>>
> 
> The change baffled me too.  It wasn't visually necessary by looking at
> the code, but in practice it needed to be changed.   I verified list
> settings to make sure mlist.host_name was the virtual, I dug into
> Utils.get_site_email(), and everything seemed to be coded correctly.
> But it was only after I removed the call to Utils.get_site_email(...)
> and replaced it with mlist.getListAddress('bounces') that the "Bounce
> action notification" emails started to be delivered as
> From:list-bounces at virtal, Sender:list-bounces at virtual,
> To:list-owner at virtual.
> 
> I'm not in over my head on this, I'm literally floating on the bottom :-)


At some point, I will have time to actually test some of this and figure
out what's going on and what's required. I agree that using
Message.OwnerNotification() is generally preferable to using
Message.UserNotification() to the list-owner address if for no other
reason that it allows leaving the moderators out of notices that don't
concern them.

Right now, I'm in the middle of a significant feature addition for MM 3.
When that's done, I'll have more time to look at this.

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

From mark at msapiro.net  Thu Oct 20 14:06:27 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 20 Oct 2016 11:06:27 -0700
Subject: [Mailman-Users] deleting an accidentally accepted spam posting
In-Reply-To: <CABTRqU5Vwja4bTAvop4_JjBSqQuYNDZZmpHDmbBS5Vra112sQQ@mail.gmail.com>
References: <CABTRqU5Vwja4bTAvop4_JjBSqQuYNDZZmpHDmbBS5Vra112sQQ@mail.gmail.com>
Message-ID: <6c817c03-85fe-9898-ef24-2d41870ed7e6@msapiro.net>

On 10/20/2016 09:56 AM, Matt Morgan wrote:
> 
> Fortunately, this list is 100% digest-only with the exception of
> mail-archive.com, and their spam filtering seems to have killed it there.
> 
> I loaded digest.mbox with mutt and deleted the offending message, so (I
> believe) it won't be in the next digest. Is that all I have to do to wipe
> this from my server? What else?


Does your list have local archives in addition to archiving at
mail-archive.com? If so, you probably want to remove it from the archive
too.

There are various ways to do this. Some are relatively easy, but may
have undesirable side effects. Some are very involved.

See <https://wiki.list.org/x/4030681> for more information.

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

From luscheina at yahoo.de  Fri Oct 21 03:48:36 2016
From: luscheina at yahoo.de (Christian F Buser)
Date: Fri, 21 Oct 2016 09:48:36 +0200
Subject: [Mailman-Users] Recipient disabled due to bounces
Message-ID: <20161021094836133004.2f7208f7@yahoo.de>

Good morning 

I just gor a message from Mailman that a list subscription has been disabled because of too many bounces. This is quite okay, I think - but when I look at the Mailman management page, the user is still there as a subscribe. The only difference is the check mark and a "B" in the area "no message (reason)". 

Of course, he does not receive any more messages, and the "B" probably means because messages have bounced. But why isn't he unsubscribed completely? 

Thank you for clarifying. 

Christian 

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

From Hagedorn at uni-koeln.de  Fri Oct 21 04:20:32 2016
From: Hagedorn at uni-koeln.de (Sebastian Hagedorn)
Date: Fri, 21 Oct 2016 10:20:32 +0200
Subject: [Mailman-Users] Recipient disabled due to bounces
In-Reply-To: <20161021094836133004.2f7208f7@yahoo.de>
References: <20161021094836133004.2f7208f7@yahoo.de>
Message-ID: <FE821BE9B53E0F425C188BBC@tyrion.rrz.uni-koeln.de>

--On 21. Oktober 2016 um 09:48:36 +0200 Christian F Buser via Mailman-Users 
<mailman-users at python.org> wrote:

> I just gor a message from Mailman that a list subscription has been
> disabled because of too many bounces. This is quite okay, I think - but
> when I look at the Mailman management page, the user is still there as a
> subscribe. The only difference is the check mark and a "B" in the area
> "no message (reason)".
>
> Of course, he does not receive any more messages, and the "B" probably
> means because messages have bounced. But why isn't he unsubscribed
> completely?

Once a user is disabled, by default Mailman keeps sending a few messages to 
the address to check if it's working again. This is controlled by the 
bounce_you_are_disabled_warnings setting.
-- 
    .:.Sebastian Hagedorn - Weyertal 121 (Geb?ude 133), Zimmer 2.02.:.
                 .:.Regionales Rechenzentrum (RRZK).:.
   .:.Universit?t zu K?ln / Cologne University - ? +49-221-470-89578.:.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20161021/ce21f4d0/attachment.sig>

From beta at admilon.net  Sun Oct 23 01:44:54 2016
From: beta at admilon.net (Matthias Schmidt)
Date: Sun, 23 Oct 2016 14:44:54 +0900
Subject: [Mailman-Users] Start qrunner on ElCapitan (MacOS X Server)
In-Reply-To: <fb9f9f0c-0ee2-6535-1cf2-9977d19a5157@msapiro.net>
References: <A535C02A-FB41-459B-9B36-EB7B77230543@admilon.net>
 <1a7c5d14-380d-f28f-4b34-e054662ad253@uni-konstanz.de>
 <47BA4943-D209-4A32-979A-9F2F207460A0@admilon.net>
 <bfa1214f-a47a-294c-a561-923102a0dcd6@msapiro.net>
 <51F9163E-BBD8-42B5-B2C3-68B914E7B4E3@admilon.net>
 <fb9f9f0c-0ee2-6535-1cf2-9977d19a5157@msapiro.net>
Message-ID: <89D716A8-3517-4BC1-A904-B6FB6A8290DD@admilon.net>

Mark,

thanks.

> Am 19.10.2016 um 23:55 schrieb Mark Sapiro <mark at msapiro.net>:
> 
> On 10/19/2016 02:51 AM, Matthias Schmidt wrote:
>> 
>> Now I get in the system log:
>> com.apple.xpc.launchd[1] (org.mailman): Service only ran for 1 seconds. Pushing respawn out by 9 seconds.
>> 
>> and after that I get:
>> The master qrunner lock could not be acquired because it appears as if another
>> master qrunner is already running.
>> in mailman?s error log
> 
> 
> Because the original master IS still running. The PID in the lockfile
> exists. The problem is 'mailmanctl start' forks a watcher process. The
> original mailmanctl exits so launchd thinks it only ran for 1 second,
> but it?s child and all the qrunners are still running.
> 
> 
>> after unloading the plist and running mailmanctl -s start again, I get the same error as output.
>> When I delete these 2 lock files and run mailmanctl start as sudo all is fine.
> 
> 
> All is not fine. You have 2 Mailman instances running. See
> <https://wiki.list.org/x/4030715>.
> 
> I don't know how to set up plist's for launchd. There may be some sort
> of daemon option to account for processes that fork a daemon and then exit.


that was the right hint, adding sleep 1 to my script did the trick :-)

thank you :-)

Matthias

> 
> See <https://wiki.list.org/x/4030523> and posts linked therefrom, in
> particular
> <http://www.mail-archive.com/mailman-users at python.org/msg56923.html>.
> This is for 10.6, and I don't know if 10.11 is different in this respect
> or not. I think there is more recent discussion in this list's archives
> which you may find by searching at
> <http://www.mail-archive.com/mailman-users at python.org/>.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20161023/28eb77a7/attachment.sig>

From kippels at hhu.de  Mon Oct 24 10:07:33 2016
From: kippels at hhu.de (Julian Kippels)
Date: Mon, 24 Oct 2016 16:07:33 +0200
Subject: [Mailman-Users] Recursive lists
Message-ID: <20161024160733.3fc9dc47@kriemhild>

Hi,

is it possible to subsrcibe a list to another list?

For example I have the lists scientists at domain, students at domain and
all at domain. I would like to subscribe the scientists and students lists
to all so that I can reach everyone with a single list.

Thanks
Julian

From jewel.brueggeman-makda at washburn.edu  Mon Oct 24 09:41:09 2016
From: jewel.brueggeman-makda at washburn.edu (Jewel Brueggeman-Makda)
Date: Mon, 24 Oct 2016 13:41:09 +0000
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
Message-ID: <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>

Would it be best to copy the entire mailman directory to the new server or just the lists and archives?  
Command issued on new server to copy data from old.
rsync -avr root at serverip:/usr/local/mailman /usr/local/mailman

-----Original Message-----
From: Mailman-Users [mailto:mailman-users-bounces+jewel.makda=washburn.edu at python.org] On Behalf Of Mark Sapiro
Sent: Saturday, September 24, 2016 11:36 AM
To: mailman-users at python.org
Subject: Re: [Mailman-Users] Migrating Mailman to New Server (Same Domain)

On 09/23/2016 02:50 PM, Jewel Brueggeman-Makda wrote:
> TGIF Mailman Gurus,
> 
> My current Mailman 2.1.12 server is lists.washlaw.edu and is running on a RedHat vm.  I need to move it onto a new server which already has a new instance of Mailman 2.1.22 also on a RedHat vm. I already ran the ./configure command to be the same setup as the OLD server.  I have searched the discussion list archives on the steps and am not fully understanding what needs to be done. Below are the steps I do know I need to take but then I am at a loss.
> 
> 
> 1.       Post Postfix, Apache and Mialman on OLD server and NEW servers
> 
> 2.       Tar up the lists and archives from the mailman directory and copy the tar files to the new server
> 
> a.       tar xvfx /usr/local/mailman/lists

should be  'tar cpvzf lists.tgz /usr/local/mailman/lists'

> b.      tar xvfz /usr/local/mailman/archives

should be 'tar cpvzf archives.tgz /usr/local/mailman/archives'

caveat: do not use the -h/--dereference option because archives/public contains only symlinks, and if it winds up with actual files, they don't get updated.


> 3.       Untar the lists and archives onto NEW server
> 
> a.       tar -xvf lists.tgz
> 
> b.      tar -xvf archives.tgz


Or instead of 2 and 3, if the two servers can talk to each other, use 'rsync -a'.


> c.       Run from /usr/local/mailman/bin ./check_perms -f
> 
> 4.       Run newaliases

You don't need to run newaliases, but you do need to run Mailman's bin/genaliases.

Assuming the new server will ultimately be accessed via the old servers mail and web domain names, that's all you need.

If domain names will change, you will need to run fix_url after moving the lists. See <https://wiki.list.org/x/4030616>.

And, for the archives, in order to fix URLs to listinfo pages in the archives, the easiest thing is to just move the /usr/local/mailman/archives/private/LIST.mbox/LIST.mbox files and rebuild the pipermail archives with 'bin/arch --wipe'

-- 
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/jewel.makda%40washburn.edu

From mark at msapiro.net  Mon Oct 24 11:19:38 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 24 Oct 2016 08:19:38 -0700
Subject: [Mailman-Users] Recursive lists
In-Reply-To: <20161024160733.3fc9dc47@kriemhild>
References: <20161024160733.3fc9dc47@kriemhild>
Message-ID: <86712e49-5832-36bd-8805-20caa32cafba@msapiro.net>

On 10/24/2016 07:07 AM, Julian Kippels wrote:
> 
> is it possible to subsrcibe a list to another list?


See <https://wiki.list.org/x/4030574> and <https://wiki.list.org/x/4030540>.

-- 
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 Oct 24 11:37:10 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 24 Oct 2016 08:37:10 -0700
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
 <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
Message-ID: <9613d6ce-7f2c-0658-6efc-2f37a2a185ab@msapiro.net>

On 10/24/2016 06:41 AM, Jewel Brueggeman-Makda wrote:
> Would it be best to copy the entire mailman directory to the new server or just the lists and archives?  
> Command issued on new server to copy data from old.
> rsync -avr root at serverip:/usr/local/mailman /usr/local/mailman


That rsync should work if you want absolutely everything to be the same.
There could be issues if the whole environment is not the same. E.g. if
Mailman was configured --with-python=/usr/bin/python2.6 and the only
Python on the new server is Python 2.7.

Also, there can be considerations if E.g. the user number for the
'mailman' user is different on the new server, but rsync usually handles
that, at least if running as root on both ends.

That's why we suggest building a working Mailman on the new server and
just moving lists and archives.

Aside: the 'r' in '-avr' is redundant as it is implied by '-a'.

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

From fmouse at fmp.com  Mon Oct 24 11:45:10 2016
From: fmouse at fmp.com (Lindsay Haisley)
Date: Mon, 24 Oct 2016 10:45:10 -0500
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
 <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
Message-ID: <1477323910.54228.200.camel@fmp.com>

FWIW, I've done two complete migrations of a number of mailman (v2)
lists as I've changed servers over the past few years. A couple of
scripts I've used have worked perfectly in every case. In every
migration, the basic Mailman installation is set up and running on the
new server. Mailman versions, as long as we're talking about v2.x.x,
are a no-nevermind.?

The first, which runs on the old server is called tar_list.sh, is kept
in /usr/local/sbin and is run as root:

    #!/bin/sh
    if [ "$1" = "" ]; then
    	    echo 'Usage: tar_list.sh <listname>'
    	    exit
    fi

    if [ ! -e /var/lib/mailman/lists/$1 ]; then
    	    echo "$1: No such list!"
    	    exit
    fi

    mkdir /tmp/$1
    cd /var/lib/mailman/lists/

    echo Creating $1_list.tar.gz ....
    tar -czvf $1_list.tar.gz $1
    mv $1_list.tar.gz /tmp/$1

    cd /var/lib/mailman/archives/private/

    echo Creating $1_archive.tar.gz ....
    tar -czvf $1_archive.tar.gz $1
    mv??$1_archive.tar.gz /tmp/$1

    echo Creating $1_archive_mbox.tar.gz ....
    tar -czvf $1_archive_mbox.tar.gz $1.mbox
    mv $1_archive_mbox.tar.gz /tmp/$1

    if [ -L /var/lib/mailman/archives/public/$1 ]; then
    	    touch /tmp/$1/$1_archive_is_public
    fi

The second script, on the new server, lives in ~mailman/bin and is run
as the mailman user (which, on my server, has a real, usable shell):

    #!/bin/sh
    if [ "$2" = "" ]; then
    ????????echo 'Usage: untar_list.sh <server> <listname>'
    ????????exit
    fi

    cd ~/tmp/
    echo "Give root password on remote system ..."
    scp root@$1:/tmp/$2/* .
    cd /var/lib/mailman/lists/

    echo ""
    echo "Creating list $2 ..."
    tar -xzvpf ~/tmp/$2_list.tar.gz

    cd /var/lib/mailman/archives/private/

    echo ""
    echo "Creating archive for $2 ..."
    tar --same-owner -xzvpf ~/tmp/$2_archive.tar.gz

    echo "Creating archive mbox for $1 ..."
    tar --same-owner -xzvpf ~/tmp/$2_archive_mbox.tar.gz

    if [ -e ~/tmp/$2_archive_is_public ]; then
    	    ln -s /var/lib/mailman/archives/private/$2 /var/lib/mailman/archives/public/$2
    fi

    echo""
    echo "If no errors, delete files in ~/tmp and delete /tmp/$2 directory on remote system"

This does require (and this may be a show-stopper for some) that the
mailman user on the new system be able to ssh to the old server as
root. I'm sure there's an easy workaround for this, but since I've
always has full root access to my servers and run connections between
servers via encrypted VPNs, it's been simply a matter of modifying the
sshd_config file to allow this.

On Mon, 2016-10-24 at 13:41 +0000, Jewel Brueggeman-Makda wrote:
> Would it be best to copy the entire mailman directory to the new
> server or just the lists and archives???
> Command issued on new server to copy data from old.
> rsync -avr root at serverip:/usr/local/mailman /usr/local/mailman
> 
> -----Original Message-----
> From: Mailman-Users [mailto:mailman-users-bounces+jewel.makda=washbur
> n.edu at python.org] On Behalf Of Mark Sapiro
> Sent: Saturday, September 24, 2016 11:36 AM
> To: mailman-users at python.org
> Subject: Re: [Mailman-Users] Migrating Mailman to New Server (Same
> Domain)
> 
> On 09/23/2016 02:50 PM, Jewel Brueggeman-Makda wrote:
> > 
> > TGIF Mailman Gurus,
> > 
> > My current Mailman 2.1.12 server is lists.washlaw.edu and is
> > running on a RedHat vm.??I need to move it onto a new server which
> > already has a new instance of Mailman 2.1.22 also on a RedHat vm. I
> > already ran the ./configure command to be the same setup as the OLD
> > server.??I have searched the discussion list archives on the steps
> > and am not fully understanding what needs to be done. Below are the
> > steps I do know I need to take but then I am at a loss.
> > 
> > 
> > 1.???????Post Postfix, Apache and Mialman on OLD server and NEW
> > servers
> > 
> > 2.???????Tar up the lists and archives from the mailman directory
> > and copy the tar files to the new server
> > 
> > a.???????tar xvfx /usr/local/mailman/lists
> should be??'tar cpvzf lists.tgz /usr/local/mailman/lists'
> 
> > 
> > b.??????tar xvfz /usr/local/mailman/archives
> should be 'tar cpvzf archives.tgz /usr/local/mailman/archives'
> 
> caveat: do not use the -h/--dereference option because
> archives/public contains only symlinks, and if it winds up with
> actual files, they don't get updated.
> 
> 
> > 
> > 3.???????Untar the lists and archives onto NEW server
> > 
> > a.???????tar -xvf lists.tgz
> > 
> > b.??????tar -xvf archives.tgz
> 
> Or instead of 2 and 3, if the two servers can talk to each other, use
> 'rsync -a'.
> 
> 
> > 
> > c.???????Run from /usr/local/mailman/bin ./check_perms -f
> > 
> > 4.???????Run newaliases
> You don't need to run newaliases, but you do need to run Mailman's
> bin/genaliases.
> 
> Assuming the new server will ultimately be accessed via the old
> servers mail and web domain names, that's all you need.
> 
> If domain names will change, you will need to run fix_url after
> moving the lists. See <https://wiki.list.org/x/4030616>.
> 
> And, for the archives, in order to fix URLs to listinfo pages in the
> archives, the easiest thing is to just move the
> /usr/local/mailman/archives/private/LIST.mbox/LIST.mbox files and
> rebuild the pipermail archives with 'bin/arch --wipe'
> 
-- 
Lindsay Haisley       | "The first casualty when
FMP Computer Services |         war comes is truth."
512-259-1190          |            
http://www.fmp.com    |     -- Hiram W Johnson



From jewel.brueggeman-makda at washburn.edu  Mon Oct 24 13:49:18 2016
From: jewel.brueggeman-makda at washburn.edu (Jewel Brueggeman-Makda)
Date: Mon, 24 Oct 2016 17:49:18 +0000
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <9613d6ce-7f2c-0658-6efc-2f37a2a185ab@msapiro.net>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
 <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
 <9613d6ce-7f2c-0658-6efc-2f37a2a185ab@msapiro.net>
Message-ID: <MWHPR04MB0577133140BCA714B211410FB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>

There are different versions of python, so I will stick to only copying the lists and archives directories.  What about copying the data directory?  I read that this was important too.

-----Original Message-----
From: Mailman-Users [mailto:mailman-users-bounces+jewel.makda=washburn.edu at python.org] On Behalf Of Mark Sapiro
Sent: Monday, October 24, 2016 10:37 AM
To: mailman-users at python.org
Subject: Re: [Mailman-Users] Migrating Mailman to New Server (Same Domain)

On 10/24/2016 06:41 AM, Jewel Brueggeman-Makda wrote:
> Would it be best to copy the entire mailman directory to the new server or just the lists and archives?  
> Command issued on new server to copy data from old.
> rsync -avr root at serverip:/usr/local/mailman /usr/local/mailman


That rsync should work if you want absolutely everything to be the same.
There could be issues if the whole environment is not the same. E.g. if Mailman was configured --with-python=/usr/bin/python2.6 and the only Python on the new server is Python 2.7.

Also, there can be considerations if E.g. the user number for the 'mailman' user is different on the new server, but rsync usually handles that, at least if running as root on both ends.

That's why we suggest building a working Mailman on the new server and just moving lists and archives.

Aside: the 'r' in '-avr' is redundant as it is implied by '-a'.

-- 
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/jewel.makda%40washburn.edu

From fmouse at fmp.com  Mon Oct 24 14:48:07 2016
From: fmouse at fmp.com (Lindsay Haisley)
Date: Mon, 24 Oct 2016 13:48:07 -0500
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <MWHPR04MB0577133140BCA714B211410FB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
 <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
 <9613d6ce-7f2c-0658-6efc-2f37a2a185ab@msapiro.net>
 <MWHPR04MB0577133140BCA714B211410FB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
Message-ID: <1477334887.54228.209.camel@fmp.com>

On Mon, 2016-10-24 at 17:49 +0000, Jewel Brueggeman-Makda wrote:
> There are different versions of python, so I will stick to only
> copying the lists and archives directories.? What about copying the
> data directory?? I read that this was important too.

The "list" and its per-list data are all contained, in modern
installations of Mailman, in the files in /var/lib/mailman/lists. The
files in /var/lib/mailman/data are per-site config. If you set up a
working copy of Mailman to which to migrate your lists then this
directory will already be properly populated.

So what you need to migrate, for each list, are these these two
directories:

/var/lib/mailman/lists/<listname>
/var/lib/mailman/archive/private/<listname>

If your list archives are to be public, you'll need to make a symbolic
link for each list in /var/lib/mailman/archive/public to the list
archive directory in /var/lib/mailman/archive/private

If you don't want your archives to be public, don't make this symbolic
link.

-- 
Lindsay Haisley       | "The first casualty when
FMP Computer Services |         war comes is truth."
512-259-1190          |            
http://www.fmp.com    |     -- Hiram W Johnson



From gerald.niel at gegeweb.eu  Mon Oct 24 14:45:08 2016
From: gerald.niel at gegeweb.eu (=?UTF-8?Q?G=c3=a9rald_Niel?=)
Date: Mon, 24 Oct 2016 20:45:08 +0200
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <MWHPR04MB0577133140BCA714B211410FB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
 <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
 <9613d6ce-7f2c-0658-6efc-2f37a2a185ab@msapiro.net>
 <MWHPR04MB0577133140BCA714B211410FB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
Message-ID: <34712d6e-5965-a523-aa0b-cec70e589ae0@gegeweb.eu>

Hi,

Le 24/10/2016 ? 19:49, Jewel Brueggeman-Makda a ?crit :
> There are different versions of python, so I will stick to only copying the lists and archives directories.

I've recently moved a Mailman to a new server.
I've do that, copy lists, archives and data directory.

<https://wiki.list.org/DOC/How%20do%20I%20move%20a%20list%20to%20a%20different%20server-Mailman%20installation.>

-- 
G?rald Niel
<gerald.niel at gegeweb.eu>

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

From mark at msapiro.net  Mon Oct 24 15:00:43 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 24 Oct 2016 12:00:43 -0700
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <MWHPR04MB0577133140BCA714B211410FB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
 <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
 <9613d6ce-7f2c-0658-6efc-2f37a2a185ab@msapiro.net>
 <MWHPR04MB0577133140BCA714B211410FB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
Message-ID: <b0bf8546-c0d1-57eb-33cc-df1fa688d595@msapiro.net>

On 10/24/2016 10:49 AM, Jewel Brueggeman-Makda wrote:
> There are different versions of python, so I will stick to only copying the lists and archives directories.  What about copying the data directory?  I read that this was important too.

There are various things in data/. Some can be copied and some should
not be.

adm.py and creator.py if any are the encrypted site password and list
creator password respectively. These can be set if needed with
bin/mmsitepass.

aliases* and virtual-mailman* can be copied, but it is better to
regenerate them with bin/genaliases after moving the lists.

bounce-events* if it exists is a queue of current bounces for
BounceRunner and if copied, won't be used.

heldmsg* are held messages. If you are copying the
lists/LISTNAME/request.pck files these should be copied

last_mailman_version should not be copied if the Mailman versions are
different. It should be the version of this Mailman.

master-qrunner.pid is the PID of the currently running Mailman and
should not be copied.

sitelist.cfg is only an example config_list input file to more
appropriately configure the site ('mailman') list. It will be the same
in both places anyway.

The important things are the Postfix aliases and virtual mappings and
it's better to regenerate those with genaliases, and the held messages
which should be copied if there are any.

Bottom line: Copy the heldmsg* files
             Run genaliases
             Run mmsitepass if needed.

-- 
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 Oct 24 15:14:03 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 24 Oct 2016 12:14:03 -0700
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <1477334887.54228.209.camel@fmp.com>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
 <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
 <9613d6ce-7f2c-0658-6efc-2f37a2a185ab@msapiro.net>
 <MWHPR04MB0577133140BCA714B211410FB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
 <1477334887.54228.209.camel@fmp.com>
Message-ID: <e4e1165e-1806-b408-e5f6-c25bc2f8136a@msapiro.net>

On 10/24/2016 11:48 AM, Lindsay Haisley wrote:
> 
> The "list" and its per-list data are all contained, in modern
> installations of Mailman, in the files in /var/lib/mailman/lists. The
> files in /var/lib/mailman/data are per-site config. If you set up a
> working copy of Mailman to which to migrate your lists then this
> directory will already be properly populated.


Not entirely. If there are held messages, they are indexed in the
lists/LISTNAME/request.pck files, but the messages themselves are in
data/heldmsg* files.

If Mailman-Postfix integration is configured, the Postfix aliases and
virtual mappings are in data/aliases* and data/virtual-mailman*, but it
is best to regenerate these with bin/genaliases after moving the lists.

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

From beta at admilon.net  Tue Oct 25 02:54:21 2016
From: beta at admilon.net (Matthias Schmidt)
Date: Tue, 25 Oct 2016 15:54:21 +0900
Subject: [Mailman-Users] Migrating Mailman to New Server (Same Domain)
In-Reply-To: <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
References: <MWHPR04MB05775F051767CCB81727AC7DB1C80@MWHPR04MB0577.namprd04.prod.outlook.com>
 <abc5589a-0be1-7639-b3c6-4c146211ac47@msapiro.net>
 <MWHPR04MB0577331C3F95CD0AC5C008DAB1A90@MWHPR04MB0577.namprd04.prod.outlook.com>
Message-ID: <49C1953C-A524-4331-8915-2CE45AF81101@admilon.net>


> Am 24.10.2016 um 22:41 schrieb Jewel Brueggeman-Makda <jewel.brueggeman-makda at washburn.edu>:
> 
> Would it be best to copy the entire mailman directory to the new server or just the lists and archives?
> Command issued on new server to copy data from old.
> rsync -avr root at serverip:/usr/local/mailman /usr/local/mailman

what worked for me, was copying/syncing all mailman directories to the new volume and run an update on mailman by downloading the last version and recompile it with the same settings of config as before. Then I just checked the settings file. Without that mailman wouldn?t start.
cheers
Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20161025/7c6e1d56/attachment.sig>

From rstasel at uoregon.edu  Tue Oct 25 17:46:25 2016
From: rstasel at uoregon.edu (Ryan C Stasel)
Date: Tue, 25 Oct 2016 21:46:25 +0000
Subject: [Mailman-Users] "Prevent" Reply-all
Message-ID: <58E739AF-988B-4AC2-A112-5381E92A5DE7@uoregon.edu>

Hi everyone, 

I?ve been googling a bit, but the only thing I can find is from back in 2010 (https://mail.python.org/pipermail/mailman-users/2010-May/069388.html) as to if it?s possible to configure a mailman list to ?prevent? reply-all. 

Basically, I support a lot of users that seem to not realize the difference between the two, or they just don?t care if everyone gets inundated with ?thanks? and ?congrats? responses. So I?m curious if there?s any way to make a mailman list not easily accommodate reply-all. I thought reply-to munging would work, but it doesn?t sound like it does. What I want is really what rpschwar wanted back then. 

User A send message to list. List members get the mail, but it ?appears? to be from User A and not from the list. So a Reply and Reply-all both do the same thing. To really reply-all, users would have to physically type in the mail list address into their To or CC fields. 

Is this possible (short of re-educating our users about how ?reply-all? really isn?t appropriate in most cases)?

Thanks! 

-Ryan Stasel

From mark at msapiro.net  Tue Oct 25 18:42:45 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 25 Oct 2016 15:42:45 -0700
Subject: [Mailman-Users] "Prevent" Reply-all
In-Reply-To: <58E739AF-988B-4AC2-A112-5381E92A5DE7@uoregon.edu>
References: <58E739AF-988B-4AC2-A112-5381E92A5DE7@uoregon.edu>
Message-ID: <6dc2b339-662f-b41b-9d14-ee3df0794b9b@msapiro.net>

On 10/25/2016 02:46 PM, Ryan C Stasel wrote:
> 
> What I want is really what rpschwar wanted back then. 
> 
> User A send message to list. List members get the mail, but it ?appears? to be from User A and not from the list. So a Reply and Reply-all both do the same thing. To really reply-all, users would have to physically type in the mail list address into their To or CC fields. 
> 
> Is this possible (short of re-educating our users about how ?reply-all? really isn?t appropriate in most cases)?


There's not much you can do with list configuration.

Mailman ensures the list posting address is always in To: or Cc:, so you
have to modify code (Mailman/Handlers/CookHeaders.py) to keep it out.
You also may need to set the list's Non-digest options -> personalize to
Full Personalization so the list address is not in To:.

Perhaps a better way to do all of this is to set the list's Non-digest
options -> personalize to Full Personalization and create a custom
handler (see <https://wiki.list.org/x/4030615>) to go in the pipeline
after CookHeaders and to just remove any Cc: from the message. Then the
From: will be the poster, To: will be the individual recipient and there
will be no Cc:.

However, with any method like this, you will run afoul of DMARC if the
domain of From: publishes a DMARC p=reject or p=quarantine policy. You
really can't avoid DMARC issues without changing the From: domain.
Standard DMARC mitigations will probably work by putting the original
From: in Reply-To:, but then you have the issue of the munged From:
containing the list address and you'd need to change that, but to what
could you change it that isn't the original From:, isn't the list
address, won't bounce and won't inundate someone with unwanted mail,
Maybe the list-owner address?

Another way to do something, but not exactly what you ask is to set
Privacy options... -> Recipient filters -> max_num_recipients to 2 and
require_explicit_destination to Yes.

This will ensure that any post which addresses more than just the list,
which all reply-alls will, will be held for moderation.

For more control, you can use header_filter_rules to hold or reject
posts with more that one address in To: (a regexp like '^To:.*?@.*?@.*$'
might do although it will falsely catch a display name with an @), or
any Cc:

-- 
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  Tue Oct 25 19:55:45 2016
From: rstasel at uoregon.edu (Ryan C Stasel)
Date: Tue, 25 Oct 2016 23:55:45 +0000
Subject: [Mailman-Users] "Prevent" Reply-all
In-Reply-To: <6dc2b339-662f-b41b-9d14-ee3df0794b9b@msapiro.net>
References: <58E739AF-988B-4AC2-A112-5381E92A5DE7@uoregon.edu>
 <6dc2b339-662f-b41b-9d14-ee3df0794b9b@msapiro.net>
Message-ID: <4D360FD5-1764-4FF2-ADCB-6C6A48239BC0@uoregon.edu>


> On Oct 25, 2016, at 15:42 , Mark Sapiro <mark at msapiro.net> wrote:
> 
> On 10/25/2016 02:46 PM, Ryan C Stasel wrote:
>> 
> There's not much you can do with list configuration.
> 
> Mailman ensures the list posting address is always in To: or Cc:, so you
> have to modify code (Mailman/Handlers/CookHeaders.py) to keep it out.
> You also may need to set the list's Non-digest options -> personalize to
> Full Personalization so the list address is not in To:.
> 
> Perhaps a better way to do all of this is to set the list's Non-digest
> options -> personalize to Full Personalization and create a custom
> handler (see <https://wiki.list.org/x/4030615>) to go in the pipeline
> after CookHeaders and to just remove any Cc: from the message. Then the
> From: will be the poster, To: will be the individual recipient and there
> will be no Cc:.
> 
> However, with any method like this, you will run afoul of DMARC if the
> domain of From: publishes a DMARC p=reject or p=quarantine policy. You
> really can't avoid DMARC issues without changing the From: domain.
> Standard DMARC mitigations will probably work by putting the original
> From: in Reply-To:, but then you have the issue of the munged From:
> containing the list address and you'd need to change that, but to what
> could you change it that isn't the original From:, isn't the list
> address, won't bounce and won't inundate someone with unwanted mail,
> Maybe the list-owner address?
> 
> Another way to do something, but not exactly what you ask is to set
> Privacy options... -> Recipient filters -> max_num_recipients to 2 and
> require_explicit_destination to Yes.
> 
> This will ensure that any post which addresses more than just the list,
> which all reply-alls will, will be held for moderation.
> 
> For more control, you can use header_filter_rules to hold or reject
> posts with more that one address in To: (a regexp like '^To:.*?@.*?@.*$'
> might do although it will falsely catch a display name with an @), or
> any Cc:

Hmm, darn. I might play with the max recipients thing, but I think the end result of that will be similar to just making the list moderation only. 

Thanks Mark! 

-Ryan Stasel


From bernd at petrovitsch.priv.at  Tue Oct 25 19:11:12 2016
From: bernd at petrovitsch.priv.at (Bernd Petrovitsch)
Date: Wed, 26 Oct 2016 01:11:12 +0200
Subject: [Mailman-Users] "Prevent" Reply-all
In-Reply-To: <58E739AF-988B-4AC2-A112-5381E92A5DE7@uoregon.edu>
References: <58E739AF-988B-4AC2-A112-5381E92A5DE7@uoregon.edu>
Message-ID: <1477437072.22540.16.camel@petrovitsch.priv.at>

Hi!

On Tue, 2016-10-25 at 21:46 +0000, Ryan C Stasel wrote:
[...]
> User A send message to list. List members get the mail, but it
> ?appears? to be from User A and not from the list. So a Reply and 

And the mail actually *was* from user A - it was just replicated and
distributed to many others via the mailinglist (software).

> Reply-all both do the same thing. To really reply-all, users would
> have to physically type in the mail list address into their To or CC
> fields.?

The "reply-all" button in - TTBOMK - all MUAs does this and the "List-
Reply" button in the better ones does this too: grab the appropriate
addresses from the headers and use them for the reply. That's actually
the definition of them IMHO.

Do you use "Reply-To-Munging"? If yes, you actually want to *not* *do*
reply-to-munging so the (simple) "reply" button goes just to the
address in the From: header.

Personally: And *if* people press "reply-to-all", they may actually
want it and what software can decide based on which criteria that they
actually do not want it?

> Is this possible (short of re-educating our users about how ?reply-
> all? really isn?t appropriate in most cases)?

No - Email and mailing lists are just tools (just like a hammer) and if
people use them wrong, it's not the job of the hammer to decide if he
should hit or not hit the nail - even if the hammer could decide that a
finger is in between.

Since on one (else) complains via the mailinglist (otherwise you would
have mentioned it IMHO) that "thank you" mails should be private, it
probably bothers no one really.

It's IMHO also a thing for the mailinglist charta, if "thank you" mails
(and similar) are actually wanted/encouraged or "only private,
otherwise it bandwidth and archive space waste".

And some people may actually think that saying "thank you" in public is
actually a good thing - even if it's only just the education;-)

Kind regards,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at

From camelia.botez at weizmann.ac.il  Thu Oct 27 07:23:37 2016
From: camelia.botez at weizmann.ac.il (Camelia Botez)
Date: Thu, 27 Oct 2016 11:23:37 +0000
Subject: [Mailman-Users] cannot subscribe from outside using web interface
Message-ID: <74B33B2DD6D2A148967C7ECBEBF842CF0113476A1E@IBWMBX02>

Our mailman server is on DMZ and a couple of month ago was changed to work https.
>From inside LAN we can access mailman.domain/mailman/listinfo/test and subscribe using browser interface.
>From outside LAN we get :
The site cannot be reached    mailman.org refused to connect.

Any idea ?


Thank you for help

From beta at admilon.net  Thu Oct 27 08:22:21 2016
From: beta at admilon.net (Matthias Schmidt)
Date: Thu, 27 Oct 2016 21:22:21 +0900
Subject: [Mailman-Users] cannot subscribe from outside using web
 interface
In-Reply-To: <74B33B2DD6D2A148967C7ECBEBF842CF0113476A1E@IBWMBX02>
References: <74B33B2DD6D2A148967C7ECBEBF842CF0113476A1E@IBWMBX02>
Message-ID: <B57CBC5B-AD0F-4BB2-82B1-D6348A59E2FB@admilon.net>


> Am 27.10.2016 um 20:23 schrieb Camelia Botez <camelia.botez at weizmann.ac.il>:
> 
> Our mailman server is on DMZ and a couple of month ago was changed to work https.
> From inside LAN we can access mailman.domain/mailman/listinfo/test and subscribe using browser interface.
> From outside LAN we get :
> The site cannot be reached    mailman.org refused to connect.
> 
> Any idea ?
> 

dns
firewall
else check the logs ;-)
Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20161027/a809c3b5/attachment.sig>

From turnbull.stephen.fw at u.tsukuba.ac.jp  Thu Oct 27 10:03:51 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Thu, 27 Oct 2016 23:03:51 +0900
Subject: [Mailman-Users] cannot subscribe from outside using web interface
In-Reply-To: <74B33B2DD6D2A148967C7ECBEBF842CF0113476A1E@IBWMBX02>
References: <74B33B2DD6D2A148967C7ECBEBF842CF0113476A1E@IBWMBX02>
Message-ID: <22546.2375.476540.926896@turnbull.sk.tsukuba.ac.jp>

Camelia Botez writes:

 > Our mailman server is on DMZ and a couple of month ago was changed
 > to work https.
 > From inside LAN we can access mailman.domain/mailman/listinfo/test
 > and subscribe using browser interface.
 > From outside LAN we get :
 > The site cannot be reached    mailman.org refused to connect.
 > 
 > Any idea ?

If you're able to access via HTTPS from inside, but can't even connect
from outside, it's probably a firewall issue, and not something we can
help with.

1.  Are there any other HTTPS resources on that server that you can test?
    If you can access other resources but not to Mailman, perhaps your
    frontend webserver (Apache?) is not configured the same for HTTPS
    as it was for HTTP.
2.  Use tcptraceroute from outside to port 443 on the Mailman host to
    find out where the connection is broken.  The "<host> refused to
    connect" is often misleading -- in many cases the attempted
    connection never reaches <host>, but the error message says
    "refused".
3.  Double-check your firewall configuration, and also the network
    filter configuration of the Mailman host.

HTH

Steve

From james at dorydesign.com  Thu Oct 27 11:24:31 2016
From: james at dorydesign.com (Jim Dory)
Date: Thu, 27 Oct 2016 07:24:31 -0800
Subject: [Mailman-Users] getting lots of approval requests for spammers
Message-ID: <CAKhfoy2+nZyPXLZTqTQe6Uuy_ycuuS9+nRb_q_3R3EJgqEYa6A@mail.gmail.com>

I'm getting a ton of spam posting attempts to our subscriber only email
list - in the order of about 100 to 150 per day and growing. As I need to
keep a look out for actual member requests (sometimes a member wants to
unsubscribe or is having some problem - a non member wants to subscribe) I
have to look through these approval headers to make sure it isn't a local
person wanting something. So it becomes a pain. Most spammers use obvious
emails so I can mass delete them (harder on my phone when managing the
mail) but I'm wondering if there is something I can do to stem the flow.

I'm with Hawkhost on a VPS plan (virtual private server) so I have a bit of
control - but don't know much about what to do - if there are access/deny
lists I can somehow use. I did enable some spam controls but it didn't seem
to do anything. It would have to a server level deny list I assume like
iptables or something to reject known spammers at least, or whole domains
like from foreign companies (.it, .br, .ch , etc) and perhaps some spoofing
going on from the likes of domains such as hilton.k12.ny.us
<cortez_josephine at hilton.k12.ny.us>.

thx, Jim

From akgul at bilkent.edu.tr  Thu Oct 27 13:17:44 2016
From: akgul at bilkent.edu.tr (Mustafa Akgul)
Date: Thu, 27 Oct 2016 20:17:44 +0300 (EEST)
Subject: [Mailman-Users] mailman stopped archiving
Message-ID: <20161027171744.B943F2C563E6@sakarya.akgul.bilkent.edu.tr>


Hello,
I have debain 7.11  , mailman  2.1.5-1 i386
I have a few lists. All  stopped archiving.
LISTNAME.mbox is not updateing
I have run chech_perms -f as root. /usr/lib/mailman  permissions are OK, and 
permissions of non-links  ar OK.

I have also  added w permission to all for directories.
Nothing happend.

Any suggestions ?

Best regards

Mustafa Akgul


From james at dorydesign.com  Thu Oct 27 13:42:28 2016
From: james at dorydesign.com (Jim Dory)
Date: Thu, 27 Oct 2016 09:42:28 -0800
Subject: [Mailman-Users] Outlook blocking all email - "email harvesting"
Message-ID: <CAKhfoy2Qw=1HEaqP4Tb0zJ4oobdv2D=kvGfO-jE8m1xqC528JQ@mail.gmail.com>

I've got a plan with Hawkhost on a VPS server for our community, subscriber
only, trade and announcements email list.

Outlook has completely blocked us so I've recently gotten messages from
mailman bounces that about 400 of our subscribers (all the hotmail, live,
outlook, etc. users) have been disabled.

I have signed up with the SNDS program and it reports that email is blocked
because we are "email harvesting". (I am working with Hawkhost on a trouble
ticket). I've tried to sign up with the JMRP program as well but when I
click the link I get sent back to the SNDS page and cannot figure out how
to get out of that loop to get actual user feedback complaint reports, if
any. But that is a different issue.

I am hoping you folks can shed some light on what to look for.

Here is the report after sending info to
https://support.live.com/eform.aspx?productKey=edfsmsbl3&ct=eformts&wa=wsignin1.0
:

Dear James Dory

We have completed reviewing the IP(s) you submitted. The following table
contains the results of our investigation.

More information needed
198.252.110.38
There are indications that the above IP(s) are engaged in namespace mining.
Outlook.com is blocking all email sent from this IP.

Namespace mining is a method commonly used by malicious senders to generate
lists of email addresses. This approach uses automation to sift through
possible email names seeking to identify valid email addresses, e.g.,
Joe at domain.com, John at domain.com, and Josy at domain.com.

You must correct the problem and you must stop the behavior described
above. We recommend that you work with your email or network administrator
to review the logs of your email servers. Check the sending log files and
concentrate on logs that are sending to nonexistent @hotmail.com, @live.com,
@msn.com, @outlook.com?with <http://outlook.com/?with> multiple tries and
failures.

From mark at msapiro.net  Thu Oct 27 15:09:40 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 27 Oct 2016 12:09:40 -0700
Subject: [Mailman-Users] mailman stopped archiving
In-Reply-To: <20161027171744.B943F2C563E6@sakarya.akgul.bilkent.edu.tr>
References: <20161027171744.B943F2C563E6@sakarya.akgul.bilkent.edu.tr>
Message-ID: <f9c1a756-9adf-cfb7-f583-3da62b9b8760@msapiro.net>

On 10/27/2016 10:17 AM, Mustafa Akgul wrote:
> 
> Hello,
> I have debain 7.11  , mailman  2.1.5-1 i386
> I have a few lists. All  stopped archiving.
> LISTNAME.mbox is not updateing
> I have run chech_perms -f as root. /usr/lib/mailman  permissions are OK, and 
> permissions of non-links  ar OK.


What's in Mailman's error log. Are the messages shunted?

Is ArchRunner running? (whats in Mailman's qrunner log?)

What's in Mailman's qfiles/archive? qfiles/shunt?

-- 
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 Oct 27 21:07:14 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 27 Oct 2016 18:07:14 -0700
Subject: [Mailman-Users] getting lots of approval requests for spammers
In-Reply-To: <CAKhfoy2+nZyPXLZTqTQe6Uuy_ycuuS9+nRb_q_3R3EJgqEYa6A@mail.gmail.com>
References: <CAKhfoy2+nZyPXLZTqTQe6Uuy_ycuuS9+nRb_q_3R3EJgqEYa6A@mail.gmail.com>
Message-ID: <81b133f9-cf98-dc11-e6c9-ea20a44706a0@msapiro.net>

On 10/27/2016 08:24 AM, Jim Dory wrote:
> I'm getting a ton of spam posting attempts to our subscriber only email
> list - in the order of about 100 to 150 per day and growing. As I need to
> keep a look out for actual member requests (sometimes a member wants to
> unsubscribe or is having some problem - a non member wants to subscribe) I
> have to look through these approval headers to make sure it isn't a local
> person wanting something. So it becomes a pain. Most spammers use obvious
> emails so I can mass delete them (harder on my phone when managing the
> mail) but I'm wondering if there is something I can do to stem the flow.
> 
> I'm with Hawkhost on a VPS plan (virtual private server) so I have a bit of
> control - but don't know much about what to do - if there are access/deny
> lists I can somehow use.


At a minimum you should have SpamAssassin and ClamAV scanning your mail
during incoming mail processing before it ever gets to Mailman.
Greylisting can also help. See
<http://wiki.apache.org/spamassassin/IntegratedInMta> for Spamassassin
and for ClamAV see <http://www.clamav.net/documentation> and google
clamav-milter.

Also see <http://sanesecurity.com/usage/signatures> for info about 3rd
party ClamAV signatures for detecting spam.

For a more comprensive package, see <https://www.mailscanner.info/>.


> I did enable some spam controls but it didn't seem
> to do anything. It would have to a server level deny list I assume like
> iptables or something to reject known spammers at least, or whole domains
> like from foreign companies (.it, .br, .ch , etc) and perhaps some spoofing
> going on from the likes of domains such as hilton.k12.ny.us
> <cortez_josephine at hilton.k12.ny.us>.


You can do things in the MTA itself. For example Postfix can do header
checks and body checks and take various actions based on regexp matches.
See <http://www.postfix.org/header_checks.5.html>.

There are many other tools and techniques beyond the scope of this list.

Within Mailman itself, you can use Privacy options... -> Spam filters ->
header_filter_rules to take various actions based of regexp matcthes on
the message headers, and there's also the possibility to use regexps in
Privacy options... -> Sender filters -> discard_these_nonmembers.

The caveat here is you want to discard and not reject because reject
causes backscatter to the generally innocent spoofed sender. This means
with header_filter_rules in particular you need to avoid false positives
to avoid silently discarding legitimate mail.

Avoiding backscatter is the main reason why the best solutions reject
the mail at incoming SMTP time.

Note that you can't use iptables because a great deal of spam comes from
botnets and the IPs are all over and not consistent.

-- 
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 Oct 27 21:28:56 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 27 Oct 2016 18:28:56 -0700
Subject: [Mailman-Users] Outlook blocking all email - "email harvesting"
In-Reply-To: <CAKhfoy2Qw=1HEaqP4Tb0zJ4oobdv2D=kvGfO-jE8m1xqC528JQ@mail.gmail.com>
References: <CAKhfoy2Qw=1HEaqP4Tb0zJ4oobdv2D=kvGfO-jE8m1xqC528JQ@mail.gmail.com>
Message-ID: <27a73a46-50bb-0a82-95cf-8e12d1c34aaf@msapiro.net>

On 10/27/2016 10:42 AM, Jim Dory wrote:
> 
> I am hoping you folks can shed some light on what to look for.
> 
> Here is the report after sending info to
> https://support.live.com/eform.aspx?productKey=edfsmsbl3&ct=eformts&wa=wsignin1.0
> :
...


I'm not sure what you're asking. Microsoft is blocking your IP for
stated reasons. These reasons may or may not be valid, but this has to
be addressed with Microsoft in any case. In my experience (none too
recent) this is a difficult, tedious process and is sometimes futile.

Out FAQ article at <https://wiki.list.org/x/4030690> has a link to
<https://mail.live.com/mail/troubleshooting.aspx>. This has some good
info. Unfortunately, the link to set up a JMRP[1] account seems broken,
but buried in the "Sender services, tools, and issue submission:"
section is a link to contact support which seems to work.

Here again, my experience contacting support is it takes multiple back
and forth messages (all of theirs seem like they could be generated by
robots or at least copy/paste from canned replies) and you never get a
real answer, but eventually the block gets removed.

[1] I don't think JMRP will help anyway. JMRP has to to with complaints,
i.e. recipients clicking spam or junk buttons, and the reason they give
for blocking you seems more to do with the patterns of addresses you are
trying to deliver to. Also, it's possible that they are blocking a
larger netblock and your (innocent) IP just happens to fall in that range.

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

From akgul at bilkent.edu.tr  Sun Oct 30 08:04:14 2016
From: akgul at bilkent.edu.tr (Mustafa Akgul)
Date: Sun, 30 Oct 2016 14:04:14 +0200 (EET)
Subject: [Mailman-Users] mailman stopped  archiving
Message-ID: <20161030120414.CC2F12C5642D@sakarya.akgul.bilkent.edu.tr>

>On 10/27/2016 10:17 AM, Mustafa Akgul wrote:
>> 
>> Hello,
>> I have debain 7.11  , mailman  2.1.5-1 i386
>> I have a few lists. All  stopped archiving.
>> LISTNAME.mbox is not updateing
>> I have run chech_perms -f as root. /usr/lib/mailman  permissions are OK, and 
>> permissions of non-links  ar OK.
>
>
>What's in Mailman's error log. Are the messages shunted?
>
>Is ArchRunner running? (whats in Mailman's qrunner log?)
>
>What's in Mailman's qfiles/archive? qfiles/shunt?
>
>-- 
>Mark Sapiro <m... at msapiro.net>        The highway is for gamblers,
>San Francisco Bay Area, California    better use your sense - B. Dylan
there is nothing im Mailman error lohg.  same ith qrunner.

ArchRunning is not running.  under qfiles there is nothing in all directories except an entry in 2014 in virgin directory?
I do not run anything in cron regarding mailman.

Any suggestions?

Regards
Mustafa Akgul




From wouter at cityhydroponics.hk  Sun Oct 30 03:01:58 2016
From: wouter at cityhydroponics.hk (Wouter van Marle)
Date: Sun, 30 Oct 2016 15:01:58 +0800
Subject: [Mailman-Users] Moderation not working
Message-ID: <20161030150158.3675c1f1@wouter-desktop>

Hi all,

I have a few mails for my list awaiting moderation.

When I try to moderate them (in my case, they have to be removed, this
were all test mails not intended for posting) it just doesn't work. 

In the web interface, I open the list, go to "Tend to pending moderator requests", and set the messages to either "Reject" or "Discard", then click the "Submit All Data" button.

A pop-up appears, security warning: 
"The information you have entered on this page will be sent over an insecure connection and could be read by a third party.

Are you sure you want to send this information?"

I click Continue, and get back the same page with all the to-be-moderated messages untouched. Nothing happens.

Any ideas?

Wouter.

From mark at msapiro.net  Sun Oct 30 10:47:13 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 30 Oct 2016 07:47:13 -0700
Subject: [Mailman-Users] Moderation not working
In-Reply-To: <20161030150158.3675c1f1@wouter-desktop>
References: <20161030150158.3675c1f1@wouter-desktop>
Message-ID: <bfd23743-9955-ebf3-ff48-10064dac4464@msapiro.net>

On 10/30/2016 12:01 AM, Wouter van Marle wrote:
> 
> In the web interface, I open the list, go to "Tend to pending moderator requests", and set the messages to either "Reject" or "Discard", then click the "Submit All Data" button.
> 
> A pop-up appears, security warning: 
> "The information you have entered on this page will be sent over an insecure connection and could be read by a third party.
> 
> Are you sure you want to send this information?"
> 
> I click Continue, and get back the same page with all the to-be-moderated messages untouched. Nothing happens.


You are accessing the admindb pages via https, but the form action URLs
on the pages are http. Your server redirects the http URL to https and
the redirect loses the POST data.

This is discussed at <https://wiki.list.org/x/4030602> and
<https://wiki.list.org/x/4030702>. You need to do steps 2. and 3. at
<https://wiki.list.org/x/4030702>. If you are not an admin of the
Mailman installation, then tell the admins they need to do this.

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

From mark at msapiro.net  Sun Oct 30 10:57:08 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 30 Oct 2016 07:57:08 -0700
Subject: [Mailman-Users] mailman stopped archiving
In-Reply-To: <20161030120414.CC2F12C5642D@sakarya.akgul.bilkent.edu.tr>
References: <20161030120414.CC2F12C5642D@sakarya.akgul.bilkent.edu.tr>
Message-ID: <d7bd900f-68c4-9bc5-c5a9-84f57e7ca34b@msapiro.net>

On 10/30/2016 05:04 AM, Mustafa Akgul wrote:

> there is nothing im Mailman error lohg.  same ith qrunner.


If there is truly nothing in Mailman's qrunner log, either you are not
looking at the right logs or the logs have been rotated and the relevant
information is in an older log or gone.


> ArchRunning is not running.


That is the problem, but the question is why?


> under qfiles there is nothing in all directories except an entry in 2014 in virgin directory?


If messages are being posted and delivered and ArchRunner is not
running, there must be entries in Malman's archive queue. If you don't
see them, you are not looking at the right queues.


> I do not run anything in cron regarding mailman.


There are several Mailman crons that should be run for other reasons,
but that's not the issue here.

Restarting Mailman may help, but until we know why ArchRunner isn't
running and fix it, the issue may just recur.

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

From wouter at cityhydroponics.hk  Sun Oct 30 11:38:19 2016
From: wouter at cityhydroponics.hk (Wouter van Marle)
Date: Sun, 30 Oct 2016 23:38:19 +0800
Subject: [Mailman-Users] Moderation not working
In-Reply-To: <bfd23743-9955-ebf3-ff48-10064dac4464@msapiro.net>
References: <20161030150158.3675c1f1@wouter-desktop>
 <bfd23743-9955-ebf3-ff48-10064dac4464@msapiro.net>
Message-ID: <20161030233819.7fc6c21c@wouter-desktop>



On Sun, 30 Oct 2016 07:47:13 -0700
Mark Sapiro <mark at msapiro.net> wrote:

> On 10/30/2016 12:01 AM, Wouter van Marle wrote:
> > 
> > In the web interface, I open the list, go to "Tend to pending
> > moderator requests", and set the messages to either "Reject" or
> > "Discard", then click the "Submit All Data" button.
> > 
> > A pop-up appears, security warning: 
> > "The information you have entered on this page will be sent over an
> > insecure connection and could be read by a third party.
> > 
> > Are you sure you want to send this information?"
> > 
> > I click Continue, and get back the same page with all the
> > to-be-moderated messages untouched. Nothing happens.
> 
> 
> You are accessing the admindb pages via https, but the form action
> URLs on the pages are http. Your server redirects the http URL to
> https and the redirect loses the POST data.
> 
> This is discussed at <https://wiki.list.org/x/4030602> and
> <https://wiki.list.org/x/4030702>. You need to do steps 2. and 3. at
> <https://wiki.list.org/x/4030702>. If you are not an admin of the
> Mailman installation, then tell the admins they need to do this.
> 

That did the trick, thanks!
I installed MailMan on an existing https site, didn't realise there's an issue with it.

Wouter.

From rex at rexgoode.com  Sun Oct 30 12:50:50 2016
From: rex at rexgoode.com (rex at rexgoode.com)
Date: Sun, 30 Oct 2016 09:50:50 -0700
Subject: [Mailman-Users] Reply Bodies as Attachments
Message-ID: <b2d9649cdc1b16b90e2860b51cdb2fb1@rexgoode.com>

I'm having the same problem on all of my lists, which most people read 
on their Android or IOS devices.

When I send something out, if anyone replies, it is delivered with my 
defined header and footer, but the body is an attachment which can't be 
read. It says, "No Application Available for This Content".

I've looked through all of the settings and can't find anything related 
to it or that affects it.

Rex Goode

From turnbull.stephen.fw at u.tsukuba.ac.jp  Sun Oct 30 15:02:47 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Mon, 31 Oct 2016 04:02:47 +0900
Subject: [Mailman-Users]  Reply Bodies as Attachments
In-Reply-To: <b2d9649cdc1b16b90e2860b51cdb2fb1@rexgoode.com>
References: <b2d9649cdc1b16b90e2860b51cdb2fb1@rexgoode.com>
Message-ID: <22550.17367.468773.255281@turnbull.sk.tsukuba.ac.jp>

rex at rexgoode.com writes:
 > I'm having the same problem on all of my lists, which most people read 
 > on their Android or IOS devices.
 > 
 > When I send something out, if anyone replies, it is delivered with my 
 > defined header and footer, but the body is an attachment which can't be 
 > read. It says, "No Application Available for This Content".
 > 
 > I've looked through all of the settings and can't find anything related 
 > to it or that affects it.

The problem is almost surely that headers and footers added by Mailman
using MIME conventions are more or less incompatible with HTML mail.
Competent MUAs deal with this fine[1], but unfortunately competent
MUAs are mostly found on Unix systems, not on the popular OSes or
handheld devices.

There are workarounds for this that rewrite the HTML instead of using
MIME, but we are unwilling to support them because rewriting HTML
reliably across all of the variations put out by different MUAs
requires a huge amount of effort, and won't be successful in the end
because new variations arise daily -- it's whack-a-mole with no prizes.

There are three workarounds that usually help (you only need one).
Which is best depends on your users' preferences and list practices.
(1) Don't allow HTML mail.
(2) Have Mailman convert it to text.
(3) Don't add headers or footer at all.  This means you have to delete
    everything, including whitespace, from those text boxes in the
    admin interface.

Footnotes: 
[1]  The algorithm is easy to describe and shouldn't be hard to
implement: print the plain text header using default formatting in a
frame, print the mail itself in another frame, and then the footer in
a third frame, stacking the frames vertically.  This might be a
strategy that would work in general, but last I checked you couldn't
count on MUAs to support frames, so....


From mark at msapiro.net  Sun Oct 30 15:21:36 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 30 Oct 2016 12:21:36 -0700
Subject: [Mailman-Users] Reply Bodies as Attachments
In-Reply-To: <b2d9649cdc1b16b90e2860b51cdb2fb1@rexgoode.com>
References: <b2d9649cdc1b16b90e2860b51cdb2fb1@rexgoode.com>
Message-ID: <c70b744f-38fa-7cce-a8d5-c7fcf07bf288@msapiro.net>

On 10/30/2016 09:50 AM, rex at rexgoode.com wrote:
> I'm having the same problem on all of my lists, which most people read
> on their Android or IOS devices.


Mobile MUAs are often limited in rendering anything but the simplest
MIME structured messages.


> When I send something out, if anyone replies, it is delivered with my
> defined header and footer, but the body is an attachment which can't be
> read. It says, "No Application Available for This Content".


See <https://wiki.list.org/x/4030707>.

The issue is the message delivered from Mailman is structured like this:

multipart/mixed
    text/plain
        (msg_header)
    message/rfc822
        (the original message with it's own MIME structure)
    text/plain
        (msg_footer)

and the mobile MUAs are saying they don't know how to render a
message/rfc822 part. Actually, the appropriate application is the MUA
itself and it may be possible for users to configure their devices so
the MUA knows that. It should be shocking that the MUAs don't get that,
but by now I expect it.

Aside: For Android I recommend K9 Mail by K9 Dog Walkers available from
the Play Store or on GitHub at <https://github.com/k9mail/k-9>.

The above referenced article suggests solutions. If you don't need HTML
or non-text attachments on your list, I suggest the following content
filtering settings:

filter_content: Yes
pass_mime_types:
    multipart
    message/rfc822
    text/plain
    text/html
collapse_alternatives: Yes
convert_html_to_plaintext: Yes

which will ensure your messages are plain text only and allow adding
msg_header and msg_footer to the body and not as separate MIME parts.	

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

From dap1 at bellsouth.net  Mon Oct 31 08:43:23 2016
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Mon, 31 Oct 2016 08:43:23 -0400
Subject: [Mailman-Users] Mailman qrunner: [abrt] full crash report
In-Reply-To: <5816a7d1.PVWH6nlhqILKwozk%user@localhost>
References: <5816a7d1.PVWH6nlhqILKwozk%user@localhost>
Message-ID: <22d5e422-0e17-e4bc-6179-8c4f41370853@bellsouth.net>

I have been getting these crash reports occasionally. Does this look
like a mailman problem or is mailman falling victim to some OS (Centos
7) or other issue? TIA.


	

	

	

	

time: Thu 20 Oct 2016 06:43:20 AM EDT

cmdline:        /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
uid:            41 (mailman)
abrt_version:   2.1.11
event_log:      
executable:     /usr/bin/python2.7
global_pid:     3842
hostname:       dap002
kernel:         3.10.0-327.36.2.el7.x86_64
last_occurrence: 1477879758
pid:            3842
pkg_arch:       x86_64
pkg_epoch:      3
pkg_name:       mailman
pkg_release:    21.el7_1
pkg_version:    2.1.15
pwd:            /usr/lib/mailman
runlevel:       N 3
username:       mailman

cgroup:
:10:perf_event:/
:9:cpuset:/
:8:freezer:/
:7:blkio:/
:6:devices:/
:5:cpuacct,cpu:/
:4:memory:/
:3:hugetlb:/
:2:net_cls:/
:1:name=systemd:/system.slice/mailman.service

core_backtrace:
:{   "signal": 6
:,   "executable": "/usr/bin/python2.7"
:,   "stacktrace":
:      [ {   "crash_thread": true
:        ,   "frames":
:              [ {   "address": 140714112447991
:                ,   "build_id": "53c0918c85fa9cc08d2b57e76467631ab07554ae"
:                ,   "build_id_offset": 218615
:                ,   "function_name": "raise"
:                ,   "file_name": "/lib64/libc.so.6"
:                }
:              , {   "address": 140714112453864
:                ,   "build_id": "53c0918c85fa9cc08d2b57e76467631ab07554ae"
:                ,   "build_id_offset": 224488
:                ,   "function_name": "abort"
:                ,   "file_name": "/lib64/libc.so.6"
:                }
:              , {   "address": 140714126793150
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 1034686
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126210812
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 452348
:                ,   "function_name": "PyFrame_New"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126678028
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 919564
:                ,   "function_name": "PyEval_EvalFrameEx"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126678112
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 919648
:                ,   "function_name": "PyEval_EvalFrameEx"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126678112
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 919648
:                ,   "function_name": "PyEval_EvalFrameEx"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126684349
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 925885
:                ,   "function_name": "PyEval_EvalCodeEx"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126684610
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 926146
:                ,   "function_name": "PyEval_EvalCode"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126788095
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 1029631
:                ,   "function_name": "run_mod"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126792638
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 1034174
:                ,   "function_name": "PyRun_FileExFlags"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126797385
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 1038921
:                ,   "function_name": "PyRun_SimpleFileExFlags"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                }
:              , {   "address": 140714126867359
:                ,   "build_id": "e0629f287ee1197290386973b9c5bd0576c35ee4"
:                ,   "build_id_offset": 1108895
:                ,   "function_name": "Py_Main"
:                ,   "file_name": "/lib64/libpython2.7.so.1.0"
:                } ]
:        } ]
:}

dso_list:
:/usr/lib64/python2.7/lib-dynload/itertoolsmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/stropmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/_socketmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libc-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103
:/usr/lib64/libssl.so.1.0.1e openssl-libs-1:1.0.1e-51.el7_2.7.x86_64 (CentOS) 1475934561
:/usr/lib64/python2.7/lib-dynload/operator.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/_multibytecodecmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/grpmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libpcre.so.1.2.0 pcre-8.32-15.el7_2.1.x86_64 (CentOS) 1464083272
:/usr/lib64/python2.7/lib-dynload/_collectionsmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/arraymodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/cStringIO.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/math.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/unicodedata.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/_io.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libresolv-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103
:/usr/lib64/libutil-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103
:/usr/lib64/libkrb5.so.3.3 krb5-libs-1.13.2-12.el7_2.x86_64 (CentOS) 1459808218
:/usr/lib64/libnss_files-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103
:/usr/lib64/libz.so.1.2.7 zlib-1.2.7-15.el7.x86_64 (CentOS) 1451751366
:/usr/lib64/ld-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103
:/usr/lib64/python2.7/lib-dynload/_randommodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libdl-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103
:/usr/lib64/python2.7/lib-dynload/_heapq.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libgssapi_krb5.so.2.2 krb5-libs-1.13.2-12.el7_2.x86_64 (CentOS) 1459808218
:/usr/lib64/python2.7/lib-dynload/_struct.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/bin/python2.7 python-2.7.5-39.el7_2.x86_64 (CentOS) 1474297163
:/usr/lib64/libfreebl3.so nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 (CentOS) 1462192388
:/usr/lib64/python2.7/lib-dynload/binascii.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/_ssl.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/selectmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libfreeblpriv3.so nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 (CentOS) 1462192388
:/usr/lib64/python2.7/lib-dynload/_localemodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libkrb5support.so.0.1 krb5-libs-1.13.2-12.el7_2.x86_64 (CentOS) 1459808218
:/usr/lib64/python2.7/lib-dynload/_codecs_jp.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libpthread-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103
:/usr/lib64/python2.7/lib-dynload/timemodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/fcntlmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/datetime.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libcom_err.so.2.1 libcom_err-1.42.9-7.el7.x86_64 (CentOS) 1430258082
:/usr/lib64/python2.7/lib-dynload/_cryptmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/_hashlib.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/_functoolsmodule.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libcrypt-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103
:/usr/lib64/python2.7/lib-dynload/_codecs_iso2022.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib/locale/locale-archive glibc-common-2.17-106.el7_2.8.x86_64 (CentOS) 1470694096
:/usr/lib64/liblzma.so.5.0.99 xz-libs-5.1.2-12alpha.el7.x86_64 (CentOS) 1451751377
:/usr/lib64/libcrypto.so.1.0.1e openssl-libs-1:1.0.1e-51.el7_2.7.x86_64 (CentOS) 1475934561
:/usr/lib64/libselinux.so.1 libselinux-2.2.2-6.el7.x86_64 (CentOS) 1421526525
:/usr/lib64/python2.7/lib-dynload/cPickle.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libkeyutils.so.1.5 keyutils-libs-1.5.8-3.el7.x86_64 (CentOS) 1421526540
:/usr/lib64/libk5crypto.so.3.1 krb5-libs-1.13.2-12.el7_2.x86_64 (CentOS) 1459808218
:/usr/lib64/libpython2.7.so.1.0 python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/python2.7/lib-dynload/_codecs_kr.so python-libs-2.7.5-39.el7_2.x86_64 (CentOS) 1474297161
:/usr/lib64/libm-2.17.so glibc-2.17-106.el7_2.8.x86_64 (CentOS) 1470694103

environ:
:LANG=en_US.UTF-8
:PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

limits:
:Limit                     Soft Limit           Hard Limit           Units     
:Max cpu time              unlimited            unlimited            seconds   
:Max file size             unlimited            unlimited            bytes     
:Max data size             unlimited            unlimited            bytes     
:Max stack size            8388608              unlimited            bytes     
:Max core file size        0                    unlimited            bytes     
:Max resident set          unlimited            unlimited            bytes     
:Max processes             6965                 6965                 processes 
:Max open files            1024                 4096                 files     
:Max locked memory         65536                65536                bytes     
:Max address space         unlimited            unlimited            bytes     
:Max file locks            unlimited            unlimited            locks     
:Max pending signals       6965                 6965                 signals   
:Max msgqueue size         819200               819200               bytes     
:Max nice priority         0                    0                    
:Max realtime priority     0                    0                    
:Max realtime timeout      unlimited            unlimited            us        

machineid:
:systemd=e55051aee1c342e0b8848d427b6bc883
:sosreport_uploader-dmidecode=5b0bf9be13e3758892620ca2c353a7bbd16f16fee7ccb7ca6caa6f5eb9fe9aa7

maps:
:00400000-00401000 r-xp 00000000 08:02 1049442                            /usr/bin/python2.7
:00600000-00601000 r--p 00000000 08:02 1049442                            /usr/bin/python2.7
:00601000-00602000 rw-p 00001000 08:02 1049442                            /usr/bin/python2.7
:00a12000-00f65000 rw-p 00000000 00:00 0                                  [heap]
:7ffa82053000-7ffa820cc000 r-xp 00000000 08:02 919399                     /usr/lib64/libfreeblpriv3.so
:7ffa820cc000-7ffa822cb000 ---p 00079000 08:02 919399                     /usr/lib64/libfreeblpriv3.so
:7ffa822cb000-7ffa822ce000 r--p 00078000 08:02 919399                     /usr/lib64/libfreeblpriv3.so
:7ffa822ce000-7ffa822cf000 rw-p 0007b000 08:02 919399                     /usr/lib64/libfreeblpriv3.so
:7ffa822cf000-7ffa822d3000 rw-p 00000000 00:00 0 
:7ffa822d3000-7ffa822d5000 r-xp 00000000 08:02 919309                     /usr/lib64/libfreebl3.so
:7ffa822d5000-7ffa824d4000 ---p 00002000 08:02 919309                     /usr/lib64/libfreebl3.so
:7ffa824d4000-7ffa824d5000 r--p 00001000 08:02 919309                     /usr/lib64/libfreebl3.so
:7ffa824d5000-7ffa824d6000 rw-p 00002000 08:02 919309                     /usr/lib64/libfreebl3.so
:7ffa824d6000-7ffa824de000 r-xp 00000000 08:02 918677                     /usr/lib64/libcrypt-2.17.so
:7ffa824de000-7ffa826dd000 ---p 00008000 08:02 918677                     /usr/lib64/libcrypt-2.17.so
:7ffa826dd000-7ffa826de000 r--p 00007000 08:02 918677                     /usr/lib64/libcrypt-2.17.so
:7ffa826de000-7ffa826df000 rw-p 00008000 08:02 918677                     /usr/lib64/libcrypt-2.17.so
:7ffa826df000-7ffa8270d000 rw-p 00000000 00:00 0 
:7ffa8270d000-7ffa8270e000 r-xp 00000000 08:02 928636                     /usr/lib64/python2.7/lib-dynload/_cryptmodule.so
:7ffa8270e000-7ffa8290d000 ---p 00001000 08:02 928636                     /usr/lib64/python2.7/lib-dynload/_cryptmodule.so
:7ffa8290d000-7ffa8290e000 r--p 00000000 08:02 928636                     /usr/lib64/python2.7/lib-dynload/_cryptmodule.so
:7ffa8290e000-7ffa8290f000 rw-p 00001000 08:02 928636                     /usr/lib64/python2.7/lib-dynload/_cryptmodule.so
:7ffa8290f000-7ffa82920000 r-xp 00000000 08:02 929733                     /usr/lib64/python2.7/lib-dynload/datetime.so
:7ffa82920000-7ffa82b1f000 ---p 00011000 08:02 929733                     /usr/lib64/python2.7/lib-dynload/datetime.so
:7ffa82b1f000-7ffa82b20000 r--p 00010000 08:02 929733                     /usr/lib64/python2.7/lib-dynload/datetime.so
:7ffa82b20000-7ffa82b24000 rw-p 00011000 08:02 929733                     /usr/lib64/python2.7/lib-dynload/datetime.so
:7ffa82b24000-7ffa82b36000 r-xp 00000000 08:02 930055                     /usr/lib64/python2.7/lib-dynload/cPickle.so
:7ffa82b36000-7ffa82d36000 ---p 00012000 08:02 930055                     /usr/lib64/python2.7/lib-dynload/cPickle.so
:7ffa82d36000-7ffa82d37000 r--p 00012000 08:02 930055                     /usr/lib64/python2.7/lib-dynload/cPickle.so
:7ffa82d37000-7ffa82d38000 rw-p 00013000 08:02 930055                     /usr/lib64/python2.7/lib-dynload/cPickle.so
:7ffa82d38000-7ffa82d3d000 r-xp 00000000 08:02 930024                     /usr/lib64/python2.7/lib-dynload/selectmodule.so
:7ffa82d3d000-7ffa82f3c000 ---p 00005000 08:02 930024                     /usr/lib64/python2.7/lib-dynload/selectmodule.so
:7ffa82f3c000-7ffa82f3d000 r--p 00004000 08:02 930024                     /usr/lib64/python2.7/lib-dynload/selectmodule.so
:7ffa82f3d000-7ffa82f3f000 rw-p 00005000 08:02 930024                     /usr/lib64/python2.7/lib-dynload/selectmodule.so
:7ffa82f3f000-7ffa82f48000 r-xp 00000000 08:02 930050                     /usr/lib64/python2.7/lib-dynload/arraymodule.so
:7ffa82f48000-7ffa83147000 ---p 00009000 08:02 930050                     /usr/lib64/python2.7/lib-dynload/arraymodule.so
:7ffa83147000-7ffa83148000 r--p 00008000 08:02 930050                     /usr/lib64/python2.7/lib-dynload/arraymodule.so
:7ffa83148000-7ffa8314a000 rw-p 00009000 08:02 930050                     /usr/lib64/python2.7/lib-dynload/arraymodule.so
:7ffa8314a000-7ffa831e0000 r-xp 00000000 08:02 930036                     /usr/lib64/python2.7/lib-dynload/unicodedata.so
:7ffa831e0000-7ffa833df000 ---p 00096000 08:02 930036                     /usr/lib64/python2.7/lib-dynload/unicodedata.so
:7ffa833df000-7ffa833e0000 r--p 00095000 08:02 930036                     /usr/lib64/python2.7/lib-dynload/unicodedata.so
:7ffa833e0000-7ffa833f3000 rw-p 00096000 08:02 930036                     /usr/lib64/python2.7/lib-dynload/unicodedata.so
:7ffa833f3000-7ffa83475000 rw-p 00000000 00:00 0 
:7ffa83475000-7ffa8347a000 r-xp 00000000 08:02 930025                     /usr/lib64/python2.7/lib-dynload/stropmodule.so
:7ffa8347a000-7ffa83679000 ---p 00005000 08:02 930025                     /usr/lib64/python2.7/lib-dynload/stropmodule.so
:7ffa83679000-7ffa8367a000 r--p 00004000 08:02 930025                     /usr/lib64/python2.7/lib-dynload/stropmodule.so
:7ffa8367a000-7ffa8367c000 rw-p 00005000 08:02 930025                     /usr/lib64/python2.7/lib-dynload/stropmodule.so
:7ffa8367c000-7ffa8367f000 r-xp 00000000 08:02 929746                     /usr/lib64/python2.7/lib-dynload/fcntlmodule.so
:7ffa8367f000-7ffa8387e000 ---p 00003000 08:02 929746                     /usr/lib64/python2.7/lib-dynload/fcntlmodule.so
:7ffa8387e000-7ffa8387f000 r--p 00002000 08:02 929746                     /usr/lib64/python2.7/lib-dynload/fcntlmodule.so
:7ffa8387f000-7ffa83880000 rw-p 00003000 08:02 929746                     /usr/lib64/python2.7/lib-dynload/fcntlmodule.so
:7ffa83880000-7ffa83883000 r-xp 00000000 08:02 929617                     /usr/lib64/python2.7/lib-dynload/_randommodule.so
:7ffa83883000-7ffa83a82000 ---p 00003000 08:02 929617                     /usr/lib64/python2.7/lib-dynload/_randommodule.so
:7ffa83a82000-7ffa83a83000 r--p 00002000 08:02 929617                     /usr/lib64/python2.7/lib-dynload/_randommodule.so
:7ffa83a83000-7ffa83a84000 rw-p 00003000 08:02 929617                     /usr/lib64/python2.7/lib-dynload/_randommodule.so
:7ffa83a84000-7ffa83a88000 r-xp 00000000 08:02 928779                     /usr/lib64/python2.7/lib-dynload/_hashlib.so
:7ffa83a88000-7ffa83c87000 ---p 00004000 08:02 928779                     /usr/lib64/python2.7/lib-dynload/_hashlib.so
:7ffa83c87000-7ffa83c88000 r--p 00003000 08:02 928779                     /usr/lib64/python2.7/lib-dynload/_hashlib.so
:7ffa83c88000-7ffa83c89000 rw-p 00004000 08:02 928779                     /usr/lib64/python2.7/lib-dynload/_hashlib.so
:7ffa83c89000-7ffa83c8a000 rw-p 00000000 00:00 0 
:7ffa83c8a000-7ffa83c91000 r-xp 00000000 08:02 929795                     /usr/lib64/python2.7/lib-dynload/math.so
:7ffa83c91000-7ffa83e90000 ---p 00007000 08:02 929795                     /usr/lib64/python2.7/lib-dynload/math.so
:7ffa83e90000-7ffa83e91000 r--p 00006000 08:02 929795                     /usr/lib64/python2.7/lib-dynload/math.so
:7ffa83e91000-7ffa83e93000 rw-p 00007000 08:02 929795                     /usr/lib64/python2.7/lib-dynload/math.so
:7ffa83e93000-7ffa83ed4000 rw-p 00000000 00:00 0 
:7ffa83ed4000-7ffa83ef0000 r-xp 00000000 08:02 928853                     /usr/lib64/python2.7/lib-dynload/_io.so
:7ffa83ef0000-7ffa840ef000 ---p 0001c000 08:02 928853                     /usr/lib64/python2.7/lib-dynload/_io.so
:7ffa840ef000-7ffa840f0000 r--p 0001b000 08:02 928853                     /usr/lib64/python2.7/lib-dynload/_io.so
:7ffa840f0000-7ffa840fa000 rw-p 0001c000 08:02 928853                     /usr/lib64/python2.7/lib-dynload/_io.so
:7ffa840fa000-7ffa840fd000 r-xp 00000000 08:02 928782                     /usr/lib64/python2.7/lib-dynload/_heapq.so
:7ffa840fd000-7ffa842fc000 ---p 00003000 08:02 928782                     /usr/lib64/python2.7/lib-dynload/_heapq.so
:7ffa842fc000-7ffa842fd000 r--p 00002000 08:02 928782                     /usr/lib64/python2.7/lib-dynload/_heapq.so
:7ffa842fd000-7ffa842ff000 rw-p 00003000 08:02 928782                     /usr/lib64/python2.7/lib-dynload/_heapq.so
:7ffa842ff000-7ffa84309000 r-xp 00000000 08:02 929752                     /usr/lib64/python2.7/lib-dynload/itertoolsmodule.so
:7ffa84309000-7ffa84508000 ---p 0000a000 08:02 929752                     /usr/lib64/python2.7/lib-dynload/itertoolsmodule.so
:7ffa84508000-7ffa84509000 r--p 00009000 08:02 929752                     /usr/lib64/python2.7/lib-dynload/itertoolsmodule.so
:7ffa84509000-7ffa8450e000 rw-p 0000a000 08:02 929752                     /usr/lib64/python2.7/lib-dynload/itertoolsmodule.so
:7ffa8450e000-7ffa84514000 r-xp 00000000 08:02 926324                     /usr/lib64/python2.7/lib-dynload/_collectionsmodule.so
:7ffa84514000-7ffa84713000 ---p 00006000 08:02 926324                     /usr/lib64/python2.7/lib-dynload/_collectionsmodule.so
:7ffa84713000-7ffa84714000 r--p 00005000 08:02 926324                     /usr/lib64/python2.7/lib-dynload/_collectionsmodule.so
:7ffa84714000-7ffa84716000 rw-p 00006000 08:02 926324                     /usr/lib64/python2.7/lib-dynload/_collectionsmodule.so
:7ffa84716000-7ffa84757000 rw-p 00000000 00:00 0 
:7ffa84757000-7ffa8475c000 r-xp 00000000 08:02 929645                     /usr/lib64/python2.7/lib-dynload/binascii.so
:7ffa8475c000-7ffa8495b000 ---p 00005000 08:02 929645                     /usr/lib64/python2.7/lib-dynload/binascii.so
:7ffa8495b000-7ffa8495c000 r--p 00004000 08:02 929645                     /usr/lib64/python2.7/lib-dynload/binascii.so
:7ffa8495c000-7ffa8495d000 rw-p 00005000 08:02 929645                     /usr/lib64/python2.7/lib-dynload/binascii.so
:7ffa8495d000-7ffa84a1e000 rw-p 00000000 00:00 0 
:7ffa84a1e000-7ffa84a25000 r-xp 00000000 08:02 930048                     /usr/lib64/python2.7/lib-dynload/_struct.so
:7ffa84a25000-7ffa84c24000 ---p 00007000 08:02 930048                     /usr/lib64/python2.7/lib-dynload/_struct.so
:7ffa84c24000-7ffa84c25000 r--p 00006000 08:02 930048                     /usr/lib64/python2.7/lib-dynload/_struct.so
:7ffa84c25000-7ffa84c27000 rw-p 00007000 08:02 930048                     /usr/lib64/python2.7/lib-dynload/_struct.so
:7ffa84c27000-7ffa84c2b000 r-xp 00000000 08:02 930087                     /usr/lib64/python2.7/lib-dynload/timemodule.so
:7ffa84c2b000-7ffa84e2a000 ---p 00004000 08:02 930087                     /usr/lib64/python2.7/lib-dynload/timemodule.so
:7ffa84e2a000-7ffa84e2b000 r--p 00003000 08:02 930087                     /usr/lib64/python2.7/lib-dynload/timemodule.so
:7ffa84e2b000-7ffa84e2d000 rw-p 00004000 08:02 930087                     /usr/lib64/python2.7/lib-dynload/timemodule.so
:7ffa84e2d000-7ffa84e31000 r-xp 00000000 08:02 929565                     /usr/lib64/python2.7/lib-dynload/_localemodule.so
:7ffa84e31000-7ffa85030000 ---p 00004000 08:02 929565                     /usr/lib64/python2.7/lib-dynload/_localemodule.so
:7ffa85030000-7ffa85031000 r--p 00003000 08:02 929565                     /usr/lib64/python2.7/lib-dynload/_localemodule.so
:7ffa85031000-7ffa85032000 rw-p 00004000 08:02 929565                     /usr/lib64/python2.7/lib-dynload/_localemodule.so
:7ffa85032000-7ffa8503b000 r-xp 00000000 08:02 929961                     /usr/lib64/python2.7/lib-dynload/operator.so
:7ffa8503b000-7ffa8523a000 ---p 00009000 08:02 929961                     /usr/lib64/python2.7/lib-dynload/operator.so
:7ffa8523a000-7ffa8523b000 r--p 00008000 08:02 929961                     /usr/lib64/python2.7/lib-dynload/operator.so
:7ffa8523b000-7ffa8523d000 rw-p 00009000 08:02 929961                     /usr/lib64/python2.7/lib-dynload/operator.so
:7ffa8523d000-7ffa85241000 r-xp 00000000 08:02 930056                     /usr/lib64/python2.7/lib-dynload/cStringIO.so
:7ffa85241000-7ffa85440000 ---p 00004000 08:02 930056                     /usr/lib64/python2.7/lib-dynload/cStringIO.so
:7ffa85440000-7ffa85441000 r--p 00003000 08:02 930056                     /usr/lib64/python2.7/lib-dynload/cStringIO.so
:7ffa85441000-7ffa85443000 rw-p 00004000 08:02 930056                     /usr/lib64/python2.7/lib-dynload/cStringIO.so
:7ffa85443000-7ffa85467000 r-xp 00000000 08:02 922723                     /usr/lib64/liblzma.so.5.0.99
:7ffa85467000-7ffa85666000 ---p 00024000 08:02 922723                     /usr/lib64/liblzma.so.5.0.99
:7ffa85666000-7ffa85667000 r--p 00023000 08:02 922723                     /usr/lib64/liblzma.so.5.0.99
:7ffa85667000-7ffa85668000 rw-p 00024000 08:02 922723                     /usr/lib64/liblzma.so.5.0.99
:7ffa85668000-7ffa856c8000 r-xp 00000000 08:02 923359                     /usr/lib64/libpcre.so.1.2.0
:7ffa856c8000-7ffa858c7000 ---p 00060000 08:02 923359                     /usr/lib64/libpcre.so.1.2.0
:7ffa858c7000-7ffa858c8000 r--p 0005f000 08:02 923359                     /usr/lib64/libpcre.so.1.2.0
:7ffa858c8000-7ffa858c9000 rw-p 00060000 08:02 923359                     /usr/lib64/libpcre.so.1.2.0
:7ffa858c9000-7ffa858ea000 r-xp 00000000 08:02 917877                     /usr/lib64/libselinux.so.1
:7ffa858ea000-7ffa85aea000 ---p 00021000 08:02 917877                     /usr/lib64/libselinux.so.1
:7ffa85aea000-7ffa85aeb000 r--p 00021000 08:02 917877                     /usr/lib64/libselinux.so.1
:7ffa85aeb000-7ffa85aec000 rw-p 00022000 08:02 917877                     /usr/lib64/libselinux.so.1
:7ffa85aec000-7ffa85aee000 rw-p 00000000 00:00 0 
:7ffa85aee000-7ffa85b04000 r-xp 00000000 08:02 922703                     /usr/lib64/libresolv-2.17.so
:7ffa85b04000-7ffa85d04000 ---p 00016000 08:02 922703                     /usr/lib64/libresolv-2.17.so
:7ffa85d04000-7ffa85d05000 r--p 00016000 08:02 922703                     /usr/lib64/libresolv-2.17.so
:7ffa85d05000-7ffa85d06000 rw-p 00017000 08:02 922703                     /usr/lib64/libresolv-2.17.so
:7ffa85d06000-7ffa85d08000 rw-p 00000000 00:00 0 
:7ffa85d08000-7ffa85d0b000 r-xp 00000000 08:02 917977                     /usr/lib64/libkeyutils.so.1.5
:7ffa85d0b000-7ffa85f0a000 ---p 00003000 08:02 917977                     /usr/lib64/libkeyutils.so.1.5
:7ffa85f0a000-7ffa85f0b000 r--p 00002000 08:02 917977                     /usr/lib64/libkeyutils.so.1.5
:7ffa85f0b000-7ffa85f0c000 rw-p 00003000 08:02 917977                     /usr/lib64/libkeyutils.so.1.5
:7ffa85f0c000-7ffa85f19000 r-xp 00000000 08:02 918316                     /usr/lib64/libkrb5support.so.0.1
:7ffa85f19000-7ffa86119000 ---p 0000d000 08:02 918316                     /usr/lib64/libkrb5support.so.0.1
:7ffa86119000-7ffa8611a000 r--p 0000d000 08:02 918316                     /usr/lib64/libkrb5support.so.0.1
:7ffa8611a000-7ffa8611b000 rw-p 0000e000 08:02 918316                     /usr/lib64/libkrb5support.so.0.1
:7ffa8611b000-7ffa86130000 r-xp 00000000 08:02 917878                     /usr/lib64/libz.so.1.2.7
:7ffa86130000-7ffa8632f000 ---p 00015000 08:02 917878                     /usr/lib64/libz.so.1.2.7
:7ffa8632f000-7ffa86330000 r--p 00014000 08:02 917878                     /usr/lib64/libz.so.1.2.7
:7ffa86330000-7ffa86331000 rw-p 00015000 08:02 917878                     /usr/lib64/libz.so.1.2.7
:7ffa86331000-7ffa86360000 r-xp 00000000 08:02 918290                     /usr/lib64/libk5crypto.so.3.1
:7ffa86360000-7ffa8655f000 ---p 0002f000 08:02 918290                     /usr/lib64/libk5crypto.so.3.1
:7ffa8655f000-7ffa86561000 r--p 0002e000 08:02 918290                     /usr/lib64/libk5crypto.so.3.1
:7ffa86561000-7ffa86562000 rw-p 00030000 08:02 918290                     /usr/lib64/libk5crypto.so.3.1
:7ffa86562000-7ffa86563000 rw-p 00000000 00:00 0 
:7ffa86563000-7ffa86566000 r-xp 00000000 08:02 917884                     /usr/lib64/libcom_err.so.2.1
:7ffa86566000-7ffa86765000 ---p 00003000 08:02 917884                     /usr/lib64/libcom_err.so.2.1
:7ffa86765000-7ffa86766000 r--p 00002000 08:02 917884                     /usr/lib64/libcom_err.so.2.1
:7ffa86766000-7ffa86767000 rw-p 00003000 08:02 917884                     /usr/lib64/libcom_err.so.2.1
:7ffa86767000-7ffa8683c000 r-xp 00000000 08:02 918313                     /usr/lib64/libkrb5.so.3.3
:7ffa8683c000-7ffa86a3c000 ---p 000d5000 08:02 918313                     /usr/lib64/libkrb5.so.3.3
:7ffa86a3c000-7ffa86a49000 r--p 000d5000 08:02 918313                     /usr/lib64/libkrb5.so.3.3
:7ffa86a49000-7ffa86a4c000 rw-p 000e2000 08:02 918313                     /usr/lib64/libkrb5.so.3.3
:7ffa86a4c000-7ffa86a95000 r-xp 00000000 08:02 918226                     /usr/lib64/libgssapi_krb5.so.2.2
:7ffa86a95000-7ffa86c95000 ---p 00049000 08:02 918226                     /usr/lib64/libgssapi_krb5.so.2.2
:7ffa86c95000-7ffa86c96000 r--p 00049000 08:02 918226                     /usr/lib64/libgssapi_krb5.so.2.2
:7ffa86c96000-7ffa86c98000 rw-p 0004a000 08:02 918226                     /usr/lib64/libgssapi_krb5.so.2.2
:7ffa86c98000-7ffa86e56000 r-xp 00000000 08:02 918527                     /usr/lib64/libcrypto.so.1.0.1e
:7ffa86e56000-7ffa87056000 ---p 001be000 08:02 918527                     /usr/lib64/libcrypto.so.1.0.1e
:7ffa87056000-7ffa87070000 r--p 001be000 08:02 918527                     /usr/lib64/libcrypto.so.1.0.1e
:7ffa87070000-7ffa8707c000 rw-p 001d8000 08:02 918527                     /usr/lib64/libcrypto.so.1.0.1e
:7ffa8707c000-7ffa87080000 rw-p 00000000 00:00 0 
:7ffa87080000-7ffa870e3000 r-xp 00000000 08:02 920301                     /usr/lib64/libssl.so.1.0.1e
:7ffa870e3000-7ffa872e2000 ---p 00063000 08:02 920301                     /usr/lib64/libssl.so.1.0.1e
:7ffa872e2000-7ffa872e6000 r--p 00062000 08:02 920301                     /usr/lib64/libssl.so.1.0.1e
:7ffa872e6000-7ffa872ed000 rw-p 00066000 08:02 920301                     /usr/lib64/libssl.so.1.0.1e
:7ffa872ed000-7ffa87300000 r-xp 00000000 08:02 930047                     /usr/lib64/python2.7/lib-dynload/_ssl.so
:7ffa87300000-7ffa874ff000 ---p 00013000 08:02 930047                     /usr/lib64/python2.7/lib-dynload/_ssl.so
:7ffa874ff000-7ffa87500000 r--p 00012000 08:02 930047                     /usr/lib64/python2.7/lib-dynload/_ssl.so
:7ffa87500000-7ffa87504000 rw-p 00013000 08:02 930047                     /usr/lib64/python2.7/lib-dynload/_ssl.so
:7ffa87504000-7ffa87507000 r-xp 00000000 08:02 928681                     /usr/lib64/python2.7/lib-dynload/_functoolsmodule.so
:7ffa87507000-7ffa87706000 ---p 00003000 08:02 928681                     /usr/lib64/python2.7/lib-dynload/_functoolsmodule.so
:7ffa87706000-7ffa87707000 r--p 00002000 08:02 928681                     /usr/lib64/python2.7/lib-dynload/_functoolsmodule.so
:7ffa87707000-7ffa87708000 rw-p 00003000 08:02 928681                     /usr/lib64/python2.7/lib-dynload/_functoolsmodule.so
:7ffa87708000-7ffa87717000 r-xp 00000000 08:02 930045                     /usr/lib64/python2.7/lib-dynload/_socketmodule.so
:7ffa87717000-7ffa87916000 ---p 0000f000 08:02 930045                     /usr/lib64/python2.7/lib-dynload/_socketmodule.so
:7ffa87916000-7ffa87917000 r--p 0000e000 08:02 930045                     /usr/lib64/python2.7/lib-dynload/_socketmodule.so
:7ffa87917000-7ffa8791c000 rw-p 0000f000 08:02 930045                     /usr/lib64/python2.7/lib-dynload/_socketmodule.so
:7ffa8791c000-7ffa8791e000 r-xp 00000000 08:02 929750                     /usr/lib64/python2.7/lib-dynload/grpmodule.so
:7ffa8791e000-7ffa87b1d000 ---p 00002000 08:02 929750                     /usr/lib64/python2.7/lib-dynload/grpmodule.so
:7ffa87b1d000-7ffa87b1e000 r--p 00001000 08:02 929750                     /usr/lib64/python2.7/lib-dynload/grpmodule.so
:7ffa87b1e000-7ffa87b1f000 rw-p 00002000 08:02 929750                     /usr/lib64/python2.7/lib-dynload/grpmodule.so
:7ffa87b1f000-7ffa87b3c000 r-xp 00000000 08:02 925839                     /usr/lib64/python2.7/lib-dynload/_codecs_kr.so
:7ffa87b3c000-7ffa87d3b000 ---p 0001d000 08:02 925839                     /usr/lib64/python2.7/lib-dynload/_codecs_kr.so
:7ffa87d3b000-7ffa87d3f000 r--p 0001c000 08:02 925839                     /usr/lib64/python2.7/lib-dynload/_codecs_kr.so
:7ffa87d3f000-7ffa87d40000 rw-p 00020000 08:02 925839                     /usr/lib64/python2.7/lib-dynload/_codecs_kr.so
:7ffa87d40000-7ffa87d74000 r-xp 00000000 08:02 925556                     /usr/lib64/python2.7/lib-dynload/_codecs_jp.so
:7ffa87d74000-7ffa87f73000 ---p 00034000 08:02 925556                     /usr/lib64/python2.7/lib-dynload/_codecs_jp.so
:7ffa87f73000-7ffa87f80000 r--p 00033000 08:02 925556                     /usr/lib64/python2.7/lib-dynload/_codecs_jp.so
:7ffa87f80000-7ffa87f81000 rw-p 00040000 08:02 925556                     /usr/lib64/python2.7/lib-dynload/_codecs_jp.so
:7ffa87f81000-7ffa87f87000 r-xp 00000000 08:02 929567                     /usr/lib64/python2.7/lib-dynload/_multibytecodecmodule.so
:7ffa87f87000-7ffa88187000 ---p 00006000 08:02 929567                     /usr/lib64/python2.7/lib-dynload/_multibytecodecmodule.so
:7ffa88187000-7ffa88188000 r--p 00006000 08:02 929567                     /usr/lib64/python2.7/lib-dynload/_multibytecodecmodule.so
:7ffa88188000-7ffa8818a000 rw-p 00007000 08:02 929567                     /usr/lib64/python2.7/lib-dynload/_multibytecodecmodule.so
:7ffa8818a000-7ffa8818f000 r-xp 00000000 08:02 923372                     /usr/lib64/python2.7/lib-dynload/_codecs_iso2022.so
:7ffa8818f000-7ffa8838e000 ---p 00005000 08:02 923372                     /usr/lib64/python2.7/lib-dynload/_codecs_iso2022.so
:7ffa8838e000-7ffa8838f000 r--p 00004000 08:02 923372                     /usr/lib64/python2.7/lib-dynload/_codecs_iso2022.so
:7ffa8838f000-7ffa88390000 rw-p 00005000 08:02 923372                     /usr/lib64/python2.7/lib-dynload/_codecs_iso2022.so
:7ffa88390000-7ffa8e8b7000 r--p 00000000 08:02 140591                     /usr/lib/locale/locale-archive
:7ffa8e8b7000-7ffa8e8c3000 r-xp 00000000 08:02 922006                     /usr/lib64/libnss_files-2.17.so
:7ffa8e8c3000-7ffa8eac2000 ---p 0000c000 08:02 922006                     /usr/lib64/libnss_files-2.17.so
:7ffa8eac2000-7ffa8eac3000 r--p 0000b000 08:02 922006                     /usr/lib64/libnss_files-2.17.so
:7ffa8eac3000-7ffa8eac4000 rw-p 0000c000 08:02 922006                     /usr/lib64/libnss_files-2.17.so
:7ffa8eac4000-7ffa8eaca000 rw-p 00000000 00:00 0 
:7ffa8eaca000-7ffa8ec81000 r-xp 00000000 08:02 918526                     /usr/lib64/libc-2.17.so
:7ffa8ec81000-7ffa8ee81000 ---p 001b7000 08:02 918526                     /usr/lib64/libc-2.17.so
:7ffa8ee81000-7ffa8ee85000 r--p 001b7000 08:02 918526                     /usr/lib64/libc-2.17.so
:7ffa8ee85000-7ffa8ee87000 rw-p 001bb000 08:02 918526                     /usr/lib64/libc-2.17.so
:7ffa8ee87000-7ffa8ee8c000 rw-p 00000000 00:00 0 
:7ffa8ee8c000-7ffa8ef8d000 r-xp 00000000 08:02 919729                     /usr/lib64/libm-2.17.so
:7ffa8ef8d000-7ffa8f18c000 ---p 00101000 08:02 919729                     /usr/lib64/libm-2.17.so
:7ffa8f18c000-7ffa8f18d000 r--p 00100000 08:02 919729                     /usr/lib64/libm-2.17.so
:7ffa8f18d000-7ffa8f18e000 rw-p 00101000 08:02 919729                     /usr/lib64/libm-2.17.so
:7ffa8f18e000-7ffa8f190000 r-xp 00000000 08:02 919444                     /usr/lib64/libutil-2.17.so
:7ffa8f190000-7ffa8f38f000 ---p 00002000 08:02 919444                     /usr/lib64/libutil-2.17.so
:7ffa8f38f000-7ffa8f390000 r--p 00001000 08:02 919444                     /usr/lib64/libutil-2.17.so
:7ffa8f390000-7ffa8f391000 rw-p 00002000 08:02 919444                     /usr/lib64/libutil-2.17.so
:7ffa8f391000-7ffa8f394000 r-xp 00000000 08:02 919692                     /usr/lib64/libdl-2.17.so
:7ffa8f394000-7ffa8f593000 ---p 00003000 08:02 919692                     /usr/lib64/libdl-2.17.so
:7ffa8f593000-7ffa8f594000 r--p 00002000 08:02 919692                     /usr/lib64/libdl-2.17.so
:7ffa8f594000-7ffa8f595000 rw-p 00003000 08:02 919692                     /usr/lib64/libdl-2.17.so
:7ffa8f595000-7ffa8f5ab000 r-xp 00000000 08:02 917559                     /usr/lib64/libpthread-2.17.so
:7ffa8f5ab000-7ffa8f7ab000 ---p 00016000 08:02 917559                     /usr/lib64/libpthread-2.17.so
:7ffa8f7ab000-7ffa8f7ac000 r--p 00016000 08:02 917559                     /usr/lib64/libpthread-2.17.so
:7ffa8f7ac000-7ffa8f7ad000 rw-p 00017000 08:02 917559                     /usr/lib64/libpthread-2.17.so
:7ffa8f7ad000-7ffa8f7b1000 rw-p 00000000 00:00 0 
:7ffa8f7b1000-7ffa8f929000 r-xp 00000000 08:02 924277                     /usr/lib64/libpython2.7.so.1.0
:7ffa8f929000-7ffa8fb29000 ---p 00178000 08:02 924277                     /usr/lib64/libpython2.7.so.1.0
:7ffa8fb29000-7ffa8fb2a000 r--p 00178000 08:02 924277                     /usr/lib64/libpython2.7.so.1.0
:7ffa8fb2a000-7ffa8fb68000 rw-p 00179000 08:02 924277                     /usr/lib64/libpython2.7.so.1.0
:7ffa8fb68000-7ffa8fb77000 rw-p 00000000 00:00 0 
:7ffa8fb77000-7ffa8fb98000 r-xp 00000000 08:02 917916                     /usr/lib64/ld-2.17.so
:7ffa8fbb4000-7ffa8fcb8000 rw-p 00000000 00:00 0 
:7ffa8fce9000-7ffa8fd70000 rw-p 00000000 00:00 0 
:7ffa8fd97000-7ffa8fd98000 rw-p 00000000 00:00 0 
:7ffa8fd98000-7ffa8fd99000 r--p 00021000 08:02 917916                     /usr/lib64/ld-2.17.so
:7ffa8fd99000-7ffa8fd9a000 rw-p 00022000 08:02 917916                     /usr/lib64/ld-2.17.so
:7ffa8fd9a000-7ffa8fd9b000 rw-p 00000000 00:00 0 
:7ffed1c17000-7ffed1c38000 rw-p 00000000 00:00 0                          [stack]
:7ffed1d5f000-7ffed1d61000 r-xp 00000000 00:00 0                          [vdso]
:ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

open_fds:
:0:/dev/null
:pos:	0
:flags:	0100000
:mnt_id:	19
:1:/dev/null
:pos:	0
:flags:	0100000
:mnt_id:	19
:2:/dev/null
:pos:	0
:flags:	0100000
:mnt_id:	19
:3:/var/log/mailman/error-20161017
:pos:	0
:flags:	0102002
:mnt_id:	73
:4:/dev/null
:pos:	0
:flags:	0100000
:mnt_id:	19
:5:/var/log/mailman/error-20161017
:pos:	0
:flags:	0102002
:mnt_id:	73
:6:/var/log/mailman/qrunner
:pos:	403
:flags:	0102002
:mnt_id:	73

os_info:
:NAME="CentOS Linux"
:VERSION="7 (Core)"
:ID="centos"
:ID_LIKE="rhel fedora"
:VERSION_ID="7"
:PRETTY_NAME="CentOS Linux 7 (Core)"
:ANSI_COLOR="0;31"
:CPE_NAME="cpe:/o:centos:centos:7"
:HOME_URL="https://www.centos.org/"
:BUG_REPORT_URL="https://bugs.centos.org/"
:
:CENTOS_MANTISBT_PROJECT="CentOS-7"
:CENTOS_MANTISBT_PROJECT_VERSION="7"
:REDHAT_SUPPORT_PRODUCT="centos"
:REDHAT_SUPPORT_PRODUCT_VERSION="7"
:

proc_pid_status:
:Name:	python
:State:	S (sleeping)
:Tgid:	3842
:Ngid:	0
:Pid:	3842
:PPid:	3826
:TracerPid:	0
:Uid:	41	41	41	41
:Gid:	41	41	41	41
:FDSize:	64
:Groups:	41 
:VmPeak:	  231740 kB
:VmSize:	  231736 kB
:VmLck:	       0 kB
:VmPin:	       0 kB
:VmHWM:	   14052 kB
:VmRSS:	   13296 kB
:VmData:	    9220 kB
:VmStk:	     136 kB
:VmExe:	       4 kB
:VmLib:	   11252 kB
:VmPTE:	     268 kB
:VmSwap:	       0 kB
:Threads:	1
:SigQ:	0/6965
:SigPnd:	0000000000000000
:ShdPnd:	0000000000000000
:SigBlk:	0000000000000000
:SigIgn:	0000000001001000
:SigCgt:	0000000180004003
:CapInh:	0000000000000000
:CapPrm:	0000000000000000
:CapEff:	0000000000000000
:CapBnd:	0000001fffffffff
:Seccomp:	0
:Cpus_allowed:	f
:Cpus_allowed_list:	0-3
:Mems_allowed:	00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
:Mems_allowed_list:	0
:voluntary_ctxt_switches:	407061
:nonvoluntary_ctxt_switches:	155

var_log_messages:
:[System Logs]:
:
:[User Logs]:

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

From mark at msapiro.net  Mon Oct 31 12:43:48 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 31 Oct 2016 09:43:48 -0700
Subject: [Mailman-Users] Mailman qrunner: [abrt] full crash report
In-Reply-To: <22d5e422-0e17-e4bc-6179-8c4f41370853@bellsouth.net>
References: <5816a7d1.PVWH6nlhqILKwozk%user@localhost>
 <22d5e422-0e17-e4bc-6179-8c4f41370853@bellsouth.net>
Message-ID: <0e00aaba-e7c3-0429-05c3-cf5583dc8c6e@msapiro.net>

On 10/31/2016 05:43 AM, Dennis Putnam wrote:
> I have been getting these crash reports occasionally. Does this look
> like a mailman problem or is mailman falling victim to some OS (Centos
> 7) or other issue? TIA.
> 
> 
> time: Thu 20 Oct 2016 06:43:20 AM EDT
> 
> cmdline:        /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s


The crash is in VirginRunner, but it is at a very low level within
Python itself.

Is there anything in Mailman's logs. There probably won't be anything in
the 'error' log specific to this event because the runner itself
crashed, but there should be something in the qrunner log about the
death and restart (and after the 10th time, it won't restart so you'd
need to restart Mailman).

Also, is it always VirginRunner and is the "core_backtrace:" always similar?

VirginRunner processes Mailman generated notices. There should be
messages in Mailman's logs and the system mail log which will indicate
what kind of notice Mailman was trying to send.

Also when VirginRunner dies, there will be a *.bak file left in the
virgin queue and when the runner restarts, this file will be recovered
and reprocessed, so there should be log messages (e.g. in Mailman's
'smtp' log) about that.

In any case, this seems more of a Python or OS issue than Mailman per se.

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

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

From dap1 at bellsouth.net  Mon Oct 31 13:15:13 2016
From: dap1 at bellsouth.net (Dennis Putnam)
Date: Mon, 31 Oct 2016 13:15:13 -0400
Subject: [Mailman-Users] Mailman qrunner: [abrt] full crash report
In-Reply-To: <0e00aaba-e7c3-0429-05c3-cf5583dc8c6e@msapiro.net>
References: <5816a7d1.PVWH6nlhqILKwozk%user@localhost>
 <22d5e422-0e17-e4bc-6179-8c4f41370853@bellsouth.net>
 <0e00aaba-e7c3-0429-05c3-cf5583dc8c6e@msapiro.net>
Message-ID: <a770b93b-10b7-0a54-7a73-25ba39c7de72@bellsouth.net>

Hi Mark,

Thanks for the reply.

You are correct, there is nothing in the error log and this is all that
is in the qrunner log at that time:

Oct 20 06:43:20 2016 (3826) Master qrunner detected subprocess exit
(pid: 3842, sig: 6, sts: None, class: VirginRunner, slice: 1/1) [restarting]
Oct 20 06:43:21 2016 (30064) VirginRunner qrunner started.

For that particular day mailman was idle so there was no mailman log.
There was no list activity. That would seem to support your suggestion
that this is not a mailman problem but rather mailman is a victim of
some OS or external issue. Odd however, that it is always mailman that
is effected and yes, the dumps seem to be similar, although I did not
try to do a diff on any of them (that probably wouldn't mean much anyway).

On 10/31/2016 12:43 PM, Mark Sapiro wrote:
> On 10/31/2016 05:43 AM, Dennis Putnam wrote:
>> I have been getting these crash reports occasionally. Does this look
>> like a mailman problem or is mailman falling victim to some OS (Centos
>> 7) or other issue? TIA.
>>
>>
>> time: Thu 20 Oct 2016 06:43:20 AM EDT
>>
>> cmdline:        /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
>
> The crash is in VirginRunner, but it is at a very low level within
> Python itself.
>
> Is there anything in Mailman's logs. There probably won't be anything in
> the 'error' log specific to this event because the runner itself
> crashed, but there should be something in the qrunner log about the
> death and restart (and after the 10th time, it won't restart so you'd
> need to restart Mailman).
>
> Also, is it always VirginRunner and is the "core_backtrace:" always similar?
>
> VirginRunner processes Mailman generated notices. There should be
> messages in Mailman's logs and the system mail log which will indicate
> what kind of notice Mailman was trying to send.
>
> Also when VirginRunner dies, there will be a *.bak file left in the
> virgin queue and when the runner restarts, this file will be recovered
> and reprocessed, so there should be log messages (e.g. in Mailman's
> 'smtp' log) about that.
>
> In any case, this seems more of a Python or OS issue than Mailman per se.
>
>
>
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at python.org
> https://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: https://mail.python.org/mailman/options/mailman-users/dap1%40bellsouth.net


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

From mark at msapiro.net  Mon Oct 31 13:45:32 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 31 Oct 2016 10:45:32 -0700
Subject: [Mailman-Users] Mailman qrunner: [abrt] full crash report
In-Reply-To: <a770b93b-10b7-0a54-7a73-25ba39c7de72@bellsouth.net>
References: <5816a7d1.PVWH6nlhqILKwozk%user@localhost>
 <22d5e422-0e17-e4bc-6179-8c4f41370853@bellsouth.net>
 <0e00aaba-e7c3-0429-05c3-cf5583dc8c6e@msapiro.net>
 <a770b93b-10b7-0a54-7a73-25ba39c7de72@bellsouth.net>
Message-ID: <fc2064b8-c67f-f061-9a61-9b0939cbc726@msapiro.net>

On 10/31/2016 10:15 AM, Dennis Putnam wrote:
> Hi Mark,
> 
> Thanks for the reply.
> 
> You are correct, there is nothing in the error log and this is all that
> is in the qrunner log at that time:
> 
> Oct 20 06:43:20 2016 (3826) Master qrunner detected subprocess exit
> (pid: 3842, sig: 6, sts: None, class: VirginRunner, slice: 1/1) [restarting]
> Oct 20 06:43:21 2016 (30064) VirginRunner qrunner started.


This can ultimately become more serious. If VirginRunner continues to
die at times, after the 10th time, it won't automatically restart and
you will need to manually restart Mailman.


> For that particular day mailman was idle so there was no mailman log.
> There was no list activity. That would seem to support your suggestion
> that this is not a mailman problem but rather mailman is a victim of
> some OS or external issue. Odd however, that it is always mailman that
> is effected and yes, the dumps seem to be similar, although I did not
> try to do a diff on any of them (that probably wouldn't mean much anyway).


In that case, all VirginRunner was doing was waking up, checking it's
queue, finding it empty and going back to sleep which it and most of the
other runners except RetryRunner do every QRUNNER_SLEEP_TIME (1 second
default).

Since all the runners are basically doing the same loop, this may not
always affect VirginRunner.

The bottom line is if you can't figure out why this is happening and
stop it (and I don't think I can help much here) you'll have to monitor
to be sure no runner is not restarted because of the restart limit and
restart Mailman if necessary or maybe periodically whether needed or not.

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

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