10.1 Developing the Core

When a message is sent to many recipient and is handled by many modules, aegee-milter creates internally something like a table. Each column represents a recipient and each row is a module. When a module provides the same results for two recipients, then that cell in the table is extended and the two modules share the cell.

For example for a message with three recipients, that is handled by the modules delay and sieve, the table looks like:

The same latter in two cells means that the cell is shared.

Here, mod_sieve think that the result of the evaluation for rec1 and rec3 will be the same, therefore the cell in row mod_sieve in columns rec1 and rec3 is shared. mod_delay has for all recipients the same handling, therefore all cells in the last row a shared.

aegee-milter executes the code for each cell only once. In the above example mod_sieve will be executed for rec1 and rec3. For rec2 it will not be executed, because the result of executing it will be the same, as for rec1. mod_delay will be executed only once for this message and all recipients, since the result for executing the module for each recipient is the same.

The core exports a variable GKeyFile *inifile, which lists and modules can import with extern "C" GKeyFile *inifile. It points to the open INI configuration file. Lists and modules shall check the value only in the sections with their own name. Currently, if there is an unrecognized option in a section, the corresponding list/module throws an exception and aegee-milter terminates. However, if there is an unrecognized section name, the section is ignored.

The core stores per SMTP transaction data in a variable of type Privdata. This variable is passed to any call of the modules and is not passed to call to methods from the lists. It turned out in practice, that lists do not need the per SMTP transaction data, in order to serve their purpose.