The mailfront program acts as a driver container, loading up a protocol module, a backend module, and a list of plugins at run time. All protocols are completely interchangeable, as are the backends.
The protocol and backend modules are specified as the first two command line arguments. The remainder of the command line arguments specify lists of plugins.
If $PLUGINS is set, it contains a list of plugins, separated by colons, that will be loaded after the plugins specified on the command line. If $MODULE_PATH is set, it specifies the directory in which modules will be loaded. Otherwise, the built in module path will be used, which is configured by editing the file conf-modules before building.
Each plugin name may be one of following three forms:
Note that in both cases where a plugin is loaded, it is first removed from the list if it was previously loaded. It is not possible for the same module to be loaded multiple times.
A configuration that would match previous installations of mailfront using the qmail backend would use the following list of plugins:
check-fqdn:counters:mailrules:relayclient:cvm-validate:qmail-validate:add-received:patterns:accept-sender
The included *front-qmail shell script wrappers for the mailfront program are preconfigured to load the above list of plugins before any of their command line arguments or $PLUGINS.
The protocol module is responsible for all interaction at the network I/O level with the client. It links into the system by calling down to the handler wrappers provided by mailfront, which in turn dispatches calls to the plugins and finally the backend.
The following protocols are available:
Plugins hook into the mail system at 5 main points:
At each of these events, mailfront goes through the list of loaded plugins. For each plugin that has a handler for such an event, mailfront calls that handler. If the handler returns no response, control passes to the next handler, otherwise no further handlers are called. If the returned code was an error, it is passed back to the protocol immediately, which will present it to the client. If the sender or recipient handlers of all the plugins return no response, the address is considered rejected, and it is not passed on to the back end. This is done to prevent the default configuration from being an open relay. Plugins may modify the sender or recipient address, but not the data (yet).
The following plugins are included in the main package:
The backend is the final stage in incoming mail handling, and is responsible for passing the message on to the mail system. It is invoked only if no plugin returned an error result. Other than the above two differences, the backend is structured identically to the plugins described above.
The following backends are available:
Some plugins require the use of a temporary file, either to be able to modify contents after receiving a message or to fulfill external timing requirements. These plugins are noted in their documentation above. The temporary files are created in the directory named by $TMPDIR (defaults to "/tmp").