Mailman 3 June 2015 - Mailman-Developers

Mailman 3 upgrade WAS: Re: postorius login question
by Danil Smirnov 09 Jun '15

09 Jun '15

2015-06-08 12:22 GMT+03:00 Aurelien Bompard <aurelien(a)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

1 0

Update 2.0 - Creating threads to handle dynamic list
by Stephen J. Turnbull 09 Jun '15

09 Jun '15

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.

2 1

The full Mailman 3 suite is now on GitLab
by Barry Warsaw 08 Jun '15

08 Jun '15

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

1 0

Re: [Mailman-Developers] postorius login question
by Abhilash Raj 08 Jun '15

08 Jun '15

Hi Danil, On Sun, 7 Jun 2015 15:01:46 +0300 Danil Smirnov <danil(a)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

2 1

virtual hosts again
by Danil Smirnov 07 Jun '15

07 Jun '15

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

1 0

html question
by Danil Smirnov 07 Jun '15

07 Jun '15

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

1 0

postorius login question
by Danil Smirnov 07 Jun '15

07 Jun '15

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

1 0

Re: [Mailman-Developers] MM 3: bundler; stuck on buildout phase...
by Bill.Costa＠unh.edu 07 Jun '15

07 Jun '15

> 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(a)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 ]==

3 2

Re: [Mailman-Developers] can not post to the list
by Danil Smirnov 05 Jun '15

05 Jun '15

2015-06-03 11:17 GMT+03:00 Aurelien Bompard <aurelien(a)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

1 0

MM 3: bundler; stuck on buildout phase...
by Bill.Costa＠unh.edu 05 Jun '15

05 Jun '15

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(a)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 ]==

2 1

Mailman-Developers June 2015