www.postfix.org/MILTER_README.html
Postfix before-queue Milter support Introduction Postfix version 23 introduces support for Sendmail 8 Milter (mail filter) applications. A Milter application can instruct the MTA to accept, reject, discard or quarantine a connection, command, or message content;
Having yet another MTA-specific version of all that software is a poor use of human resources. Postfix 23 implements all the requests of Sendmail 8 Milter protocols up to version 4, except one: message body replacement.
Limitations Building Milter applications Although Milter applications can be written in C, JAVA or Perl, this text deals with C applications only. For these, you need a library that implements the Milter protocol. On some recent Linux and *BSD distributions, the Sendmail libmilter library is installed by default.
On other platforms you have two options: * Install the Sendmail libmilter library and the corresponding include files, then build the Milter applications. On Linux systems, libmilter is usually part of the sendmail-devel package.
After this, follow the installation instructions in the Milter source distribution to specify the location of the libmilter include files and library. systemtype/libmilter') Then build the Milter application. Running Milter applications To run a Milter application, see the documentation of the filter for options. Configuring Postfix Like Sendmail, Postfix has a lot of configuration options that control how it talks to Milter applications. Initially, many options are global, that is, they apply to all Milter applications. Future Postfix versions may support per-Milter timeouts, per-Milter error handling, etc.
You specify Milter applications by the name of their listening socket (other Milter options will be discussed below). The example below shows only one Milter application, but Postfix allows multiple milters.
Nowadays, Milter applications are also developed to sign mail so that other systems can detect spam, phishing, etc. Using such signing Milters is easy enough for mail that arrives via SMTP, but that does not handle submissions via the Postfix sendmail command line.
However, since there is no real ESMTP client involved, Milter applications must not reject these simulated SMTP events. When they do, Postfix will report a configuration error, but no mail will be lost. The general syntax for listening sockets is as follows: unix:pathname Connect to the local UNIX-domain server that is bound to the specified pathname.
cleanup process runs chrooted, an absolute pathname is interpreted relative to the Postfix queue directory. inet:host:port Connect to the specified TCP port on the specified local or remote host. The host and port can be specified in numeric or symbolic form. Note: Postfix syntax differs from Milter syntax which has the form inet:port@host.
milter_default_action parameter specifies how Postfix handles errors. The default is to respond with a temporary error status, so that the client will try again later. Specify "accept" if you want to receive mail as if the filter does not exist, and "reject" to reject mail with a permanent status.
milter_default_action = tempfail Milter protocol version As Postfix is not built with the Sendmail libmilter library, you may also need to configure the Milter protocol version that Postfix should use.
Milter protocol timeouts Postfix uses different time limits at different Milter protocol stages. The table shows wich timeouts are used and when (EOH = end of headers;
milter_content_timeout 100s HEADER, EOH, BODY, EOM Beware: 10s is not a lot for applications that do a lot of DNS lookups. However, if you increase the above timeouts too much, remote SMTP clients may hang up and mail may be delivered multiple times. This is an inherent problem with before-queue filtering. Sendmail macro emulation Postfix emulates a limited number of Sendmail macros, as shown in the table. Different macros are available at different SMTP protocol stages (EOM = end-of-message); their availability is not always the same as in Sendmail.
milter_macro_v Postfix sends specific sets of macros at different SMTP protocol stages. The sets are configured with the parameters as described in the table (EOM = end of message).
milter_unknown_command_macros 3 or higher unknown command Workarounds Sendmail Milter applications were originally developed for the Sendmail version 8 MTA, which has a different architecture than Postfix. The result is that some Milter applications make assumptions that don't hold outside the Sendmail environment.
com <unknown-msgid> This happens because the Milter application expects that the queue ID is known before the MTA accepts the MAIL FROM (sender) command. Postfix, on the other hand, does not create a queue file until after Postfix accepts the first valid RCPT TO (recipient) command. To work around the ugly message header, we add a little code to the Milter source to look up the queue ID after Postfix receives the end of the message. With some Milter applications we can fix both the WARNING and the "unknown-msgid" by postponing the call of mlfi_eoh() (or whatever routine logs the WARNING) until the end of the message. Other Milter applications will dump core when you do this. Limitations This section lists limitations of the Postfix Milter implementation. Some limitations will be removed disappear as support is extended over time. Of course the usual limitations of before-queue filtering will always apply.
cleanup server simulates SMTP events for connect, helo, mail from, rcpt to, and data. However, Milter applications must not reject these simulated SMTP events. Postfix will report a configuration error when this happens. This may be a problem when you want to apply a signing Milter to such mail.
SMTPD_PROXY_README), Milter applications have access only to the SMTP command information; they have no access to the message header or body, and cannot make modifications to the message or to the envelope.
|
http://csua.com/feed/