Differences between revisions 18 and 19
Revision 18 as of 2010-07-25 02:52:07
Size: 8709
Editor: anna
Comment: updated info around web u/i
Revision 19 as of 2010-07-25 02:52:08
Size: 8745
Editor: anna
Comment: Migrated to Confluence 4.0
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma page-filename DEV/versions/14352445 #pragma page-filename DEV/versions/15958349
Line 3: Line 3:
This is where I am collecting the feature list and other artifacts for Mailman 3.0 which will be a major upgrade for the project. Many things that people have been wanting for years will be addressed, most notably a unified user database, true virtual domain support, and backing the Mailman data in a real database layer. From a development perspective, we will be adopting a very strict test-driven development model, utilizing modern Python technology and coding styles. The focus will be on providing core Mailman as a library for easy integration into other frameworks and sites, while continuing the tradition of providing a turnkey solution with all the necessary parts, making it even easier to download, install, and go.
Line 5: Line 4:
There is currently no ETA for Mailman 3, but development is moving quickly.  Contributors are welcome and encouraged!  Discussions will happen on the [[mailto:mailman-developers@python.org|mailman-developers mailing list]].  Anyone can check out and use the [[../MailmanBranches|current development source branches]].  The list below is not a commitment of features (unless marked with a '''Done''' :-) ). Add your own as comments and I will move as appropriate into the wish list.  You might also want to consider looking at the much more modest [[../Mailman 2.2|Mailman 2.2]] branch. This is where I am collecting the feature list and other artifacts for Mailman 3.0 which will be a major upgrade for the project. Many things that people have been wanting for years will be addressed, most notably a unified user database, true virtual domain support, and backing the Mailman data in a real database layer. From a development perspective, we will be adopting a very strict test-driven development model, utilizing modern Python technology and coding styles. The focus will be on providing core Mailman as a library for easy integration into other frameworks and sites, while continuing the tradition of providing a turnkey solution with all the necessary parts, making it even easier to download, install, and go.

There is currently no ETA for Mailman 3, but development is moving quickly. Contributors are welcome and encouraged! Discussions will happen on the [[mailto:mailman-developers@python.org|mailman-developers mailing list]]. Anyone can check out and use the [[../MailmanBranches|current development source branches]]. The list below is not a commitment of features (unless marked with a '''Done'''  ). Add your own as comments and I will move as appropriate into the wish list. You might also want to consider looking at the much more modest [[../Mailman 2.2|Mailman 2.2]] branch.
Line 8: Line 9:
Line 11: Line 13:
Line 12: Line 15:
Line 13: Line 17:
Line 17: Line 22:
 * Remove all unnecessary ''''future'''' statements ('''Done''')
 * Remove {{{True}}}/{{{False}}} hackery ('''Done''')
 * Remove all unnecessary _''future''_ statements ('''Done''')
 * Remove `True`/`False` hackery ('''Done''')
Line 20: Line 25:
 * Eliminate the use of {{{types}}} module as much as possible ('''Done''')  * Eliminate the use of `types` module as much as possible ('''Done''')
Line 22: Line 27:
 * Use the [[http://www.python.org/doc/current/lib/module-subprocess.html|subprocess]] module instead of things like {{{os.popen()}}}.  * Use the [[http://www.python.org/doc/current/lib/module-subprocess.html|subprocess]] module instead of things like `os.popen()`.
Line 24: Line 30:
 * Get rid of the "one list per site with the same name" restriction (cf. [[DOC/4.47 Virtual domain hosting with Mailman?|FAQ on Virtual domain hosting with Mailman]], Hans Ulrich Niedermann's [[http://nix.lauft.net/mailman/|vhost Branch]]) ('''Done''')
* Get rid of the "one list per site with the same name" restriction (cf. [[../../DOC/4.47 Virtual domain hosting with Mailman?|FAQ on Virtual domain hosting with Mailman]], Hans Ulrich Niedermann's [[http://nix.lauft.net/mailman/|vhost Branch]]) ('''Done''')
Line 26: Line 33:
Line 27: Line 35:
 * Strip nodup recipients from both the {{{To}}} and {{{Cc}}} headers, and juggle recipient headers so that the list address is always in the {{{To}}} field.  This might address the other major complaint against no-reply-to-munging, recipient proliferation.
* Strip nodup recipients from both the `To` and `Cc` headers, and juggle recipient headers so that the list address is always in the `To` field. This might address the other major complaint against no-reply-to-munging, recipient proliferation.
Line 29: Line 39:
A web UI improvement project was undertaken for the [[../Summer of Code|2006 summer of code]].  Although there were good ideas, we didn't end up with anything usable, so a new u/i subproject was coordinated. A link to this project can be found [[http://wiki.list.org/display/DEV/Web+Interface|here]].
A web UI improvement project was undertaken for the [[../Summer of Code|2006 summer of code]]. Although there were good ideas, we didn't end up with anything usable, so a new u/i subproject was coordinated. A link to this project can be found [[http://wiki.list.org/display/DEV/Web+Interface|here]].
Line 32: Line 43:
 * Add an option to allow ''verified'' non-members to post to the list.  A verified non-member is someone who posts to the list and responds in the affirmative to a confirmation message.  A verified member can post in the future (think [[http://www.gmane.org|Gmane]]).
* Add an option to allow ''verified'' non-members to post to the list. A verified non-member is someone who posts to the list and responds in the affirmative to a confirmation message. A verified member can post in the future (think [[http://www.gmane.org|Gmane]]).
Line 34: Line 46:
 * Get rid of password reminders altogether.  Encrypt member passwords and use a password reset feature instead of a reminder. ('''Done''')  * Get rid of password reminders altogether. Encrypt member passwords and use a password reset feature instead of a reminder. ('''Done''')
Line 36: Line 49:
 * Clean up our Unicode story!  All strings should be Unicode internally, with conversion at the boundaries of the system.  IWBNI we could get rid of all the catches of UnicodeErrors, however we may have to make changes to things like the email library.
* Clean up our Unicode story! All strings should be Unicode internally, with conversion at the boundaries of the system. IWBNI we could get rid of all the catches of UnicodeErrors, however we may have to make changes to things like the email library.
Line 39: Line 53:
 * Switch to $strings (i.e. {{{string.Template}}} instances) for all i18n substitutions.  We should be able to mechanically update all existing translations. ('''Under way''')  * Switch to $strings (i.e. `string.Template` instances) for all i18n substitutions. We should be able to mechanically update all existing translations. ('''Under way''')
Line 41: Line 55:
Line 42: Line 57:
Line 43: Line 59:
 * Hook into the [[../LMTP process|LMTP process]] so that messages can be disposed of as early as possible.  Check potential senders and recipients at LTMP time. ('''Under way''')  * Hook into the [[../LMTP process|LMTP process]] so that messages can be disposed of as early as possible. Check potential senders and recipients at LTMP time. ('''Under way''')
Line 45: Line 61:
Line 46: Line 63:
Line 61: Line 79:
 * Make ISO 8601 compliant? [[http://wiki.list.org/display/DEV/ISO+8601+date]]  * Make ISO 8601 compliant? [[http://wiki.list.org/display/DEV/ISO+8601+date|http://wiki.list.org/display/DEV/ISO+8601+date]]
Line 63: Line 82:
Line 71: Line 91:
 * For Postfix, switch to [[http://www.postfix.org/VIRTUAL_README.html|separate domains, non-UNIX accounts]] virtual domains and maildir delivery by default.  Delivery mechanics for other MTAs may or may not change.  * For Postfix, switch to [[http://www.postfix.org/VIRTUAL_README.html|separate domains, non-UNIX accounts]] virtual domains and maildir delivery by default. Delivery mechanics for other MTAs may or may not change.
Line 73: Line 93:
 * Fix the bounce probe problem, and make bounce processing more efficient.  Right now, it sucks.  * Fix the bounce probe problem, and make bounce processing more efficient. Right now, it sucks.

Mailman 3.0

This is where I am collecting the feature list and other artifacts for Mailman 3.0 which will be a major upgrade for the project. Many things that people have been wanting for years will be addressed, most notably a unified user database, true virtual domain support, and backing the Mailman data in a real database layer. From a development perspective, we will be adopting a very strict test-driven development model, utilizing modern Python technology and coding styles. The focus will be on providing core Mailman as a library for easy integration into other frameworks and sites, while continuing the tradition of providing a turnkey solution with all the necessary parts, making it even easier to download, install, and go.

There is currently no ETA for Mailman 3, but development is moving quickly. Contributors are welcome and encouraged! Discussions will happen on the mailman-developers mailing list. Anyone can check out and use the current development source branches. The list below is not a commitment of features (unless marked with a Done ). Add your own as comments and I will move as appropriate into the wish list. You might also want to consider looking at the much more modest Mailman 2.2 branch.

To Do List

Here are things we need to do before MM3 can be released.

  • Defend against runaway .bak file restore loops in the Switchboard.

(Potential) feature set

Compatibility and code cleaning

  • Python 2.6 or newer is required.

  • Switch to email 4 (Done)

  • Use Python's standard logging package throughout. (Done)

  • Convert the last of the string exceptions in Errors.py to class exceptions
  • Remove all unnecessary _future_ statements (Done)

  • Remove True/False hackery (Done)

  • Fix unit test suite! (Done)

  • Eliminate the use of types module as much as possible (Done)

  • Use the optparse module throughout instead of getopt. (Under way)

  • Use the subprocess module instead of things like os.popen().

Wart removal

Message cleanup

  • Strip nodup recipients from both the To and Cc headers, and juggle recipient headers so that the list address is always in the To field. This might address the other major complaint against no-reply-to-munging, recipient proliferation.

Web U/I

A web UI improvement project was undertaken for the 2006 summer of code. Although there were good ideas, we didn't end up with anything usable, so a new u/i subproject was coordinated. A link to this project can be found here.

Privacy

  • Add an option to allow verified non-members to post to the list. A verified non-member is someone who posts to the list and responds in the affirmative to a confirmation message. A verified member can post in the future (think Gmane).

  • Rosters should not be public by default.
  • Get rid of password reminders altogether. Encrypt member passwords and use a password reset feature instead of a reminder. (Done)

Internationalization

  • Clean up our Unicode story! All strings should be Unicode internally, with conversion at the boundaries of the system. IWBNI we could get rid of all the catches of UnicodeErrors, however we may have to make changes to things like the email library.

  • Switch to a new templating system that lets us share templates across languages, but extract messages for the catalog.
  • Finish the transition to an externally managed translation system

  • Switch to $strings (i.e. string.Template instances) for all i18n substitutions. We should be able to mechanically update all existing translations. (Under way)

  • Language variants (e.g. en_UK)

Spam defenses

  • Possibly integrate Spambayes or SpamAssassin or pyzor.

  • Hook into the LMTP process so that messages can be disposed of as early as possible. Check potential senders and recipients at LTMP time. (Under way)

  • Suppress backscatter bounces when SPF headers do not match.

Archiving

Note that what we can accomplish here will be based on the availability of an Archiving Champion.

  • Reconsider using a 3rd-party archiver
  • Perhaps URLs to messages should be based on message-ids instead of message numbers so that regenerating archives can't break links. This must include backward compatible links

  • Ditch direct access and vend all archive messages through CGI so that we can do address obfuscation, and message deletion, etc. on the fly (with caching of course, but have to worry about web crawlers).
  • Add RSS feed

  • Allow for admins to remove or edit messages through the web.
  • Move archive threads into another list?
  • Put archives in the list/mylist directory.

  • Add a search option
  • Make archives default template look and feel similar to Web UI (whatever it looks like after the Summer of Code project is done)

  • Make archive templatable (at least by changing CSS) so they can match people's existing site look-and-feel
  • MUAs usually make URLs clickable. An new Archive could be used when posts are distributed, in the footer, so that each message has a link to the whole thread in the Archive.
  • Present all messages in a thread at once, and offer plaintext download of the whole thread
  • Put messages into a database and/or move away from mbox as the canonical storage format.
  • Make ISO 8601 compliant? http://wiki.list.org/display/DEV/ISO+8601+date

Operational/Performance/Administration

  • Improve admin statistics gather (# of posts sent, # bounced, # of domains accessed, which lists are quiet and which are busy) and make these available via the web interface.
  • Use a real RDBM on the back end, through a Python-based ORM. (Done)

  • Caps for list member count and outgoing messages per time slice.
  • Better feedback to users who have bounced (e.g. put a link to their last bounced message on their member page).
  • The 'digest option' needs to be improved to delete 'double messages'
  • Add a datetime of when the user subscribed (Done)

  • Add audit train for user subscriptions. Who added them? What checks were made?
  • Provide a better list-data export and import mechanism via XML. Possibly allow for data export via the web.

  • For Postfix, switch to separate domains, non-UNIX accounts virtual domains and maildir delivery by default. Delivery mechanics for other MTAs may or may not change.

  • Partition queue directories into hashed subdirectories so that all queue files do not live in the same directory (which increases contention on the directory inodes and reduces overall performance).
  • Fix the bounce probe problem, and make bounce processing more efficient. Right now, it sucks.
  • Discard messages that have been in the bounces or shunt queues for a long time.
  • Include message headers in discard notifications - currently it isn't always possible to tell who sent a message that's been discarded, which makes it a bit pointless sending a notification. It would be nice to include brief headers in the first message part.
  • Increase user permission granularity per "checkbox requests" below
  • Add checkbox to moderation requests with option "Allow this user to ignore size limitations in the future"
  • Add checkbox to moderation requests with option "Allow this user to use implicit addressing in the future"
  • I don't know if this is a reasonable request or not, but if yes, could each user be allowed an override for post sizes (slightly different from above "ignore size in future" request)?


MailmanWiki: DEV/Mailman 3.0 (last edited 2018-04-20 06:57:02 by maxking)