Tue, 14 Nov 2006
Postfix Filtering
When I wrote about Posfix on the IS MU mailserver, I promised more details about my life with Postfix. So here we are:
I think one of the biggest pros of Postfix is that it has sane defaults. The only things you have to configure are those which are special for your setup. Now the cons: the biggest problem of Postfix is probably its filtering mechanism. When you want to do for example virus or spam filtering inside the SMTP session, there are three ways to do it:
The first one is the policy server - this is the server which listens
on a socket (often being run by master process), reads
requests from the SMTP server, and sends its verdicts to it (verdict
can be DUNNO, DISCARD, REJECT, etc). It is possible to have a policy server
for every part of the SMTP conversation - MAIL FROM, RCPT TO, DATA, end of
DATA, etc. Policy servers are great for implementing greylisting, for example.
However, there is one rather stupid property of the policy servers,
which renders them unusable for virus or spam filtering: even the end-of-DATA
policy server gets only the envelope information, and not the message itself.
Why implement an end-of-DATA policy server at all, when it doesn't get any
new information apart from what is already available in the DATA stage?
The second method is Milter (sendmail-compatible mail filtering
interface). However, it does not have a native library for writing milters,
and it requires sendmail to be installed and configured
as well. Blehhh.
The last method of filtering is SMTP proxy - you can write a SMTP proxy, and Postfix's SMTP server forwards the message to the proxy, which can then do any filtering/discarding/rejecting according to its policy. If the message is to be passed back to Postfix for further handling, the proxy should send it over SMTP as well (recommended configuration is to run another SMTP daemon bound to another port on the loopback interface). This is poorly documented, because nobody knows whether Postfix's SMTP server passes all commands to the proxy (and thus which features of [E]SMTP should the proxy implement), or whether the proxy gets the message in some simplified form.
I am not aware of any other filtering mechanism, which would not include writing its own SMTP server and client, and which would allow me to filter messages (decide whether to reject or discard the message, or pass it in, maybe with an added header). As a performance-wise bonus, it would be nice if the filtering mechanism allowed the message to be accessed directly as a file inside the queue, without copying data and sending it back.