SquirrelMail  
Donations
News
About
Support
Security
Screen shots
Download
Plugins
Documentation
Sponsors
Bounties





Junk Email Filter






Security Notice
Phishing campain
Version 1.4.15
Security Upgrade

Google has initiated the [Google Summer of Code] project for 2007. In short: Google pays students to spend a summer on some open source project, mentored by someone from that project. Each project/student has one mentor from inside the project. These are the ideas that were approved on behalf of SquirrelMail.

The easiest way to contact the SquirrelMail Project regarding the Summer of Code is to use the [development mailing list].

Configuration reform

Mentor: Thijs Kinkhorst
Project page: GSoCConfigurationReform

SquirrelMail currently has an ancient configuration system, with bits distributed over multiple places. We can discern between system-wide settings done by the administrator, and per-user preferences. However, to most of our code these things are the same.

The system wide settings are currently just plain global variables that a function can therefore read. The user preferences use getPref() functions. A replacement could be a configuration class that provides read access to these variables for the code on the one side. On the other side this class would need input: the system wide settings from config.php and the user preferences from some (pluggable) preferences storage backend.

In summary:

  • The configuration class provides read access to variables for the code. Code doesn't need to know whether it's system or user preferences.
  • The configuration class can read system-wide preferences from some defined place (currently config/config.php)
  • The configuration class(es) can read user preferences from preference storage backends (currently file or SQL database), and provides a means to update these preferences as well (for use in options pages etc.).
  • The configuration class must have a way to enforce administrator set config/preferences. Enforced settings mustn't be displayed in the UI.
  • Both user and system configuration values need to be easily overridden by plugins

There's more improvements possible, e.g. replacing conf.pl or configtest.php with something better. Access control to user preferences is also an idea. Getting a good configuration class is a prerequisite though.

Plugin Management System

Mentor: Paul Lesniewski
Project page: ThePluginManagementProject

While not part of the SquirrelMail product itself, this is a project that is invaluable to every single administrator that downloads and installs SquirrelMail. The current SquirrelMail website organizes plugins in a simple but functional system. However, we have spent the last few years brainstorming an enormous list of changes for how we both manage plugin submission as well as plugin organization on the website.

The plugin system would be re-written from scratch, and done in a manner that allows it to be adapted with as little change as possible into a new website/look and feel (since at some point, the SquirrelMail website will change). It would provide several tools for people submitting their plugins, and for the plugin team who manage, negotiate, and approve the plugin submissions. On the website side, it would provide numerous ways for SquirrelMail administrators to view plugins by various criteria and determine compatibility between various SquirrelMail versions and the plugins they want. Other tools, such as RSS feeds for new plugin releases and so forth will also be part of the system.

The student would be provided with a long list of ideas and requirements as well as a tentative database schema that has been proposed for the system.

© 1999-2016 by The SquirrelMail Project Team