From aurelien at bompard.org  Mon Jun  1 11:17:33 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Mon, 1 Jun 2015 11:17:33 +0200
Subject: [Mailman-Developers] right adding of mailman 3 conf lines to
	httpd.conf
In-Reply-To: <CAMrrXbq-6U7GS0yUDy5At6424X5rQPxe4zt89=tc2+z_u2Vs4A@mail.gmail.com>
References: <CAMrrXbryjbKVhOY6tEcUnQFQg--OaOhr8i-GfOagGFNfkrv6dw@mail.gmail.com>
 <87617bv04o.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAMrrXbrett7vQLooTc7YChnNSip6KduEkXva7pL_e7JZMSzA-w@mail.gmail.com>
 <CAMrrXbq-6U7GS0yUDy5At6424X5rQPxe4zt89=tc2+z_u2Vs4A@mail.gmail.com>
Message-ID: <CAHmoxtUVQG4p5oS1v5Dn7RAsWiYiVqdmEtDjJwf38FNuaaQcmQ@mail.gmail.com>

> ValueError: Unable to configure handler 'file': [Errno 13] Permission
> denied: '/var/log/mailman-web/mailman-web.log'
> After I corrected permissions for log file mentioned I can access
> Postorius and Hyperkitty.
> Everything looks working, I will test in more details later.

Ah, right, the fact that you have to create the directory and set the
permissions for the production setup was not added in the README file.
I'll fix that.
I'm however surprised that you didn't get the error in your Apache
logs without uncommenting the ErrorLog directive. Do you have anything
in your apache error log?

Aur?lien

From aurelien at bompard.org  Mon Jun  1 11:27:08 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Mon, 1 Jun 2015 11:27:08 +0200
Subject: [Mailman-Developers] can not post to the list
In-Reply-To: <CAMrrXbp1sXjCUEE5LS-aDpxjdZpHYAVT9ENgu=YW5abghpvX-g@mail.gmail.com>
References: <CAMrrXbp1sXjCUEE5LS-aDpxjdZpHYAVT9ENgu=YW5abghpvX-g@mail.gmail.com>
Message-ID: <CAHmoxtVAYQ0_RJwd_c_f2tkaML2nqZaEMh-WVembhFO2V3c=WA@mail.gmail.com>

>   File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman_hyperkitty/__init__.py",
> line 101, in list_url
>     return self._get_url({"mlist": mlist.fqdn_listname})
>   File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman_hyperkitty/__init__.py",
> line 82, in _get_url
>     result = requests.get(url, params=params)

That's Mailman core trying to talk to HyperKitty over http to get the
list archives URL. The URL it's trying to reach is set in the
"deployment/mailman-hyperkitty.cfg".
My guess is that you need to update it because if HyperKitty is
running under Apache, the port is no longer 8000, it's 80 (so you can
remove it from the URL).
If that's the problem, I'll update the README file.

Aur?lien

From danil at smirnov.la  Mon Jun  1 14:19:56 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Mon, 1 Jun 2015 15:19:56 +0300
Subject: [Mailman-Developers] right adding of mailman 3 conf lines to
	httpd.conf
In-Reply-To: <CAHmoxtUVQG4p5oS1v5Dn7RAsWiYiVqdmEtDjJwf38FNuaaQcmQ@mail.gmail.com>
References: <CAMrrXbryjbKVhOY6tEcUnQFQg--OaOhr8i-GfOagGFNfkrv6dw@mail.gmail.com>
 <87617bv04o.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAMrrXbrett7vQLooTc7YChnNSip6KduEkXva7pL_e7JZMSzA-w@mail.gmail.com>
 <CAMrrXbq-6U7GS0yUDy5At6424X5rQPxe4zt89=tc2+z_u2Vs4A@mail.gmail.com>
 <CAHmoxtUVQG4p5oS1v5Dn7RAsWiYiVqdmEtDjJwf38FNuaaQcmQ@mail.gmail.com>
Message-ID: <CAMrrXbp=OJpemve3RYJ1Y5o6ATj-rHrkrMWMVSkA4aFZsd456g@mail.gmail.com>

2015-06-01 12:17 GMT+03:00 Aurelien Bompard <aurelien at bompard.org>:
>
> Ah, right, the fact that you have to create the directory and set the
> permissions for the production setup was not added in the README file.
> I'll fix that.
> I'm however surprised that you didn't get the error in your Apache
> logs without uncommenting the ErrorLog directive. Do you have anything
> in your apache error log?

Thanks Aurelien!
I've checked one more time - no, I have nothing related to the issue
in httpd logs.

Danil

From danil at smirnov.la  Mon Jun  1 15:40:36 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Mon, 1 Jun 2015 16:40:36 +0300
Subject: [Mailman-Developers] mailman 3: http vs https
Message-ID: <CAMrrXbpfEn+9No6C_A0XiW0scKPVSxze5E2SU3m_u7=AePOspQ@mail.gmail.com>

Please help I've got in troubles with http/https schemes of the
Postorious/Hyperkitty.

Initially I configured Mailman 3 in :443 virtualhost section of
subdomain lists.domaint.tld
with automatic redirection from :80 by mod_rewrite. I could access
pages with https scheme.

Then I noticed that my SSL-certificate doesn't allow wildcard-subdomains.

I saw two options here:

1) To use a folder on main domain.tld instead of subdomain which does
not looks like a great idea because of Hyperkitty somehow control
robots.txt file which is domain-wide, not folder-wide.

2) To get rid of https.

I choose last option and have moved Mailman 3 config lines to :80
virtualhost, commented redirection too.

Now I can see Postorius and Hyperkitty on http connection but I can't
login - I've been redirecting to https pages right after login, which
are not accessible.

The worst thing is that if I move Mailman 3 lines back to :443
virtualhost section, I got unbelievable redirect from https site to
http one which was never configured!

So I messed up completely.

Danil

p.s. I use 'Forget about site' feature of Firefox browser and check
with Chrome so it's unlikely a cache issue.

From aurelien at bompard.org  Mon Jun  1 16:23:36 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Mon, 1 Jun 2015 16:23:36 +0200
Subject: [Mailman-Developers] mailman 3: http vs https
In-Reply-To: <CAMrrXbpfEn+9No6C_A0XiW0scKPVSxze5E2SU3m_u7=AePOspQ@mail.gmail.com>
References: <CAMrrXbpfEn+9No6C_A0XiW0scKPVSxze5E2SU3m_u7=AePOspQ@mail.gmail.com>
Message-ID: <CAHmoxtViE=+aHzK6ST1DcdNRFBa228hN2zkk2VvwTjToip-m9Q@mail.gmail.com>

> 2) To get rid of https.
>
> I choose last option and have moved Mailman 3 config lines to :80
> virtualhost, commented redirection too.
>
> Now I can see Postorius and Hyperkitty on http connection but I can't
> login - I've been redirecting to https pages right after login, which
> are not accessible.

If you don't want to use HTTPS, there's a USE_SSL variable in the
Django settings file that you need to set to False.
Otherwise, HyperKitty and Postorius will try to redirect you to HTTPS
on the login page and when you're logged in to prevent credentials and
session theft.

Aur?lien

From danil at smirnov.la  Mon Jun  1 20:08:06 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Mon, 1 Jun 2015 21:08:06 +0300
Subject: [Mailman-Developers] mailman 3: http vs https
In-Reply-To: <CAHmoxtViE=+aHzK6ST1DcdNRFBa228hN2zkk2VvwTjToip-m9Q@mail.gmail.com>
References: <CAMrrXbpfEn+9No6C_A0XiW0scKPVSxze5E2SU3m_u7=AePOspQ@mail.gmail.com>
 <CAHmoxtViE=+aHzK6ST1DcdNRFBa228hN2zkk2VvwTjToip-m9Q@mail.gmail.com>
Message-ID: <CAMrrXborTo=ENJjdmPBzuFVQ2K0zUSrfd2yqzb6+NEbTXu8cGg@mail.gmail.com>

2015-06-01 17:23 GMT+03:00 Aurelien Bompard <aurelien at bompard.org>:
> If you don't want to use HTTPS, there's a USE_SSL variable in the
> Django settings file that you need to set to False.


Thanks, this works.

From danil at smirnov.la  Mon Jun  1 20:22:45 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Mon, 1 Jun 2015 21:22:45 +0300
Subject: [Mailman-Developers] can not post to the list
In-Reply-To: <CAHmoxtVAYQ0_RJwd_c_f2tkaML2nqZaEMh-WVembhFO2V3c=WA@mail.gmail.com>
References: <CAMrrXbp1sXjCUEE5LS-aDpxjdZpHYAVT9ENgu=YW5abghpvX-g@mail.gmail.com>
 <CAHmoxtVAYQ0_RJwd_c_f2tkaML2nqZaEMh-WVembhFO2V3c=WA@mail.gmail.com>
Message-ID: <CAMrrXbrTrVP8hqfXO6-iraPiO7ZvD+V+1WRB0S-_V2pwtW3i5w@mail.gmail.com>

2015-06-01 12:27 GMT+03:00 Aurelien Bompard <aurelien at bompard.org>:
> That's Mailman core trying to talk to HyperKitty over http to get the
> list archives URL. The URL it's trying to reach is set in the
> "deployment/mailman-hyperkitty.cfg".
> My guess is that you need to update it because if HyperKitty is
> running under Apache, the port is no longer 8000, it's 80 (so you can
> remove it from the URL).
> If that's the problem, I'll update the README file.

Thanks, Aurelien.

I tried two variants in mailman-hyperkitty.cfg:

base_url: http://127.0.0.1/archives

----------

Jun 01 21:15:55 2015 (17357) held message approved, message-id:
<CAMrrXbrjXySQCuW21zOSMrV=HfYPqoDDx95jM-kexZqiDcsWHg at mail.gmail.com>
Jun 01 21:15:55 2015 (17357) 127.0.0.1 - - "POST
/3.0/lists/test at domain.tld/held/6 HTTP/1.1" 204 0
Jun 01 21:15:56 2015 (17364) HyperKitty failure on
http://127.0.0.1/archives/api/mailman/urls: <!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /archives/api/mailman/urls was not found on this
server.</p>
</body></html>
 (404)
Jun 01 21:15:56 2015 (17364) HyperKitty failure on
http://127.0.0.1/archives/api/mailman/urls: <!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /archives/api/mailman/urls was not found on this
server.</p>
</body></html>
 (404)
Jun 01 21:15:56 2015 (17365) HyperKitty failure on
http://127.0.0.1/archives/api/mailman/archive: <!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /archives/api/mailman/archive was not found on
this server.</p>
</body></html>
 (404)
Jun 01 21:15:56 2015 (17365) Broken archiver: hyperkitty
Traceback (most recent call last):
  File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman/runners/archive.py",
line 107, in _dispose
    archiver.system_archiver.archive_message(mlist, msg_copy)
  File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman_hyperkitty/__init__.py",
line 132, in archive_message
    raise ValueError(result.text)
ValueError: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /archives/api/mailman/archive was not found on
this server.</p>
</body></html>

----------

base_url: http://lists.domain.tld/archives

----------

Jun 01 21:09:54 2015 (17357) held message approved, message-id:
<CAMrrXbqtf2d-5baBmQ3dMVh34XWUKsAQkDtKotzwmVtB5DDJpw at mail.gmail.com>
Jun 01 21:09:54 2015 (17357) 127.0.0.1 - - "POST
/3.0/lists/test at domain.tld/held/5 HTTP/1.1" 204 0
Jun 01 21:09:55 2015 (17357) 127.0.0.1 - - "GET
/3.0/lists/test.domain.tld HTTP/1.1" 200 303
Jun 01 21:09:55 2015 (17357) 127.0.0.1 - - "GET
/3.0/lists/test at domain.tld/held HTTP/1.1" 200 90
Jun 01 21:09:55 2015 (17364) HyperKitty failure on
http://lists.domain.tld/archives/api/mailman/urls:
                <html><title>Forbidden</title><body>
                <h1>Access is forbidden</h1></body></html> (403)
Jun 01 21:09:55 2015 (17364) HyperKitty failure on
http://lists.domain.tld/archives/api/mailman/urls:
                <html><title>Forbidden</title><body>
                <h1>Access is forbidden</h1></body></html> (403)
Jun 01 21:09:56 2015 (17365) HyperKitty failure on
http://lists.domain.tld/archives/api/mailman/archive:
                <html><title>Forbidden</title><body>
                <h1>Access is forbidden</h1></body></html> (403)
Jun 01 21:09:56 2015 (17365) Broken archiver: hyperkitty
Traceback (most recent call last):
  File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman/runners/archive.py",
line 107, in _dispose
    archiver.system_archiver.archive_message(mlist, msg_copy)
  File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman_hyperkitty/__init__.py",
line 132, in archive_message
    raise ValueError(result.text)
ValueError:
                <html><title>Forbidden</title><body>
                <h1>Access is forbidden</h1></body></html>

----------

Probably last one is because of misconfiguration of
api_key: SecretArchiverAPIKey
?

What should I put here?

Danil

From godricglow at gmail.com  Wed Jun  3 00:50:33 2015
From: godricglow at gmail.com (Pranjal Yadav)
Date: Wed, 3 Jun 2015 04:20:33 +0530
Subject: [Mailman-Developers] Update 2.0 - Creating threads to handle
	dynamic list
Message-ID: <CAE2E6m=3iMnS6ZbQA=mJceVZwtNin0uBj0JoTixsSo9QkshtWg@mail.gmail.com>

After adding "dlist_enabled" attribute to mailing list object and adding
relevant
doctest and unittest, the most important part of the dlist project is
threads. I have
talked about all the details including introduction, implementation,
requirements
and the code in my blog. Its in initial stage so everything is not working
yet,
however I'm planning to finish this implementation along with tests by next
weekend.

I need your reviews on the blog to better understand problems  (if any) in
the
implementation. I'm also updating everything on daily basis in my gitlab
repo
which is also mentioned below along with the blog.

Blog: prany.github.io
code: giitlab.com/godricglow/mailman

PS: A lot of details regarding message table, member and subscription model
etc are missing from this blog and will be updated in the coming blog by
weekend.


-- 
cheers

*Pranjal Yadav (PranY)*

From aurelien at bompard.org  Wed Jun  3 10:17:53 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Wed, 3 Jun 2015 10:17:53 +0200
Subject: [Mailman-Developers] can not post to the list
In-Reply-To: <CAMrrXbrTrVP8hqfXO6-iraPiO7ZvD+V+1WRB0S-_V2pwtW3i5w@mail.gmail.com>
References: <CAMrrXbp1sXjCUEE5LS-aDpxjdZpHYAVT9ENgu=YW5abghpvX-g@mail.gmail.com>
 <CAHmoxtVAYQ0_RJwd_c_f2tkaML2nqZaEMh-WVembhFO2V3c=WA@mail.gmail.com>
 <CAMrrXbrTrVP8hqfXO6-iraPiO7ZvD+V+1WRB0S-_V2pwtW3i5w@mail.gmail.com>
Message-ID: <CAHmoxtWRZF+t1uHp33=ViArM_3RWijuT8Lpgwyc=r8CBkVbhhQ@mail.gmail.com>

> Probably last one is because of misconfiguration of
> api_key: SecretArchiverAPIKey ?

If the first URL does not match, it means that HyperKitty is not
activated in the virtualhost for 127.0.0.1.
You should get a message in HyperKitty's logs stating that the
connection was refused because the IP address is not allowed.
You have two options:
- activate HyperKitty for 127.0.0.1
- in HyperKitty's settings file (production.py), edit the
MAILMAN_ARCHIVER_FROM variable to allow you local IP. This IP address
must not change.

Aur?lien

From danil at smirnov.la  Wed Jun  3 17:25:26 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Wed, 3 Jun 2015 18:25:26 +0300
Subject: [Mailman-Developers] can not post to the list
In-Reply-To: <CAHmoxtWRZF+t1uHp33=ViArM_3RWijuT8Lpgwyc=r8CBkVbhhQ@mail.gmail.com>
References: <CAMrrXbp1sXjCUEE5LS-aDpxjdZpHYAVT9ENgu=YW5abghpvX-g@mail.gmail.com>
 <CAHmoxtVAYQ0_RJwd_c_f2tkaML2nqZaEMh-WVembhFO2V3c=WA@mail.gmail.com>
 <CAMrrXbrTrVP8hqfXO6-iraPiO7ZvD+V+1WRB0S-_V2pwtW3i5w@mail.gmail.com>
 <CAHmoxtWRZF+t1uHp33=ViArM_3RWijuT8Lpgwyc=r8CBkVbhhQ@mail.gmail.com>
Message-ID: <CAMrrXbruz2dasZbsY6TvW-A783yn6eByjocELc__jRsR_JdX1Q@mail.gmail.com>

Could you please be more specific with this "activate Hyperkytty on ..."?
Link to the manual would be okay... (Sorry for the topposting).
03.06.2015 11:18 ???????????? "Aurelien Bompard" <aurelien at bompard.org>
???????:

> > Probably last one is because of misconfiguration of
> > api_key: SecretArchiverAPIKey ?
>
> If the first URL does not match, it means that HyperKitty is not
> activated in the virtualhost for 127.0.0.1.
> You should get a message in HyperKitty's logs stating that the
> connection was refused because the IP address is not allowed.
> You have two options:
> - activate HyperKitty for 127.0.0.1
> - in HyperKitty's settings file (production.py), edit the
> MAILMAN_ARCHIVER_FROM variable to allow you local IP. This IP address
> must not change.
>
> Aur?lien
> _______________________________________________
> 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 ankush.sharma.ece12 at iitbhu.ac.in  Wed Jun  3 18:12:41 2015
From: ankush.sharma.ece12 at iitbhu.ac.in (Ankush Sharma)
Date: Wed, 3 Jun 2015 21:42:41 +0530
Subject: [Mailman-Developers] GSOC - Mailman Client in JS update
Message-ID: <CAE8zidTnoBaWc1wVsjvhz4NBv9kLktM634R1f8ypQSbzGuUQwQ@mail.gmail.com>

Hey,

I have wrote a blog post regarding my work on the project till date.
Interested people can have a look.

Link : http://black-perl.me/black-perl-gsoc-with-mailman-week-i

Thanks,
Ankush Sharma

From stephen at xemacs.org  Thu Jun  4 11:00:53 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 04 Jun 2015 18:00:53 +0900
Subject: [Mailman-Developers] Update 2.0 - Creating threads to handle
	dynamic list
In-Reply-To: <CAE2E6m=3iMnS6ZbQA=mJceVZwtNin0uBj0JoTixsSo9QkshtWg@mail.gmail.com>
References: <CAE2E6m=3iMnS6ZbQA=mJceVZwtNin0uBj0JoTixsSo9QkshtWg@mail.gmail.com>
Message-ID: <87d21bu9tm.fsf@uwakimon.sk.tsukuba.ac.jp>

Hi all,

I'll get to reviewing Pranjal's blog post later tonight; anybody who's
going to be working on it (especially Terri), you might want to wait
on mine so we don't duplicate.

Steve

From stephen at xemacs.org  Thu Jun  4 19:28:44 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 05 Jun 2015 02:28:44 +0900
Subject: [Mailman-Developers] Update 2.0 - Creating threads to
	handle	dynamic list
In-Reply-To: <CAE2E6m=3iMnS6ZbQA=mJceVZwtNin0uBj0JoTixsSo9QkshtWg@mail.gmail.com>
References: <CAE2E6m=3iMnS6ZbQA=mJceVZwtNin0uBj0JoTixsSo9QkshtWg@mail.gmail.com>
Message-ID: <876173tmb7.fsf@uwakimon.sk.tsukuba.ac.jp>

Pranjal Yadav writes:

 > Blog: prany.github.io
 > code: giitlab.com/godricglow/mailman

Sorry about the long brain dump.  Pick some of the issues to address
now and save the rest for later.

I took a look at your blog.  First I reviewed your proposal blog from
April 29 (http://prany.github.io/gsoc15.html), and had the following
thoughts.

1.  I don't understand why the "X-Original-To" header field is checked
    after "To".  I imagine there is a reason, but as this header is
    non-standard, something needs to be said about its presumed
    semantics and when you would expect it to appear, as well as what
    MTAs implement it (I don't think Mailman itself does, at least not
    in our upstream version).

2.  I also wonder about the deviation from normal Mailman semantics
    which I believe will pick up the address from the envelope sender.
    (Of course there's an option to refuse posts where the message
    headers do not contain the list as an addressee, but that option
    isn't always selected.)

    For Systers, I'm sure that these semantics are fine, but in
    general I would think many list admins would expect dlist
    semantics to be as close as possible to ordinary semantics.

3.  I'm not sure about the wisdom of having a separate named pipeline
    for dlists.  I agree with you that the actual pipeline should
    include different handlers rather than trying to incorporate the
    dlist logic in existing handlers.  (Of course somebody may want to
    refactor to exploit commonalities in the code, but IMO your best
    strategy is to copy the whole calculate-recipients and decorate
    Handlers and modify them as convenient.)  However, Mailman already
    allows per-list (2.x allowed per-message! dunno if 3 does)
    pipelines.

    So I'm thinking that maybe we should put the standard pipelines in
    variables (a sort of pipeline registry), and *always* attach a
    pipeline attribute to each list.  To prevent a list from changing
    the global objects for everybody, we could make pipelines tuples
    rather than lists.  (We would need to run that by Barry first,
    though.)

4.  Since Thread.base_message_id is supposed to be a UUID, that (or a
    hash) would be a reasonable primary key for the Thread.  This
    would lead to an interesting extension that any message could
    become a new dlist.  Don't know if that would be useful, but it
    might be (often threads split).

Now, about the progress report blog of May 31
(http://prany.github.io/threads-for-dynamic-sublists.html).  First a
few stylistic comments.

5.  You start by saying that messages "are not kept in a structure."
    It's not obvious what you mean by that.  Obviously there are
    message and metadata classes defined in Mailman.  I guess you mean
    that you want a history of the messages which might simply be a
    list of message-ids, or their hashes.  However, your Thread class
    in the proposal doesn't seem to keep any history.

6.  I disagree with you about the use of the word "conversation."

    A *conversation* is an ambiguously defined collection of messages
    that have various commonalities -- a time span, a topic, and a
    group of participants, at least.

    A *thread* is a collection of messages that can be arranged in a
    DAG (or even a tree) by using the reply-to relationship (which may
    be implemented using the In-Reply-To and/or References fields, but
    I'm referring to the human concept of "reply" here).

    A *dlist* is a collection of messages defined by having a
    particular mailbox among their addressees.

    As I see it, your goal is to *implement* conversations (or maybe a
    better word is "facilitate") using d-lists.  I have no objection
    at all to using conversation in that sense.  However, it's
    important to recognize that what a human thinks of as a
    conversation is quite different from what a machine can implement
    as a thread or a dlist.

    Also, while you have the right to use whatever definitions you
    want, I think most people who are well-versed in email semantics
    and implementations will agree with the definition of thread I
    gave, and also agree that dlists are something quite different.
    That means you will have a difficult time communicating if you use
    the words "conversation", "thread", and "dlist" as rough synonyms.

7.  I don't understand what you mean by "to make threads which are
    meaningful rather than grouping them visually."  I sort of
    understand what you mean by "visual grouping", but in fact all
    MUAs I know of also implement navigation based on the thread
    structure (normally with a depth-first traversal, and the visual
    display also corresponds to that order).  On the other hand,
    "meaningful threads" has no particular meaning to me.

8.  Under "Requirement" you write

    [W]e aim to use this concept [of threading] only for those mailing
    lists which are initially 'dlist_enabled' or simply saying dynamic
    list enabled via mailing list object's attribute.

    but as described in 6, threads are quite a different concept from
    dlists.[1]

9.  Under "Code" you give a simple list of modules to modify, but I
    think you should describe in more detail what you propose to do.

10. The link to your repo is broken!  (It's prefixed by your blog for
    some reason.)

Some comments about the code (I'm looking at "git diff master dlist").

11. Throughout, I think you should use "dlist" rather than "thread"
    for naming classes and other identifiers.

11. In dlist.py, your __all__ variable is wrong, I believe (the dlist
    module has no dlist attribute).

12. class DlistCommands probably should derive from the main Mailman
    commands class.

13. DlistCommands.__init__() should have an else: statement that gives
    a useful error message.  Ditto the "ignored" part of __iter__().

14. In threads.py, the stub methods in class IThread should raise
    NotImplemented or something like that.

15. In message.py, the decision to add msgdata as an attribute to the
    Message model really needs justification, since the original
    design carefully separates the two.

16. Isn't the assignment to thread_id dead?  Also, use .get() here,
    not try ... except.  And *never* use a bare except, not even in
    very early prototype code.  Defining self-documenting Exceptions
    is trivial.  The problem is that msgdata[] could invoke arbitrary
    code which could raise things you can't imagine.

17. In lmtp.py you're going to need to deal with dlist names, as well
    as +new and friends.

Overall I think it's a reasonable first cut, but some things seem to
be a little careless (like the __all__ lists).


Footnotes: 
[1] I actually don't think implementing threads as such would be very
difficult.  Simply keep a history of Message-IDs (or their hashes) and
allow users to "subscribe" to the replies to arbitrary messages (and
to replies to the replies, of course), alternatively unsubscribe (what
in a traditional MUA would be "killing" the thread).  The hard part
would be the UI, since most users would not be capable of, let alone
happy with, specifying message IDs to commands.  I do have some ideas
about that, though.


From Bill.Costa at unh.edu  Fri Jun  5 03:16:19 2015
From: Bill.Costa at unh.edu (Bill.Costa at unh.edu)
Date: Thu, 4 Jun 2015 21:16:19 -0400 (EDT)
Subject: [Mailman-Developers] MM 3: bundler; stuck on buildout phase...
Message-ID: <alpine.LRH.2.03.1506042103460.32565@conundrum.unh.edu>

Following the instructions found here:

    https://mailman-bundler.readthedocs.org/en/latest/

No problems installing the Install Virtualenv (the Python 2.7
version), and made sure I ran that and not the v3 version.
It also looks like the zc.buildout install went OK.

At first the buildout command appears to chug along OK, although
with many warnings.  But eventually we hit a wall with:

>    :
>    :
>    :
> Getting distribution for 'python-social-auth>=0.2.3'.
> warning: no previously-included files matching '*' found under directory '.tox'
> warning: no previously-included files matching '*.pyc' found under directory 'social'
> warning: no previously-included files matching '*.pyc' found under directory 'examples'
> warning: no previously-included files matching '*.db' found under directory 'examples'
> warning: no previously-included files matching 'local_settings.py' found under directory 'examples'
> warning: no previously-included files matching '*' found under directory 'examples/webpy_example/sessions'
> No eggs found in /tmp/easy_install-EoeZsT/python-social-auth-0.2.10/egg-dist-tmp-QsdLrf (setup script problem?)
> While:
>   Installing mailman-web.
>   Getting distribution for 'python-social-auth>=0.2.3'.
> Error: Couldn't install: python-social-auth 0.2.10
> (venv)$

Full buildout log attached.  Any suggestions on how to proceed
would be welcomed.

...BC

-- 
=====================================[ Bill.Costa at unh.edu ]==
  Bill Costa
  1 Leavitt Lane
  UNH IT -- 1st Floor
  University of New Hampshire
  Durham, NH  03824
  USA
  Voice: +1-603-862-3056
  No good deed... Goes unpunished.
===========================[ http://pubpages.unh.edu/~wfc ]==
-------------- next part --------------
(venv)$ cd mailman-bundler/
(venv)$ pip install zc.buildout
Collecting zc.buildout
  Downloading zc.buildout-2.3.1.tar.gz (292kB)
    100% |????????????????????????????????| 294kB 1.1MB/s 
Requirement already satisfied (use --upgrade to upgrade): setuptools>=8.0 in /usr/local/mailman3/UNH/Src/venv/lib/python2.7/site-packages (from zc.buildout)
Building wheels for collected packages: zc.buildout
  Running setup.py bdist_wheel for zc.buildout
  Stored in directory: /usr/local/mailman/.cache/pip/wheels/e1/87/5d/6256832fdc9428cc897a32eda12322a8eafd77c0dfca171b39
Successfully built zc.buildout
Installing collected packages: zc.buildout
Successfully installed zc.buildout-2.3.1
(venv)$ buildout
Creating directory '/usr/local/mailman3/UNH/Src/mailman-bundler/bin'.
Creating directory '/usr/local/mailman3/UNH/Src/mailman-bundler/parts'.
Creating directory '/usr/local/mailman3/UNH/Src/mailman-bundler/eggs'.
Creating directory '/usr/local/mailman3/UNH/Src/mailman-bundler/develop-eggs'.
Develop: '/usr/local/mailman3/UNH/Src/mailman-bundler/.'
warning: no files found matching '*.in' under directory 'mailman_bundler'
warning: no files found matching '*.in' under directory 'deployment'
warning: no files found matching 'deployment/mailman-web.logrotate.conf'
Getting distribution for 'djangorecipe'.
Got djangorecipe 1.11.
Getting distribution for 'Django'.
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
Got Django 1.8.2.
Getting distribution for 'zc.recipe.egg>=2.0.0a3'.
Got zc.recipe.egg 2.0.1.
Getting distribution for 'collective.recipe.cmd'.
warning: no previously-included files matching '*.pyc' found anywhere in distribution
Got collective.recipe.cmd 0.10.
Getting distribution for 'z3c.recipe.filetemplate'.
Got z3c.recipe.filetemplate 2.2.0.
Installing mailman-web.
Getting distribution for 'Django<1.8'.
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
Got Django 1.7.8.
Getting distribution for 'postorius'.
no previously-included directories found matching 'src/postorius/doc/_build'
zip_safe flag not set; analyzing archive contents...
postorius.doc.conf: module references __file__
postorius.tests.__init__: module references __file__
Got postorius 1.0.1.
Getting distribution for 'hyperkitty'.
warning: no files found matching 'requirements.txt'
zip_safe flag not set; analyzing archive contents...
hyperkitty.tests.utils: module references __file__
Got HyperKitty 1.0.1.
Getting distribution for 'Whoosh'.
warning: no files found matching '*.txt' under directory 'tests'
warning: no files found matching '*.txt' under directory 'benchmark'
warning: no files found matching '*.txt' under directory 'docs'
warning: no files found matching '*.txt' under directory 'files'
warning: no files found matching '*.py' under directory 'files'
warning: no files found matching '*.jpg' under directory 'files'
Got Whoosh 2.7.0.
Getting distribution for 'mock'.
warning: no files found matching '*.png' under directory 'docs'
warning: no files found matching '*.css' under directory 'docs'
warning: no files found matching '*.html' under directory 'docs'
warning: no files found matching '*.js' under directory 'docs'
zip_safe flag not set; analyzing archive contents...
Got mock 1.0.1.
Getting distribution for 'beautifulsoup4'.
zip_safe flag not set; analyzing archive contents...
Got beautifulsoup4 4.3.2.
Getting distribution for 'lockfile>=0.9.1'.

Installed /tmp/easy_install-02CUv5/lockfile-0.10.2/.eggs/pbr-1.0.1-py2.7.egg
Got lockfile 0.10.2.
Getting distribution for 'django-extensions>=1.3.7'.
zip_safe flag not set; analyzing archive contents...
django_extensions.settings: module references __file__
django_extensions.management.utils: module references __file__
django_extensions.management.commands.syncdata: module references __file__
django_extensions.management.commands.show_templatetags: module MAY be using inspect.getabsfile
django_extensions.management.commands.runprofileserver: module references __path__
django_extensions.management.commands.create_jobs: module references __file__
django_extensions.management.commands.create_jobs: module references __path__
django_extensions.management.commands.create_command: module references __file__
django_extensions.management.commands.create_command: module references __path__
django_extensions.management.commands.create_template_tags: module references __file__
django_extensions.management.commands.create_template_tags: module references __path__
django_extensions.management.commands.runserver_plus: module references __path__
django_extensions.management.commands.create_app: module references __path__
Got django-extensions 1.5.5.
Getting distribution for 'django-haystack>=2.1.0'.
Got django-haystack 2.3.1.
Getting distribution for 'enum34>=1.0'.
zip_safe flag not set; analyzing archive contents...
Got enum34 1.0.4.
Getting distribution for 'networkx>=1.9.1'.
warning: no files found matching 'scripts/*'
warning: no files found matching 'networkx/tests/*.txt'
warning: no files found matching 'networkx/*/*/tests/*.txt'
warning: no previously-included files matching '*~' found anywhere in distribution
warning: no previously-included files matching '*.pyc' found anywhere in distribution
warning: no previously-included files matching '.svn' found anywhere in distribution
no previously-included directories found matching 'doc/build'
no previously-included directories found matching 'doc/source/reference/generated'
no previously-included directories found matching 'doc/source/examples'
no previously-included directories found matching 'doc/source/static/examples'
no previously-included directories found matching 'doc/source/templates/gallery.html'
Got networkx 1.9.1.
Getting distribution for 'python-dateutil<2.0'.
Got python-dateutil 1.5.
Getting distribution for 'mailmanclient>=1.0.0b1'.
no previously-included directories found matching '_build'
no previously-included directories found matching 'dist'
no previously-included directories found matching '.tox'
warning: no previously-included files found matching '.bzrignore'
zip_safe flag not set; analyzing archive contents...
mailmanclient.testing.nose: module references __file__
Installing mailmanclient 1.0.0+rev71
Caused installation of a distribution:
mailmanclient 1.0.0
with a different version.
Got mailmanclient 1.0.0.
Getting distribution for 'django-browserid>=0.11.1'.
Got django-browserid 1.0.0.
Getting distribution for 'django-compressor>=1.3'.
warning: no files found matching '*.js' under directory 'compressor/tests/media'
warning: no files found matching '*.css' under directory 'compressor/tests/media'
warning: no files found matching '*.png' under directory 'compressor/tests/media'
warning: no files found matching '*.coffee' under directory 'compressor/tests/media'
Got django-compressor 1.5.
Getting distribution for 'django-paintstore>=0.1.2'.
Got django-paintstore 0.2.
Getting distribution for 'pytz>=2012'.
Got pytz 2015.4.
Getting distribution for 'robot-detection>=0.3'.
/usr/local/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'summary'
  warnings.warn(msg)
zip_safe flag not set; analyzing archive contents...
Got robot-detection 0.3.
Getting distribution for 'cssmin>=0.2.0'.
warning: no previously-included files matching '.DS_Store' found anywhere in distribution
zip_safe flag not set; analyzing archive contents...
Got cssmin 0.2.0.
Getting distribution for 'rjsmin>=1.0.6'.
zip_safe flag not set; analyzing archive contents...
Got rjsmin 1.0.10.
Getting distribution for 'django-crispy-forms>=1.4.0'.
warning: no files found matching '*' under directory 'crispy_forms/static'
Got django-crispy-forms 1.4.0.
Getting distribution for 'djangorestframework>=3.0.0'.
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
Got djangorestframework 3.1.3.
Getting distribution for 'python-social-auth>=0.2.3'.
warning: no previously-included files matching '*' found under directory '.tox'
warning: no previously-included files matching '*.pyc' found under directory 'social'
warning: no previously-included files matching '*.pyc' found under directory 'examples'
warning: no previously-included files matching '*.db' found under directory 'examples'
warning: no previously-included files matching 'local_settings.py' found under directory 'examples'
warning: no previously-included files matching '*' found under directory 'examples/webpy_example/sessions'
No eggs found in /tmp/easy_install-EoeZsT/python-social-auth-0.2.10/egg-dist-tmp-QsdLrf (setup script problem?)
While:
  Installing mailman-web.
  Getting distribution for 'python-social-auth>=0.2.3'.
Error: Couldn't install: python-social-auth 0.2.10
(venv)$ 

From danil at smirnov.la  Fri Jun  5 11:00:51 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Fri, 5 Jun 2015 12:00:51 +0300
Subject: [Mailman-Developers] MM 3: bundler; stuck on buildout phase...
In-Reply-To: <alpine.LRH.2.03.1506042103460.32565@conundrum.unh.edu>
References: <alpine.LRH.2.03.1506042103460.32565@conundrum.unh.edu>
Message-ID: <CAMrrXbr=gL+JN=GrG8ft1Cqv=q_JAa=W6ZAY=e2awTm=jOJZwQ@mail.gmail.com>

2015-06-05 4:16 GMT+03:00  <Bill.Costa at unh.edu>:
> Full buildout log attached.  Any suggestions on how to proceed
> would be welcomed.

Do
pip install python-social-auth

Best, Danil

From Bill.Costa at unh.edu  Fri Jun  5 16:16:58 2015
From: Bill.Costa at unh.edu (Bill.Costa at unh.edu)
Date: Fri, 5 Jun 2015 10:16:58 -0400 (EDT)
Subject: [Mailman-Developers] MM 3: bundler; stuck on buildout phase...
In-Reply-To: <CAMrrXbr=gL+JN=GrG8ft1Cqv=q_JAa=W6ZAY=e2awTm=jOJZwQ@mail.gmail.com>
References: <alpine.LRH.2.03.1506042103460.32565@conundrum.unh.edu>
 <CAMrrXbr=gL+JN=GrG8ft1Cqv=q_JAa=W6ZAY=e2awTm=jOJZwQ@mail.gmail.com>
Message-ID: <alpine.LRH.2.03.1506050955440.5572@conundrum.unh.edu>

> pip install python-social-auth

Gotcha.  Just because it's a bundle doesn't mean that it contains
all possible dependencies.  It is surprising, however, that the
buildout just doesn't do the install itself.  Restarted the build
and...

> Successfully built mailman mailman-hyperkitty ...
> Installing collected packages: ... mailman, ... mailman-hyperkitty
> Successfully installed ... mailman-3.0.0 mailman-hyperkitty-1.0.0 ...

So far, so good.  Thanks for the help.  The saga continues...

...BC

-- 
=====================================[ Bill.Costa at unh.edu ]==
  Bill Costa
  1 Leavitt Lane
  UNH IT -- 1st Floor
  University of New Hampshire
  Durham, NH  03824
  USA
  Voice: +1-603-862-3056
  No good deed... Goes unpunished.
===========================[ http://pubpages.unh.edu/~wfc ]==

From danil at smirnov.la  Fri Jun  5 18:33:52 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Fri, 5 Jun 2015 19:33:52 +0300
Subject: [Mailman-Developers] can not post to the list
In-Reply-To: <CAHmoxtWRZF+t1uHp33=ViArM_3RWijuT8Lpgwyc=r8CBkVbhhQ@mail.gmail.com>
References: <CAMrrXbp1sXjCUEE5LS-aDpxjdZpHYAVT9ENgu=YW5abghpvX-g@mail.gmail.com>
 <CAHmoxtVAYQ0_RJwd_c_f2tkaML2nqZaEMh-WVembhFO2V3c=WA@mail.gmail.com>
 <CAMrrXbrTrVP8hqfXO6-iraPiO7ZvD+V+1WRB0S-_V2pwtW3i5w@mail.gmail.com>
 <CAHmoxtWRZF+t1uHp33=ViArM_3RWijuT8Lpgwyc=r8CBkVbhhQ@mail.gmail.com>
Message-ID: <CAMrrXbpEtw7Sn1pHu6e7gGXkLahiKiy-4imR2_Jj4NF84Ru_5w@mail.gmail.com>

2015-06-03 11:17 GMT+03:00 Aurelien Bompard <aurelien at bompard.org>:
> If the first URL does not match, it means that HyperKitty is not
> activated in the virtualhost for 127.0.0.1.
> You should get a message in HyperKitty's logs stating that the
> connection was refused because the IP address is not allowed.
> You have two options:
> - activate HyperKitty for 127.0.0.1
> - in HyperKitty's settings file (production.py), edit the
> MAILMAN_ARCHIVER_FROM variable to allow you local IP. This IP address
> must not change.

Thank you, Aurelian. Now I'm figured all these out.

The first option - to activate Hyperkitty on 127.0.0.1 is not good
opportunity for me because I have shared host and would not have
Mailman 3 archive/manager on every domain I have there instead of its
actual content. :)

Below is the instruction how you would configure Mailman3 just for one
virtual host of your server.

1. Put content of deployment/apache.conf into the virtualhost section
of your Mailman 3 archive/manager domain - every line excluding the
following 4 ones:

WSGISocketPrefix run/wsgi
WSGIRestrictStdout On
WSGIRestrictSignal Off
WSGIPythonOptimize 1

You must put them outside of any of your virtualhost section.

2. Edit your deployment/mailman-hyperkitty.cfg file and set
base_url: http://yourvirtualhostdomain.tld/archives

3. Add to your mailman_web/settings_local.py the ip address of your
virtual host:

MAILMAN_ARCHIVER_FROM = ('ip.ip.ip.ip')

I hope this will help someone.

Everybody have a great weekend,
Danil

From stephen at xemacs.org  Sat Jun  6 06:36:16 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 06 Jun 2015 13:36:16 +0900
Subject: [Mailman-Developers] MM 3: bundler; stuck on buildout phase...
In-Reply-To: <alpine.LRH.2.03.1506050955440.5572@conundrum.unh.edu>
References: <alpine.LRH.2.03.1506042103460.32565@conundrum.unh.edu>
 <CAMrrXbr=gL+JN=GrG8ft1Cqv=q_JAa=W6ZAY=e2awTm=jOJZwQ@mail.gmail.com>
 <alpine.LRH.2.03.1506050955440.5572@conundrum.unh.edu>
Message-ID: <87sia5sbb3.fsf@uwakimon.sk.tsukuba.ac.jp>

Bill.Costa at unh.edu writes:
 > > pip install python-social-auth
 > 
 > Gotcha.  Just because it's a bundle doesn't mean that it contains
 > all possible dependencies.  It is surprising, however, that the
 > buildout just doesn't do the install itself.  Restarted the build
 > and...

Something in django used to depend on it and install it, but not any
more.  buildout just hasn't caught up yet, partly because the devs
already have it installed, I guess.


From aurelien at bompard.org  Sun Jun  7 11:09:42 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Sun, 7 Jun 2015 11:09:42 +0200
Subject: [Mailman-Developers] MM 3: bundler; stuck on buildout phase...
In-Reply-To: <alpine.LRH.2.03.1506050955440.5572@conundrum.unh.edu>
References: <alpine.LRH.2.03.1506042103460.32565@conundrum.unh.edu>
 <CAMrrXbr=gL+JN=GrG8ft1Cqv=q_JAa=W6ZAY=e2awTm=jOJZwQ@mail.gmail.com>
 <alpine.LRH.2.03.1506050955440.5572@conundrum.unh.edu>
Message-ID: <CAHmoxtXt3r+yuY0uSd9LUBhh8eVE07BBi8XtjJiHfzQNgxew0Q@mail.gmail.com>

> It is surprising, however, that the
> buildout just doesn't do the install itself.  Restarted the build
> and...

It should but there's a bug in the latest version of
python-social-auth that prevents the automatic install:
https://github.com/omab/python-social-auth/issues/623

For the time being, installing it via pip is the way to go.

Aur?lien

From danil at smirnov.la  Sun Jun  7 14:01:46 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Sun, 7 Jun 2015 15:01:46 +0300
Subject: [Mailman-Developers] postorius login question
Message-ID: <CAMrrXbpJ3hhKf=kHhRTMp6yQJWcss_FY_K_oPBEOvqvyALCCbA@mail.gmail.com>

Hi Mailman3 devs!

When I click on "Login" link on Postorius main page
http://lists.domain.tld/archives/

I get the page with the following login methods:
Mozilla Persona
Google
Yahoo!

Above these three links I see words "Login with your email"
which is not link and this is confusing.

Are there a way to login with just email and password
as we have in Mailman2?

Danil

From danil at smirnov.la  Sun Jun  7 14:22:48 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Sun, 7 Jun 2015 15:22:48 +0300
Subject: [Mailman-Developers] html question
Message-ID: <CAMrrXbrYVuLyLb9gxn8iByKpLjenZu2eGYsHWaaXr6e1gAnioQ@mail.gmail.com>

I've sent simple html-formatted message with image inside the body to
my Mailman 3 test list.

On "Held messages" page there is 'View' button and it was
disappointing that this feature
just show a source code of message (35 thousand lines because of image
attached).

When I approve the message it went to the archive but with no proper
html rendering also. The html was simple formatting and it become
attachment.html file which even cannot be opened in place, just
downloaded.

Are there any plans to show html messages nicely in 'View' feature and archives?

Thanks,
Danil

From danil at smirnov.la  Sun Jun  7 22:14:28 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Sun, 7 Jun 2015 23:14:28 +0300
Subject: [Mailman-Developers] virtual hosts again
Message-ID: <CAMrrXbrb4apMB_APE8imXeuYpDKw1EAxj42tZTQrTtBE=JZupQ@mail.gmail.com>

Hi!

Are there a way to install Mailman 3 on several virtual hosts to make
Postorius archives be generated separately for each of them? (Or, at
least, to use several aliases for them like 'lists.domain.tld' for
each domain added.)

I would like to know the right way to do this (if it's possible). Now
I'm stuck with one virtual host configured for Postorius and could not
add another one.

Danil

From raj.abhilash1 at gmail.com  Mon Jun  8 10:34:50 2015
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Mon, 8 Jun 2015 14:04:50 +0530
Subject: [Mailman-Developers] postorius login question
In-Reply-To: <CAMrrXbpJ3hhKf=kHhRTMp6yQJWcss_FY_K_oPBEOvqvyALCCbA@mail.gmail.com>
References: <CAMrrXbpJ3hhKf=kHhRTMp6yQJWcss_FY_K_oPBEOvqvyALCCbA@mail.gmail.com>
Message-ID: <20150608140450.46df8d91@angel.angel.in>

Hi Danil,

On Sun, 7 Jun 2015 15:01:46 +0300
Danil Smirnov <danil at smirnov.la> wrote:

> Hi Mailman3 devs!
> 
> When I click on "Login" link on Postorius main page
> http://lists.domain.tld/archives/
> 
> I get the page with the following login methods:
> Mozilla Persona
> Google
> Yahoo!
> 
> Above these three links I see words "Login with your email"
> which is not link and this is confusing.

Logging in via Email is probably broken in the Mailman 3.0 release.
AFAIR it has been fixed the main trunk. We suggest people to use the
Persona Login instead of the email.


-- 
thanks,
Abhilash Raj

From raj.abhilash1 at gmail.com  Mon Jun  8 10:43:36 2015
From: raj.abhilash1 at gmail.com (Abhilash Raj)
Date: Mon, 8 Jun 2015 14:13:36 +0530
Subject: [Mailman-Developers] html question
In-Reply-To: <CAMrrXbrYVuLyLb9gxn8iByKpLjenZu2eGYsHWaaXr6e1gAnioQ@mail.gmail.com>
References: <CAMrrXbrYVuLyLb9gxn8iByKpLjenZu2eGYsHWaaXr6e1gAnioQ@mail.gmail.com>
Message-ID: <20150608141336.1f903774@angel.angel.in>

Hi Danil,

On Sun, 7 Jun 2015 15:22:48 +0300
Danil Smirnov <danil at smirnov.la> wrote:

> I've sent simple html-formatted message with image inside the body to
> my Mailman 3 test list.
> 
> On "Held messages" page there is 'View' button and it was
> disappointing that this feature
> just show a source code of message (35 thousand lines because of image
> attached).

Postorius just queries the core via REST API the for the message and
dumps the message code in the "View". Probably we need to identify if
the message contains a text/html part and then render that
appropriately.

> When I approve the message it went to the archive but with no proper
> html rendering also. The html was simple formatting and it become
> attachment.html file which even cannot be opened in place, just
> downloaded.
> 
> Are there any plans to show html messages nicely in 'View' feature
> and archives?

Care to open an issue for it on Gitlab?
https://gitlab.com/mailman/postorius/issues


-- 
thanks,
Abhilash Raj

From aurelien at bompard.org  Mon Jun  8 11:22:37 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Mon, 8 Jun 2015 11:22:37 +0200
Subject: [Mailman-Developers] postorius login question
In-Reply-To: <20150608140450.46df8d91@angel.angel.in>
References: <CAMrrXbpJ3hhKf=kHhRTMp6yQJWcss_FY_K_oPBEOvqvyALCCbA@mail.gmail.com>
 <20150608140450.46df8d91@angel.angel.in>
Message-ID: <CAHmoxtVmfWvQHg0+aSqhowPOtnvi76tWpFpXPKaf1X9uZWKD5A@mail.gmail.com>

> Logging in via Email is probably broken in the Mailman 3.0 release.
> AFAIR it has been fixed the main trunk. We suggest people to use the
> Persona Login instead of the email.

I fixed it in HyperKitty and released a new tarballs a few days later,
it should be OK but it's not officially supported for 3.0. There are a
few missing features, like password reset, etc.
To login with the internal database, set USE_INTERNAL_AUTH to True in
your settings file.

I agree that the "login with your email" header can be misleading, it
made more sense with the old page layout, but not much now, I'll
remove it.


Aur?lien

From barry at list.org  Mon Jun  8 16:15:31 2015
From: barry at list.org (Barry Warsaw)
Date: Mon, 8 Jun 2015 10:15:31 -0400
Subject: [Mailman-Developers] The full Mailman 3 suite is now on GitLab
Message-ID: <20150608101531.11eab290@limelight.wooz.org>

Hi everyone.

Through Abhilash's diligent work, we've finally brought all Mailman 3
development under one group on GitLab.

https://gitlab.com/groups/mailman

This includes the Core, Postorius, HyperKitty, the client library, the
bundler, Postorius-standalone, documentation, and even the soon-to-be deployed
new website.

Please remember that Launchpad is still used for Mailman 2.1, and there are no
plans to move any of the project artifacts for that series.  All Mailman 3
issues, feature requests, merge requests, etc. for all other related projects
should be filed against the appropriate project on GitLab.

While we're at it, I'll also point out that Abhilash has pushed out a rtfd
site for the Mailman Suite, with pointers to the various sub-projects:

http://gnu-mailman.readthedocs.org/

Thanks Abhilash!

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

From barry at list.org  Mon Jun  8 16:52:05 2015
From: barry at list.org (Barry Warsaw)
Date: Mon, 8 Jun 2015 10:52:05 -0400
Subject: [Mailman-Developers] html question
In-Reply-To: <20150608141336.1f903774@angel.angel.in>
References: <CAMrrXbrYVuLyLb9gxn8iByKpLjenZu2eGYsHWaaXr6e1gAnioQ@mail.gmail.com>
 <20150608141336.1f903774@angel.angel.in>
Message-ID: <20150608105205.31b3a4ff@anarchist.wooz.org>

On Jun 08, 2015, at 02:13 PM, Abhilash Raj wrote:

>Postorius just queries the core via REST API the for the message and
>dumps the message code in the "View". Probably we need to identify if
>the message contains a text/html part and then render that
>appropriately.

Although we do have to be careful not to provide a vector for malware
attacking list admins.

Cheers,
-Barry


From terri at toybox.ca  Tue Jun  9 08:02:36 2015
From: terri at toybox.ca (Terri Oda)
Date: Mon, 08 Jun 2015 23:02:36 -0700
Subject: [Mailman-Developers] html question
In-Reply-To: <20150608105205.31b3a4ff@anarchist.wooz.org>
References: <CAMrrXbrYVuLyLb9gxn8iByKpLjenZu2eGYsHWaaXr6e1gAnioQ@mail.gmail.com>
 <20150608141336.1f903774@angel.angel.in>
 <20150608105205.31b3a4ff@anarchist.wooz.org>
Message-ID: <5576817C.3030607@toybox.ca>

On 2015-06-08 7:52 AM, Barry Warsaw wrote:
> On Jun 08, 2015, at 02:13 PM, Abhilash Raj wrote:
>
>> Postorius just queries the core via REST API the for the message and
>> dumps the message code in the "View". Probably we need to identify if
>> the message contains a text/html part and then render that
>> appropriately.
>
> Although we do have to be careful not to provide a vector for malware
> attacking list admins.

Indeed.  We should use a known parser to defang anything we re-display 
and absolutely positively not write a new one.  There's probably 
something suitable in django already.

  Terri


From godricglow at gmail.com  Tue Jun  9 14:58:14 2015
From: godricglow at gmail.com (pranjal)
Date: Tue, 09 Jun 2015 18:28:14 +0530
Subject: [Mailman-Developers] Update 2.0 - Creating threads to handle
 dynamic list
In-Reply-To: <876173tmb7.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAE2E6m=3iMnS6ZbQA=mJceVZwtNin0uBj0JoTixsSo9QkshtWg@mail.gmail.com>
 <876173tmb7.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <5576E2E6.3030603@gmail.com>

Thanks for the detailed review. Replies inline!

Stephen J. Turnbull wrote:
> Pranjal Yadav writes:
>
>   > Blog: prany.github.io
>   > code: giitlab.com/godricglow/mailman
>
> Sorry about the long brain dump.  Pick some of the issues to address
> now and save the rest for later.
>
> I took a look at your blog.  First I reviewed your proposal blog from
> April 29 (http://prany.github.io/gsoc15.html), and had the following
> thoughts.
>
> 1.  I don't understand why the "X-Original-To" header field is checked
>      after "To".  I imagine there is a reason, but as this header is
>      non-standard, something needs to be said about its presumed
>      semantics and when you would expect it to appear, as well as what
>      MTAs implement it (I don't think Mailman itself does, at least not
>      in our upstream version).
I agree with you, I was checking for "X-Original-To:" due to some 
confusion, I
read /mailman/config/schema and misunderstood the last part where it says
subsequent methods will be re-written with second headers and adding to
the confusion was systers implementation which too checked for both. will
check for "To:" in the header.
> 3.  I'm not sure about the wisdom of having a separate named pipeline
>      for dlists.  I agree with you that the actual pipeline should
>      include different handlers rather than trying to incorporate the
>      dlist logic in existing handlers.  (Of course somebody may want to
>      refactor to exploit commonalities in the code, but IMO your best
>      strategy is to copy the whole calculate-recipients and decorate
>      Handlers and modify them as convenient.)  However, Mailman already
>      allows per-list (2.x allowed per-message! dunno if 3 does)
>      pipelines.
>
>      So I'm thinking that maybe we should put the standard pipelines in
>      variables (a sort of pipeline registry), and *always* attach a
>      pipeline attribute to each list.  To prevent a list from changing
>      the global objects for everybody, we could make pipelines tuples
>      rather than lists.  (We would need to run that by Barry first,
>      though.)
I'm not sure how this would work so I will need a bit more explanation for
this comment. AFAIK all mailing lists are attached with a pipeline from
Base pipeline, Virgin-pipeline, Owner-pipeline or Posting-pipeline, mostly
all messages attach to the 'built-in' or simply default-posting-pipeline
initially. So how exactly should I create those registries from pipelines?
Adding another attribute to the mailing lists will be easy but replacing
lists as pipelines tuples is a pretty complex thought. We'll run it with 
Barry
as you said and then I will post the necessary changes.
>
> 4.  Since Thread.base_message_id is supposed to be a UUID, that (or a
>      hash) would be a reasonable primary key for the Thread.  This
>      would lead to an interesting extension that any message could
>      become a new dlist.  Don't know if that would be useful, but it
>      might be (often threads split).
>
> Now, about the progress report blog of May 31
> (http://prany.github.io/threads-for-dynamic-sublists.html).  First a
> few stylistic comments.
>
> 5.  You start by saying that messages "are not kept in a structure."
>      It's not obvious what you mean by that.  Obviously there are
>      message and metadata classes defined in Mailman.  I guess you mean
>      that you want a history of the messages which might simply be a
>      list of message-ids, or their hashes.  However, your Thread class
>      in the proposal doesn't seem to keep any history.
By "structure" I simple meant any form of order/arrangement that can
be achieved, using history is one good way of doing so. However I simply
planned to make threads to do so.
>
> 6.  I disagree with you about the use of the word "conversation."
>
>      A *conversation* is an ambiguously defined collection of messages
>      that have various commonalities -- a time span, a topic, and a
>      group of participants, at least.
>
>      A *thread* is a collection of messages that can be arranged in a
>      DAG (or even a tree) by using the reply-to relationship (which may
>      be implemented using the In-Reply-To and/or References fields, but
>      I'm referring to the human concept of "reply" here).
>
>      A *dlist* is a collection of messages defined by having a
>      particular mailbox among their addressees.
>
>      As I see it, your goal is to *implement* conversations (or maybe a
>      better word is "facilitate") using d-lists.  I have no objection
>      at all to using conversation in that sense.  However, it's
>      important to recognize that what a human thinks of as a
>      conversation is quite different from what a machine can implement
>      as a thread or a dlist.
>
>      Also, while you have the right to use whatever definitions you
>      want, I think most people who are well-versed in email semantics
>      and implementations will agree with the definition of thread I
>      gave, and also agree that dlists are something quite different.
>      That means you will have a difficult time communicating if you use
>      the words "conversation", "thread", and "dlist" as rough synonyms.
I strongly agree with the definitions and I accept misusing the
term "conversation" which I wrote to convey an idea as to how
threads are understood in day to day life. I will make sure I don't
confuse with all these terms again.
>
> 7.  I don't understand what you mean by "to make threads which are
>      meaningful rather than grouping them visually."  I sort of
>      understand what you mean by "visual grouping", but in fact all
>      MUAs I know of also implement navigation based on the thread
>      structure (normally with a depth-first traversal, and the visual
>      display also corresponds to that order).  On the other hand,
>      "meaningful threads" has no particular meaning to me.
>
> 8.  Under "Requirement" you write
>
>      [W]e aim to use this concept [of threading] only for those mailing
>      lists which are initially 'dlist_enabled' or simply saying dynamic
>      list enabled via mailing list object's attribute.
>
>      but as described in 6, threads are quite a different concept from
>      dlists.[1]
Thanks for pointing this out, I will use above definitions to answer this.
*Dlist* is a collection of messages defined by having a particular mailbox
among their addressees, so when I say a list should be dlist enabled, its
merely a check that the list is good to be a Dlist, now the collection 
of new
messages inside this newly formed Dlist will be arranged in an order using
Reply-To relationship and thus forming a *Thread*.
>
> 9.  Under "Code" you give a simple list of modules to modify, but I
>      think you should describe in more detail what you propose to do.
I will include relevant part of the code with details.
> 10. The link to your repo is broken!  (It's prefixed by your blog for
>      some reason.)
>
> Some comments about the code (I'm looking at "git diff master dlist").
>
> 11. Throughout, I think you should use "dlist" rather than "thread"
>      for naming classes and other identifiers.
Agreed and changed!
>
> 11. In dlist.py, your __all__ variable is wrong, I believe (the dlist
>      module has no dlist attribute).
Thanks again for pointing this out , I will not repeat this.
>
> 12. class DlistCommands probably should derive from the main Mailman
>      commands class.
>
> 13. DlistCommands.__init__() should have an else: statement that gives
>      a useful error message.  Ditto the "ignored" part of __iter__().
I haven't yet started working on "Errors" and that is on my list for 
this week
so I think this won't be an issue next time.
>
> 14. In threads.py, the stub methods in class IThread should raise
>      NotImplemented or something like that.
Same as above.
>
> 15. In message.py, the decision to add msgdata as an attribute to the
>      Message model really needs justification, since the original
>      design carefully separates the two.
Looking into this, I had no clue about the original design and I should
be more careful with what I choose to use, lesson learnt.
> 16. Isn't the assignment to thread_id dead?  Also, use .get() here,
>      not try ... except.  And *never* use a bare except, not even in
>      very early prototype code.  Defining self-documenting Exceptions
>      is trivial.  The problem is that msgdata[] could invoke arbitrary
>      code which could raise things you can't imagine.
Sure, I will use .get() here, I used a bare except as this was an early
prototype which you correctly pointed out.
>
> 17. In lmtp.py you're going to need to deal with dlist names, as well
>      as +new and friends.
>
> Overall I think it's a reasonable first cut, but some things seem to
> be a little careless (like the __all__ lists).
>
>
> Footnotes:
> [1] I actually don't think implementing threads as such would be very
> difficult.  Simply keep a history of Message-IDs (or their hashes) and
> allow users to "subscribe" to the replies to arbitrary messages (and
> to replies to the replies, of course), alternatively unsubscribe (what
> in a traditional MUA would be "killing" the thread).  The hard part
> would be the UI, since most users would not be capable of, let alone
> happy with, specifying message IDs to commands.  I do have some ideas
> about that, though.
>


From danil at smirnov.la  Tue Jun  9 16:21:50 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Tue, 9 Jun 2015 17:21:50 +0300
Subject: [Mailman-Developers] Mailman 3 upgrade WAS: Re: postorius login
	question
Message-ID: <CAMrrXbpEJ-Rbkf4nZWLwbKewkPEewyjOTHFwF=F1peeBOmGr1w@mail.gmail.com>

2015-06-08 12:22 GMT+03:00 Aurelien Bompard <aurelien at bompard.org>:
> I fixed it in HyperKitty and released a new tarballs a few days later,
> it should be OK but it's not officially supported for 3.0. There are a
> few missing features, like password reset, etc.
> To login with the internal database, set USE_INTERNAL_AUTH to True in
> your settings file.

Thank you Aurelien!

Could you please give us some details regarding the right way
of upgrade of Mailman 3?

We have good installation manual but there are lack of information
regarding the upgrade process.

It's important to have one because of the current development stage
is pretty dynamic.

Best,
Danil

From danil at smirnov.la  Tue Jun  9 16:36:38 2015
From: danil at smirnov.la (Danil Smirnov)
Date: Tue, 9 Jun 2015 17:36:38 +0300
Subject: [Mailman-Developers] html question
In-Reply-To: <20150608141336.1f903774@angel.angel.in>
References: <CAMrrXbrYVuLyLb9gxn8iByKpLjenZu2eGYsHWaaXr6e1gAnioQ@mail.gmail.com>
 <20150608141336.1f903774@angel.angel.in>
Message-ID: <CAMrrXbr2WO7fjnfsg1D6LbAg=Z5+4y8xEYNBnGRtiZjB7Xedsg@mail.gmail.com>

2015-06-08 11:43 GMT+03:00 Abhilash Raj <raj.abhilash1 at gmail.com>:
> Care to open an issue for it on Gitlab?
> https://gitlab.com/mailman/postorius/issues

Done:
https://gitlab.com/mailman/postorius/issues/23

From khushboo9293 at gmail.com  Fri Jun 12 07:08:22 2015
From: khushboo9293 at gmail.com (khushboo surana)
Date: Fri, 12 Jun 2015 10:38:22 +0530
Subject: [Mailman-Developers] Problem passing parameters to the REST API
Message-ID: <CAOGyfZHUyy2c0Pj1OUPgq9voUY12HKjnkPNxb0jmNN2QExp4Wg@mail.gmail.com>

Hello,

I am working on Mailman to implement report generations for unsubscription
stats like no. of members who unsubscribed through different modes like
email confirmation. web-confirmation, etc. ( For more details refer:
http://systers.org/wiki/doku.php/f_dlist_stats_scripts)

I made changes in the Mailman Model to add attributes for date and mode of
unsubsrciption in the member table. I also changed the unsubscribe() method
in mailman/model/member.py file to accept another parameter called 'mode'
and add that to the member table.

I am trying to change all the methods in the Client and REST API that
access the unsubscribe method, to pass  the mode,  but I am facing
problems.

In the mailmanclient/_client.py file I have made the following changes:

def unsubscribe(self, email, mode):
     data = dict(mode = mode)
      for member in self.members:
            if member.email == email:
                self._connection.call(member.self_link, data=data,
method='DELETE')
                break


I have also changed the 'on_delete()' method of the mailman/rest/members.py
file to retrieve the data sent.

When I run mmclient in postorius and try to unsubscribe a member from the
list I get the following error:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/khushboo/gsoc/mailman.client/src/mailmanclient/_client.py",
line 619, in unsubscribe
    self._connection.call(member.self_link, data=data, method='DELETE')
  File "/home/khushboo/gsoc/mailman.client/src/mailmanclient/_client.py",
line 108, in call
    raise HTTPError(url, response.status, content, response, None)
HTTPError: HTTP Error 500: A server error occurred.  Please contact the
administrator.



In the Core, I get the following logs:

Traceback (most recent call last):
  File "/usr/lib/python3.4/wsgiref/handlers.py", line 137, in run
    self.result = application(self.environ, self.start_response)
  File "/home/khushboo/gsoc/mailman/src/mailman/database/transaction.py",
line 57, in wrapper
    rtn = function(*args, **kws)
  File "/home/khushboo/gsoc/mailman/src/mailman/rest/wsgiapp.py", line 65,
in __call__
    environ, start_response)
  File
"/home/khushboo/gsoc/mailman/lib/python3.4/site-packages/falcon-0.3.0-py3.4.egg/falcon/api.py",
line 182, in __call__
    responder(req, resp, **params)
TypeError: on_delete() missing 1 required positional argument: 'response'


I am trying to debug the problem but haven't been able to make much
progress. Can someone please help figure out the problem.

Thanks
Khushboo

From barry at list.org  Fri Jun 12 20:18:08 2015
From: barry at list.org (Barry Warsaw)
Date: Fri, 12 Jun 2015 14:18:08 -0400
Subject: [Mailman-Developers] Problem passing parameters to the REST API
In-Reply-To: <CAOGyfZHUyy2c0Pj1OUPgq9voUY12HKjnkPNxb0jmNN2QExp4Wg@mail.gmail.com>
References: <CAOGyfZHUyy2c0Pj1OUPgq9voUY12HKjnkPNxb0jmNN2QExp4Wg@mail.gmail.com>
Message-ID: <20150612141808.68e965d1@anarchist.wooz.org>

On Jun 12, 2015, at 10:38 AM, khushboo surana wrote:

>I have also changed the 'on_delete()' method of the mailman/rest/members.py
>file to retrieve the data sent.

I'd like to see the diff, or the modified function.

>In the Core, I get the following logs:
>
>Traceback (most recent call last):
>  File "/usr/lib/python3.4/wsgiref/handlers.py", line 137, in run
>    self.result = application(self.environ, self.start_response)
>  File "/home/khushboo/gsoc/mailman/src/mailman/database/transaction.py",
>line 57, in wrapper
>    rtn = function(*args, **kws)
>  File "/home/khushboo/gsoc/mailman/src/mailman/rest/wsgiapp.py", line 65,
>in __call__
>    environ, start_response)
>  File
>"/home/khushboo/gsoc/mailman/lib/python3.4/site-packages/falcon-0.3.0-py3.4.egg/falcon/api.py",
>line 182, in __call__
>    responder(req, resp, **params)
>TypeError: on_delete() missing 1 required positional argument: 'response'

Is that the entire traceback?  I would have expected to see the on_delete()
method mentioned there.  There's probably a chained traceback in the log files
before the one you pasted.

Be sure you don't change the signature of the on_delete() method.  That must
take exactly three arguments: self, request, and response.  Normally, the way
on_patch() or on_post() dig parameters out of the data is through a
Validator() instance, which lists the parameters and their type conversion
methods.  You can see examples of this all over the rest submodule methods.

But on_delete() (really the HTTP DELETE method) doesn't accept any arguments
since its purpose is to delete a resource.

I'm not sure what your best option is for recording the "mode" of the
deletion.  I'm not sure whether it's technically acceptable to add data to a
DELETE method (the documentation and books I've consulted don't say either
way).  But it would definitely be out of the ordinary for Mailman's REST API.
Even if it were acceptable, I think this on_delete() method would at least
have to accept and do something reasonable with zero arguments (i.e. the mode
would be optional).

Cheers,
Barry


From nafisa_shazia at outlook.com  Sat Jun 13 05:00:02 2015
From: nafisa_shazia at outlook.com (Nafisa Shazia)
Date: Fri, 12 Jun 2015 20:00:02 -0700
Subject: [Mailman-Developers] Problem Passing Parameters to the REST API
Message-ID: <BAY173-W50D3EF2A26A61F02CB144B99BA0@phx.gbl>

Hello Barry,

I had the same (roundabout) problem as my peer in 
regards to passing parameters to the REST API. For the 
Systers-customized version of Mailman, I wanted to add an 'essay' field 
to the member, such that someone trying to subscribe to our mailing list
 would write an essay that could be stored. I made whatever changes to 
the code I thought were necessary and then attempted to subscribe a 
member myself. 

This Google Doc highlights some code and errors that I ran into. 

https://docs.google.com/document/d/1CbqZ_uONS-uEzVXoV8B198LmQoQ8vUqRspcJTdBhgGA/edit?usp=sharing

My main question is: How deep do I need to go into the subscription workflow to add a single field? 

Thanks,
Nafisa Shazia 		 	   		  

From stephen at xemacs.org  Sat Jun 13 08:13:02 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 13 Jun 2015 15:13:02 +0900
Subject: [Mailman-Developers]  Problem Passing Parameters to the REST API
In-Reply-To: <BAY173-W50D3EF2A26A61F02CB144B99BA0@phx.gbl>
References: <BAY173-W50D3EF2A26A61F02CB144B99BA0@phx.gbl>
Message-ID: <87fv5wi1ap.fsf@uwakimon.sk.tsukuba.ac.jp>

Nafisa Shazia writes:

 > Hello Barry,
 > 
 > I had the same (roundabout) problem as my peer in 
 > regards to passing parameters to the REST API.

Khushboo's solution is going to be different, although most of the
following general discussion should apply.

 > My main question is: How deep do I need to go into the subscription
 > workflow to add a single field?

The short answer is: *you* don't.  In Mailman 2, there was no user
concept, only subscribers (also called members in that context).  A
subscription was a relationship between an email address and a mailing
list.  This was implemented as a one-many attribute of the list.
Also, in general it was not possible to identify whether two addresses
correspond to the same person.

In Mailman 3, there *is* a user model, and you can be a user without
subscribing to any lists (eg, a moderator), but every subscription is
a relationship between a user and a mailing list.  This is implemented
as a many-many relationship:

    def __init__(self, essay, role, list_id, subscriber):
        self._member_id = uid_factory.new_uid()
        self.role = role
        self.essay = essay
        self.list_id = list_id

[Note: at least in Chrome, Google docs does *not* format your code as
Python code, nor does copy-paste give valid Python code.]

Unfortunately you omitted the rest of the function.  So your Google
doc is pretty, but it makes people trying to help you do a lot of
extra work. :-(  Here's the rest of that function:

        if IAddress.providedBy(subscriber):
            self._address = subscriber
            # Look this up dynamically.
            self._user = None
        elif IUser.providedBy(subscriber):
            self._user = subscriber
            # Look this up dynamically.
            self._address = None
        else:
            raise ValueError('subscriber must be a user or address')
        if role in (MemberRole.owner, MemberRole.moderator):
            self.moderation_action = Action.accept
        elif role is MemberRole.member:
            self.moderation_action =
            getUtility(IListManager).get_by_list_id(
                list_id).default_member_action
        else:
            assert role is MemberRole.nonmember, (
                'Invalid MemberRole: {0}'.format(role))
            self.moderation_action =
            getUtility(IListManager).get_by_list_id(
                list_id).default_nonmember_action

This makes it clear that it's possible to subscribe just an address.
However, under the hood Mailman provides a dummy user.  (This is
implied by the comment "Look this up dynamically.")

Now, in the Systers application, you don't want address-only anonymous
subscribers, you want users who have "personalities", ie, user objects
with the appropriate attributes.  So you should be adding your "essay"
attribute to the *users*, not to (list) members.  I'm not sure about
the UI, there are a couple of possibilities.  You have to take account
of the fact that there are non-Systers like me who subscribe to the
lists, although that could be done by list administrators if preferred.

(IMHO, the term "member" is very confusing, because there's a natural
tendency to think of a member as being a person and assuming it has
personal attributes, but that's not the case at all in Mailman 2, and
in Mailman 3 it might not be the case.)

The long answer is actually shorter<wink />.  Most likely you should
not need to change the subscription workflow at all.  If you do, it's
going to require deep surgery and a lot of work.  Consider the
signature of on_post.  It is the same for *all* classes that implement
it.  (This is what Pythonistas call "duck-typing" or "protocol".)  To
change it for one class, you need to change it for all.

Instead, you want to find the *object* (typically only one) that needs
to change and change its model.  This typically requires changing an
interface (under interfaces) as well as the model itself (under
model), and often other code used in the implementation.  In the case
of adding the essay, you need to add the attribute in
interfaces/user.py, and initialize it in model/user.py.  For some
reason there's no rest/user.py, but probably in rest/users.py you will
want to add code in an appropriate class's on_post method to retrieve
the "essay" parameter from the request and attach it to the
appropriate AUser object.

Note that an __init__ method is *not* a public protocol (you never see
code that invokes it as x.__init__(arg1, arg2, ...)), so it can (and
does) vary a lot from class to class.  The only requirement is that
the first argument refer to the object itself (conventionally "self",
but some programmers use "s" or "me" or "this") so that it can be
called using object.method() syntax.  The on_* methods on the other
hand are invoked by various workflows in exactly the same way for any
object they receive, regardless of type.  (That's implicitly the
definition of "protocol" -- "do it this way and it just works".)


Regards,
Steve

From barry at list.org  Sat Jun 13 18:42:13 2015
From: barry at list.org (Barry Warsaw)
Date: Sat, 13 Jun 2015 12:42:13 -0400
Subject: [Mailman-Developers] Problem Passing Parameters to the REST API
In-Reply-To: <BAY173-W50D3EF2A26A61F02CB144B99BA0@phx.gbl>
References: <BAY173-W50D3EF2A26A61F02CB144B99BA0@phx.gbl>
Message-ID: <20150613124213.39a77195@limelight.wooz.org>

On Jun 12, 2015, at 08:00 PM, Nafisa Shazia wrote:

>My main question is: How deep do I need to go into the subscription workflow
>to add a single field?

Steve provided some good background and answers, and I'll just add a few
more thoughts.

The subscription workflow stuff was added fairly late in the 3.0 cycle and I
had to give up on a few things to make this work.  Most importantly was the
idea of attaching additional information to the subscription request, e.g. the
preferred delivery mode (regular or digest).

The subscription workflow is interesting because there are steps which need to
be persistent.  This happens when a confirmation is required from the user, or
an approval is required from the list moderator.  In those cases, we need to
store the state of the workflow in the database, keyed off a token, and then
reconstitute the workflow when that token is presented, either in an email or
through the REST API.  In order to simplify, we only persist the the most
important bits of the subscription request, and things like the delivery mode
didn't make the cut.

In 3.1, I would like to add back the ability to attach other pieces of
information to the subscription request, but that will probably require some
additional changes to the database schema.  I might be able to reuse the
Pending database, which at its heart is a rather simple key/value store.
Anything we add here would also have to be exposed to the REST API, and I'd
rather not let that accept arbitrary parameters.

It's possible that an essay string could be attached to the subscription
request.  There are implementation details such as making sure the essay gets
deleted if the request gets denied or times out, and there are issues of the
model as Steve points out.  E.g. if a new address is getting subscribed for an
existing user, and that user already has an essay, does the new one overwrite
the old one, or does it get ignored?

On Jun 13, 2015, at 03:13 PM, Stephen J. Turnbull wrote:

>In Mailman 3, there *is* a user model, and you can be a user without
>subscribing to any lists (eg, a moderator), but every subscription is
>a relationship between a user and a mailing list.

Right; the model works like this:

Addresses represent an email address.  The internal terminology always
describes IAddress instances as "address" and string typed email addresses as
"email".  Addresses have certain properties in addition to the email, as you
can see in the IAddress interface.

Users represent people.  An IUser can control multiple addresses but an
address can only be linked to (zero or) one user.  A user can have a
"preferred address" which is used in memberships when no explicit address is
given.  Users can have multiple memberships.

Members represents the relationship between an address or a user (collectively
termed "subscriber" internally) and a mailing list.  Members also have roles,
so this relationship triplet is what defines a membership.  E.g. Anne
subscribed to the Ant mailing list as a member is a different IMember instance
than Anne subscribed to the Ant mailing list as an owner.

A roster is a collection of members, but it's important to remember that there
are no roster objects in the database.  A roster is a query, so all kinds of
rosters can exist.  E.g. the roster of all digest members of mailing list Bee,
or the roster of all of Bart's memberships in all mailing lists, regardless of
role.

>This makes it clear that it's possible to subscribe just an address.
>However, under the hood Mailman provides a dummy user.  (This is
>implied by the comment "Look this up dynamically.")

Right, while the model does support subscribing bare (i.e. unlinked to a user)
addresses to mailing lists, this generally isn't exposed externally.

The other important constraint is that users can only be subscribed to mailing
lists if they have a preferred address, since ultimately we have to deliver
messages to this member, and if we don't know what address to use, we can't
send the user messages.

>So you should be adding your "essay" attribute to the *users*, not to (list)
>members.

+1

>(IMHO, the term "member" is very confusing, because there's a natural
>tendency to think of a member as being a person and assuming it has personal
>attributes, but that's not the case at all in Mailman 2, and in Mailman 3 it
>might not be the case.)

IMembers (the interface that describes members) indeed doesn't have much
personality.  The closest thing is perhaps that members can have different
preferences than the underlying subscriber (user or address).

The preference system (such as whether a person wants to receive a list copy
if they're explicitly CC'd on a message) is based on a hierarchy.  Attributes
are looked up in this order, with the first one found winning:

 * The member's preferences
 * The subscribed address's [1] preferences
 * The subscribed user's preferences
 * The system default preferences

(It's arguable that mailing lists should have preferences, in which case the
hierarchy should probably be extended to look up list, followed by domain
preferences before the system defaults.)

[1] "The subscribed address" means the IAddress if that was used as the
subscriber explicitly, or the IUser's preferred address if the user was
subscribed.

I hope that provides some additional useful information.  Be sure to read the
rest of Steve's response; there's lots of good stuff in there. :)

Cheers,
-Barry

From khushboo9293 at gmail.com  Sun Jun 14 11:57:05 2015
From: khushboo9293 at gmail.com (khushboo surana)
Date: Sun, 14 Jun 2015 15:27:05 +0530
Subject: [Mailman-Developers] Problem passing parameters to the REST API
In-Reply-To: <20150612141808.68e965d1@anarchist.wooz.org>
References: <CAOGyfZHUyy2c0Pj1OUPgq9voUY12HKjnkPNxb0jmNN2QExp4Wg@mail.gmail.com>
 <20150612141808.68e965d1@anarchist.wooz.org>
Message-ID: <CAOGyfZGqoHhL9jbntDZF5yD3W1PnW6khfHsunmQmpbsF-efSrg@mail.gmail.com>

Hello!!

First of all I am sorry I did not not provide a lot of information
(especially the diffs) in my previous mail that was required to get to the
root of the problem. However, with the information Barry provided, I was
able to make a few corrections to my code and now I am able to pass the
mode of unsubscription as a parameter to the REST through the HTTP DELETE
request.


On Fri, Jun 12, 2015 at 11:48 PM, Barry Warsaw <barry at list.org> wrote:

> I'd like to see the diff, or the modified function.

 Although it may not be required now, I am adding the link to my changes
below. In case you need to see it to give further suggestions.

Mailman Core:
https://github.com/khushboo9293/mailman/commit/d3e7b10da3f05357b6436ce2d9938bfb361a54d6

Mailman Client:
https://github.com/khushboo9293/mailman.client/commit/83397557f693f10b4a3f4d93bfb5be5c2412113d

> Be sure you don't change the signature of the on_delete() method.  That
must
> take exactly three arguments: self, request, and response.  Normally, the
way
> on_patch() or on_post() dig parameters out of the data is through a
> Validator() instance, which lists the parameters and their type conversion
> methods.

I hadn't changed the signature of the on_delete() method the method took 3
arguments only.Instead, I tried to pass the parameters in the body of
DELETE request and used validator() to extract the data. But after cross
checking with other examples in REST modules, I found a mistake in the way
I was using validator and rectified it.

> But on_delete() (really the HTTP DELETE method) doesn't accept any
arguments
> since its purpose is to delete a resource.
>
> I'm not sure what your best option is for recording the "mode" of the
> deletion.  I'm not sure whether it's technically acceptable to add data
to a
> DELETE method (the documentation and books I've consulted don't say either
> way).

As per what I had read, its is not forbidden to send data through a DELETE
request but in many cases it is rejected or ignored by the server. In my
case however, I am able to retrieve the data in the on_delete() method here
and pass it to the model method unsubscribe().
Link to rest/members.py

> Even if it were acceptable, I think this on_delete() method would at least
> have to accept and do something reasonable with zero arguments (i.e. the
mode
> would be optional).

I have made changes in the REST code (rest/members.py) to make the mode
optional. If the mode is not provided in the parameters, then the default
mode would be assigned. Currently I don't know what the default mode of
unsubsciption is, hence provided an arbitrary string.


Regards
Khushboo

From khushboo9293 at gmail.com  Fri Jun 19 20:24:44 2015
From: khushboo9293 at gmail.com (khushboo surana)
Date: Fri, 19 Jun 2015 23:54:44 +0530
Subject: [Mailman-Developers] Unsubscribe through email - Mailman 3
Message-ID: <CAOGyfZFu_ULLmsXDqC_UJ7gpmn2zmtpGBv-sMPZkkbupGJNHhA@mail.gmail.com>

Hello all,

I am a GSoC student working on Syster's custom version of Mailman. I am
trying to record the stats for the number of users unsubscribed through
different means like email-confirmation, admin mass removal , etc.
More details here: http://systers.org/wiki/doku.php/f_dlist_stats_scripts

In the mailman source code, I don't see the
provision to process an unsubscription request through email, i.e,
when a user sends an email with the subject 'Unsubscribe'. It is
possible that the provision is there and I have missed it. If so,
please correct me.

I tried to check for myself if that functionality is there by sending
an email with the subject "unsubscribe", but that just appears in the
held messages of the admin interface waiting for moderator action.

Is there an existing functionality for unsubscription through email in
Mailman 3. If yes, what is its implementation design (just a brief
overview).


-Khushboo

From mark at msapiro.net  Fri Jun 19 20:58:52 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 19 Jun 2015 11:58:52 -0700
Subject: [Mailman-Developers] Unsubscribe through email - Mailman 3
In-Reply-To: <CAOGyfZFu_ULLmsXDqC_UJ7gpmn2zmtpGBv-sMPZkkbupGJNHhA@mail.gmail.com>
References: <CAOGyfZFu_ULLmsXDqC_UJ7gpmn2zmtpGBv-sMPZkkbupGJNHhA@mail.gmail.com>
Message-ID: <5584666C.2050702@msapiro.net>

On 06/19/2015 11:24 AM, khushboo surana wrote:
> 
> In the mailman source code, I don't see the
> provision to process an unsubscription request through email, i.e,
> when a user sends an email with the subject 'Unsubscribe'. It is
> possible that the provision is there and I have missed it. If so,
> please correct me.


One sends the command 'unsubscribe' or 'leave' in the Subject: or the
first body line of a message to the LIST-request address.

The command is processed by src/mailman/commands/eml_membership.py. Some
docs are at
<http://mailman.readthedocs.org/en/latest/src/mailman/commands/docs/membership.htm>

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

From vince at vheuser.com  Wed Jun 24 14:52:36 2015
From: vince at vheuser.com (vince at vheuser.com)
Date: Wed, 24 Jun 2015 08:52:36 -0400
Subject: [Mailman-Developers] export entire list?
References: <CAOGyfZFu_ULLmsXDqC_UJ7gpmn2zmtpGBv-sMPZkkbupGJNHhA@mail.gmail.com>
Message-ID: <87C1FD86297D446490086ECB05E431DE@L520>

Is there an easy way to export an entire list of names and email addresses?
I've searched the documentation and the web with no luck.
Thanks
Vince H.


From mark at msapiro.net  Wed Jun 24 16:23:01 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 24 Jun 2015 07:23:01 -0700
Subject: [Mailman-Developers] export entire list?
In-Reply-To: <87C1FD86297D446490086ECB05E431DE@L520>
References: <CAOGyfZFu_ULLmsXDqC_UJ7gpmn2zmtpGBv-sMPZkkbupGJNHhA@mail.gmail.com>
 <87C1FD86297D446490086ECB05E431DE@L520>
Message-ID: <558ABD45.8020706@msapiro.net>

On 06/24/2015 05:52 AM, vince at vheuser.com wrote:
> Is there an easy way to export an entire list of names and email addresses?
> I've searched the documentation and the web with no luck.


For Mailman 2.1, see the FAQ at <http://wiki.list.org/x/4030569>. Or do
you mean MM 3?

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

From vince at vheuser.com  Wed Jun 24 16:30:25 2015
From: vince at vheuser.com (vince at vheuser.com)
Date: Wed, 24 Jun 2015 10:30:25 -0400
Subject: [Mailman-Developers] export entire list?
References: <CAOGyfZFu_ULLmsXDqC_UJ7gpmn2zmtpGBv-sMPZkkbupGJNHhA@mail.gmail.com>
 <87C1FD86297D446490086ECB05E431DE@L520>
Message-ID: <47C8754640B2458794DC15BDA05FEAA0@L520>

----- Original Message ----- 
From: <vince at vheuser.com>
To: <mailman-developers at python.org>
Sent: Wednesday, June 24, 2015 8:52 AM
Subject: [Mailman-Developers] export entire list?


> Is there an easy way to export an entire list of names and email 
> addresses?
> I've searched the documentation and the web with no luck.
> Thanks
> Vince H.
>
Found it.
http://wiki.list.org/DOC/How%20do%20I%20extract%20%28export%29%20a%20list%20of%20my%20list%27s%20members%20%28subscribers%29%3F

Vince H.



From godricglow at gmail.com  Thu Jun 25 15:48:05 2015
From: godricglow at gmail.com (Pranjal Yadav)
Date: Thu, 25 Jun 2015 19:18:05 +0530
Subject: [Mailman-Developers] Update 2.1 - Functional Threads, Handler,
	Rule and Runner
Message-ID: <CAE2E6mke3Oygqb9-eKyAXqOTQB410BoQTV7hWx=Y4D197P7r5w@mail.gmail.com>

Hello all

I recently posted my "Pre-Mid-Term" report on my blog, here I would like to
mention few other details. Firstly I skipped week 3 from my timeline and
will
be going this week as per week 4. However I have successfully completed
most of work from week 5 to 10 so I have plenty of time to have your reviews
for the work till mid term. There will be no rush for the remaining work as
it
involves writing few tests and documentation. However I'm facing some issues
while calculating new recipients as per dlist preference but I think it
will be
solved in a day or two. I will need your reviews to modify/add to my work if
there is anything missing.

Blog : http://prany.github.io/dlist-pre-mid-term-report.html

-- 

*Pranjal Yadav*

*IIT Kharagpur*

From bhavesh.goyal093 at gmail.com  Fri Jun 26 13:02:22 2015
From: bhavesh.goyal093 at gmail.com (Bhavesh Goyal)
Date: Fri, 26 Jun 2015 11:02:22 +0000
Subject: [Mailman-Developers] Progress Update: Admins Dashboard
Message-ID: <CACczSNG+C4D6t4LaYRoh_f=0Y7Xg+chxuB_GZ=JvqpkZsxHSxA@mail.gmail.com>

Hi !

I updated my blog recently with the initial 3 weeks of my project
experience. Its been great so far, for I ve got to learn so much more than
I expected and hope to extract more from the coming time.

For the project, I ve successfully implemented the view for The Tasks,
List-Index, The Activity Tracker and The Graphical Stats Widget along with
a nav bar featuring a quick global search among lists, members and the
domains. The Dashboard's view is kept restricted based on the logged in
user's privileges. I am planning on refining the dashboard views,
refactoring and removing any code smells from the code for the coming time.

Any reviews over any UI updations required, widget functionality or overall
code structure would be greatly appreciated. This marks my current work
till mid terms along with testing and bug fixing upon which I am currently
working on.

Thanks for your consideration :)

Project Link :
https://code.launchpad.net/~bhavesh-goyal093/postorius/dashboard
Blog : towardsgsoc15.wordpress.com

-- 
Regards,
Bhavesh Goyal,
Computer Science Engineering,
IIIT Hyderabad