I am pleased to announce the release Mailman 2.1.20.
Python 2.4 is the minimum supported, but Python 2.7 is recommended.
This release has one new feature, a few bug fixes, an update to the
Polish message catalog and a fix for a recently discovered security
vulnerability.
See the attached README for more details.
Mailman is free software for managing email mailing lists and
e-newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.
For more information, please see:
http://www.list.orghttp://www.gnu.org/software/mailmanhttp://mailman.sourceforge.net/
Mailman 2.1.20 can be downloaded from
https://launchpad.net/mailman/2.1/http://ftp.gnu.org/gnu/mailman/https://sourceforge.net/projects/mailman/
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
A security vulnerability in Mailman has been found and fixed. It has
been assigned CVE-2015-2775. The details of this vulnerability and fix
will be announced next Tuesday, 31 March 2015, at which time both a
patch for this specific vulnerability and Mailman 2.1.20 will be released.
In addition to this security fix, Mailman 2.1.20 includes a new feature
allowing a list owner to change a list member's address through the
admin Membership Management... Section, and a couple of minor bug fixes.
The new feature is a fix for <https://launchpad.net/bugs/266809>.
The bugs fixed are: <https://launchpad.net/bugs/1426825>,
<https://launchpad.net/bugs/1426829> and
<https://launchpad.net/bugs/1427389>.
The security vulnerability, the details of which are currently private,
is <https://launchpad.net/bugs/1437145>.
The security vulnerability only affects those installations which use
Exim, Postfix's postfix_to_mailman.py or similar programmatic (not
aliases) MTA delivery to Mailman, and have untrusted local users on the
Mailman server.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Refer to the bottom of this email for some previous quotes from @barry on this topic. I’ve also had off list discussions with Barry in which he has mentioned this same topic so it seems to have some previous thought gone into it.
I’m wanting to raise the topic of “fine grained subscription control” (for want of a better term) for discussion. Please note these thoughts refer to discussion style lists rather than notification style lists. Please prefix every sentence here with IMO - I’m not saying I’m right about anything, just putting forward food for thought. Also, I’m no Mailman expert so if my assumptions are plain wrong please let me know.
One of the core problems of mailing lists (at least as implemented in Mailman) is that there’s not much middle ground between being very involved (i.e receive all posts to list), or being almost-not-involved (i.e. receiving daily digests or no digest).
List noise and relevancy is the main problem and it’s a big impediment to lists being more widely used.
Very engaged users might be ok with constantly deleting messages that they are not interested in (i.e. irrelevant noise). Less engaged users will be annoyed with the noise and unsubscribe, or will switch to digest notification which I suggest to you is close to unsubscription anyway because that user no longer sees emails that they might have been interested in had they known there was a message on that subject. Digest users I suggest are at best observers rather than participators.
The more active the list, the greater the noise problem, the more users will drop out of the list. As a list gains more subscribers, eventually even the most engaged user will have had enough of the volume of messages and will drop back to digest or write some mailbox rule that moves the emails to a folder, effectively dis-engaging them from the list conversation flow. Thus Mailman discussion-style lists currently don’t scale.
Even for low volume lists, noise is a major inhibitor to usage in certain contexts. Consider for example the CIO of a company or the manager of a division of 30 developers. There are various mailing lists being used by the various projects that they are responsible for. The leader is not participating however because the noise from those lists would be overwhelming. They would however like to be partipcating in list discussions either that they initiated, are explicitly copied into, or relate to topics (keywords) that they are interested in. In reality, I’m not convinced Mailman would often be used in contexts like this currently because the relevancy/noise/digest/unsubscribe problem is a showstopper.
The systers have recognised this problem and their solution is Dynamic sublists as described here:
http://wiki.list.org/DEV/Dynamic%20Sublists
"List subscribers can decide whether to be a part of new conversations or not. If the users decide to subscribe to new conversations, then they will receive all the messages of a new conversation unless they explicitly unsubscribe from it. If they otherwise decide to unsubscribe from new conversations,then they will receive only the first message of every new conversation unless they explicitly subscribe to it.”
I don’t think dynamic sublists are an effective solution (IMO, remember?). Getting the root message in all conversations is still too noisy and its a clumsy mechanic to have to opt in to further discussion and my thinking is that opt-in-to-discuss will impose a barrier to engagement that will reduce user interaction - put another way - “opt in to every discussion? too hard”.
Possibly a solution worth considering is fine-grained subscription control, in which there is a set of SEND and DONTSEND rules at a List default level and at a user level.
SEND:
Discussions where list member email address is in to/from/cc:
Discussions where to/from/cc contains one or more of: sally(a)example.org, davina(a)example.org, *.example.com
Discussions where subject contains keyword: hyperkitty
Discussions where body contains keyword: hyperkitty
DONTSEND:
Discussions where list member email address is in to/from/cc:
Discussions where to/from/cc contains one or more of: sally(a)example.org, davina(a)example.org
Discussions where subject contains keyword: Java
Discussions where body contains keyword: ruby
The technical hurdle to making this work is that Mailman needs access to historical messages to make it work (i.e. integrating some level of aqrchive like functionality into the Mailman database). I suggest this this may not be as hard as it sounds and hey, we’ve got a database there anyway so why not use it?
One possibility is that this could be pushed into archiving but I don’t think that actually is practical - such concepts really need to be built deep into the core. I’m not advocating archiving-in-core here because I think archiving should like outside core. I do think however that there is value in the core having access to archive data to implement fine grained subscription control and I think it should do so on its own terms (and in its own database) rather than asking archivers to provide the needed functionality.
Fine grained subscription control whilst probably relatively involved to implement, is sure to have a huge payoff in giving users more relevance and less noise, perhaps increasing uptake of Mailman in situations where the noise and relevancy problem currently make Mailman impractical.
Thoughts anyone?
as
Quoting @barry ….
http://mailman.9.n7.nabble.com/Improving-the-archives-tt31296.html#a31340
“”"I like this for several reasons. I've long wanted a bridge between the traditional mailing list and a forum because to me they’re related along a spectrum of emotional investment.
What I mean is this. For the subjects and projects I care deeply about, I join the mailing list. I want to be intimately involved in the day-to-day collaboration that being subscribed gives me. I care enough about that that I'm willing to put up with the pain that comes along with mailing lists, such as the overhead for subscribing, deleting topics I don't care about, the occasional spam, the overhead of going on vacation or leaving the list, etc.
But there are even more topics or projects that I have only a fleeting interest in. Say I find a bug in some X program, or wake up and decide to learn how to use setuptools, or find that some recent update broke my Linux server. In all those cases, I might want to start a thread of discussion or ask a question, and be very involved in that thread for a week or two. Then, my interest wanes, or I get my question answered, or other projects pique my interest. Mailing lists are pretty bad at managing those kinds of fleeting involvement, but forums are quite nice. There's usually fairly low overhead (and probably even less if OpenID and such were in widespread adoption) for joining, and when I lose interest the forum doesn't fill up my inbox. OTOH, forums seem good for short 'instant' messages, but not so good (IMO) for free ranging, detailed discussions. So there's a spectrum. “””
Stephen commented on my proposal that instead of storing all downloads on
the server, we should only cache recent ones and build the others on
request, because many archives are only downloaded once when they are
ported to a different archiver. Since this is in contradiction to the
suggestion Aurelien made, I'm going to leave my proposal as-is for now.
Hopefully the link to this thread in my proposal will be a source of
up-to-date information on project constraints during the application review
process.
On Thu, Mar 26, 2015 at 11:15 AM, David Udelson <dru5(a)cornell.edu> wrote:
> > I'm already using the "jobs" infrastructure provided by the
> > django-extensions package:
> > http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html
>
> Cool. I didn't know about this extension, but it looks like it does what
> we need. So the background process would be its own file in the jobs
> directory, and we could leave it to the admin to setup the crontab?
>
> > I have another test server with more current info if you want, but I
> > break it regularly. It's lists-dev.cloud.fedoraproject.org
>
> Thanks for linking this. I got my own local dev server working yesterday,
> but this one is much more populated.
>
> > We do put the attachment in the mbox, as a MIME component like in
> > every email.
>
> I see how this works now. Are the attachments always Base64 encoded?
>
> >> Another possible "nice-to-have" feature I thought of yesterday is a
> >> download link that scripts can use to get archives (e.g.
> >> "/download?year=x&month=y"). On the other hand, maybe this is just a
> >> security risk that has no actual use case, but I'd still like to have a
> >> second opinion on this.
> >
> > Well, there still is the authentication issue.
>
> I guess getting the scripts to authenticate would be a little complicated,
> but otherwise does this seem like something worth including? If my proposal
> gets accepted, I'm ok with leaving this as an open question until it
> becomes clear whether or not I'm going to have extra time at the end of the
> summer.
>
> Thanks,
> David
>
>
>
>
> On Thu, Mar 26, 2015 at 7:33 AM, Aurelien Bompard <aurelien(a)bompard.org>
> wrote:
>
>> > In my proposal I suggested using any of several asynchronous job queue
>> > libraries, such as Celery or Huey. These all use redis as a back-end.
>> > Because I have no experience with asynchronous job queues, I'm not sure
>> if
>> > this is too much baggage for our purposes. Maybe we just don't want the
>> > extra dependencies.
>>
>> Yeah, we don't want to add another database or an AMQP server just for
>> that. We must keep it simple for admins to deploy.
>>
>> > Regarding cron jobs, there's also django-background-task which is a
>> simple
>> > django addon that might do what we need. Again, if we don't want/need
>> the
>> > extra dependency, rolling our own cron job should be fairly
>> > straight-forward.
>>
>> I'm already using the "jobs" infrastructure provided by the
>> django-extensions package:
>> http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html
>> I did consider django-background-task but django-extensions seemed
>> like a better fit, because django-background-task seems written for
>> delayed tasks, not periodic tasks (well, a task could call itself
>> again when done, but it seems like a hack). I'm not opposed to
>> switching to django-background-task if we use the "delayed job"
>> feature or if we need the extra flexibility of choosing exactly how
>> many seconds apart we want our tasks to run.
>>
>> >> If we choose to pre-build the mbox files, we can't simply have them
>> > served through the webserver, because some lists are private
>> >
>> > Then there is also an authentication step?
>>
>> Yeah, we must use HyperKitty's authentication and check if the user is
>> allowed to see the archive. So the files can't be served by the
>> webserver like static files.
>>
>> > I noticed on the test server
>> > that I can't actually look at any of the mailing lists because they're
>> all
>> > private.
>>
>> If you're looking at lists.stg.fedoraproject.org, it's currently very
>> outdated (still running the Python2-compatible branch of Mailman 3). I
>> have another test server with more current info if you want, but I
>> break it regularly. It's lists-dev.cloud.fedoraproject.org
>>
>> > When we create the mbox file, do we simply note that an attachment
>> existed
>> > (e.g. "Attachment: myattachment.txt") or do we actually put the
>> attachment
>> > in the mbox? AFAIK mbox is a plaintext format, so if the latter is the
>> case
>> > then I'm not exactly sure how this would work...
>>
>> We do put the attachment in the mbox, as a MIME component like in
>> every email. If you choose "view source" when looking at an email with
>> attachments, you'll see how it's done.
>>
>> > Are there going to be any issues handling unicode foreign characters or
>> > with file locks? Right now it looks like we should only have one process
>> > handling the mbox, but is it possible that more than one could be
>> spawned
>> > somehow?
>>
>> No, mbox files are not designed for concurrent writes, so it's better
>> to have a single process write to them.
>>
>> > Another possible "nice-to-have" feature I thought of yesterday is a
>> > download link that scripts can use to get archives (e.g.
>> > "/download?year=x&month=y"). On the other hand, maybe this is just a
>> > security risk that has no actual use case, but I'd still like to have a
>> > second opinion on this.
>>
>> Well, there still is the authentication issue.
>>
>> Aurélien
>> _______________________________________________
>> Mailman-Developers mailing list
>> Mailman-Developers(a)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/dru5%40cornell.e…
>>
>> Security Policy: http://wiki.list.org/x/QIA9
>>
>
>
Dave
You seem to have an interest in Mailman being accessible.
Care to share some requirements/requests/tips/pointers for the various people who are writing user interface code that talks to Mailman.
I’d like to take this sort of thing into account early in the process if possible so now is a good time to talk about what you want/need.
as
At 01:51 AM 3/25/2015, Ana Badescu wrote:
>Hello,
>
>While writing my proposal I came across 2 important issues related to the
>Javascript Client for the Mailman project that have yet to be raised:
>
>2. I'd also like to make part of the project, a node.js application that
>uses the Mailman Javascript client and offers all the functionality
>Postorious does. Is that a good idea? This doesn't make the scope of the
>project too large or unattainable.
>Please remember that anything you develop should be accessible to
>disabled persons. This is possible with JAVA generally, but means
>some planning, using the right libraries etc.
Dave
David Andrews and long white cane Harry.
E-Mail: dandrews(a)visi.com or david.andrews(a)nfbnet.org
Hi guys,
I have updated my proposal for "A Dashboard for Admins/Owners/Moderators"
project.
I have tried to address the issues raised. Reviews on it are welcome.
Regards,
Shreyas Lakhe
I want to make some minor backward incompatible changes to the JSON
representation for pending mailing lists requests, e.g. subscription holds.
You'll see these for example in urls like:
>>> dump_json('http://localhost:9001/3.0/lists/ant@example.com/requests')
entry 0:
delivery_mode: regular
display_name: Anne Person
email: anne(a)example.com
http_etag: "..."
language: en
request_id: ...
type: subscription
when: 2005-08-01T07:49:23
The first change is that `type: subscription` requests will change their
`address` key to `email` for consistency with other parts of the API. Second,
there will be no `password` key.
Let me know if this is a problem, and I can copy `email` to `address` so that
both would appear, and add a dummy `password` key.
Cheers,
-Barry
> I'm already using the "jobs" infrastructure provided by the
> django-extensions package:
> http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html
Cool. I didn't know about this extension, but it looks like it does what we
need. So the background process would be its own file in the jobs
directory, and we could leave it to the admin to setup the crontab?
> I have another test server with more current info if you want, but I
> break it regularly. It's lists-dev.cloud.fedoraproject.org
Thanks for linking this. I got my own local dev server working yesterday,
but this one is much more populated.
> We do put the attachment in the mbox, as a MIME component like in
> every email.
I see how this works now. Are the attachments always Base64 encoded?
>> Another possible "nice-to-have" feature I thought of yesterday is a
>> download link that scripts can use to get archives (e.g.
>> "/download?year=x&month=y"). On the other hand, maybe this is just a
>> security risk that has no actual use case, but I'd still like to have a
>> second opinion on this.
>
> Well, there still is the authentication issue.
I guess getting the scripts to authenticate would be a little complicated,
but otherwise does this seem like something worth including? If my proposal
gets accepted, I'm ok with leaving this as an open question until it
becomes clear whether or not I'm going to have extra time at the end of the
summer.
Thanks,
David
On Thu, Mar 26, 2015 at 7:33 AM, Aurelien Bompard <aurelien(a)bompard.org>
wrote:
> > In my proposal I suggested using any of several asynchronous job queue
> > libraries, such as Celery or Huey. These all use redis as a back-end.
> > Because I have no experience with asynchronous job queues, I'm not sure
> if
> > this is too much baggage for our purposes. Maybe we just don't want the
> > extra dependencies.
>
> Yeah, we don't want to add another database or an AMQP server just for
> that. We must keep it simple for admins to deploy.
>
> > Regarding cron jobs, there's also django-background-task which is a
> simple
> > django addon that might do what we need. Again, if we don't want/need the
> > extra dependency, rolling our own cron job should be fairly
> > straight-forward.
>
> I'm already using the "jobs" infrastructure provided by the
> django-extensions package:
> http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html
> I did consider django-background-task but django-extensions seemed
> like a better fit, because django-background-task seems written for
> delayed tasks, not periodic tasks (well, a task could call itself
> again when done, but it seems like a hack). I'm not opposed to
> switching to django-background-task if we use the "delayed job"
> feature or if we need the extra flexibility of choosing exactly how
> many seconds apart we want our tasks to run.
>
> >> If we choose to pre-build the mbox files, we can't simply have them
> > served through the webserver, because some lists are private
> >
> > Then there is also an authentication step?
>
> Yeah, we must use HyperKitty's authentication and check if the user is
> allowed to see the archive. So the files can't be served by the
> webserver like static files.
>
> > I noticed on the test server
> > that I can't actually look at any of the mailing lists because they're
> all
> > private.
>
> If you're looking at lists.stg.fedoraproject.org, it's currently very
> outdated (still running the Python2-compatible branch of Mailman 3). I
> have another test server with more current info if you want, but I
> break it regularly. It's lists-dev.cloud.fedoraproject.org
>
> > When we create the mbox file, do we simply note that an attachment
> existed
> > (e.g. "Attachment: myattachment.txt") or do we actually put the
> attachment
> > in the mbox? AFAIK mbox is a plaintext format, so if the latter is the
> case
> > then I'm not exactly sure how this would work...
>
> We do put the attachment in the mbox, as a MIME component like in
> every email. If you choose "view source" when looking at an email with
> attachments, you'll see how it's done.
>
> > Are there going to be any issues handling unicode foreign characters or
> > with file locks? Right now it looks like we should only have one process
> > handling the mbox, but is it possible that more than one could be spawned
> > somehow?
>
> No, mbox files are not designed for concurrent writes, so it's better
> to have a single process write to them.
>
> > Another possible "nice-to-have" feature I thought of yesterday is a
> > download link that scripts can use to get archives (e.g.
> > "/download?year=x&month=y"). On the other hand, maybe this is just a
> > security risk that has no actual use case, but I'd still like to have a
> > second opinion on this.
>
> Well, there still is the authentication issue.
>
> Aurélien
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers(a)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/dru5%40cornell.e…
>
> Security Policy: http://wiki.list.org/x/QIA9
>
> In my proposal I suggested using any of several asynchronous job queue
> libraries, such as Celery or Huey. These all use redis as a back-end.
> Because I have no experience with asynchronous job queues, I'm not sure if
> this is too much baggage for our purposes. Maybe we just don't want the
> extra dependencies.
Yeah, we don't want to add another database or an AMQP server just for
that. We must keep it simple for admins to deploy.
> Regarding cron jobs, there's also django-background-task which is a simple
> django addon that might do what we need. Again, if we don't want/need the
> extra dependency, rolling our own cron job should be fairly
> straight-forward.
I'm already using the "jobs" infrastructure provided by the
django-extensions package:
http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html
I did consider django-background-task but django-extensions seemed
like a better fit, because django-background-task seems written for
delayed tasks, not periodic tasks (well, a task could call itself
again when done, but it seems like a hack). I'm not opposed to
switching to django-background-task if we use the "delayed job"
feature or if we need the extra flexibility of choosing exactly how
many seconds apart we want our tasks to run.
>> If we choose to pre-build the mbox files, we can't simply have them
> served through the webserver, because some lists are private
>
> Then there is also an authentication step?
Yeah, we must use HyperKitty's authentication and check if the user is
allowed to see the archive. So the files can't be served by the
webserver like static files.
> I noticed on the test server
> that I can't actually look at any of the mailing lists because they're all
> private.
If you're looking at lists.stg.fedoraproject.org, it's currently very
outdated (still running the Python2-compatible branch of Mailman 3). I
have another test server with more current info if you want, but I
break it regularly. It's lists-dev.cloud.fedoraproject.org
> When we create the mbox file, do we simply note that an attachment existed
> (e.g. "Attachment: myattachment.txt") or do we actually put the attachment
> in the mbox? AFAIK mbox is a plaintext format, so if the latter is the case
> then I'm not exactly sure how this would work...
We do put the attachment in the mbox, as a MIME component like in
every email. If you choose "view source" when looking at an email with
attachments, you'll see how it's done.
> Are there going to be any issues handling unicode foreign characters or
> with file locks? Right now it looks like we should only have one process
> handling the mbox, but is it possible that more than one could be spawned
> somehow?
No, mbox files are not designed for concurrent writes, so it's better
to have a single process write to them.
> Another possible "nice-to-have" feature I thought of yesterday is a
> download link that scripts can use to get archives (e.g.
> "/download?year=x&month=y"). On the other hand, maybe this is just a
> security risk that has no actual use case, but I'd still like to have a
> second opinion on this.
Well, there still is the authentication issue.
Aurélien