From lac at openend.se  Fri Nov  4 10:17:24 2016
From: lac at openend.se (Laura Creighton)
Date: Fri, 4 Nov 2016 15:17:24 +0100
Subject: [Mailman-Developers] Silly usability problem in mailman3.
Message-ID: <201611041417.uA4EHORQ029829@theraft.openend.se>


I wanted to subscribe to the spanking-new mailing list, tox-dev.
In order to get to do this, I had to uncheck the checkbox on the top
'Hide inactive'

Apparently I was the first person to subscribe to the list, as there
were 0 subscribers and 0 discussions.

Whatever algorithm is being used to determine if a list is inactive or
not should be tweaked to understand that absolutely spanking-new
mailing lists -- which mailman3 already knows how to recognise --
are not considered inactive.

Thank you.

Laura 

From mark at msapiro.net  Fri Nov  4 13:44:40 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 4 Nov 2016 10:44:40 -0700
Subject: [Mailman-Developers] Problems signing up for the new tox-dev
 mailing list.
In-Reply-To: <201611041337.uA4DbJ6X023840@theraft.openend.se>
References: <20161104095316.GY21830@merlinux.eu>
 <201611041337.uA4DbJ6X023840@theraft.openend.se>
Message-ID: <e9156f6f-0b62-0edd-954f-84f4e49107b7@msapiro.net>

Resending with correct mailman-developers at python.org addressee.

On 11/4/16 6:37 AM, Laura Creighton wrote:
> 
> I subscribed, which required registering to HyperKitty.  This worked fine.
> Subscribing was odd.  I had to click on the 'Hide inactive' checkbox to find
> the list.  Apparently I am the first person to try to subscribe to this list
> as there were 0 participants and 0 discussions.  But I think it would be
> better if spanking new lists were not classified as inactive, for the
> benefit of extremely naive users.  So a little bad.


HyperKitty is the archiver. The list was inactive from HyperKitty's
point of view because there were no recent posts (no posts at all) in
the archive.

Had you gone to Postorius (the web list management UI) at
<https://mail.python.org/mm3/mailman3/lists/>, you would have seen the list.

It appears that the issue is that the sign-up process, once completed
redirects you to HyperKitty at <https://mail.python.org/mm3/archives/>
rather than back to Postorius at
<https://mail.python.org/mm3/mailman3/lists/>. You can get back to
Postorius from HyperKitty by clicking "Manage lists" at the top right.

I agree this is confusing. You may wish to file an issue with HyperKitty
about this at <https://gitlab.com/mailman/hyperkitty/issues>.


> The very bad news was when I tried to edit my options for this list.
> I got:
> https://mail.python.org/mm3/mailman3/accounts/list-options/tox-dev.python.org/
> Server Error (500)


Thanks very much for the report. I'll investigate and report back.

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

From mark at msapiro.net  Fri Nov  4 14:12:11 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 4 Nov 2016 11:12:11 -0700
Subject: [Mailman-Developers] Silly usability problem in mailman3.
In-Reply-To: <201611041417.uA4EHORQ029829@theraft.openend.se>
References: <201611041417.uA4EHORQ029829@theraft.openend.se>
Message-ID: <abc793bb-d98d-c80e-9d61-18ee57918cfe@msapiro.net>

On 11/4/16 7:17 AM, Laura Creighton wrote:
> 
> Whatever algorithm is being used to determine if a list is inactive or
> not should be tweaked to understand that absolutely spanking-new
> mailing lists -- which mailman3 already knows how to recognise --
> are not considered inactive.


As I suggested elsewhere, please file an issue at
<https://gitlab.com/mailman/hyperkitty/issues>.

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

From mark at msapiro.net  Fri Nov  4 15:09:05 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 4 Nov 2016 12:09:05 -0700
Subject: [Mailman-Developers] Problems signing up for the new tox-dev
 mailing list.
In-Reply-To: <e9156f6f-0b62-0edd-954f-84f4e49107b7@msapiro.net>
References: <20161104095316.GY21830@merlinux.eu>
 <201611041337.uA4DbJ6X023840@theraft.openend.se>
 <e9156f6f-0b62-0edd-954f-84f4e49107b7@msapiro.net>
Message-ID: <a6d808d9-6325-bf05-500b-d0f3368f5c84@msapiro.net>

On 11/4/16 10:44 AM, Mark Sapiro wrote:
> 
> On 11/4/16 6:37 AM, Laura Creighton wrote:
> 
>> The very bad news was when I tried to edit my options for this list.
>> I got:
>> https://mail.python.org/mm3/mailman3/accounts/list-options/tox-dev.python.org/
>> Server Error (500)
> 
> 
> Thanks very much for the report. I'll investigate and report back.


The error in the log is "Cannot convert parameters: delivery_status".

I am able to duplicate the error. The issue is when you first go to your
list settings at
<https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/members/options/lac at openend.se>,
they are unpopulated. At that point, you have the list's default
settings, but you have no personal settings.

Then if you try to "Save changes" on that page without selecting
something for each of the radio buttons, the values POSTed for each of
the settings which is unchecked are invalid.

I have reported this issue at
<https://gitlab.com/mailman/postorius/issues/163>.

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

From mark at msapiro.net  Sat Nov  5 12:06:37 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 5 Nov 2016 09:06:37 -0700
Subject: [Mailman-Developers] MM3 DMARC mitigations
In-Reply-To: <f6ad7bc0-c592-330a-bbe9-f0acf42d3b31@linuxfoundation.org>
References: <DC10615A-235A-4B48-9277-95C52399ADAC@linuxfoundation.org>
 <20161025180344.4fa62926@subdivisions.wooz.org>
 <22544.55786.669446.639325@turnbull.sk.tsukuba.ac.jp>
 <9E54396D-103B-4421-9D27-D95CC1425B75@linuxfoundation.org>
 <20161028150432.381ac46e@subdivisions.wooz.org>
 <158ceaf8-bfbc-3f8a-61aa-51eb46863621@msapiro.net>
 <756227e8-8051-712f-96e7-ba8c52dfe480@linuxfoundation.org>
 <57a762a0-da05-06eb-9b64-e2c64cc9cb69@msapiro.net>
 <f6ad7bc0-c592-330a-bbe9-f0acf42d3b31@linuxfoundation.org>
Message-ID: <3c86a416-257f-a399-c215-fc7868bf14d0@msapiro.net>

On 10/31/2016 03:08 PM, Eric Searcy wrote:
> 
> That reminds me.  I have a proposed idea for another nice-to-have, that
> I'm mentioning now in case it has any impact on the architecture you are
> describing.  Some email systems (e.g. Exchange) do not accept any
> inbound email crossing their edge that uses their own From domain.  It's
> like a tiny microcosm of DMARC but only for their domain, and there is
> no way for the outside world to know about their policy.  However, when
> a member of the community says they get all list messages *except those
> from their colleagues*, it's clear they have this kind of setup.  It
> would be great to have a customizable-by-sender-domain munge-or-wrap
> filter that let me add other domains to get the same treatment as
> domains that don't publish DMARC -- even if not needed for general
> receipt of their messages, so that emails to others at the same domain
> on the list can be received.  (This functionality doesn't exist in mm2
> either.)


Adding Mailman-Developers to the recipients.

As I noted in the original thread, this would not be difficult to add,
but it won't be in the initial implementation of DMARC mitigations for
MM 3 (see <https://gitlab.com/mailman/mailman/merge_requests/215> for
more on that).

However, I've just become aware that Microsoft has implemented another
"feature". So far, the info I have is this is limited to their "hosted
mail services", but it may well spread. What they are doing is looking
at incoming mail for signs of spoofing/phishing and if found, they place
a prominent notice

This sender failed our fraud detection checks and may not be who they
appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

in the message. The issue for us is that one of the tests is the To: and
From: addresses are the same. That means that any message To: a list
with DMARC mitigations applied will be sent From: the list and any
recipients using these Microsoft services will see that warning in the
list message[1].

How long will it be before this spreads to all Microsoft email services
<sigh>?


[1] I first became aware of this via the thread at
<http://lists.mailscanner.info/pipermail/mailscanner/2016-November/104001.html>.
There it was the poster who saw the warning in his copy of the list
message and mistakenly thought it was a rejection of his post to the
list. The reply at
<http://lists.mailscanner.info/pipermail/mailscanner/2016-November/104017.html>
has interesting info.

-- 
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-developers/attachments/20161105/ed82b615/attachment.sig>

From vesely at tana.it  Sat Nov  5 07:11:35 2016
From: vesely at tana.it (Alessandro Vesely)
Date: Sat, 5 Nov 2016 12:11:35 +0100
Subject: [Mailman-Developers] Camera-ready option to mitigate DMARC issues
Message-ID: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>

Dear all,
I'd like to probe the feasibility of this option.

The idea is to add a footer only in case it is not present, similar to what is 
done with subject_prefix.  By properly setting both of them, a sender can 
submit what can be called a camera-ready post.  Since no change applies, no 
DKIM signature breaks.  Hence, dmarc_moderation_action is not needed for such 
posts.  It is not even necessary to check author's domain policy.

I'm not familiar with Mailman administration, so I ask your opinion.  How long 
would it take to code this option?  How useful would it be?

Camera-ready posts would be created by hands, by cleverly configuring some 
email client, or by using purposely written add-ons.  They could also be done 
by MSAs who care about the damage they cause by publishing p=reject --the 
process can certainly be standardized and automated.

TIA for any reply, and thanks for a great product
Ale

From dandrews at visi.com  Sat Nov  5 12:29:13 2016
From: dandrews at visi.com (David Andrews)
Date: Sat, 05 Nov 2016 11:29:13 -0500
Subject: [Mailman-Developers] MM3 DMARC mitigations
In-Reply-To: <3c86a416-257f-a399-c215-fc7868bf14d0@msapiro.net>
References: <DC10615A-235A-4B48-9277-95C52399ADAC@linuxfoundation.org>
 <20161025180344.4fa62926@subdivisions.wooz.org>
 <22544.55786.669446.639325@turnbull.sk.tsukuba.ac.jp>
 <9E54396D-103B-4421-9D27-D95CC1425B75@linuxfoundation.org>
 <20161028150432.381ac46e@subdivisions.wooz.org>
 <158ceaf8-bfbc-3f8a-61aa-51eb46863621@msapiro.net>
 <756227e8-8051-712f-96e7-ba8c52dfe480@linuxfoundation.org>
 <57a762a0-da05-06eb-9b64-e2c64cc9cb69@msapiro.net>
 <f6ad7bc0-c592-330a-bbe9-f0acf42d3b31@linuxfoundation.org>
 <3c86a416-257f-a399-c215-fc7868bf14d0@msapiro.net>
Message-ID: <auto-000069358325@mailfront2.g2host.com>

At 11:06 AM 11/5/2016, Mark Sapiro wrote:

>However, I've just become aware that Microsoft has implemented another
>"feature". So far, the info I have is this is limited to their "hosted
>mail services", but it may well spread. What they are doing is looking
>at incoming mail for signs of spoofing/phishing and if found, they place
>a prominent notice
>
>This sender failed our fraud detection checks and may not be who they
>appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>
>
>in the message. The issue for us is that one of the tests is the To: and
>From: addresses are the same. That means that any message To: a list
>with DMARC mitigations applied will be sent From: the list and any
>recipients using these Microsoft services will see that warning in the
>list message[1].
>
>How long will it be before this spreads to all Microsoft email services
><sigh>?

This message has started appearing on messages on a list I subscribe 
to at work, the state of MN, and they use hosted office 365 etc., and 
the messages are almost always from legitimate senders, so going to 
be a problem.

Dave



From mark at msapiro.net  Sat Nov  5 14:51:13 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 5 Nov 2016 11:51:13 -0700
Subject: [Mailman-Developers] Camera-ready option to mitigate DMARC
 issues
In-Reply-To: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>
References: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>
Message-ID: <3332beb9-4c40-9ec2-ea92-09e22aa10686@msapiro.net>

On 11/05/2016 04:11 AM, Alessandro Vesely wrote:
> 
> The idea is to add a footer only in case it is not present, similar to
> what is done with subject_prefix.  By properly setting both of them, a
> sender can submit what can be called a camera-ready post.  Since no
> change applies, no DKIM signature breaks.  Hence,
> dmarc_moderation_action is not needed for such posts.  It is not even
> necessary to check author's domain policy.


Mailman could conceivably keep track of whether it has changed any
headers or anything in the body of the post, but it's more complicated
than that. The first big problem is the Munge From or Wrap Message
transformations are applied before any msg_header or msg_footer is added
(or maybe added).

I.e. in both MM 2.1 and MM 3, the DMARC mitigations are applied in the
incoming handler pipeline before the message is queued for delivery
processing. Various decorations such as adding msg_header and msg_footer
and modifying To: depend on "personalization" and have to be done by
delivery processing on a per-recipient basis. In fact, the "camera
ready" notion can't apply to any post that is going to be personalized
in any way. This in itself would limit the usefulness.

It would be more feasible to do this by the poster adding a
"X-Camera-Ready:" header to the post saying don't transform my message,
but this is unacceptable as it would bypass content filtering,
personalization and various other things.


> I'm not familiar with Mailman administration, so I ask your opinion. 
> How long would it take to code this option?


How many angels can dance on the head of a pin?


> How useful would it be?


In my opinion, certainly not enough to justify the effort in trying and
the inevitable bug reports that would follow from all the edge cases.


> Camera-ready posts would be created by hands, by cleverly configuring
> some email client, or by using purposely written add-ons.  They could
> also be done by MSAs who care about the damage they cause by publishing
> p=reject --the process can certainly be standardized and automated.


How does the sender's automated process even know what msg_header and
msg_footer will be added by the list?

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

From turnbull.stephen.fw at u.tsukuba.ac.jp  Sun Nov  6 03:17:53 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Sun, 6 Nov 2016 17:17:53 +0900
Subject: [Mailman-Developers] Camera-ready option to mitigate DMARC issues
In-Reply-To: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>
References: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>
Message-ID: <22558.59185.457340.323362@turnbull.sk.tsukuba.ac.jp>

Alessandro Vesely writes:

 > The idea is to add a footer only in case it is not present,

Aside from the technical difficulties that Mark describes, this
suffers from a really big defect: for this to be actually useful,
you'd need near-100% participation (Authenticated Received Chain has
the same problem).  Once you've got that, no new Mailman code is
needed: just don't use a footer in the first place!  And it requires
effort on the part of providers we already know are irresponsible and
inconsiderate because they provide personal mail services disrupted by
"p=reject", or on the part of users at those sites, many of whom blame
mailing lists, not their irresponsible and/or inexpert providers, for
difficulties with posting.

If you don't get near 100%, then you need to provide the workarounds
for all users and originating sites that don't participate anyway, to
all of your subscribers -- and "nonparticipants" will include the
posters who are most likely to blame the lists for any delivery
problems, and get upset about "different treatment" (eg, From-
munging).


From turnbull.stephen.fw at u.tsukuba.ac.jp  Sun Nov  6 03:39:10 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Sun, 6 Nov 2016 17:39:10 +0900
Subject: [Mailman-Developers] MM3 DMARC mitigations
In-Reply-To: <auto-000069358325@mailfront2.g2host.com>
References: <DC10615A-235A-4B48-9277-95C52399ADAC@linuxfoundation.org>
 <20161025180344.4fa62926@subdivisions.wooz.org>
 <22544.55786.669446.639325@turnbull.sk.tsukuba.ac.jp>
 <9E54396D-103B-4421-9D27-D95CC1425B75@linuxfoundation.org>
 <20161028150432.381ac46e@subdivisions.wooz.org>
 <158ceaf8-bfbc-3f8a-61aa-51eb46863621@msapiro.net>
 <756227e8-8051-712f-96e7-ba8c52dfe480@linuxfoundation.org>
 <57a762a0-da05-06eb-9b64-e2c64cc9cb69@msapiro.net>
 <f6ad7bc0-c592-330a-bbe9-f0acf42d3b31@linuxfoundation.org>
 <3c86a416-257f-a399-c215-fc7868bf14d0@msapiro.net>
 <auto-000069358325@mailfront2.g2host.com>
Message-ID: <22558.60462.763306.311891@turnbull.sk.tsukuba.ac.jp>

Removing known MM-DEV subscribers, the CC list is getting long.

David Andrews writes:
 > At 11:06 AM 11/5/2016, Mark Sapiro wrote:
 > 
 > >However, I've just become aware that Microsoft has implemented another
 > >"feature". [...] one of the tests is the To: and
 > >From: addresses are the same. That means that any message To: a list
 > >with DMARC mitigations applied will be sent From: the list and any
 > >recipients using these Microsoft services will see that warning in the
 > >list message[1].

The fact is, every time we work around the actual semantics of
"p=reject" (described in the block quote below), the spammers can hide
behind our usage, I expect they will, and those tricks will be given
spam (or worse, phish) points.

Maybe it's time to default to rejecting posts from p=reject domains,
with the explanatory message:

    Your domain publishes a "p=reject" DMARC policy, which is a
    statement to recipients that they allow you to send only
    authenticated direct mail.  This is a mailing list which re-sends
    your mail after processing, and therefore you are not allowed to
    post according to your email provider's policy.  Please repost
    from an address which allows you to post to full service mailing
    lists.

    Note: A few large providers claim to permit posting to mailing
    lists, but publish "p=reject" anyway.  They privately acknowledge
    doing so to protect users from spammers and phishers who have
    stolen millions of address books and other private information of
    users from them.

Of course this could be conditional on the presence of a header OR a
footer OR Subject-munging in the list config.  I'm semi-serious, but
more likely is a "pass-through" tactic: ie, no headers, footers, or
Subject-munging on posts from "p=reject" sites.  The point is that
spammers can omit those things, but they can't emulate the valid
authentication on posts from DMARC sites.  Unfortunately, some lists
do need to add disclaimers and the like, so can't use the pass-through
approach.

The only tactics that actually work in the sense that spammers can't
use them are (1) ARC (but that requires cooperation from receiving
hosts that is unlikely[1]), (2) "pass-through" operation, and (3)
preemptive rejection/discard.

 > This message has started appearing on messages on a list I subscribe 
 > to at work, the state of MN, and they use hosted office 365 etc., and 
 > the messages are almost always from legitimate senders, so going to 
 > be a problem.

My condolences.

Footnotes: 
[1]  It needs to be *all* receiving hosts.  Some of them will
undoubtedly be sufficiently lacking in email expertise that they
delegate these decisions to Office 365 etc.


From vesely at tana.it  Sun Nov  6 12:39:19 2016
From: vesely at tana.it (Alessandro Vesely)
Date: Sun, 6 Nov 2016 18:39:19 +0100
Subject: [Mailman-Developers] Camera-ready option to mitigate DMARC
 issues
In-Reply-To: <3332beb9-4c40-9ec2-ea92-09e22aa10686@msapiro.net>
References: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>
 <3332beb9-4c40-9ec2-ea92-09e22aa10686@msapiro.net>
Message-ID: <10ffdef7-6dca-3b84-ec61-37a457bc32bf@tana.it>

On Sat 05/Nov/2016 19:51:13 +0100 Mark Sapiro wrote:
> On 11/05/2016 04:11 AM, Alessandro Vesely wrote:
>>
>> The idea is to add a footer only in case it is not present, similar to
>> what is done with subject_prefix.  By properly setting both of them, a
>> sender can submit what can be called a camera-ready post.  Since no
>> change applies, no DKIM signature breaks.  Hence,
>> dmarc_moderation_action is not needed for such posts.  It is not even
>> necessary to check author's domain policy.
>
> Mailman could conceivably keep track of whether it has changed any
> headers or anything in the body of the post, but it's more complicated
> than that. The first big problem is the Munge From or Wrap Message
> transformations are applied before any msg_header or msg_footer is added
> (or maybe added).

Is it possible to abort processing the in-memory msg and revert to the file? 
Doing so --after thorough checks-- would prevent breaking the signature by 
altering the order of recipient, switching MIME values from token to 
quoted-string or vice-versa, and similar changes that memory representation may 
unwittingly imply.

> I.e. in both MM 2.1 and MM 3, the DMARC mitigations are applied in the
> incoming handler pipeline before the message is queued for delivery
> processing.

All right, so we cannot save that lookup.

> Various decorations such as adding msg_header and msg_footer and modifying
> To: depend on "personalization" and have to be done by delivery processing
> on a per-recipient basis. In fact, the "camera ready" notion can't apply to
> any post that is going to be personalized in any way. This in itself would
> limit the usefulness.

Sure, personalization cannot be compatible with camera-ready.

> It would be more feasible to do this by the poster adding a
> "X-Camera-Ready:" header to the post saying don't transform my message,
> but this is unacceptable as it would bypass content filtering,
> personalization and various other things.

X-Camera-Ready: may be useful to automate at senders'.  For an author doing it 
by hands, having to set a header field is an added difficulty...

>> I'm not familiar with Mailman administration, so I ask your opinion.
>> How long would it take to code this option?
>
> How many angels can dance on the head of a pin?

Ah, not so many of them are still able to perform that, nowadays ;-)

>> Camera-ready posts would be created by hands, by cleverly configuring
>> some email client, or by using purposely written add-ons.  They could
>> also be done by MSAs who care about the damage they cause by publishing
>> p=reject --the process can certainly be standardized and automated.
>
> How does the sender's automated process even know what msg_header and
> msg_footer will be added by the list?

MTAs can learn List-Post addresses when they receive mail.  When they see one, 
they can, say, change the envelope recipient to an internal mailbox which 
processes the decoration (and maybe adds X-Camera-Ready:).  The decorating 
module could be carved out from Mailman, and complemented so as to let it 
download its parameters from well known locations or some such.

Ale

From vesely at tana.it  Sun Nov  6 12:58:56 2016
From: vesely at tana.it (Alessandro Vesely)
Date: Sun, 6 Nov 2016 18:58:56 +0100
Subject: [Mailman-Developers] Camera-ready option to mitigate DMARC
 issues
In-Reply-To: <22558.59185.457340.323362@turnbull.sk.tsukuba.ac.jp>
References: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>
 <22558.59185.457340.323362@turnbull.sk.tsukuba.ac.jp>
Message-ID: <3f786db2-ec1f-2057-5e4f-d60b9564d38d@tana.it>

On Sun 06/Nov/2016 09:17:53 +0100 Stephen J. Turnbull wrote:
> Alessandro Vesely writes:
>
>> The idea is to add a footer only in case it is not present,
>
> Aside from the technical difficulties that Mark describes, this
> suffers from a really big defect: for this to be actually useful,
> you'd need near-100% participation (Authenticated Received Chain has
> the same problem).

No, the difference is that ARC applies at the receiving side, so you need 100% 
compliance of list subscribers.  Camera-ready applies at the sending side, so 
the list can still apply any anti-DMARC workarounds if it fails.

> Once you've got that, no new Mailman code is needed: just don't use a footer
> in the first place!


> And it requires effort on the part of providers we already know are
> irresponsible and inconsiderate because they provide personal mail services
> disrupted by "p=reject", or on the part of users at those sites, many of
> whom blame mailing lists, not their irresponsible and/or inexpert providers,
> for difficulties with posting.

Yes, but then it would be less disgusting to punish users of intractable providers.

> If you don't get near 100%, then you need to provide the workarounds
> for all users and originating sites that don't participate anyway, to
> all of your subscribers -- and "nonparticipants" will include the
> posters who are most likely to blame the lists for any delivery
> problems, and get upset about "different treatment" (eg, From-
> munging).

Yes, that's already in place.  It is considered a somewhat dirty solution. 
Camera-ready is cleaner than anything I have heard till now.  Probably it is 
not workable, but I cannot understand why.  It works well in several publishing 
environments, typically journals, which distribute templates to authors.  Why 
can't it work for mailing lists?

Ale

From mark at msapiro.net  Sun Nov  6 13:48:06 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 6 Nov 2016 10:48:06 -0800
Subject: [Mailman-Developers] Camera-ready option to mitigate DMARC
 issues
In-Reply-To: <3f786db2-ec1f-2057-5e4f-d60b9564d38d@tana.it>
References: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>
 <22558.59185.457340.323362@turnbull.sk.tsukuba.ac.jp>
 <3f786db2-ec1f-2057-5e4f-d60b9564d38d@tana.it>
Message-ID: <91e9f82d-f946-811c-310f-98dc3c874359@msapiro.net>

On 11/06/2016 09:58 AM, Alessandro Vesely wrote:
> 
> Camera-ready is cleaner than anything I have heard till now. 
> Probably it is not workable, but I cannot understand why.  It works well
> in several publishing environments, typically journals, which distribute
> templates to authors.  Why can't it work for mailing lists?


Mailing lists are different. They are subject to attack from spammers
and others which is different from the environments you are looking at.

I don't think your suggestions are workable. If you were to submit an
actual implementation, we could evaluate it's specific feasibility, but
in the absence of that, I won't spend time looking for flaws in
something that doesn't exist.

Note that Mailman lists can already be configured to make no DKIM
signature breaking modifications to messages. Most lists are not
configured that way because the modifications, which go beyond the
simple addition of a footer or a subject prefix, are desired by the list.

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

From turnbull.stephen.fw at u.tsukuba.ac.jp  Sun Nov  6 14:24:22 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Mon, 7 Nov 2016 04:24:22 +0900
Subject: [Mailman-Developers] Camera-ready option to mitigate DMARC
 issues
In-Reply-To: <3f786db2-ec1f-2057-5e4f-d60b9564d38d@tana.it>
References: <c06afe40-2155-4bcc-4c63-87977781ba07@tana.it>
 <22558.59185.457340.323362@turnbull.sk.tsukuba.ac.jp>
 <3f786db2-ec1f-2057-5e4f-d60b9564d38d@tana.it>
Message-ID: <22559.33638.899540.275254@turnbull.sk.tsukuba.ac.jp>

Alessandro Vesely writes:

 > Camera-ready is cleaner than anything I have heard till now.

Clean, maybe, but Mark explained why the scheme is fragile even if you
can get participation.  The killer problem is personalization, but the
other problems are also intractable.  Serial numbers in the Subject is
a case where the variable content is not predictable by the author or
originating system.

 > Probably it is not workable, but I cannot understand why.  It works
 > well in several publishing environments, typically journals, which
 > distribute templates to authors.  Why can't it work for mailing
 > lists?

It can, it just depends on high participation rates to be useful.  As
I pointed out, if you can get that participation, you don't need any
changes to Mailman, you just don't add footers to the body or list
tags to the Subject.

So why don't you try the experiment on some of your lists and see how
much participation you get?

From barry at list.org  Mon Nov  7 21:05:39 2016
From: barry at list.org (Barry Warsaw)
Date: Mon, 7 Nov 2016 21:05:39 -0500
Subject: [Mailman-Developers] MM3 DMARC mitigations
In-Reply-To: <22558.60462.763306.311891@turnbull.sk.tsukuba.ac.jp>
References: <DC10615A-235A-4B48-9277-95C52399ADAC@linuxfoundation.org>
 <20161025180344.4fa62926@subdivisions.wooz.org>
 <22544.55786.669446.639325@turnbull.sk.tsukuba.ac.jp>
 <9E54396D-103B-4421-9D27-D95CC1425B75@linuxfoundation.org>
 <20161028150432.381ac46e@subdivisions.wooz.org>
 <158ceaf8-bfbc-3f8a-61aa-51eb46863621@msapiro.net>
 <756227e8-8051-712f-96e7-ba8c52dfe480@linuxfoundation.org>
 <57a762a0-da05-06eb-9b64-e2c64cc9cb69@msapiro.net>
 <f6ad7bc0-c592-330a-bbe9-f0acf42d3b31@linuxfoundation.org>
 <3c86a416-257f-a399-c215-fc7868bf14d0@msapiro.net>
 <auto-000069358325@mailfront2.g2host.com>
 <22558.60462.763306.311891@turnbull.sk.tsukuba.ac.jp>
Message-ID: <20161107210539.26afa359@subdivisions.wooz.org>

On Nov 06, 2016, at 05:39 PM, Stephen J. Turnbull wrote:

>Maybe it's time to default to rejecting posts from p=reject domains,
>with the explanatory message:
>
>    Your domain publishes a "p=reject" DMARC policy, which is a
>    statement to recipients that they allow you to send only
>    authenticated direct mail.  This is a mailing list which re-sends
>    your mail after processing, and therefore you are not allowed to
>    post according to your email provider's policy.  Please repost
>    from an address which allows you to post to full service mailing
>    lists.
>
>    Note: A few large providers claim to permit posting to mailing
>    lists, but publish "p=reject" anyway.  They privately acknowledge
>    doing so to protect users from spammers and phishers who have
>    stolen millions of address books and other private information of
>    users from them.

With some verbiage massaging perhaps, I am supportive of a "hammer" option
such as this.  Maybe we can't enable it by default, but I don't think it's
unreasonable for site/list admins to be able to be more proactive in their
rejection of such messages.  It will probably make no difference, but if we
can inform users as to the real culprits in this mess, they can either
complain to their ISPs or vote with their feet and find a new provider.  That
won't happen if they continue to blame the list software or site.

(If we're serious about this, we should likely have a locked down wiki page
with more detail, linked to from the default p=reject rejection message.)

Cheers,
-Barry

From mark at msapiro.net  Tue Nov  8 00:00:49 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 7 Nov 2016 21:00:49 -0800
Subject: [Mailman-Developers] MM3 DMARC mitigations
In-Reply-To: <20161107210539.26afa359@subdivisions.wooz.org>
References: <DC10615A-235A-4B48-9277-95C52399ADAC@linuxfoundation.org>
 <20161025180344.4fa62926@subdivisions.wooz.org>
 <22544.55786.669446.639325@turnbull.sk.tsukuba.ac.jp>
 <9E54396D-103B-4421-9D27-D95CC1425B75@linuxfoundation.org>
 <20161028150432.381ac46e@subdivisions.wooz.org>
 <158ceaf8-bfbc-3f8a-61aa-51eb46863621@msapiro.net>
 <756227e8-8051-712f-96e7-ba8c52dfe480@linuxfoundation.org>
 <57a762a0-da05-06eb-9b64-e2c64cc9cb69@msapiro.net>
 <f6ad7bc0-c592-330a-bbe9-f0acf42d3b31@linuxfoundation.org>
 <3c86a416-257f-a399-c215-fc7868bf14d0@msapiro.net>
 <auto-000069358325@mailfront2.g2host.com>
 <22558.60462.763306.311891@turnbull.sk.tsukuba.ac.jp>
 <20161107210539.26afa359@subdivisions.wooz.org>
Message-ID: <17eb27d5-15f9-fdfe-192c-fb0d72ff4937@msapiro.net>

On 11/07/2016 06:05 PM, Barry Warsaw wrote:
> 
> With some verbiage massaging perhaps, I am supportive of a "hammer" option
> such as this.  Maybe we can't enable it by default, but I don't think it's
> unreasonable for site/list admins to be able to be more proactive in their
> rejection of such messages.  It will probably make no difference, but if we
> can inform users as to the real culprits in this mess, they can either
> complain to their ISPs or vote with their feet and find a new provider.  That
> won't happen if they continue to blame the list software or site.


It's in MM 2.1 and it's in my dmarc branch MR
<https://gitlab.com/mailman/mailman/merge_requests/215>. The list has
dmarc_moderation_action with possible values none, munge_from,
wrap_message, reject or discard.

The default reason is not what Steve proposes. The default is in
mailman/rules/dmarc.py per

        reason = (mlist.dmarc_moderation_notice or
                  _('You are not allowed to post to this mailing '
                    'list From: a domain which publishes a DMARC '
                    'policy of reject or quarantine, and your message'
                    ' has been automatically rejected.  If you think '
                    'that your messages are being rejected in error, '
                    'contact the mailing list owner at ${listowner}.'))
        msgdata['moderation_reasons'] = [wrap(reason)]

As it is, the list can supply its own reason. The default could of
course be changed or made a configuration setting.

-- 
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  Tue Nov  8 00:16:05 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Tue, 8 Nov 2016 14:16:05 +0900
Subject: [Mailman-Developers] MM3 DMARC mitigations
In-Reply-To: <20161107210539.26afa359@subdivisions.wooz.org>
References: <DC10615A-235A-4B48-9277-95C52399ADAC@linuxfoundation.org>
 <20161025180344.4fa62926@subdivisions.wooz.org>
 <22544.55786.669446.639325@turnbull.sk.tsukuba.ac.jp>
 <9E54396D-103B-4421-9D27-D95CC1425B75@linuxfoundation.org>
 <20161028150432.381ac46e@subdivisions.wooz.org>
 <158ceaf8-bfbc-3f8a-61aa-51eb46863621@msapiro.net>
 <756227e8-8051-712f-96e7-ba8c52dfe480@linuxfoundation.org>
 <57a762a0-da05-06eb-9b64-e2c64cc9cb69@msapiro.net>
 <f6ad7bc0-c592-330a-bbe9-f0acf42d3b31@linuxfoundation.org>
 <3c86a416-257f-a399-c215-fc7868bf14d0@msapiro.net>
 <auto-000069358325@mailfront2.g2host.com>
 <22558.60462.763306.311891@turnbull.sk.tsukuba.ac.jp>
 <20161107210539.26afa359@subdivisions.wooz.org>
Message-ID: <22561.24469.682087.815724@turnbull.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > It will probably make no difference, but if we can inform users as
 > to the real culprits in this mess, they can either complain to
 > their ISPs or vote with their feet and find a new provider.  That
 > won't happen if they continue to blame the list software or site.

Well, I'll be happy to create the patch just to make the statement,
but honestly, I doubt we can convince anybody who actually believes
that list software created this mess to believe otherwise.  Unlike
telephone numbers, email addresses are not portable, so the incentives
against moving (which weaken the effectiveness of complaints) are
really strong, too.

 > (If we're serious about this, we should likely have a locked down
 > wiki page with more detail, linked to from the default p=reject
 > rejection message.)

Agreed.  Maybe I'll sprint on this at PyConCA. :-)

The sad thing is the DMARC protocol is actually really well-designed
for two purposes: allowing mailbox providers to get information about
mal-use of their domain names, and allowing organizations that conduct
business transactions via direct email to prevent spoofing.  It
doesn't address the problem of spoofed indirect mail (like mailing
list posts) because that's just a really hard problem because there's
no known good way to inform users about the trustworthiness of
individual messages.  (I'd like to blame it on the popular MUAs, but
I'm afraid the problem is deeper than that.)

Steve


From turnbull.stephen.fw at u.tsukuba.ac.jp  Mon Nov 14 13:37:06 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Tue, 15 Nov 2016 03:37:06 +0900
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
Message-ID: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>

Just to let you know.

Also, I've done a little tracker curation (specifically HyperKitty),
mostly tagging -- probably you should assume nothing important is
happening if you get notices.

Steve


From turnbull.stephen.fw at u.tsukuba.ac.jp  Mon Nov 14 14:26:23 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Tue, 15 Nov 2016 04:26:23 +0900
Subject: [Mailman-Developers] Adding gitlab group members and permissions
Message-ID: <22570.4063.141982.753520@turnbull.sk.tsukuba.ac.jp>

I added a new group member (mdupuis) with Reporter permission, and
upgraded existing members (adammendoza, aniketshukla, khushbuparakh)
to "Reporter".  Dunno what policy is but Reporter looks pretty
harmless, and Guest is pretty crippled (can't even set tags).

WDOT?

Steve

From mark at msapiro.net  Mon Nov 14 14:48:01 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 14 Nov 2016 11:48:01 -0800
Subject: [Mailman-Developers] Adding gitlab group members and permissions
In-Reply-To: <22570.4063.141982.753520@turnbull.sk.tsukuba.ac.jp>
References: <22570.4063.141982.753520@turnbull.sk.tsukuba.ac.jp>
Message-ID: <a9d3b3f1-6dce-675f-bbd0-16aef7679dc3@msapiro.net>

On 11/14/2016 11:26 AM, Stephen J. Turnbull wrote:
> I added a new group member (mdupuis) with Reporter permission, and
> upgraded existing members (adammendoza, aniketshukla, khushbuparakh)
> to "Reporter".  Dunno what policy is but Reporter looks pretty
> harmless, and Guest is pretty crippled (can't even set tags).
> 
> WDOT?


I think that's fine and I think adding other interested people as
"Reporter" is also fine, but I just looked at the list, and it seems
that Simon (@thelinuxguy) went missing so I added him back. I hope this
is OK.

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

From barry at list.org  Mon Nov 14 15:03:31 2016
From: barry at list.org (Barry Warsaw)
Date: Mon, 14 Nov 2016 15:03:31 -0500
Subject: [Mailman-Developers] Adding gitlab group members and permissions
In-Reply-To: <22570.4063.141982.753520@turnbull.sk.tsukuba.ac.jp>
References: <22570.4063.141982.753520@turnbull.sk.tsukuba.ac.jp>
Message-ID: <20161114150331.14ea32ea@subdivisions.wooz.org>

On Nov 15, 2016, at 04:26 AM, Stephen J. Turnbull wrote:

>I added a new group member (mdupuis) with Reporter permission, and
>upgraded existing members (adammendoza, aniketshukla, khushbuparakh)
>to "Reporter".  Dunno what policy is but Reporter looks pretty
>harmless, and Guest is pretty crippled (can't even set tags).

Thanks Steve, great idea.  Thanks Mark for adding back Simon.

Cheers,
-Barry

From barry at list.org  Mon Nov 14 15:17:41 2016
From: barry at list.org (Barry Warsaw)
Date: Mon, 14 Nov 2016 15:17:41 -0500
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
In-Reply-To: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
Message-ID: <20161114151741.3ad7701c@subdivisions.wooz.org>

On Nov 15, 2016, at 03:37 AM, Stephen J. Turnbull wrote:

>Also, I've done a little tracker curation (specifically HyperKitty),
>mostly tagging -- probably you should assume nothing important is
>happening if you get notices.

Thanks Steve!

I guess I should use this opportunity to say that I'd like to get Mailman 3.1
out in December.  I'm going to be pretty brutal about triaging Core bugs and
merge requests to get it down to a reasonable number, and I'd like to try to
do a beta release in a couple of weeks.

How do the other subprojects look for a December release?

This is a good link to track the project-wide milestone:

https://gitlab.com/groups/mailman/milestones/31?title=3.1

One problem is that it doesn't include HK, so we need to figure that out.  And
we need to figure out whether we want to continue to support the bundler or
use some other container-based release mechanism (I am going to continue to
play with building a Snap for the bits and pieces).

Another reason to do the 3.1 release: I want to retire the 3.0.x branch.

Cheers,
-Barry

From turnbull.stephen.fw at u.tsukuba.ac.jp  Mon Nov 14 16:09:20 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Tue, 15 Nov 2016 06:09:20 +0900
Subject: [Mailman-Developers] Adding gitlab group members and permissions
Message-ID: <22570.10240.730219.433659@turnbull.sk.tsukuba.ac.jp>

I added a new group member (mdupuis) with Reporter permission, and
upgraded existing members (adammendoza, aniketshukla, khushbuparakh)
to "Reporter".  Dunno what policy is but Reporter looks pretty
harmless, and Guest is pretty crippled (can't even set tags).

WDOT?

Steve

From simon.hanna at serve-me.info  Mon Nov 14 18:17:36 2016
From: simon.hanna at serve-me.info (Simon Hanna)
Date: Tue, 15 Nov 2016 00:17:36 +0100
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
In-Reply-To: <20161114151741.3ad7701c@subdivisions.wooz.org>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
 <20161114151741.3ad7701c@subdivisions.wooz.org>
Message-ID: <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>

On 11/14/2016 09:17 PM, Barry Warsaw wrote:
> How do the other subprojects look for a December release?
>
> This is a good link to track the project-wide milestone:
>
> https://gitlab.com/groups/mailman/milestones/31?title=3.1
I went ahead and tagged a couple of issues from Postorius and mailmanclient
with the milestone.
They are all user facing and I think would result in a lot of new issues,
if they are not addresses before.
> One problem is that it doesn't include HK, so we need to figure that out.
I guess you need to somehow create a milestone in hyperkitty itself.
I don't have the right to do so. I'm not 100% sure,
but I guess maxking created those for postorius and hyperkitty
> And we need to figure out whether we want to continue to support the bundler or
> use some other container-based release mechanism (I am going to continue to
> play with building a Snap for the bits and pieces).
Speaking for myself here:
I'm not using it and I guess I won't be in the future.
I'm using a git repository for my configuration that can be found here
https://gitlab.com/thelinuxguy/mailman-suite
along with a local branch that holds all my deployment specific changes.
I still don't really understand what bundler does, and I always have to look
through all the directories to try and find the file that I want to edit.

From barry at list.org  Mon Nov 14 18:52:38 2016
From: barry at list.org (Barry Warsaw)
Date: Mon, 14 Nov 2016 18:52:38 -0500
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
In-Reply-To: <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
 <20161114151741.3ad7701c@subdivisions.wooz.org>
 <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>
Message-ID: <20161114185238.2fddf33b@subdivisions.wooz.org>

On Nov 15, 2016, at 12:17 AM, Simon Hanna wrote:

>I went ahead and tagged a couple of issues from Postorius and mailmanclient
>with the milestone.  They are all user facing and I think would result in a
>lot of new issues, if they are not addresses before.

Thanks Simon.

>I guess you need to somehow create a milestone in hyperkitty itself.

Yep.  I just created the 3.1 milestone.  Can you see if you can assign issues
to that milestone?

>I'm not using it and I guess I won't be in the future.  I'm using a git
>repository for my configuration that can be found here
>https://gitlab.com/thelinuxguy/mailman-suite along with a local branch that
>holds all my deployment specific changes.  I still don't really understand
>what bundler does, and I always have to look through all the directories to
>try and find the file that I want to edit.

I'm not sure how useful bundler is either.  I don't think Mark used it when he
deployed MM3 on python.org.  Container-based solutions seem like the better
option, and I think we could support multiple container formats without much
trouble (although, it would be good to have some CI around them).

Cheers,
-Barry

From raj.abhilash1 at gmail.com  Mon Nov 14 19:19:17 2016
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Mon, 14 Nov 2016 16:19:17 -0800
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
In-Reply-To: <20161114185238.2fddf33b@subdivisions.wooz.org>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
 <20161114151741.3ad7701c@subdivisions.wooz.org>
 <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>
 <20161114185238.2fddf33b@subdivisions.wooz.org>
Message-ID: <CAF2AkXkmC_ziX77Fxd+byO1YtgUFQuYXaPh+Q9Vu=jsdgu0XYw@mail.gmail.com>

On 14 November 2016 at 15:52, Barry Warsaw <barry at list.org> wrote:

> On Nov 15, 2016, at 12:17 AM, Simon Hanna wrote:
>
> >I went ahead and tagged a couple of issues from Postorius and
> mailmanclient
> >with the milestone.  They are all user facing and I think would result in
> a
> >lot of new issues, if they are not addresses before.
>
> Thanks Simon.
>
> >I guess you need to somehow create a milestone in hyperkitty itself.
>
> Yep.  I just created the 3.1 milestone.  Can you see if you can assign
> issues
> to that milestone?
>
> >I'm not using it and I guess I won't be in the future.  I'm using a git
> >repository for my configuration that can be found here
> >https://gitlab.com/thelinuxguy/mailman-suite along with a local branch
> that
> >holds all my deployment specific changes.  I still don't really understand
> >what bundler does, and I always have to look through all the directories
> to
> >try and find the file that I want to edit.
>
> I'm not sure how useful bundler is either.  I don't think Mark used it
> when he
> deployed MM3 on python.org.  Container-based solutions seem like the
> better
> option, and I think we could support multiple container formats without
> much
> trouble (although, it would be good to have some CI around them).
>
>
Containers does makes things very easy but I am not sure how much
comfortable people are with containers running in production for long
periods of time, unattended. Dockers seems to be still tinkering with the
public facing APIs and breaking compatibilities across versions of clients
and server (which itself is another issue due to security).  Other
solutions like rkt and others are still not very mature and would mean a
lot of deployment errors and bugs. However, we can have them as an *option*
for deployments along with os specific packages.

I'd be willing to help with build automation and maintain containers for
all the sub projects. Although, I won't be able to spare a lot of time in
next 15 days as I have a paper deadline coming in very soon.


> Cheers,
> -Barry
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> https://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/
> mailman-developers%40python.org/
> Unsubscribe: https://mail.python.org/mailman/options/mailman-
> developers/raj.abhilash1%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>



-- 
thanks,
Abhilash Raj

From mark at msapiro.net  Mon Nov 14 21:44:55 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 14 Nov 2016 18:44:55 -0800
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
In-Reply-To: <20161114185238.2fddf33b@subdivisions.wooz.org>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
 <20161114151741.3ad7701c@subdivisions.wooz.org>
 <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>
 <20161114185238.2fddf33b@subdivisions.wooz.org>
Message-ID: <fee95261-6f33-ac13-c2e1-41a2c5ed6e8c@msapiro.net>

On 11/14/2016 03:52 PM, Barry Warsaw wrote:
> 
> I'm not sure how useful bundler is either.  I don't think Mark used it when he
> deployed MM3 on python.org.


Actually I did, but at this point I wouldn't use it for a fresh install.
It was useful for me when I didn't understand how all the pieces fit
together, and I still use the mailman-post-update script that it creates
to run several Django commands that may be needed following updates to
HyperKitty and Postorius.

It would need work. It doesn't know to install django-mailman3 nor the
changes in Django settings for that and Allauth.

-- 
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  Tue Nov 15 09:12:56 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Tue, 15 Nov 2016 23:12:56 +0900
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
In-Reply-To: <fee95261-6f33-ac13-c2e1-41a2c5ed6e8c@msapiro.net>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
 <20161114151741.3ad7701c@subdivisions.wooz.org>
 <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>
 <20161114185238.2fddf33b@subdivisions.wooz.org>
 <fee95261-6f33-ac13-c2e1-41a2c5ed6e8c@msapiro.net>
Message-ID: <22571.6120.514605.156444@turnbull.sk.tsukuba.ac.jp>

Mark Sapiro writes:
 > On 11/14/2016 03:52 PM, Barry Warsaw wrote:

 > > I'm not sure how useful bundler is either.

It was a good idea at the time, but IMO it will be way too much work
to keep up to date as is.  If we must provide a bundle, I think we
should use something like Simon's script (AIUI) to create a fully-
provisioned tree from git, probably in (a) venv(s), and make a source
tarball from that, venvs and all.  Something like a top-level setup.py
to install it all in $prefix.

Folks who don't want that (distros, seasoned admins) can probably
handle git.  Probably... ;-)  And following readthedocs for config.

Steve



From barry at list.org  Tue Nov 15 10:01:06 2016
From: barry at list.org (Barry Warsaw)
Date: Tue, 15 Nov 2016 10:01:06 -0500
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
In-Reply-To: <22571.6120.514605.156444@turnbull.sk.tsukuba.ac.jp>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
 <20161114151741.3ad7701c@subdivisions.wooz.org>
 <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>
 <20161114185238.2fddf33b@subdivisions.wooz.org>
 <fee95261-6f33-ac13-c2e1-41a2c5ed6e8c@msapiro.net>
 <22571.6120.514605.156444@turnbull.sk.tsukuba.ac.jp>
Message-ID: <20161115100106.508970ec@subdivisions.wooz.org>

On Nov 15, 2016, at 11:12 PM, Stephen J. Turnbull wrote:

>It was a good idea at the time, but IMO it will be way too much work
>to keep up to date as is.  If we must provide a bundle, I think we
>should use something like Simon's script (AIUI) to create a fully-
>provisioned tree from git, probably in (a) venv(s), and make a source
>tarball from that, venvs and all.  Something like a top-level setup.py
>to install it all in $prefix.
>
>Folks who don't want that (distros, seasoned admins) can probably
>handle git.  Probably... ;-)  And following readthedocs for config.

I think I missed a reference to Simon's script, but I'd be interested in that
approach too.  At this point it sounds like we shouldn't fixate on a single
deployment mechanism; we can provide some official containers, help distro
packagers, and above all, have really good documentation.

Cheers,
-Barry

From simon.hanna at serve-me.info  Tue Nov 15 10:45:07 2016
From: simon.hanna at serve-me.info (Simon Hanna)
Date: Tue, 15 Nov 2016 16:45:07 +0100
Subject: [Mailman-Developers] Mailman Sprint happening NOW at PyCon 2016
 Canada
In-Reply-To: <20161115100106.508970ec@subdivisions.wooz.org>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
 <20161114151741.3ad7701c@subdivisions.wooz.org>
 <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>
 <20161114185238.2fddf33b@subdivisions.wooz.org>
 <fee95261-6f33-ac13-c2e1-41a2c5ed6e8c@msapiro.net>
 <22571.6120.514605.156444@turnbull.sk.tsukuba.ac.jp>
 <20161115100106.508970ec@subdivisions.wooz.org>
Message-ID: <984ba4ea-eaba-b0df-c4dd-5f4e84fc1e34@serve-me.info>



On 11/15/2016 04:01 PM, Barry Warsaw wrote:
> On Nov 15, 2016, at 11:12 PM, Stephen J. Turnbull wrote:
>
>> It was a good idea at the time, but IMO it will be way too much work
>> to keep up to date as is.  If we must provide a bundle, I think we
>> should use something like Simon's script (AIUI) to create a fully-
>> provisioned tree from git, probably in (a) venv(s), and make a source
>> tarball from that, venvs and all.  Something like a top-level setup.py
>> to install it all in $prefix.
>>
>> Folks who don't want that (distros, seasoned admins) can probably
>> handle git.  Probably... ;-)  And following readthedocs for config.
> I think I missed a reference to Simon's script, but I'd be interested in that
> approach too.  At this point it sounds like we shouldn't fixate on a single
> deployment mechanism; we can provide some official containers, help distro
> packagers, and above all, have really good documentation.
https://gitlab.com/thelinuxguy/mailman-suite/

It's not really a script. It's a django project configuration (Which
you'll need to run postorius/hyperkitty)
But it's built so that you can easily choose which components you want
to actually use.
However you may want to deploy Mailman, you'll have to use such a structure.
It's pretty much barebones, with the added complexity resulting from
allowing
you to choose to run only one of postorius or hyperkitty..
And I tried to write up everything important in the readme...

It doesn't actually install anything on its own, but instructs on the
different options available...
It also includes nginx and uwsgi config files since I'm using them for
deployment

It should work as is for the master branches, but my setups are a little
behind right now...

From best.sum at gmail.com  Tue Nov 15 16:17:58 2016
From: best.sum at gmail.com (Leon)
Date: Tue, 15 Nov 2016 16:17:58 -0500
Subject: [Mailman-Developers] Attachment in mail
Message-ID: <CAPDq0P0hT7EocLpXPaXaGx0PwUOmX_zeaWxyR=hhcyJhFQijMA@mail.gmail.com>

Hi developers. I was wondering if mailman can block attachments in mails.
Mails sent out by mailman may have various attachments eg. logo in mail
template. I know mailman can block mails with attachments, but that is not
what we want. We hope to send out mails without attachments.

-- 
Best wishes,
Leon

From mark at msapiro.net  Tue Nov 15 22:55:20 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 15 Nov 2016 19:55:20 -0800
Subject: [Mailman-Developers] Attachment in mail
In-Reply-To: <CAPDq0P0hT7EocLpXPaXaGx0PwUOmX_zeaWxyR=hhcyJhFQijMA@mail.gmail.com>
References: <CAPDq0P0hT7EocLpXPaXaGx0PwUOmX_zeaWxyR=hhcyJhFQijMA@mail.gmail.com>
Message-ID: <fa07ee8e-00bd-4812-98d5-13c1ffa1cc79@msapiro.net>

On 11/15/2016 01:17 PM, Leon wrote:
> Hi developers. I was wondering if mailman can block attachments in mails.
> Mails sent out by mailman may have various attachments eg. logo in mail
> template. I know mailman can block mails with attachments, but that is not
> what we want. We hope to send out mails without attachments.


This post really belongs on Mailman-users
<https://mail.python.org/mailman/listinfo/mailman-users>. Please address
any follow-ups to that list.

Check out the Content filtering section in the web list admin UI. If you
have further questions about this, please join the Mailman-users list at
<https://mail.python.org/mailman/listinfo/mailman-users> and post them
there.

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

From mark at msapiro.net  Tue Nov 15 23:05:18 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 15 Nov 2016 20:05:18 -0800
Subject: [Mailman-Developers] Attachment in mail
In-Reply-To: <fa07ee8e-00bd-4812-98d5-13c1ffa1cc79@msapiro.net>
References: <CAPDq0P0hT7EocLpXPaXaGx0PwUOmX_zeaWxyR=hhcyJhFQijMA@mail.gmail.com>
 <fa07ee8e-00bd-4812-98d5-13c1ffa1cc79@msapiro.net>
Message-ID: <ffe23609-f8f6-64e2-0810-b5fb7b0d3226@msapiro.net>

On 11/15/2016 07:55 PM, Mark Sapiro wrote:
> On 11/15/2016 01:17 PM, Leon wrote:
>> Hi developers. I was wondering if mailman can block attachments in mails.
>> Mails sent out by mailman may have various attachments eg. logo in mail
>> template. I know mailman can block mails with attachments, but that is not
>> what we want. We hope to send out mails without attachments.
> 
> 
> This post really belongs on Mailman-users
> <https://mail.python.org/mailman/listinfo/mailman-users>. Please address
> any follow-ups to that list.
> 
> Check out the Content filtering section in the web list admin UI. If you
> have further questions about this, please join the Mailman-users list at
> <https://mail.python.org/mailman/listinfo/mailman-users> and post them
> there.
> 


-- 
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 Nov 16 21:40:42 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Thu, 17 Nov 2016 11:40:42 +0900
Subject: [Mailman-Developers] Mailman Sprint was fun at PyCon 2016 Canada!
In-Reply-To: <20161115100106.508970ec@subdivisions.wooz.org>
References: <22570.1106.891601.40504@turnbull.sk.tsukuba.ac.jp>
 <20161114151741.3ad7701c@subdivisions.wooz.org>
 <df6af4ae-877d-093b-c465-6f864bd15920@serve-me.info>
 <20161114185238.2fddf33b@subdivisions.wooz.org>
 <fee95261-6f33-ac13-c2e1-41a2c5ed6e8c@msapiro.net>
 <22571.6120.514605.156444@turnbull.sk.tsukuba.ac.jp>
 <20161115100106.508970ec@subdivisions.wooz.org>
Message-ID: <22573.6314.498949.47005@turnbull.sk.tsukuba.ac.jp>

Note updated Subject. ;-)

First time as a sprint leader, got really lucky with the sprinters.
ellmetha did a bunch of work (4 MRs!) without a word [of English ;-];
I talked with mdupuis quite a bit but didn't need to look at any of
his code at the time.  I don't know if the code is up to snuff, but
they picked useful things to work on!

Back in the conversation about distribution, Barry Warsaw writes:

 > I think I missed a reference to Simon's script, but I'd be
 > interested in that approach too.

I didn't understand it correctly myself, but Simon explains in a
parallel followup to your message.

What I have in mind is a script that

(1a) takes an argument which is a tuple of git refs, defaulting to our
    most recent release tags in the version for that release
(1b) takes an argument which is a non-existent directory to create
(1c) takes an argument which is the install prefix, default /usr/local
(2) checks for prereqs, if not satisified exits with error message
(3) creates the directory, cds there
(4) creates appropriate venvs
(5) clones 6 projects from gitlab
(6) checkouts each project at its configured ref, see (1)
(7) builds each project with appropriate venv
(8) installs to $prefix/usr/mailman and $prefix/var/mailman (ignoring
    distro policy if different!)
(9) prints a message pointing to instructions for configuring MTA and
    webserver

Maybe we can do better than (9) for Postscript, Exim (which is what I
use, so my hand is up for that), and Apache.

 > At this point it sounds like we shouldn't fixate on a single
 > deployment mechanism; we can provide some official containers, help
 > distro packagers, and above all, have really good documentation.

I don't know about containers, I'm old-fashioned (and the only useful
things my damn accountants will let me spend money on is travel and
computers, I'm swimming in hosts although not IPs or time to play with
containers).  How much work would that be?  Can we really expect our
mom-and-pop users to have containerized hosts available?  Do cPanel
hosts do containers?

But as you know "really good documentation" is (a) a lot of work and
(b) the product of reponsive users, especially beta testers.  We
shouldn't promise that yet.

Just-back-to-JP-from-PyConCA-and-a-successful-Mailman-sprint-ly y'rs,


From danil at smirnov.la  Fri Nov 18 09:08:35 2016
From: danil at smirnov.la (Danil Smirnov)
Date: Fri, 18 Nov 2016 16:08:35 +0200
Subject: [Mailman-Developers] Docker files for mailman
In-Reply-To: <3023406d-c6dd-75a5-b4ea-798c3dc3465b@serve-me.info>
References: <3023406d-c6dd-75a5-b4ea-798c3dc3465b@serve-me.info>
Message-ID: <CAMrrXbqOBYE23dzymmJjhhynJArqKWRSqHM2QoKFnGXTrhSSSA@mail.gmail.com>

Hi Simon!

I've just tried to build docker image from the Dockerfile mentioned on page
https://wiki.list.org/DEV/Mailman%203.0/Mailman%203.0%20Suite%20Dockerfile

The building has stopped with the following error

Installing mailman.
> The executable python3.4 (from --python=python3.4) does not exist
> /tmp/tmpez1ftK/run: 2: /tmp/tmpez1ftK/run:
> /mailman3/mailman-bundler/venv-3.4/bin/pip: not found
> While:
>   Installing mailman.
>
> An internal error occurred due to a bug in either zc.buildout or in a
> recipe being used:
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/zc/buildout/buildout.py",
> line 1995, in main
>     getattr(buildout, command)(args)
>   File "/usr/local/lib/python2.7/dist-packages/zc/buildout/buildout.py",
> line 666, in install
>     installed_files = self[part]._call(recipe.install)
>   File "/usr/local/lib/python2.7/dist-packages/zc/buildout/buildout.py",
> line 1410, in _call
>     return f()
>   File
> "/mailman3/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py",
> line 56, in install
>     self.execute()
>   File
> "/mailman3/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py",
> line 69, in execute
>     run_commands(cmds, self.shell)
>   File
> "/mailman3/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py",
> line 39, in run_commands
>     check_call('%s %s' % (shell, tmpfile), shell=True)
>   File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
>     raise CalledProcessError(retcode, cmd)
> CalledProcessError: Command 'sh /tmp/tmpez1ftK/run' returned non-zero exit
> status 127
> The command '/bin/sh -c buildout' returned a non-zero code: 1
>

Do you have any clue what happens?

Danil


On 17 July 2016 at 20:06, Simon Hanna <simon.hanna at serve-me.info> wrote:

> Hi,
>
> I started working on docker files for Mailman.
>
> I created three repositories:
> - https://github.com/simonsmiley/postorius-docker
>   Holds the files needed to create a postorius container
> - https://github.com/simonsmiley/mailman-docker
>   Holds the files needed to create a core container
> - https://github.com/simonsmiley/mailman-compose
>   Holds docker-compose files that greatly simply the process of running
>   the containers
>
> * The mailman repo currently lacks documentation
> * Currently no emails can be sent.
>   I still have to figure out what the best way is...
> * Hyperkitty will be added next
>   (together with a complete "bundler" install)
>
>
> I pushed two images to the docker hub. Their names are
> thelinuxguy/postorius and thelinuxguy/mailman
>
> I created two organizations
> mailman on docker hub and gnu-mailman on github
> https://github.com/gnu-mailman
> https://hub.docker.com/u/mailman/
>
> I know we shouldn't use github, but there is no way around
> github/bitbucket for automated builds on docker hub.
>
> I post here to inform you about the docker images and I also to ask if
> I'm allowed to keep these two organizations and move my images/repos
> there. I'll happily give push/owner access to additional people if
> requested.
>
> The repositories could be mirrored to the gitlab mailman group,
> sadly the process doesn't work the other way round just yet.
>
> In case this request gets denied, I'll just remove the organizations and
> let the images be "unofficial".
>
> cheers,
> Simon
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> https://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/
> mailman-developers%40python.org/
> Unsubscribe: https://mail.python.org/mailman/options/mailman-
> developers/danil%40smirnov.la
>
> Security Policy: http://wiki.list.org/x/QIA9
>

From danil at smirnov.la  Fri Nov 18 11:11:59 2016
From: danil at smirnov.la (Danil Smirnov)
Date: Fri, 18 Nov 2016 18:11:59 +0200
Subject: [Mailman-Developers] Docker files for mailman
In-Reply-To: <CAMrrXbqOBYE23dzymmJjhhynJArqKWRSqHM2QoKFnGXTrhSSSA@mail.gmail.com>
References: <3023406d-c6dd-75a5-b4ea-798c3dc3465b@serve-me.info>
 <CAMrrXbqOBYE23dzymmJjhhynJArqKWRSqHM2QoKFnGXTrhSSSA@mail.gmail.com>
Message-ID: <CAMrrXboT-LT9mb=U--9ZoJw8YDLnd2M=+xMu9dy4X-54c7rrhg@mail.gmail.com>

Okay I've found that image can be built if you base on Ubuntu Trusty distro
(line 6 of the Dockerfile: "FROM ubuntu:trusty") and add ruby-sass to the
set of packages to install (line 13: "apt-get install -y git python3-dev
python3-pip python-dev python-pip python-virtualenv ruby-sass").

I'm not sure whether I need to change it in the Wiki...

On 18 November 2016 at 16:08, Danil Smirnov <danil at smirnov.la> wrote:

> Hi Simon!
>
> I've just tried to build docker image from the Dockerfile mentioned on page
> https://wiki.list.org/DEV/Mailman%203.0/Mailman%203.0%20Suite%20Dockerfile
>
> The building has stopped with the following error
>
> Installing mailman.
>> The executable python3.4 (from --python=python3.4) does not exist
>> /tmp/tmpez1ftK/run: 2: /tmp/tmpez1ftK/run: /mailman3/mailman-bundler/venv-3.4/bin/pip:
>> not found
>> While:
>>   Installing mailman.
>>
>> An internal error occurred due to a bug in either zc.buildout or in a
>> recipe being used:
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/zc/buildout/buildout.py",
>> line 1995, in main
>>     getattr(buildout, command)(args)
>>   File "/usr/local/lib/python2.7/dist-packages/zc/buildout/buildout.py",
>> line 666, in install
>>     installed_files = self[part]._call(recipe.install)
>>   File "/usr/local/lib/python2.7/dist-packages/zc/buildout/buildout.py",
>> line 1410, in _call
>>     return f()
>>   File "/mailman3/mailman-bundler/eggs/collective.recipe.cmd-0.
>> 11-py2.7.egg/collective/recipe/cmd/__init__.py", line 56, in install
>>     self.execute()
>>   File "/mailman3/mailman-bundler/eggs/collective.recipe.cmd-0.
>> 11-py2.7.egg/collective/recipe/cmd/__init__.py", line 69, in execute
>>     run_commands(cmds, self.shell)
>>   File "/mailman3/mailman-bundler/eggs/collective.recipe.cmd-0.
>> 11-py2.7.egg/collective/recipe/cmd/__init__.py", line 39, in run_commands
>>     check_call('%s %s' % (shell, tmpfile), shell=True)
>>   File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
>>     raise CalledProcessError(retcode, cmd)
>> CalledProcessError: Command 'sh /tmp/tmpez1ftK/run' returned non-zero
>> exit status 127
>> The command '/bin/sh -c buildout' returned a non-zero code: 1
>>
>
> Do you have any clue what happens?
>
> Danil
>
>
> On 17 July 2016 at 20:06, Simon Hanna <simon.hanna at serve-me.info> wrote:
>
>> Hi,
>>
>> I started working on docker files for Mailman.
>>
>> I created three repositories:
>> - https://github.com/simonsmiley/postorius-docker
>>   Holds the files needed to create a postorius container
>> - https://github.com/simonsmiley/mailman-docker
>>   Holds the files needed to create a core container
>> - https://github.com/simonsmiley/mailman-compose
>>   Holds docker-compose files that greatly simply the process of running
>>   the containers
>>
>> * The mailman repo currently lacks documentation
>> * Currently no emails can be sent.
>>   I still have to figure out what the best way is...
>> * Hyperkitty will be added next
>>   (together with a complete "bundler" install)
>>
>>
>> I pushed two images to the docker hub. Their names are
>> thelinuxguy/postorius and thelinuxguy/mailman
>>
>> I created two organizations
>> mailman on docker hub and gnu-mailman on github
>> https://github.com/gnu-mailman
>> https://hub.docker.com/u/mailman/
>>
>> I know we shouldn't use github, but there is no way around
>> github/bitbucket for automated builds on docker hub.
>>
>> I post here to inform you about the docker images and I also to ask if
>> I'm allowed to keep these two organizations and move my images/repos
>> there. I'll happily give push/owner access to additional people if
>> requested.
>>
>> The repositories could be mirrored to the gitlab mailman group,
>> sadly the process doesn't work the other way round just yet.
>>
>> In case this request gets denied, I'll just remove the organizations and
>> let the images be "unofficial".
>>
>> cheers,
>> Simon
>> _______________________________________________
>> Mailman-Developers mailing list
>> Mailman-Developers at python.org
>> https://mail.python.org/mailman/listinfo/mailman-developers
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Searchable Archives: http://www.mail-archive.com/ma
>> ilman-developers%40python.org/
>> Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/
>> danil%40smirnov.la
>>
>> Security Policy: http://wiki.list.org/x/QIA9
>>
>
>

From mailman at with-h.at  Fri Nov 18 10:26:48 2016
From: mailman at with-h.at (Dominik)
Date: Fri, 18 Nov 2016 16:26:48 +0100
Subject: [Mailman-Developers] PGP support for MM3
Message-ID: <20161118162648.086e51c1@deepthought>

Hello everybody,

I'd like to see PGP support for MM3 but I thought it might be a little
to early to file an issue.

My original motivation was a setup of a full encrypted mailing list.
I'm well aware of the fact that it provides not the security a full
end-to-end encrypted communication provides, but for some people
(including me) it is an acceptable compromise.

Encrypted mailing for groups of people is still a mess in 2016:

*  Either the group is relatively static or you never encrypt the mail
  for all people.
*  All members need to know each other. And you need the keys of all
  the other members.

So far for the motivation. Below there are some initial thoughts:

**Treat mail differently based on their signing status:**

1. Whether it has a signature or not.
2. Whether the signature is valid or not.
3. Whether the signing key matches the key of the list member.
 
**Treat mail differently based on their encryption status**

Whether it is encrypted or not.

**Other opportunities**

1. A public key per list.
2. Signing of outgoing mails with that list key.
3. Encryption of outgoing mails with that list key.
4. Send a mail with the lists public key on request.

Which one of these points a worth an implementation?

Regards

Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20161118/0ae22e5f/attachment.sig>

From mark at msapiro.net  Fri Nov 18 15:11:45 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 18 Nov 2016 12:11:45 -0800
Subject: [Mailman-Developers] PGP support for MM3
In-Reply-To: <20161118162648.086e51c1@deepthought>
References: <20161118162648.086e51c1@deepthought>
Message-ID: <43a74730-7354-988b-40b3-cf9d7d326223@msapiro.net>

On 11/18/2016 07:26 AM, Dominik wrote:
> 
> I'd like to see PGP support for MM3 but I thought it might be a little
> to early to file an issue.


There are threads on a potential GSOC proposal for this starting at
<https://mail.python.org/pipermail/mailman-developers/2016-February/025420.html>
and
<https://mail.python.org/pipermail/mailman-developers/2016-March/025621.html>.

I seem to recall more about this or maybe other GCOC proposals in this
area, but I don't know the status of any of it.

Steve may be able to provide more info.

-- 
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-developers/attachments/20161118/d4e86092/attachment.sig>

From barry at list.org  Fri Nov 18 16:47:08 2016
From: barry at list.org (Barry Warsaw)
Date: Fri, 18 Nov 2016 16:47:08 -0500
Subject: [Mailman-Developers] PGP support for MM3
In-Reply-To: <20161118162648.086e51c1@deepthought>
References: <20161118162648.086e51c1@deepthought>
Message-ID: <20161118164708.5c9be68d@subdivisions.wooz.org>

On Nov 18, 2016, at 04:26 PM, Dominik wrote:

>I'd like to see PGP support for MM3 but I thought it might be a little
>to early to file an issue.

I think full PGP support as many people want will be a multi-issue,
multi-branch effort.  For example, I can imagine a branch that enables
list-specific key management so that you can encrypt a message to a mailing
list.  Then users/addresses would each also have key management.  Those touch
the database layer.  There will probably be branches that touch the REST API,
and handler/rules, etc.  Then there are likely changes to Postorius, possibly
HyperKitty, etc.

>Encrypted mailing for groups of people is still a mess in 2016:
>
>*  Either the group is relatively static or you never encrypt the mail
>  for all people.
>*  All members need to know each other. And you need the keys of all
>  the other members.
>
>So far for the motivation. Below there are some initial thoughts:
>
>**Treat mail differently based on their signing status:**
>
>1. Whether it has a signature or not.
>2. Whether the signature is valid or not.
>3. Whether the signing key matches the key of the list member.
> 
>**Treat mail differently based on their encryption status**
>
>Whether it is encrypted or not.

You could certainly do these things.  Once the basic key management
infrastructure is in place, you could fairly easily add various rules and
handlers to effect some of these features.  E.g. a rule could say "if this
message does not have a valid signature, discard it".  That could be useful
even without full encryption.  For outgoing encryption, you'd need a pre-MTA
handler if you wanted to do personalization, e.g. encrypt the message to each
user's registered key.

>**Other opportunities**
>
>1. A public key per list.
>2. Signing of outgoing mails with that list key.
>3. Encryption of outgoing mails with that list key.

#2 and #3 could be done with list-wide handlers, since they aren't
personalized.

>4. Send a mail with the lists public key on request.

Fairly easy to add a command to do this.

>Which one of these points a worth an implementation?

All?  None?  Some?  :)

It really kind of depends on what people want.  At a minimum, I would really
like the option of running a mailing list which requires valid signatures for
posting, to avoid blindly trusting the sender headers.  That still requires
user-based key management, so perhaps that's a good place to start.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20161118/edcc77ce/attachment.sig>

From turnbull.stephen.fw at u.tsukuba.ac.jp  Sat Nov 19 11:22:50 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Sun, 20 Nov 2016 01:22:50 +0900
Subject: [Mailman-Developers] Docker files for mailman
In-Reply-To: <CAMrrXboT-LT9mb=U--9ZoJw8YDLnd2M=+xMu9dy4X-54c7rrhg@mail.gmail.com>
References: <3023406d-c6dd-75a5-b4ea-798c3dc3465b@serve-me.info>
 <CAMrrXbqOBYE23dzymmJjhhynJArqKWRSqHM2QoKFnGXTrhSSSA@mail.gmail.com>
 <CAMrrXboT-LT9mb=U--9ZoJw8YDLnd2M=+xMu9dy4X-54c7rrhg@mail.gmail.com>
Message-ID: <22576.31834.768209.70847@turnbull.sk.tsukuba.ac.jp>

Danil Smirnov writes:

 > Okay I've found that image can be built if you base on Ubuntu Trusty distro
 > (line 6 of the Dockerfile: "FROM ubuntu:trusty") and add ruby-sass to the
 > set of packages to install (line 13: "apt-get install -y git python3-dev
 > python3-pip python-dev python-pip python-virtualenv ruby-sass").

The absence of sass is a known problem with Debian-derived systems.

 > I'm not sure whether I need to change it in the Wiki...

Please do, but do mention that currently it seems to a problem only
for the Debian family of distributions.

Steve

From turnbull.stephen.fw at u.tsukuba.ac.jp  Sat Nov 19 11:37:50 2016
From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Sun, 20 Nov 2016 01:37:50 +0900
Subject: [Mailman-Developers] PGP support for MM3
In-Reply-To: <43a74730-7354-988b-40b3-cf9d7d326223@msapiro.net>
References: <20161118162648.086e51c1@deepthought>
 <43a74730-7354-988b-40b3-cf9d7d326223@msapiro.net>
Message-ID: <22576.32734.827490.955972@turnbull.sk.tsukuba.ac.jp>

Mark Sapiro writes:
 > On 11/18/2016 07:26 AM, Dominik wrote:

 > > I'd like to see PGP support for MM3 but I thought it might be a little
 > > to early to file an issue.

It's too late. :-)  The issue has already been raised, years ago.  So
far the complexity has deterred people from actually doing anything
about it.  (I hasten to add it's not *that* hard, it's just that so
far everybody except our GSoC students who has proposed adding crypto
to lists has balked at the idea that you actually have to think about
your threat model, and gone away at that point.)

 > > Which one of these points a worth an implementation?

All of them.  Individually and in various combinations.  And that's
the problem from our point of view.  If somebody would tell us *what*
they want, do a lot of the work on identifying threats, and maybe do a
coding, we could provide the *how* and help do implementations one at
a time.  But we don't have itches to scratch ourselves, and plenty to
do besides building a better mousetrap when the customer has a
cockroach problem.

 > Steve may be able to provide more info.

Abhilash Raj actually worked on the "signed list" GSOC project.  I
don't know if he's still interested in that particular project but I
believe he maintains his interest in security.  I hope he'll get
involved in the conversation.  (It may be a couple of weeks, though, I
know he's facing deadlines at school.)

As Barry mentions in a parallel response, at least at the present
time, there is no good theory of security that would allow us to
provide a single, simple "crypto-enabled list" configuration, or set
of options.  Rather, due to the nature of email, there are a very
large number of use cases and corresponding threat models, and each
requires a unique configuration.

Picking one or more and getting started on implementation, and
especially user documentation, would be welcome.  Aside from
Abhilash's work, we also have this summer's work on Authenticated
Received Chain (ARC) by Aditya Divekar that uses crypto technology,
but it's a very special use case, and has some really smart IETF
people behind it so it's well-defined.

It's the definition of use cases and threat models that users would
like us to address that is the main task now.  Once have that, we can
start building up the components for handling keys and various signing
and encryption configurations.
Steve

From best.sum at gmail.com  Mon Nov 21 22:23:08 2016
From: best.sum at gmail.com (Leon)
Date: Mon, 21 Nov 2016 22:23:08 -0500
Subject: [Mailman-Developers] Error occurs when subscribers send emails to
 list_name-leave
Message-ID: <CAPDq0P1MPs9KPRwC7c+=uVAB7z1aXs=4CyMfvQs3AZZ+7Yi1uQ@mail.gmail.com>

Hi developers.

Subscribers who sent emails to list-leave at XXX got unsubscribe confirmation
email, but they are still in the member list.

Error log of mailman:

Nov 22 02:28:50 2016 (12315) deque: do_confirm_verify
Traceback (most recent call last):
  File "/opt/mailman/git/mailman/src/mailman/app/workflow.py", line 69, in
__next__
    return step()
  File "/opt/mailman/git/mailman/src/mailman/app/subscriptions.py", line
402, in _step_send_confirmation
    raise StopIteration
StopIteration
Nov 22 02:30:03 2016 (12315) Uncaught runner exception: None
Nov 22 02:30:03 2016 (12315) Traceback (most recent call last):
  File "/opt/mailman/git/mailman/src/mailman/core/runner.py", line 159, in
_one_iteration
    self._process_one_file(msg, msgdata)
  File "/opt/mailman/git/mailman/src/mailman/core/runner.py", line 252, in
_process_one_file
    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/opt/mailman/git/mailman/src/mailman/runners/command.py", line 196,
in _dispose
    mlist, msg, msgdata, parts, results)
  File "/opt/mailman/git/mailman/src/mailman/commands/eml_confirm.py", line
56, in process
    assert member is not None, member
AssertionError: None

-- 
Best wishes,
Leon

From mark at msapiro.net  Mon Nov 21 23:07:51 2016
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 21 Nov 2016 20:07:51 -0800
Subject: [Mailman-Developers] Error occurs when subscribers send emails
 to list_name-leave
In-Reply-To: <CAPDq0P1MPs9KPRwC7c+=uVAB7z1aXs=4CyMfvQs3AZZ+7Yi1uQ@mail.gmail.com>
References: <CAPDq0P1MPs9KPRwC7c+=uVAB7z1aXs=4CyMfvQs3AZZ+7Yi1uQ@mail.gmail.com>
Message-ID: <73a838fc-adac-3f04-63fa-694993ae9818@msapiro.net>

On 11/21/2016 07:23 PM, Leon wrote:
> Hi developers.
> 
> Subscribers who sent emails to list-leave at XXX got unsubscribe confirmation
> email, but they are still in the member list.


This is a known issue. See <https://gitlab.com/mailman/mailman/issues/294>.

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

From best.sum at gmail.com  Sun Nov 27 23:33:55 2016
From: best.sum at gmail.com (Leon)
Date: Sun, 27 Nov 2016 23:33:55 -0500
Subject: [Mailman-Developers] [django_mailman3-1.0.2] No Facebook app
 configured: please add a SocialApp using the Django admin
Message-ID: <CAPDq0P3sYMexPHrK0G0YcXixUAseG5MdJ35rFoJzNNZ105K+XQ@mail.gmail.com>

Hi developers. I copied production.py from (
https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=AttachFile&do=view&target=production.py),
so 'allauth.socialaccount.providers.facebook' is in INSTALLED_APPS. Also, I
added another site and set SITE_ID = 2(
http://stackoverflow.com/questions/14019017/django-allauth-no-facebook-app-configured-please-add-a-socialapp-using-the-djan).
However, the exception is not fixed.


Error log:
ImproperlyConfigured at /accounts/login/

No Facebook app configured: please add a SocialApp using the Django admin

Request Method: GET
Request URL: http://list.conferency.com/accounts/login/?next=/archives/
Django Version: 1.10.3
Exception Type: ImproperlyConfigured
Exception Value:

No Facebook app configured: please add a SocialApp using the Django admin

Exception Location:
/opt/mailman/venv/lib/python2.7/site-packages/django_allauth-0.29.0-py2.7.egg/allauth/socialaccount/providers/facebook/provider.py
in media_js, line 131
Python Executable: /opt/mailman/venv/bin/python2
Python Version: 2.7.12
Python Path:

['/opt/mailman/mailman-bundler',
 '/opt/mailman/mailman-bundler/eggs/gunicorn-19.6.0-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/Whoosh-2.7.4-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/mock-2.0.0-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/beautifulsoup4-4.5.1-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/six-1.10.0-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/pbr-1.10.0-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/funcsigs-1.0.2-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/lockfile-0.12.2-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/django_extensions-1.7.5-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/django_haystack-2.5.1-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/enum34-1.1.6-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/networkx-1.11-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/python_dateutil-1.5-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/django_browserid-2.0.2-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/HyperKitty-1.0.4-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/mailmanclient-1.0.1-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/django_allauth-0.29.0-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/postorius-1.0.4-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/django_mailman3-1.0.2-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/Django-1.10.3-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages',
 '/opt/mailman/mailman-bundler/eggs/django_compressor-2.1-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/django_paintstore-0.2-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/pytz-2016.7-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/robot_detection-0.4-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/cssmin-0.2.0-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/rjsmin-1.0.12-py2.7-linux-x86_64.egg',
 '/opt/mailman/mailman-bundler/eggs/django_crispy_forms-1.6.1-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/djangorestframework-3.5.3-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/python_social_auth-0.2.21-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/django_gravatar2-1.4.0-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/decorator-4.0.10-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/httplib2-0.9.2-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/requests-2.12.1-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/rcssmin-1.0.6-py2.7-linux-x86_64.egg',
 '/opt/mailman/mailman-bundler/eggs/django_appconf-1.0.2-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/PyJWT-1.4.2-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/requests_oauthlib-0.7.0-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/oauthlib-2.0.1-py2.7.egg',
 '/opt/mailman/mailman-bundler/eggs/python_openid-2.2.5-py2.7.egg',
 '/opt/mailman/mailman-bundler/bin',
 '/opt/mailman/venv/lib/python2.7',
 '/opt/mailman/venv/lib/python2.7/plat-x86_64-linux-gnu',
 '/opt/mailman/venv/lib/python2.7/lib-tk',
 '/opt/mailman/venv/lib/python2.7/lib-old',
 '/opt/mailman/venv/lib/python2.7/lib-dynload',
 '/usr/lib/python2.7',
 '/usr/lib/python2.7/plat-x86_64-linux-gnu',
 '/usr/lib/python2.7/lib-tk',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/six-1.10.0-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/lockfile-0.12.2-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/django_extensions-1.7.5-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/django_haystack-2.5.1-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/enum34-1.1.6-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/networkx-1.11-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/python_dateutil-1.5-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/django_compressor-2.1-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/django_paintstore-0.2-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/pytz-2016.7-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/robot_detection-0.4-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/cssmin-0.2.0-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/rjsmin-1.0.12-py2.7-linux-x86_64.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/djangorestframework-3.5.3-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/django_gravatar2-1.4.0-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/decorator-4.0.10-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/httplib2-0.9.2-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/rcssmin-1.0.6-py2.7-linux-x86_64.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/django_appconf-1.0.2-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/requests-2.12.1-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/requests_oauthlib-0.7.0-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/python_openid-2.2.5-py2.7.egg',
 '/opt/mailman/venv/local/lib/python2.7/site-packages/oauthlib-2.0.1-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/six-1.10.0-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/lockfile-0.12.2-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/django_extensions-1.7.5-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/django_haystack-2.5.1-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/enum34-1.1.6-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/networkx-1.11-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/python_dateutil-1.5-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/django_compressor-2.1-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/django_paintstore-0.2-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/pytz-2016.7-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/robot_detection-0.4-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/cssmin-0.2.0-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/rjsmin-1.0.12-py2.7-linux-x86_64.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/djangorestframework-3.5.3-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/django_gravatar2-1.4.0-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/decorator-4.0.10-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/httplib2-0.9.2-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/rcssmin-1.0.6-py2.7-linux-x86_64.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/django_appconf-1.0.2-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/requests-2.12.1-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/requests_oauthlib-0.7.0-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/python_openid-2.2.5-py2.7.egg',
 '/opt/mailman/venv/lib/python2.7/site-packages/oauthlib-2.0.1-py2.7.egg']

Error during template rendering

In template
/opt/mailman/venv/lib/python2.7/site-packages/django_mailman3-1.0.2-py2.7.egg/django_mailman3/templates/account/login.html,
error at line *0*

No Facebook app configured: please add a SocialApp using the Django admin
1 {% extends "account/base.html" %}
2
3 {% load i18n %}
4 {% load account socialaccount %}
5 {% load bootstrap_tags %}
6
7 {% block head_title %}{% trans "Sign In" %}{% endblock %}
8
9 {% block content %}
-- 
Best wishes,
Leon

From simon.hanna at serve-me.info  Mon Nov 28 05:02:02 2016
From: simon.hanna at serve-me.info (Simon Hanna)
Date: Mon, 28 Nov 2016 11:02:02 +0100
Subject: [Mailman-Developers] [django_mailman3-1.0.2] No Facebook app
 configured: please add a SocialApp using the Django admin
In-Reply-To: <CAPDq0P3sYMexPHrK0G0YcXixUAseG5MdJ35rFoJzNNZ105K+XQ@mail.gmail.com>
References: <CAPDq0P3sYMexPHrK0G0YcXixUAseG5MdJ35rFoJzNNZ105K+XQ@mail.gmail.com>
Message-ID: <C6F4DA46-61CC-4787-A741-0BA16B4E5145@serve-me.info>

On 28 November 2016 05:33:55 GMT+01:00, Leon <best.sum at gmail.com> wrote:
>Hi developers. I copied production.py from (
>https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=AttachFile&do=view&target=production.py),
>so 'allauth.socialaccount.providers.facebook' is in INSTALLED_APPS.
>Also, I
>added another site and set SITE_ID = 2(
>http://stackoverflow.com/questions/14019017/django-allauth-no-facebook-app-configured-please-add-a-socialapp-using-the-djan).
>However, the exception is not fixed.
>
>
>Error log:
>ImproperlyConfigured at /accounts/login/
>
>No Facebook app configured: please add a SocialApp using the Django
>admin
>
The error says it all...
You need to login to the django admin and add the configuration for Facebook before you can start using it. This is needed because some auth providers require api tokens.

Also are you sure you want site_id set to 2?
You will have to configure a site in the admin as well. AFAIK with site_id set to 1 you get a automatically configured example.com site. 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.