PigeonDeliver -- PigeonAir Project

PigeonDeliver is a MDA, or Mail Delivery Agent, something taking care of storing emails received by your mail server (MTA, something like Sendmail, Postfix, Exim ...) on your disk. Oh, well, or at least this is the closest definition of PigeonDeliver I could think about.

Actually, PigeonDeliver is not limited to ``storing emails'' on the server. It is made of a set of modules inserted in a framework which allows advanced services to be offered and easing the task of writing new modules to offer new services.

PigeonDeliver modifies the delivery process of a mail so that for each recipient, a list of modules is built up, each module with a user specific configuration created by fetching data from a database and by enforcing a simple privilege mechanism based on even simpler override and ignore rules (actually, just flags :).

Once the list is built up, the delivery is taken care directly by modules, written using a simple and standard API, modules that are aware only of their own configuration and know nothing about other modules.

The PigeonDeliver framework thus creates a layer of abstraction over modules which allows them to be used on different mail servers and to be distributed among a cluster of mail servers. Currently, this sentence is not that true: while clusters are already well supported, only Postifix native API is supported while the standard unix MDA interface will be supported shortly (shorter than you may think).

All of the above means that:

• Each user can have its own configuration for every module. For example, an user may decide to disable the Antivirus for his own mailbox, or decide he doesn't want virus notification to be sent.
• Domain administrators can force user configurations and avoid them to change some or all of the configurations.
• Domain administrators can provide configurations for whole domains.
• Being all the configurations stored on a database, you can easily build interfaces to control the whole mail server. Adding/removing/renaming users/domains does not loose any email/configuration and requires a simple access to the database. Nothing more. Even if you have 10 mail servers in a cluster.
• It is very easy to add new modules to the mailing system, providing new features to users.
• If your system is not able to handle the load anymore, you can just add one more server to the cluster... no need to shut the service down or reconfigure the other nodes. As soon as a new node starts receiveing emails, it is part of the cluster.
• And much more...