path: root/TODO

The Mailman TODO list

*Bugs
- "Stale" addresses don't update properly when new bounces come in 
  (stale means we had some bounces, but delivery to that address started 
  working again before we booted them from the list)
- Treat corrupted queue files more gracefully.

*Documentation
- A detailed feature list
- A user's guide
- A site-admin's guide
- A list-admin's guide
- More in-place documentation
- A developer's guide w/ Architecture and API info, etc.

*General Web UI
- Add a navigation sidebar to all web pages - central links, and
  list-specific links for list-specific pages.
- NO DEAD ENDS
- Implement cookies for edithtml and admindb
- Make sure when settings are changed, there is always some sort of 
  confirmation!

*List Admin UI
- Make it so mass-subscribe doesn't hang waiting for the mail transport to 
  do all delivery. (This may have been done w/ the admin cookie patches?)
- Time out admin requests, and have them auto-fail after that period.
- Allow the admin to edit posts in the database (put a header in the post 
  noting that it was edited by a moderator, however!)
- Have the option for moderator passwords, so that moderators don't have 
  access to the general list options.
- An -urgent address for each list that may only be posted to by the list 
  admin.  It will seem to be sent to the whole list, but will deliver to 
  everyone ASAP, and not wait for digests.
- A web UI to the -urgent address.
- Better options for the policy on bundling digests (periodic w/ arbitrary 
  periods, size based, a combo of the two, etc).
- A button that will bundle a digest right now (tm).
- Ability to set the next digest volume and issue number from the Web
- A generic error template page.
- An option for setting the precedence header.
- Make the MM-tags accept useful options where appropriate.
- Revamp the admindb user interface, it's fairly clunky (include a decent 
  cataloging mechanism based on the file system).
- Be able to edit ALL the web pages, as well as the mail messages.
- Use templates from the templates dir until the list owner changes
  the page, so the site admin can change them...
- All the list-admin to require approvals for unsubs
- Allow the admin to disable option settings by users
- Allow the admin to easily "retire" a list, both through the Web or
  email commands.
- Ability to set defaults for the various user settings from the
  "Membership Management" page. 
- Allow admins to control and set individual headers, adding,
  removing, or overriding those in the original message (sometimes
  very useful, but could be dangerous!)
- member management page should display case-preserved email addresses 
  (but still sort case-insensitively).

*List Member UI
- Editing your user options should put you back to the edit-options page. 
- Allow the user to be excluded from postings if they're getting them
  in the to: or cc: headers.
- An option to change your email address.  Or what might be easier:
  allow a user to clone the options of an existing user into a new
  address.
- Allow users to specify a different address for password reminders
  (w/ confirmation), or come up w/ a better strategy for remailing lists
  (could be done as the default, given a generic filter mechanism).
- Allow the user to get BOTH normal and digested delivery (but I still
  don't understand why someone would want this)

*Site Administrator's UI
- Make a web based site admin UI for adding lists, deleting lists, etc.
- Use a better storage mechanism for the site admin password
- Improve list deletion by requiring a valid password (from the shell script)

*Email Handling
- Implement a more general (form-based, like the netscape email
  filter) filtering/bouncing/etc. mechanism.  Or use VERP.
- Allow for programs to run that perform filtering / reformatting.
- Set aside messages IMMEDIATELY as a rescue mechanism... make sure no
  mails are ever lost, even if there turned out to be a bad Mailman bug.

*Mailcmd interface
- Provide an email interface to administrative commands.
- Allow email unsubs from matching address to unsubscribe, possibly
  adding an "allow open unsubscribes" option to control this.  Also,
  adding a confirmation with hit-reply to resubscribe.

*Portability concerns
- Replace cron stuff with our own scheduling mechanism

*Bounce handling
- Add more patterns for bounce handling
- Occasionally remove stale bounce entries
- Send mail to people who are being removed without their knowledge
  (even though they're likely not to get it).
- Clean the code up, make it more robust and efficient (see also BUGS)
- Or trash the current approach and use something better
- Reminders to disabled addresses.  The idea is that if an addr is
  disabled due to bouncing, we should send out periodic reminders.  We
  may want to do this for explicitly disabled addrs too, but perhaps
  with a different schedule.

*Pipermail + Archiving mechanism
- Search engine for archives
- Provide downloadable tar.gz's of the html archives
- sort by date should go most-recent to oldest
- allow list owner to edit archive messages
- support for alternative archiving systems, e.g. MHonArc, Hypermail
- archive link should do *something* reasonable before the first
  message has been posted to the list.
- optional form front-end to public interfaces as a filter to address
  harvesters.

*Code cleanup
- Use the re module where regexp and regsub are used.
- Refine any remaining unqualified exception guards to specify target 
  exceptions, when appropriate.
- Turn standard mailman exceptions into class exceptions. (In
  particular, categorize into, eg, message-hold vs other sorts of
  exceptions.)
- Make error messages indicate the file, mailing list, etc at fault,
  when possible.
- Separate edit-options from the subscribe script.
- Remove dead code, etc.

*News
- Allow crossposting.  This means no errors on duplicate messages, and 
  also avoiding the need to approve separately for each list.

*Misc
- Automatically update aliases again (fix alias wrapper)
- Make the listinfo pages static, and have them regenerate when options are 
  changed, or html is edited.
- Make it so Mailman can run as a threaded server (this feature should be 
  optional).
- The threaded server should be able to off its workload to friendly machines 
  if it is overworked (distributed support).
- Refine locking to lock only necessary sections to get rid of superfluous
  contention.
- Implement member profiles, using a class to store name,
  organization, description, etc, and default option settings.  The
  lists still can have their own data, but the user can set defaults in
  their profile...
- Need to go through and verify there are no obvious security problems.
- Restrict file and directory permissions as much as possible without
  breaking Mailman functionality.


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: