Differences between revisions 5 and 6
Revision 5 as of 2013-02-16 16:36:34
Size: 10387
Editor: terri
Comment:
Revision 6 as of 2013-02-16 16:48:03
Size: 11459
Editor: terri
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma page-filename DEV/versions/15564931 #pragma page-filename DEV/versions/15564933
Line 47: Line 47:
The Mailman admin interface exposes a huge number of settings, but many lists will never use them.  We would like to have a variety of simplified interfaces specialized to various uses of Mailman (e.g. announcement list, discussion list, list where people only want to deal with moderation of messages and some related emergency features, etc) The Mailman admin interface exposes a huge number of settings, but many lists will never use them.  We would like to have a variety of simplified interfaces specialized to various uses of Mailman. 
Line 49: Line 49:
Some examples:
Line 50: Line 51:
 * An announcement list might require member management, management of authorized posters to the list, and moderation of list postings.
 * A "simple" discussion list might require member management, moderation of list postings, changes to list description, and changes to things that might trigger moderation

Although it is possible to build entirely separate new interfaces to mailman, we realize that many people will want to just use postorius and configure it to suit their needs, so ideally we would have a way of creating these themes from the main interface.  We might also want to use this theme system for more traditional theme elements such as colours and icons.  It's not yet clear the best way to do this: we might be able to achieve it using nothing more than CSS templates (this would be very lightweight and convenient in many circumstances; a fast way for anyone to see an interface customized for their most often used options) but there may also be cases where the site admin will want to disable options in the web interface for some users and not have it possible for them to circumvent it. 

We want someone to take a look at Postorius, the current Mailman web interface, and develop several proof of concept interface themes or views as well as a more general templating system to create more such themes in the future.
Line 148: Line 155:
'''Task level''': Advanced beginner (the actual technical work should not be too difficult, but you will need to be adept at reading code to find the correct places to make changes) '''Task level''':  Intermediate

GNU Mailman is hoping to participate in Google Summer of Code in 2013.  This page captures some ideas for student projects, links to setup guides, etc.

Table of Contents:

Required Skills

Incoming students will need the following skills:

  • Intermediate python programming
  • Familiarity with source control (Mailman core and Postorius use bzr, Hyperkitty uses git)
  • Ability to set up your own development environment for Mailman 

Additional desired skills may be listed with specific projects.

We're happy to help you get up to speed, but the more you are able to demonstrate ability in advance, the more likely we are to choose your application!

Getting Started

Interested in getting started with Mailman development?   Here are some links for potential students and mentors:

Mailman is written in python.  For developers, the path of least resistance is probably to use python 2.7+ (sadly not all our requirements handle python 3 yet) and work under Ubuntu Linux, although it is definitely possible to do development on other platforms.  It is definitely possible and encouraged to run your dev environment in a VM, although we do not currently have one set up and available to download.  (If you'd like to set one up and make it available for future developers, please email mailman-developers@python.org so we can help!)

Development work on Mailman 2.1 has been frozen for some time, so all new project ideas should be related to Mailman 3.

Getting in touch with the developers

If you're interested in participating in GSoC 2013 as a student, mentor, or interested community member, you should join the Mailman Developers mailing list: http://mail.python.org/mailman/listinfo/mailman-developers

Post any questions, comments, etc. to mailman-developers@python.org.

In addition you may be able to find us on IRC at #mailman on irc.freenode.org.  If no one is available to answer your question, please be patient and post it to the mailing list as well.  (We *are* the developers for Mailman -- unsurprisingly, most of us prefer to communicate via email.)

Project Ideas

Here are a few ideas for projects we would love to see completed.  If you have another idea you'd like to propose (either as a prospective student, mentor, or interested community member), please send it to mailman-developers@python.org for discussion!

Design interface "themes" for specific types of list

The Mailman admin interface exposes a huge number of settings, but many lists will never use them.  We would like to have a variety of simplified interfaces specialized to various uses of Mailman. 

Some examples:

  • An announcement list might require member management, management of authorized posters to the list, and moderation of list postings.
  • A "simple" discussion list might require member management, moderation of list postings, changes to list description, and changes to things that might trigger moderation

Although it is possible to build entirely separate new interfaces to mailman, we realize that many people will want to just use postorius and configure it to suit their needs, so ideally we would have a way of creating these themes from the main interface.  We might also want to use this theme system for more traditional theme elements such as colours and icons.  It's not yet clear the best way to do this: we might be able to achieve it using nothing more than CSS templates (this would be very lightweight and convenient in many circumstances; a fast way for anyone to see an interface customized for their most often used options) but there may also be cases where the site admin will want to disable options in the web interface for some users and not have it possible for them to circumvent it. 

We want someone to take a look at Postorius, the current Mailman web interface, and develop several proof of concept interface themes or views as well as a more general templating system to create more such themes in the future.

Task level: Intermediate

Desired skills (in addition to those named above): intermediate python, experience with django, web design (css/html/javascript), familiarity with common uses of mailing lists, ability to move past decision paralysis and make executive decisions (we expect there to be some community argument about the best choice when designing the architecture of this system: you need to be prepared to just choose something and do it.)

Log monitor

(Suggested by rsk)

Write Python scripts that monitor all of Mailman's logs, integrate what they find, and complain to the appropriate -owner addresses when bad things start happening. Bad things could be any of:

- repeated attempts to subscribe from same IP address/network block

- sudden increase in inbound traffic to otherwise-quiet list

- spike in unsubscriptions (maybe someone is forging them)

- etc.

Bonus points: integrate with HTTP and SMTP logs from which web server and whichever MTA are in play. (But this might might be better as a followon the next year. Given the diversity of the software in play and thus the diversity of the logs, it's a lot. So maybe the goal should be "don't design or code in a way that rules out doing this in the future".)

Task level: Intermediate

Desired skills (in addition to those named above): shell scripting, experience with simple visualizations might be helpful

Boilerplate stripper

(Suggested by rsk)

An increasing number of devices and services are starting to forcibly append boilerplate to users' email messages. This is annoying.

I'm talking about:

        Sent from my Android
        Sent from my Droid
        Sent from my HTC
        Sent from my Nexus

as well as the stuff appended by some freemail services.

 

So let's have a piece of code which has a catalog of these and can (if the list-owner so chooses) strip them off if they appear in the last N lines of a message.


Task level: Intermediate

Desired skills (in addition to those named above): regular expressions would probably be helpful.

Anti-spam/anti-abuse in Mailman

(Suggested by rsk)

One of the general principles of anti-spam work is that abuse control is best done as close to the origination point as possible: thus, stopping spam at your network perimeter is better than stopping it in your firewall is better than stopping it in your MTA is better than stopping it in Mailman.

However...Mailman has localized knowledge that none of the others do, so it's time to craft some serious anti-abuse clue into it -- not just to defend against incoming spam, but against *outgoing* spam, so that list operators don't find their operations blacklisted. What's needed is a flexible piece of code that holds dubious messages for moderation.

An example: freemail account hijackers are sending out messages where the entire body consists solely of a URL. That's an easy test and will stop a lot of spam that will otherwise pass, even on subscriber-only lists (because it's coming from a subscriber's account). Another example: "test" messages. They're either spam or annoying. Another example: messages whose Subject line matches certain key phrases (which I won't include here, in case your incoming mail is content filtered -- mine's not, I don't use it). Another example: any message from often-forged bogus addresses like fbi@gmail.com.

So basically the idea is: have a laundry list of tests, run them sequentially, if there are any hits, hold the message and tell the right -owner about it. The good news is that this is simple and fast: most tests are a regexp match. Also the false positive rate on some of these is zero, as in 0.000. The bad news is that once in a while there will be a false positive, but if it's rare enough and if the message need only be owner-approved to go through, then no harm.

Why *not* do this in the MTA?

  1. MTA doesn't know about lists and subscribers and patterns.
  2. Some servers mix mailing lists and end user traffic and different kinds of anti-spam are appropriate for each.
  3. Messages going *out* need much much more scrutiny than messages coming in -- much more important not to be a spam source/relay then to protect own addresses.
  4. As Mailman gains mindshare, it will come under increasing scrutiny and attack. Now would be a good time to get in front of it. Waiting until the inevitable happens will be too late.
  5. Mailing list owners often don't run the MTA.

Task level: Intermediate

Desired skills (in addition to those named above): familiarity with antispam work

Administrative email message log

(Suggested by rsk)

Add a configurable set of options that will instruct Mailman to keep a log of

(a) all incoming adminstrative messages and

(b) all outgoing administrative messages.

(a) can be kinda sorta done by configuring the MTA to send second copies elsewhere, but (b) can't...and this really should be done inside Mailman.

The log should consist of full copies of the messages in mbox format. This is useful for debugging, for dealing with attacks, AND for proving, when necessary, that someone really did opt-in or really did unsubscribe. (By administrative messages I mean anything to -request, -owner, etc., as well as outbound subscription confirmation requests.)

Task level:  Intermediate

Desired skills (in addition to those named above): none

Better content-filtering/handling error messages

(Suggested by rsk)

When messages have content stripped, make sure that the log includes the Message-ID, the MIME type, the file extension, the rule that fired, etc. so that if this was not what was intended, it's much easier to debug.

Task level: Advanced beginner (the actual technical work should not be too difficult, but you will need to be adept at reading code to find the correct places to make changes)

Desired skills (in addition to those named above): none

Not-fully-defined Project Ideas

These are some ideas that are not as well-defined, kept here for inspiration.  If you want to discuss any of these ideas, please send email to mailman-developers@python.org.

  1. Fixing bugs/adding features from the bug queues All of the components of Mailman have reasonably-maintained  bug queues.  It would be possible to build a GSoC project around a few wishlist items or desired bug fixes if none of the above projects appeals to you.  Do make sure to talk to the mailman-developers list to find out if any given set of bugs would be suitable.

MailmanWiki: DEV/Google Summer of Code 2013 (last edited 2015-03-04 06:03:22 by msapiro)