aMail planning

Some years ago I discovered a script for e-mail reading and sending, that should run as a CGI script and could read POP3 or IMAP mailboxes and send e-mails using SMTP. The amazing part of this one was that it had no dependences on any module: all protocols were implemented in a unique script. It worked fine, but only a little part of it was used each time it were run.

Once a friend and me began to use it for public access e-mail, and the first problem arrived: it must be converted to Spanish language, so two versions of the same scritp must be mantained.

To avoid these two problems I began to work on a simple library to print out simple phrases in Spanish and English: and Bit-Mail was born. Then I began to work in a new modular design, but a lot of work should be done and almost not time to do it.

Then I began to look for new ideas to enhance Bit-Mail and I discovered aMail, a full featured e-mail implemented in a few scripts. It seemed to be really good (and indeed it is) but many parts of it were still tied together.

The idea on aMail is to convert it in the best e-mail client available. Simple, uh ?

To achieve this goal, the next three objectives are of primary concern:

Security, Portability and Flexibility

Complementary to this aMail will not be restricted to be a web based e-mail reader, it should run as a CGI, standalone program inside a Mac, a Wintel or a toster. Why it should be tied to dbm ? Why it should be tied to POP3 and SMTP ?? WHY IT SHOULD BE TIED AT ALL ??!!!
To free aMail, it's a must to convert any part of it into modules that can be interchagned and EVEN deactivated to fit into each user needs.

Just take a picture of aMail in the future. You need an e-mail reader to replace your actual one, then you connect to http://aMail.sourceforge.net/configure and select each aMail feature in a dozen or so combo-boxes: interfeace type (web, standalone, etc.), storage requirements (filesystem, database, etc.), language (English, Spanish, Japanese ...), Look and feel (X-Windows, MS Windows, OpenLook, ... ) and other options. Then a list of files are downloaded to your machine and instructions on how to assemble it (or an installer, as you wish !!).

This dream its not difficult to achieve, mainly if modularization is kept in mind each time new features are added. At the end there will be an aMail-core and a lot of modules and plug-ins to be added to server each requirement: from a Palm e-mail reader to a million accounts mail hosting.

Module planning

As stated previously aMail will be converted in a core and a bunch of modules for each task to be performed: mail getting, mail sending, data storage, security checking, etc. This allows a more flexible growing, environment adaptation, easy development and bug isolation among others.

A sketch for module construction can be seen in the next figure :

As can be seen there's a level for user services (front end) and common services (back end), using Core and Security to coordinate and validate their communication.