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



SquirrelMail Developer's Manual: SquirrelMail overview Next Previous Contents

1. SquirrelMail overview

SquirrelMail is a standards-based webmail package written in PHP. It includes built-in pure PHP support for the IMAP and SMTP protocols, and all pages render in pure HTML 4.0 (with no JavaScript required) for maximum compatibility across browsers. It has very few requirements and is very easy to configure and install. SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation.

1.1 The project goals

The founding principles of the SquirrelMail Project were aimed at an audience that was looking for a webmail application that would run on low end servers for clients with simple browsers and a small set of expectations. Well, the SquirrelMail user base has swollen greatly beyond the expectations of the original SquirrelMail developers. Much of this new audience often wants and needs a webmail client that will be much, much more.

In order to meet adequately the expanded needs of our current client base, the basic principles of the SquirrelMail Project must be expanded to include several additional items. The SquirrelMail Project goals are:

  1. SquirrelMail must be very easy to install and configure.
  2. SquirrelMail must have low server requirements, allowing it to be run on low-end hardware with just a basic Apache and PHP installation.
  3. SquirrelMail must have low client requirements, allowing it to be used on low end browsers without requiring any fancy JavaScript, or so forth.
  4. SquirrelMail will provide a complete webmail application that can be used as an individual's primary access point to email.
  5. SquirrelMail will maintain an architecture that will flex to the needs of a variety of system administrators, server configurations, and web browsers while maintaining efficiency and speed.

An important note is that the principles should be expanded and not replaced. This means that the original, founding requirements of the SquirrelMail project must never be overlooked as new and cool things are developed. Rather, special care should be taken to assure that both the new and the old is respected as development progresses and the capabilities of SquirrelMail are extended.

JavaScript

Some people argue that JavaScript isn't a fancy or heavy requirement anymore, and that the project goals should be revised. Well, JavaScript is neat and all, but some clients, such as lynx and links, lack support and will probably never get it. However, most things that can be done with JavaScript can also be done at the server side, and any JavaScript should only increase usability, not functionality. JavaScript isn't supposed to be anywhere in HTML except where JavaScript-aware browsers look anyway (i.e. in handlers for intrinsic events such as onclick, onload, and onmouseover). It's still important to be able to use SquirrelMail with non-JavaScript-aware browsers. If you detest lynx, think PDA, WAP and so on instead.

JavaScript code runs in the client browser but is not a "sandboxed" technology. This means that client-side JavaScript code doesn't have near the restrictions placed on it in regards to accessing local files and changing browser behavior as do more security conscious technologies like Java. Web developers should avoid using JavaScript in anything but the most trivial roles as site visitors who value their privacy and security may have configured their browser to ignore all or part of a page's JavaScript code. In addition to the myriad security and privacy problems with client-side JavaScript, JavaScript code often introduces browser dependencies due to slightly differing JavaScript parser implementations in various web browsers. Microsoft's web application development environments actually seem to take advantage of these incompatibilities to lock users into Internet Explorer.

Web application developers are encouraged to perform all input manipulation in server-side code or, if it is absolutely necessary, in client-side code that runs in a protective environment or "sandbox". Input validation should always be performed in server-side code despite the temptation to do so in client code in order to leverage libraries that allow "easier" client-side data validation. Google "Cross Site Scripting", "SQL Injection", and "client-side trust" for an explanation of the pitfalls associated with weak client-side input validation.

This doesn't mean that it's not allowed to make use of JavaScript in SquirrelMail or its plugins, but as much of the functionality as possible mustn't depend on it. Having extra JavaScript features is allowed if they respect the users' JavaScript preference setting.

1.2 Project management

The SquirrelMail Project Team is organized as four subteams, in order to get more good stuff done in a more organized fashion. There is no official project leader. Major decisions are more of a consensus between the team leaders. Each subteam has a leader (or two), who is responsible for coordinating the activities of their team, answering questions, and helping new developers/contributors get started. Even though we have team leaders, all project members are supposed to help out with the various tasks.

The stable branch team

Team leaders:

Jonathan Angliss <jon@squirrelmail.org>

Team responsibilities:

  1. Manage, prioritize, and fix submitted bugs regarding the stable branch.
  2. Prepare and maintain the stable branch road map.
  3. Decide when to make a new stable branch release.
  4. Preparing, releasing, and announcing the stable branch releases.
  5. Give input to the development team regarding the development branch going stable.
  6. Giving approval to a development version going stable.

The development branch team

Team leaders:

Vacant

Team responsibilities:

  1. Manage, prioritize, and fix submitted bugs regarding the development branch.
  2. Manage, prioritize, and implement submitted feature requests.
  3. Design and develop a clean, modular, and scalable architecture, and refactor the existing code to fit into it.
  4. Prepare and maintain the development branch road map.
  5. Decide when to make a new development branch release.
  6. Preparing, releasing, and announcing the development branch releases.
  7. Give input to the stable team regarding the development branch going stable.

The internationalization team

Team leader:

Fredrik Jervfors <jervfors@squirrelmail.org>

Team responsibilities:

  1. Organize the SquirrelMail translation collection.
  2. Validate plugins for compliance with the development guidelines regarding translations.
  3. Keep an eye on the licenses of various translations.
  4. Recruit new translators and add new languages.
  5. Try finding new maintainers for abandoned translations.

The plugin team

Team leader:

Paul Lesniewski <paul@squirrelmail.org>

Team responsibilities:

  1. Organize the SquirrelMail third party plugin collection.
  2. Validate plugins for compliance with the development guidelines.
  3. Keep an eye on the licenses of various plugins.
  4. Try finding new maintainers for abandoned plugins.
  5. Suggest plugins to be integrated in the core, or to become official plugins.

1.3 The community

Our most valuable resource

"If you treat your users as if they're your most valuable resource, they will respond by becoming your most valuable resource"

Good projects in both the open source and commercial world succeed because of a whole community of people who are involved in the project, not just because of the small set of individuals who actually did the tinkering with the code. Open source is power! Let's look at an example.

A short case study

"Who in the computer world doesn't know what WinAmp is? WinAmp, as far as I can tell, is the Windows MP3 player that was at the forefront of the intersection between the world of Windows users and the emerging standard of MP3 for digitally recorded audio. What about WinAmp made it so successful? Was it just because the program was the greatest thing in the world?

No, I think not. In fact, from everything I have ever seen, there are some really annoying things about the program. What made it so successful, in my opinion, is the community that grew around it.

When I first saw WinAmp, it was on a college campus. My computer only had Linux on it, so I did not install WinAmp. However, I noticed that it seemed everyone in the dormitory seemed to have WinAmp installed. More than that, they really were very big on the program. They loved the skins. They IDENTIFIED with it.

What is that? That is community. That is a person feeling that they are no longer just a user of the program, but part of the program itself. No, I am not talking about some new-age "being one with the program" thing here. I am just talking about the difference between feeling as if you are a part of something, or just an outsider."

What does this have to do with SquirrelMail?

The community of SquirrelMail itself is worth much more than just the sum of the developers. Just like a bright flashlight is dwarfed by the brightness of the sun, the SquirrelMail community must shine much brighter than the SquirrelMail development team itself. If it doesn't, SquirrelMail will not survive. After all, developers are real people. Real people graduate, have kids, get married, get busy, or get hit by ice cream trucks. Life goes on. The strength of the SquirrelMail community itself guarantees that there will always be life beneath the surface as it will continue to feed the strength of the development team itself.

The SquirrelMail Project Team

The SquirrelMail Project Team isn't just the developers. The change from being the SquirrelMail Development Team is to make that point more obvious. There are a lot of other peoples helping out too. Here are some examples:

Translators: A good percentage of the SquirrelMail end users don't understand English. The SquirrelMail translators work hard to make it so that people who use other languages still can use SquirrelMail. Who cares about some fancy new feature that a developer implements - if it is only available in English, it can not be globally used.

User support: Thank goodness for our precious user support people. These people patiently, repeatedly, respond to people's inquiries on the SquirrelMail mailing lists. They often answer the same questions over and over, and are very patient and consistent with their help. Without these people, where would we be?

So, in short and again, the point is that SquirrelMail is simply a lot more then its developers. We should all try to make the SquirrelMail community stronger, and the rest of the Project Team is just as important as the developers. We can only succeed by the time and effort of the team as a whole.


Next Previous Contents
© 1999-2010 by The SquirrelMail Project Team