One of the Systers' Google Summer of Code Projects is abstracting Mailman
authentication for use with other application frameworks via LDAP and
potentially OpenID, using a SQL Member Adaptor.
If anyone has a good round-up of existing code or efforts to do this in MM
2x (using a SQL Member Adaptor) or would be interested in providing some
mentoring support to our GSoC student leading the project (particularly with
regards to doing things the "Mailman Way"), please let me know.
If you are interested in contributing to the project, with either some
mentoring or code contributions -- please join our development mailing list
A quick search didn't find anything, so I'll do a more careful check
and if there's nothing I'll add a tracker RFE and a short wiki page of
the imagined feature, probably on Monday. Unfortunately, I can't
volunteer to implement at this time.
I noticed that we've been getting a lot of posts from users who are
being quite diligent about following up on their own issues, to the
extent of their knowledge and accesses, but for one reason or another
are not using the logs.
Would it be desirable and feasible to send a periodic (options: daily,
weekly, monthly, never) activity summary to list owners (similar to
the tracker summaries that many trackers send to associated mailing
If someone's list is having problems, then they could get access via
the admin interface, which would simply wrap the text report which
would be generated for mailing in an HTML PRE element, making for
trivial implementation (once the report itself is implemented, of
Week of May 17-23, 2009
44 incoming messages processed (42 posts, 2 other)
1 message automatically discarded
2 messages held (1 non-member, 1 spam filter) of which
2 messages were approved
41 messages distributed to members
2 weekly digests produced (maximum size reached 1 time(s))
20 SMTP errors occurred of which
18 posts handled normally by bounce processing
2 subscription requests (probable backscatter)
Abstract of discarded messages
From: hormel(a)163.com To: resident(a)whitehouse.gov
Subject: We cannot transfer $1 million to you without account information
Abstract of held messages not configured.
Abstract of SMTP errors not configured.
Hopkins, Justin wrote:
>I manage approx 50 discussion lists using the mailman system. The nature
>of our organization is that one member is more than likely subscribed to
>more than just 1 list. One issue that has come up among the membership
>is the desire to authenticate only once and then be permitted to access
>the private archives for all lists that they are subscribed to without
>logging in again.
>I've noticed that using administrative credentials created a cookie
>named 'site' whereas a normal login creates a cookie identifying the
>users email address and the individual list.
>Has anyone worked on changing this functionality, or is it planned for
>Mailman 3? I've scoured list archives and the internet in general and
>haven't found even a hint that anyone is working on this or even feels
>like it's worth complaining about.
Did you look at <http://wiki.list.org/x/vgAM>? The very first paragraph
says in part "Many things that people have been wanting for years will
be addressed, most notably a unified user database ...".
The unified user database will address this and several other issues
involving user email addresses, roles, authentication, etc.
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
On May 15, 2009, at 9:10 PM, Hopkins, Justin wrote:
> Has anyone worked on changing this functionality, or is it planned for
> Mailman 3? I've scoured list archives and the internet in general and
> haven't found even a hint that anyone is working on this or even feels
> like it's worth complaining about.
This will be the case in MM3, because you'll have just one 'account'
under the unified user database.
I manage approx 50 discussion lists using the mailman system. The nature
of our organization is that one member is more than likely subscribed to
more than just 1 list. One issue that has come up among the membership
is the desire to authenticate only once and then be permitted to access
the private archives for all lists that they are subscribed to without
logging in again.
I've noticed that using administrative credentials created a cookie
named 'site' whereas a normal login creates a cookie identifying the
users email address and the individual list.
Has anyone worked on changing this functionality, or is it planned for
Mailman 3? I've scoured list archives and the internet in general and
haven't found even a hint that anyone is working on this or even feels
like it's worth complaining about.
Justin J. Hopkins
MOBIUS, Internet Applications Specialist
On May 15, 2009, at 5:04 PM, Ralf Hildebrandt wrote:
> * Mark Sapiro <mark(a)msapiro.net>:
>> Charles Gregory wrote:
>>> Has anyone ever developed a point-n-click tool to delete
>>> a message from an archive, preferably by just eliminating the
>>> From/To/Subject and body, but leaving the links intact, with
>>> a placeholder message that says "message content removed", etc?
>> Not as far as I know.
> It would totally rule. Especially on python.org, where people regret
> posting their full name because "employers tend to google them", and
> then come running to us, asking "Please remove my name".
> But I like the idea of such a function.
I've long thought that all archives should be vended dynamically
rather than statically, of course with a cache to improve performance
as necessary. This would allow you to do lots of interesting things,
such as add links dynamically (e.g. "bug 12345" pointing to your bug
tracker), or on-the-fly modification of archive style or anti-spam
obfuscation, with the proper cache invalidation.
This would also allow you to "delete" a message from the archive, by
laying down a marker that causes the program to instead return a "not
available" or cleansed message without affecting the underlying data.
due to Python defaults, mailman exhibits strange behaviour when
processing UTF-8 emails.
When no header/footer is configured, mailman passes UTF-8 emails in
original form, i.e. 8bit.
However, when either header or footer is configured in mailman, it
uses Python's libraries to
add them and as a side effect it converts 8bit emails into 7bit base64
This is highly undesirable in some cases. For instance, mailinglist
might be used to distribute
trouble tickets or other content which is expected to be easily
parsable by automated text-based
utilities. With base64, emails grow in size by 33 % and such emails
are getting much higher spam
scores since base64 is typically used by spammers to obfuscate the
payload. There are of course
much more reasons for not using base64 as the primary encoding method
for UTF-8 email.
The fix is quite simple and is already widely used by other projects.
All that needs to be done is
to redefine Python's UTF-8 charset properties, i.e. in every place
where you have
from email.Charset import Charset
you need to add:
email.Charset.add_charset('utf-8',email.Charset.SHORTEST, None, None)
With such setting, mailman will keep the 8bit encoding also when it's
adding header/footer and won't downconvert to 7bit+base64. So I'd like
to propose the above addition, at least as a configurable option
if there's any fear that enabling it by default could cause some problems.
following our discussions at the Pycon 2009 Mailman sprint I've come up with
first draft of a/the future mailman 3 web interface.
The interface has changed a lot. Changes follow these principles:
* Simplify interface
* Focus on tasks
* Order and sort by task recurrance
* Reduce information overflow e.g. by hiding help messages
* Show help messages as bubbles when selected by user
* Remove instructions on using a web from
* Use default button texts e.g. "Save" instead of "Submit your changes"
See also: <http://wiki.list.org/display/DEV/Rest+client>
I've come up with a paper prototype, which you can download in an annotated
PDF by clicking at "Mailman webinterface draft" at the following location:
The version you can download is _not a design_. It's a grid that creates a
structure, puts elements we need on a (HTML) page, orders and groups them
following the principles I've outlined above.
Please feel free to comment on it and ask questions. I've spent the last 5
days clicking the old interface, thinking and sitting before my current
proposal - I just might be blind to my own stupidity or brain dead by now. ;)
My goal is to agree on an information architecture, so we can go on and
create a design that combines functional requirements and aesthetics.
Once we've agreed on a design, we will create HTML templates and then we will
put them together with the upcoming REST client.
state of mind
Agentur für Kommunikation, Design und Softwareentwicklung
Franziskanerstraße 15 Telefon +49 89 3090 4664
81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563