Our current GNU Mailman logos were designed by the Dragon De Monsyne many
years ago. They have served us exceedingly well, but with the coming of
Mailman 3, we've decided it's time our logos got a face lift. So we're
opening up a new logo contest to the Mailman and GNU communities. We invite
your creative and inspiring designs!
Details of the contest and submission guidelines are available here:
Submissions will be open until February 28, 2010, and is open to everyone, so
feel free to forward this announcement. Please contact the Mailman Steering
Committee at mailman-cabal(a)python.org with any questions.
I'm really excited about the developments ongoing with MM3... :)
One thing I'd really like to see in MM3 with respect to list digests is
what I'll call 'Interactive HTML Digests'. Yahoo 'full featured' digests
go about halfway to where I'd like to see MM3 go.
This was discussed briefly on the users list in the thread 'Replying to
digests' on 12/29...
Here's what I'm imagining:
1. Each message subject in the summary of messages at the top of the
digest are embedded hyperlinks that if clicked, will scroll the
digest down to that message (Yahoos do this now),
2. Each message displayed in the digest body would have the following
in a single line at the very bottom *and* top of each message (Yahoos
are only at the bottom):
a) separate button/links for: 'Reply to Sender', 'Reply to List' and
maybe 'Reply to all' (that last one could be optional?), and
b) little 'Back to top' links to scroll back to the top of the message
3. When replying to a message, preserve the message subject *and* all of
the individual message references so that replying to messages from
the HTML digests doesn't break threading - basically so it looks as
if it was replied to individually and separately, not from the list
Apparently Yahoo's doesn't preserve the message header/references (bad),
but it does preserve the subject.
Also - I use Thunderbird, and when I click Yahoos 'Reply to Group', it
does 2 things wrong, but I don't know if MM could do anything about this
or if it would be a Thunderbird issue:
1) it uses the email clients 'default account' instead of the account
the user is in - so, if you just type something and click 'Send',
it is sent from the wrong account and will bounce since the email
address for that account is not a list/group member, and
2) Thunderbird's new 'Quote only selected text' doesn't work - in fact,
*nothing* is quoted. This issue is not as big as the first one,
since it can be worked around by simply copying the highlighted
text (more often than not I select text to quote rather than
quoting the whole thing) then 'pasting as quote'. Two more steps -
not that big a deal, but hey, if it can be coded to use the Clients
features, all the better.
Since I'm not a programmer, all I can do is offer to help test/debug and
document this feature should you guys see any value in implementing it.
Thanks for listening... :)
Tom Gafford wrote:
>With reference to: http://mail.python.org/pipermail/mailman-developers/2005-February/017850.ht…
>It doesn't appear that Adrian bye's fix ever made it into the Mailman code base, and now the links to the patch are broken.
The sourceforge link in the above message is still good if you join the
two lines back together.
>Does anyone know where to find his patches and whether they work on any newer version of mailman? Or if there is any other fix to this problem?
The patches are still on sourceforge. They probably work as well in
current Mailman 2.1.13 as they did in 2.1.5.
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
On Feb 11, 2010, at 04:48 PM, christian.bayle(a)orange-ftgroup.com wrote:
>We (Coclico-project http://www.coclico-project.org/) have started some
>work on a better integration of mailman and forges
This is really interesting work from a number of perspectives. You might be
aware that my day job is working on Launchpad <http://launchpad.net> which is
a Zope-based open source (AGPL) software hosting service developed by
Canonical for development of Ubuntu. As part of that work, I integrated
Mailman 2.x with Launchpad, and of course all of that code has been released
as part of Launchpad.
We did not override Security Manager, since we expose a much simpler (some bug
reporters would say *too* simple ;) admin interface to Mailman through the
Launchpad web ui. We actually don't expose the Mailman web ui at all. If
you're interested in more information about what we did, I'd be happy to
(As an aside, I wonder if it would be interesting to find ways for Launchpad
to exchange information with the forges?)
Your patches are to Mailman 2.1, but that version is in maintenance-only mode,
so we wouldn't be able to apply them to upstream. Our focus is on Mailman 3
and I would be really interested in any feedback and experience you might have
integrating that version with the forges.
>I know there is also some work made to integrate mailman and forge
>forums, we would like to deal with too.
I'm very interested in this work too.
>Our next step is to make mailman a forge plugin to demonstrate how it
>could make easier to use mailing lists in forges.
I intend to work on integrating Mailman 3 with Launchpad sometime in the next
six months or so (I'm temporarily working on a different project at
Canonical). I suspect that the work to do this will have some overlap with
We've been using mailman for a number of years and are very happy with
it, especially the integration that's possible with Exim.
However - I've recently met a problem that seems to be a common theme in
the mailing lists but without an accepted solution so I thought I just
check with the experts.
We wish to have a size limit applied to any message sent to our mailing
lists. This is going to be determined by our mailing lists
administrators. The problem is that the administrators do not want the
moderators to be able to override that limit.
As far as I can tell, whatever limits the administrators set will only
cause the message to be sent to the moderators, who can then override
the wishes of the administrators and send out the message anyway. Our
administrators are technical and will set limits based on what our
servers are able to handle. The moderators will be communications
experts who can assess the quality of the message but are not technical.
I supose what I'm looking for is the auto-reject facility for an
exceeded message size and I notice the same request scattered through
the mail archives. I wonder whether there is an accepted solution for
My task is to enhance the web admin interface for mailman-2.1.x, requested
by one of my customers. As a programmer, I learned that I need to add some
lines of code into Mailman/Cgi/admin.py (or listinfo.py).
I also learned that there are upcoming versions (2.2 and 3.0) which may have
a different (completely rewritten) interface. As far as I can understand the
current version (2.1.x) can be a widely used one for several years, so my
changes will be fruitful for the community for a few years or so.
I'd like to add the following new features. My customer is running 100+
different lists with 500+ users. So my customer asks me to give a web
interface for the following:
* Remove a given user from all lists. If a user to be removed is a list
admin, then a warning should come instead.
* Change the email address of a given user in all lists.
I know that these requests could be done via the command line interface, but
my customer would like to maintain these task via web.
My questions to you are:
* If my code is of quality, will it be a part of the mainstream code (from
2.1.14 or so)?
* Is admin.py the right place for such an enhancement?
Thank you for your answer in advance.
do still plan to create various plugin APIs for MM3?
If yes, which plugin types do you have on your mind?
Plugin-Types that came to my mind are:
Plugins that connect MM3 to an authentication provider. This could be an
internal provider, giving access to various authentication backends e.g. a
sqlite db, a socket based SQL server, a LDAP server or PAM, but also to
external providers such as OpenID etc.
Plugins that create a search index and provide (or expand an existing) a
Plugins that provide access to a mailing list archive.
Plugins that assist user/moderators/admins to filter messages or to
establish list policies (reject, permit, hold etc.).
Plugins that create and provide statistical information to
state of mind
Franziskanerstraße 15 Telefon +49 89 3090 4664
81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563