Zander Mail Agent     a proud member of    SourceForge Logo

Changes and logs:
Current version: pre-Alpha peek
Presentation: ZanderMail Agent slide show
SourceFiles and Changes: CVS
Try It : here ( username: kaksi , passwd: kaksi )

Abstract
Zander Mail Agent Project started out, when four guys started to work a kinda R&D project about Kannel WAP Gateway to their school. At the same time they decided to make a somekinda software, which could be used in different kinda situations, to demostrate the functionality of the gateway. They figured out that why not make a somekinda usefull software as well, and decided to make a mail agent, which could be used to read emails in a wap phone and in multiple mailboxes simultaneously.

They started to design the system, and decided to implement it with PHP, because it was supposed to be a fairly easy task and a big part of the functions were already implemented. When desining the system, the requirements kept growing and growing, and we decided that after releasing the pre-Alpha or Alpha version, we would make the project public. So Here it is. Below are explained the basic rules and architecture of the system, and also some stuff to explain why we did the decisions like this and not the other way around.

You can get the files from CVS or ask more info from ZanderMail development group at sourceforge ...

Architecture
The basic system architecture leans strongly on objects. The 'biggest' object is the mailPool -object. This mailPool contains all your mailbox -objects that define the boxes you choose to view. You can create several mailbox objects, example get the INBOX of your work mail and the INBOX of your scools email box. Now you can look these two at the same time. These are all saved in the database and are downloaded from there everytime you access the system. While you use the zandermail , the mailPool object is stored in session, where the system uses it from.

All output is done through a pageFormatter object. The system creates a pageFormatter to a user when the user enters, giving a profile object in the constructor. The profile object is the corner stone of the architecture and the user can reshape it anyway she/he pleases.. that makes the system quite flexible. There is an lib/library.xml -file where the admin or the developers have defined some basic profiles for several terminal equipment. The ProfileParser object then reads out this file and constructs default profiles from this files. So when you access to the login page this archotecture is used, and if the admin or the developers have made enough profiles, you could login to the system in any terminal equipment. But how does the system know, to print example WML or HTML ? Its really quite simple. In the profile, there is a attribute called mappedNames. In the library.xml there is lets say 10 default profiles where each have a different mappedNames -value(s). If example the mappedNames value is Nokia7110, the system maps this profile to every user who enters to the page, with a string nokia7110 written his/hers user_agent environment variable. Now there is a also a output attribute in the profile which defines the output language. In this case it would of course be WML. This way user can create a own profile to every terminal equipment. There are a lot of attributes in the profile -object and user can own, and of course must own, many profile objects, which are the saved in to databes, where the system uses them from. Everytime you enter the system you get to use your own profile, and if there is not suitable one system will automatically create such profile for you, from default profiles, which are defined in the lib/library.xml. All the attributes and their functionality of the profileObject is explained later.

The menuObject is a collection of arrays, which each have there own place in the menu. When the menuObject is printed out (note that the pageFormatter does that), the profile defines which items of the menu is allowed to show. If the *configure_locales option false (User can define his/hers own profile), this option does not show in menu. Same way, there are many is_something_visible attributes in the profile, but this way we can create a neat and tidy view to every terminal equipment uniquely. Example in Nokias 7110 wap phone, when looking your emails , all attributes are set to false, but is_subject_visible. That way we can define that the subject of the email message of the only thing that is shown to the user. The subject of the message is actually the only thing that can fit basicly in to a one row to this wap phones display, but it could as easily be the sender of the email, the arrival date, or just the number of attachments, this decision we leave to you.

When writing this the pre-Aplha is not ready, and a lot of issues are still open. But the basic things like the security is thinked out. The system supports fully IMAP over SSL, so if the email server does not, thats too bad, then the system uses just plain IMAP -protocol. All the usernames and passwords of remote boxes are crypted to the database, like your system password as well. Next is the todo list and below that is the presentations and documentation of the objects and scripts used. Also some screens are available....

TODO:
BUG FIXES
improve the user / mailbox / profile adding functionality
Global interface for communication, such as SMS and VoiceMail
Festival speech generator integration from XmlOutPut, for voiceMail ( generated wavs )

Security
The system supports fully IMAP over SSL. If the mail server does not support that the system uses plain IMAP protocol .
The passwords of the remote boxes are crypted to the database, with a combination of each users unique_id and system password. Note that the system password is also crypted to database, so you are the only one who knows the actual encryption-encryption key, which is the actual salt value of encryption-algorihtm used in Zandermail....

There are also a lot of variables and other stuff that we store into session. The session handling and especially the save session handling is pretty poor in php (The default handler is a file so anyone can read your session_id and session variables from /tmp with a php script, cos the owner of that process is also the webserver), so we made our own save_session handler, which stores the session variables used, to a mySql database, encrypted of course. This way we make sure no-one hijacks your session, or reads out your session variables. This makes possible to run ZanderMail agent even from public servers, where normally it would be very risky, to run this kinda applications, because the nature of the php's save session handling...

Objects and scripts:


Making the system usefull:


Tutorials and Tricks: