Cleanup: OpenLDAP now provides a sane solution for conflicts
with PAM ldap-over-tls. Victor Duchovni. File: global/dict_ldap.c.
-20900304
+20090304
Cleanup: skip over suspended or throttled queues while
looking for delivery requests. File: *qmgr/qmgr_transport.c.
Bugfix: don't disable MIME parsing with smtp_header_checks,
smtp_mime_header_checks, smtp_nested_header_checks or with
smtp_body_checks. Bug reported by Victor. File: smtp/smtp_proto.c.
+
+ Code cleanups: respect VSTRING invariants by using VSTRING_RESET
+ and VSTRING_TERMINATE instead of directly groping the
+ underlying character buffer. Files: global/dsn_buf.c,
+ milter/milter8.c.
+
+20090507
+
+ main.cf:tls_random_source now defaults to /dev/arandom on
+ OpenBSD. This device was introduced before Postfix development
+ began. Files: util/sys_defs.h, global/mail_params.h.
+
+20090510
+
+ Code cleanups: while emulating SMTP client requests for
+ Milter applications, use user@domain form addresses as
+ required by the SMTP protocol, instead of bare usernames.
+ This avoids hard to debug errors from some Milter applications.
+ Files: cleanup/cleanup_envelope.c, cleanup/cleanup_extracted.c,
+ cleanup/cleanup_addr.c.
+
+20090511
+
+ Code cleanups: don't clobber -o command-line arguments so
+ that Linux people can debug daemon command lines more easily.
+ Files: master/*server.c.
I\bIn\bnt\btr\bro\bod\bdu\buc\bct\bti\bio\bon\bn
-Postfix version 2.3 introduces support for the Sendmail version 8 Milter (mail
-filter) protocol. This protocol is used by applications that run outside the
-MTA to inspect SMTP events (CONNECT, DISCONNECT), SMTP commands (HELO, MAIL
-FROM, etc.) as well as mail content (headers and body). All this happens before
-mail is queued.
+Postfix implements support for the Sendmail version 8 Milter (mail filter)
+protocol. This protocol is used by applications that run outside the MTA to
+inspect SMTP events (CONNECT, DISCONNECT), SMTP commands (HELO, MAIL FROM,
+etc.) as well as mail content (headers and body). All this happens before mail
+is queued.
The reason for adding Milter support to Postfix is that there exists a large
collection of applications, not only to block unwanted mail, but also to verify
(DKIM), DomainKeys). Having yet another Postfix-specific version of all that
software is a poor use of human and system resources.
-Postfix version 2.4 implements all the requests of Sendmail version 8 Milter
-protocols up to version 4, including message body replacement (body replacement
-is not available with Postfix version 2.3). See, however, the workarounds and
-limitations sections at the end of this document.
+The Milter protocol has evolved over time, and different Postfix versions
+implement different feature sets. See the workarounds and limitations sections
+at the end of this document for differences between Postfix and Sendmail
+implementations.
This document provides information on the following topics:
H\bHo\bow\bw M\bMi\bil\blt\bte\ber\br a\bap\bpp\bpl\bli\bic\bca\bat\bti\bio\bon\bns\bs p\bpl\blu\bug\bg i\bin\bnt\bto\bo P\bPo\bos\bst\btf\bfi\bix\bx
The Postfix Milter implementation uses two different lists of mail filters: one
-list of filters that are used for SMTP mail only, and one list of filters that
-are used for non-SMTP mail. The two lists have different capabilities, which is
-unfortunate. Avoiding this would require major restructuring of Postfix.
+list of filters for SMTP mail only, and one list of filters for non-SMTP mail.
+The two lists have different capabilities, which is unfortunate. Avoiding this
+would require major restructuring of Postfix.
* The SMTP-only filters handle mail that arrives via the Postfix smtpd(8)
server. They are typically used to filter unwanted mail and to sign mail
shows how Milter applications plug into Postfix. Names followed by a number are
Postfix commands or server programs, while unnumbered names inside shaded areas
represent Postfix queues. To avoid clutter, the path for local submission is
-simplified (the OVERVIEW document has a more complete description).
+simplified (the OVERVIEW document has a more complete description of the
+Postfix architecture).
SMTP-only non-SMTP
filters filters
implements the Sendmail 8 Milter protocol. Postfix currently does not provide
such a library, but Sendmail does.
-On some Linux and *BSD distributions, the Sendmail libmilter library is
-installed by default. With this, applications such as dkim-milter and sid-
-milter build out of the box without requiring any tinkering:
+ * The first option is to use a pre-compiled library. Some systems install the
+ Sendmail libmilter library by default. With other systems, libmilter may be
+ provided by a package (called "sendmail-devel" on some Linux systems).
- $ g\bgz\bzc\bca\bat\bt d\bdk\bki\bim\bm-\b-m\bmi\bil\blt\bte\ber\br-\b-x\bx.\b.y\by.\b.z\bz.\b.t\bta\bar\br.\b.g\bgz\bz |\b| t\bta\bar\br x\bxf\bf -\b-
- $ c\bcd\bd d\bdk\bki\bim\bm-\b-m\bmi\bil\blt\bte\ber\br-\b-x\bx.\b.y\by.\b.z\bz
- $ m\bma\bak\bke\be
- [...lots of output omitted...]
+ Once libmilter is installed, applications such as dkim-milter and sid-
+ milter build out of the box without requiring any tinkering:
-On other platforms you have two options:
-
- * Install the Sendmail libmilter object library and include files. On Linux
- systems, libmilter may be provided by the sendmail-devel package. After
- installing libmilter, build the Milter applications as described in the
- preceding paragraph.
+ $ g\bgz\bzc\bca\bat\bt d\bdk\bki\bim\bm-\b-m\bmi\bil\blt\bte\ber\br-\b-x\bx.\b.y\by.\b.z\bz.\b.t\bta\bar\br.\b.g\bgz\bz |\b| t\bta\bar\br x\bxf\bf -\b-
+ $ c\bcd\bd d\bdk\bki\bim\bm-\b-m\bmi\bil\blt\bte\ber\br-\b-x\bx.\b.y\by.\b.z\bz
+ $ m\bma\bak\bke\be
+ [...lots of output omitted...]
- * Don't install the Sendmail libmilter library, but build the library from
- Sendmail source code instead:
+ * The other option is to build the libmilter library from Sendmail source
+ code:
$ g\bgz\bzc\bca\bat\bt s\bse\ben\bnd\bdm\bma\bai\bil\bl-\b-x\bx.\b.y\by.\b.z\bz.\b.t\bta\bar\br.\b.g\bgz\bz |\b| t\bta\bar\br x\bxf\bf -\b-
$ c\bcd\bd s\bse\ben\bnd\bdm\bma\bai\bil\bl-\b-x\bx.\b.y\by.\b.z\bz/\b/l\bli\bib\bbm\bmi\bil\blt\bte\ber\br
libmilter library simply hangs up without logging a warning, and you see a
Postfix warning message like one of the following:
- postfix/smtpd[21045]: warning: milter inet:host:port: can't read packet
- header: Unknown error : 0
- postfix/cleanup[15190]: warning: milter inet:host:port: can't read packet
- header: Success
+ warning: milter inet:host:port: can't read packet header: Unknown error : 0
+ warning: milter inet:host:port: can't read packet header: Success
+ warning: milter inet:host:port: can't read SMFIC_DATA reply packet header:
+ No such file or directory
The remedy is to lower the Postfix milter_protocol version number.
M\bMi\bil\blt\bte\ber\br p\bpr\bro\bot\bto\boc\bco\bol\bl t\bti\bim\bme\beo\bou\but\bts\bs
Postfix uses different time limits at different Milter protocol stages. The
-table shows wich timeouts are used and when (EOH = end of headers; EOM = end of
-message).
+table shows the timeout settings and the corresponding protocol stages (EOH =
+end of headers; EOM = end of message).
_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b
- |P\bPa\bar\bra\bam\bme\bet\bte\ber\br |T\bTi\bim\bme\be l\bli\bim\bmi\bit\bt|P\bPr\bro\bot\bto\boc\bco\bol\bl s\bst\bta\bag\bge\be |
+ |P\bPo\bos\bst\btf\bfi\bix\bx p\bpa\bar\bra\bam\bme\bet\bte\ber\br |T\bTi\bim\bme\be l\bli\bim\bmi\bit\bt|M\bMi\bil\blt\bte\ber\br p\bpr\bro\bot\bto\boc\bco\bol\bl s\bst\bta\bag\bge\be |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
|milter_connect_timeout|30s |CONNECT |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
|milter_content_timeout|300s |HEADER, EOH, BODY, EOM |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
-Beware: 30s may be too short for applications doing lots 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.
+Beware: 30s may be too short for Milter applications that do lots 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.
S\bSe\ben\bnd\bdm\bma\bai\bil\bl m\bma\bac\bcr\bro\bo e\bem\bmu\bul\bla\bat\bti\bio\bon\bn
Postfix emulates a limited number of Sendmail macros, as shown in the table.
Some macro values depend on whether a recipient is rejected (rejected
recipients are available on request by the Milter application). Different
-macros are available at different SMTP protocol stages (EOH = end-of-header,
+macros are available at different Milter protocol stages (EOH = end-of-header,
EOM = end-of-message); their availability is not always the same as in
Sendmail. See the workarounds section below for solutions.
_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b
- |N\bNa\bam\bme\be |A\bAv\bva\bai\bil\bla\bab\bbi\bil\bli\bit\bty\by |D\bDe\bes\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn |
+ |S\bSe\ben\bnd\bdm\bma\bai\bil\bl m\bma\bac\bcr\bro\bo |M\bMi\bil\blt\bte\ber\br p\bpr\bro\bot\bto\boc\bco\bol\bl s\bst\bta\bag\bge\be |D\bDe\bes\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |i |DATA, EOH, EOM |Queue ID |
+ |i |DATA, EOH, EOM |Queue ID, also Postfix |
+ | | |queue file name |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |j |Always |value of myhostname |
+ |j |Always |Value of myhostname |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
|_ |Always |The validated client name |
| | |and address |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
|{mail_addr} |MAIL |Sender address |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |{mail_host} |MAIL (Postfix >= 2.6) |Sender next-hop |
- | | |destination |
+ |{mail_host} |MAIL (Postfix >= 2.6, |Sender next-hop |
+ | |only with smtpd_milters) |destination |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |{mail_mailer} |MAIL (Postfix >= 2.6) |Sender mail delivery |
- | | |transport |
+ |{mail_mailer} |MAIL (Postfix >= 2.6, |Sender mail delivery |
+ | |only with smtpd_milters) |transport |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
| | |Recipient address |
|{rcpt_addr} |RCPT |With rejected recipient: |
| | |descriptive text |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
| | |Recipient next-hop |
- |{rcpt_host} |RCPT (Postfix >= 2.6) |destination |
- | | |With rejected recpient: |
+ |{rcpt_host} |RCPT (Postfix >= 2.6, |destination |
+ | |only with smtpd_milters) |With rejected recipient: |
| | |enhanced status code |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
| | |Recipient mail delivery |
- |{rcpt_mailer} |RCPT (Postfix >= 2.6) |transport |
- | | |With rejected recipient: |
+ |{rcpt_mailer} |RCPT (Postfix >= 2.6, |transport |
+ | |only with smtpd_milters) |With rejected recipient: |
| | |"error" |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
|{tls_version} |HELO, MAIL, DATA, EOH, |TLS protocol version |
|v |Always |value of milter_macro_v |
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
-Postfix sends specific sets of macros at different SMTP protocol stages. The
+Postfix sends specific sets of macros at different Milter protocol stages. The
sets are configured with the parameters as described in the table (EOH = end of
headers; EOM = end of message). The protocol version is a number that Postfix
sends at the beginning of the Milter protocol handshake.
- _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b
- |P\bPa\bar\bra\bam\bme\bet\bte\ber\br n\bna\bam\bme\be |P\bPr\bro\bot\bto\boc\bco\bol\bl v\bve\ber\brs\bsi\bio\bon\bn|P\bPr\bro\bot\bto\boc\bco\bol\bl s\bst\bta\bag\bge\be |
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |milter_connect_macros |2 or higher |CONNECT |
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |milter_helo_macros |2 or higher |HELO/EHLO |
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |milter_mail_macros |2 or higher |MAIL FROM |
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |milter_rcpt_macros |2 or higher |RCPT TO |
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |milter_data_macros |4 or higher |DATA |
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |milter_end_of_header_macros |6 or higher |EOH |
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |milter_end_of_data_macros |2 or higher |EOM |
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
- |milter_unknown_command_macros|3 or higher |unknown command|
- |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+As of Sendmail 8.14.0, Milter applications can specify what macros they want to
+receive at different Milter protocol stages. An application-specified list
+takes precedence over a Postfix-specified list.
+
+ _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b
+ |P\bPo\bos\bst\btf\bfi\bix\bx p\bpa\bar\bra\bam\bme\bet\bte\ber\br |M\bMi\bil\blt\bte\ber\br p\bpr\bro\bot\bto\boc\bco\bol\bl|M\bMi\bil\blt\bte\ber\br p\bpr\bro\bot\bto\boc\bco\bol\bl s\bst\bta\bag\bge\be|
+ | |v\bve\ber\brs\bsi\bio\bon\bn | |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |milter_connect_macros |2 or higher |CONNECT |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |milter_helo_macros |2 or higher |HELO/EHLO |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |milter_mail_macros |2 or higher |MAIL FROM |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |milter_rcpt_macros |2 or higher |RCPT TO |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |milter_data_macros |4 or higher |DATA |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |milter_end_of_header_macros |6 or higher |EOH |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |milter_end_of_data_macros |2 or higher |EOM |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ |milter_unknown_command_macros|3 or higher |unknown command |
+ |_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
W\bWo\bor\brk\bka\bar\bro\bou\bun\bnd\bds\bs
-Content filters may break DKIM etc. signatures. If you use an SMTP-based
-content filter, then you should add a line to master.cf with "-
-o disable_mime_output_conversion=yes" (note: no spaces around the "="), as
-described in the advanced content filter example.
-
-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 aren't true in a Postfix environment.
+ * To avoid breaking DKIM etc. signatures with an SMTP-based content filter,
+ update the before-filter SMTP client in master.cf, and add a line with "-
+ o disable_mime_output_conversion=yes" (note: no spaces around the "="). For
+ details, see the advanced content filter example.
+
+ /etc/postfix/master.cf:
+ # =============================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =============================================================
+ scan unix - - n - 10 smtp
+ -o smtp_send_xforward_command=yes
+ -o disable_mime_output_conversion=yes
+ -o smtp_generic_maps=
* Some Milter applications use the "{if_addr}" macro to recognize local mail;
this macro does not exist in Postfix. Workaround: use the "{client_addr}"
X-SenderID: Sendmail Sender-ID Filter vx.y.z host.example.com <unknown-
msgid>
- This happens because those Milter applications expect that the queue ID is
- known before the MTA accepts the MAIL FROM (sender) command. Postfix, on
- the other hand, does not choose a queue file name until after it accepts
- the first valid RCPT TO (recipient) command (Postfix queue file names must
- be unique across multiple directories, so the name can't be chosen before
- the file is created; if multiple messages were to use the same queue ID
- simultaneously, mail would be lost).
-
-If you experience the ugly header problem, see if a recent version of the
-Milter application fixes it. For example, current versions of dkim-filter and
-dk-filter already have code that looks up the Postfix queue ID at a later
-protocol stage.
-
-To fix the ugly message header with sid-filter applications, we change the
-source code, so that it does the queue ID lookup after Postfix receives the end
-of the message.
-
- * Edit the filter source file (named sid-filter/sid-filter.c).
-
- * Look up the smfilter table and replace mlfi_eoh by NULL.
-
- * Look up the mlfi_eom() function and add code near the top that calls
- mlfi_eoh() as shown by the b\bbo\bol\bld\bd text below:
-
- assert(ctx != NULL);
- #endif /* !DEBUG */
+ The problem is that Milter applications expect that the queue ID is known
+ before the MTA accepts the MAIL FROM (sender) command. Postfix does not
+ choose a queue ID, which is used as the queue file name, until after it
+ accepts the first valid RCPT TO (recipient) command.
- r\bre\bet\bt =\b= m\bml\blf\bfi\bi_\b_e\beo\boh\bh(\b(c\bct\btx\bx)\b);\b;
- i\bif\bf (\b(r\bre\bet\bt !\b!=\b= S\bSM\bMF\bFI\bIS\bS_\b_C\bCO\bON\bNT\bTI\bIN\bNU\bUE\bE)\b)
- r\bre\bet\btu\bur\brn\bn r\bre\bet\bt;\b;
+ If you experience the ugly header problem, see if a recent version of the
+ Milter application fixes it. For example, current versions of dkim-filter
+ and dk-filter already have code that looks up the Postfix queue ID at a
+ later protocol stage, and sid-filter version 1.0.0 no longer includes the
+ queue ID in the message header.
-NOTES:
+ To fix the ugly message header, you will need to add code that looks up the
+ Postfix queue ID at some later point im time. The example below adds the
+ lookup after the end-of-message.
- * This was tested with sid-milter-0.2.10 and sid-milter-0.2.14.
+ o Edit the filter source file (typically named xxx-filter/xxx-filter.c or
+ similar).
-To fix the ugly message header with other Milter applications, you will need to
-do something like this:
+ o Look up the mlfi_eom() function and add code near the top shown as b\bbo\bol\bld\bd
+ text below:
- * Edit the filter source file (typically named xxx-filter/xxx-filter.c or
- similar).
+ dfc = cc->cctx_msg;
+ assert(dfc != NULL);
- * Look up the mlfi_eom() function and add code near the top shown as b\bbo\bol\bld\bd
- text below:
+ /\b/*\b* D\bDe\bet\bte\ber\brm\bmi\bin\bne\be t\bth\bhe\be j\bjo\bob\bb I\bID\bD f\bfo\bor\br l\blo\bog\bgg\bgi\bin\bng\bg.\b. *\b*/\b/
+ i\bif\bf (\b(d\bdf\bfc\bc-\b->\b>m\bmc\bct\btx\bx_\b_j\bjo\bob\bbi\bid\bd =\b==\b= 0\b0 |\b||\b| s\bst\btr\brc\bcm\bmp\bp(\b(d\bdf\bfc\bc-\b->\b>m\bmc\bct\btx\bx_\b_j\bjo\bob\bbi\bid\bd,\b, J\bJO\bOB\bBI\bID\bDU\bUN\bNK\bKN\bNO\bOW\bWN\bN)\b) =\b==\b= 0\b0)\b)
+ {\b{
+ c\bch\bha\bar\br *\b*j\bjo\bob\bbi\bid\bd =\b= s\bsm\bmf\bfi\bi_\b_g\bge\bet\bts\bsy\bym\bmv\bva\bal\bl(\b(c\bct\btx\bx,\b, "\b"i\bi"\b")\b);\b;
+ i\bif\bf (\b(j\bjo\bob\bbi\bid\bd !\b!=\b= 0\b0)\b)
+ d\bdf\bfc\bc-\b->\b>m\bmc\bct\btx\bx_\b_j\bjo\bob\bbi\bid\bd =\b= j\bjo\bob\bbi\bid\bd;\b;
+ }\b}
- dfc = cc->cctx_msg;
- assert(dfc != NULL);
+ NOTES:
- /\b/*\b* D\bDe\bet\bte\ber\brm\bmi\bin\bne\be t\bth\bhe\be j\bjo\bob\bb I\bID\bD f\bfo\bor\br l\blo\bog\bgg\bgi\bin\bng\bg.\b. *\b*/\b/
- i\bif\bf (\b(d\bdf\bfc\bc-\b->\b>m\bmc\bct\btx\bx_\b_j\bjo\bob\bbi\bid\bd =\b==\b= 0\b0 |\b||\b| s\bst\btr\brc\bcm\bmp\bp(\b(d\bdf\bfc\bc-\b->\b>m\bmc\bct\btx\bx_\b_j\bjo\bob\bbi\bid\bd,\b, J\bJO\bOB\bBI\bID\bDU\bUN\bNK\bKN\bNO\bOW\bWN\bN)\b) =\b==\b= 0\b0)\b) {\b{
- c\bch\bha\bar\br *\b*j\bjo\bob\bbi\bid\bd =\b= s\bsm\bmf\bfi\bi_\b_g\bge\bet\bts\bsy\bym\bmv\bva\bal\bl(\b(c\bct\btx\bx,\b, "\b"i\bi"\b")\b);\b;
- i\bif\bf (\b(j\bjo\bob\bbi\bid\bd !\b!=\b= 0\b0)\b)
- d\bdf\bfc\bc-\b->\b>m\bmc\bct\btx\bx_\b_j\bjo\bob\bbi\bid\bd =\b= j\bjo\bob\bbi\bid\bd;\b;
- }\b}
+ o Different mail filters use slightly different names for variables. If
+ the above code does not compile, look elsewhere in the mail filter
+ source file for code that looks up the "i" macro value, and copy that
+ code.
- /* get hostname; used in the X header and in new MIME boundaries */
-
-NOTES:
-
- * Different mail filters use slightly different names for variables. If the
- above code does not compile, look for the code at the start of the mlfi_eoh
- () routine.
-
- * This fixes only the ugly message header, but not the WARNING message.
- Fortunately, many Milters log that message only once.
+ o This change fixes only the ugly message header, but not the WARNING
+ message. Fortunately, many Milters log that message only once.
L\bLi\bim\bmi\bit\bta\bat\bti\bio\bon\bns\bs
course the usual limitations of before-queue filtering will always apply. See
the CONTENT_INSPECTION_README document for a discussion.
+ * The Milter protocol has evolved over time. Therefore, different Postfix
+ versions implement different feature sets.
+
+ _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b
+ |P\bPo\bos\bst\btf\bfi\bix\bx|S\bSu\bup\bpp\bpo\bor\brt\bte\bed\bd M\bMi\bil\blt\bte\ber\br r\bre\beq\bqu\bue\bes\bst\bts\bs |
+ |_\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ | 2.6 |All Milter requests of Sendmail 8.14.0 (see notes below). |
+ |_\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ | |All Milter requests of Sendmail 8.14.0, except: |
+ | |SMFIP_RCPT_REJ (report rejected recipients to the mail filter), |
+ | 2.5 |SMFIR_CHGFROM (replace sender, with optional ESMTP parameters), |
+ | |SMFIR_ADDRCPT_PAR (add recipient, with optional ESMTP |
+ | |parameters). |
+ |_\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ | 2.4 |All Milter requests of Sendmail 8.13.0. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+ | 2.3 |All Milter requests of Sendmail 8.13.0, except: |
+ | |SMFIR_REPLBODY (replace message body). |
+ |_\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b |
+
* For Milter applications that are written in C, you need to use the Sendmail
libmilter library.
- * There are TWO sets of mail filters: filters that are used for SMTP mail
+ * Postfix has TWO sets of mail filters: filters that are used for SMTP mail
only (specified with the smtpd_milters parameter), and filters for non-SMTP
mail (specified with the non_smtpd_milters parameter). The non-SMTP filters
are primarily for local submissions.
- o When mail is filtered by non-SMTP filters, the Postfix cleanup(8)
- server has to simulate the SMTP client CONNECT and DISCONNECT events,
- and the SMTP client EHLO, MAIL FROM, RCPT TO and DATA commands. This
- works as expected, with only one exception: non-SMTP filters must not
- REJECT or TEMPFAIL simulated RCPT TO commands. When a non-SMTP filter
- REJECTs or TEMPFAILs a recipient, Postfix will report a configuration
- error, and mail will stay in the queue.
+ When mail is filtered by non_smtpd_milters, the Postfix cleanup(8) server
+ has to simulate SMTP client requests. This works as expected, with only one
+ exception: non_smtpd_milters must not REJECT or TEMPFAIL simulated RCPT TO
+ commands. When this rule is violated, Postfix will report a configuration
+ error, and mail will stay in the queue.
* Postfix currently does not apply content filters to mail that is forwarded
or aliased internally, or to mail that is generated internally such as
command information; they have no access to the message header or body, and
cannot make modifications to the message or to the envelope.
- * Postfix version 2.6 implements all Sendmail 8.14 Milter features, except it
- ignores the optional ESMTP command parameters with requests to replace the
- sender (SMFIR_CHGFROM), or to append a recipient (SMFIR_ADDRCPT_PAR). When
- a Milter application supplies ESMTP command parameters, these are logged as
- follows:
-
- postfix/cleanup[40629]: warning: 100B22B3293: cleanup_chg_from: ignoring
- ESMTP arguments "whatever"
+ * Postfix 2.6 ignores the optional ESMTP parameters in requests to replace
+ the sender (SMFIR_CHGFROM) or to append a recipient (SMFIR_ADDRCPT_PAR).
+ Postfix logs a warning message when a Milter application supplies such
+ ESMTP parameters:
- Specify "milter_protocol = 6" to enable all available Sendmail 8.14 and
- earlier Milter features.
+ warning: queue-id: cleanup_chg_from: ignoring ESMTP arguments "whatever"
+ warning: queue-id: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
- * Postfix version 2.5 implements all Sendmail 8.14 Milter features except:
- SMFIP_RCPT_REJ (report rejected recipients to the mail filter),
- SMFIR_CHGFROM (replace sender, with optional ESMTP command parameters), and
- SMFIR_ADDRCPT_PAR (add recipient, with optional ESMTP command parameters).
+ * Postfix 2.3 does not implement requests to replace the message body. Milter
+ applications log a warning message when they need this unsupported
+ operation:
- Specify "milter_protocol = 6" to enable all available Sendmail 8.14 and
- earlier Milter features.
-
- * Postfix 2.4 implements all Sendmail 8.13 Milter features.
-
- Specify "milter_protocol = 4" to enable all available Sendmail 8.13 and
- earlier Milter features.
-
- * Postfix 2.3 implements all Sendmail 8.13 Milter features except requests to
- replace the message body. Milter applications that request this unsupported
- operation will log a warning like
-
- application name: st_optionneg[134563840]: 0x3d does not fulfill action
- requirements 0x1e
+ st_optionneg[134563840]: 0x3d does not fulfill action requirements 0x1e
The solution is to use Postfix version 2.4 or later.
- Specify "milter_protocol = 4" to enable all available Sendmail 8.13 and
- earlier Milter features.
-
* Most Milter configuration options are global. Future Postfix versions may
support per-Milter timeouts, per-Milter error handling, etc.
NOTES:
* Lines 2, 11: the Postfix spawn(8) daemon by default kills its child process
- after 1000 seconds. This is too short for a policy daemon that may run for
- as long as an SMTP client is connected to an SMTP server process. The
- default time limit is overruled in main.cf with an explicit
- "policy_time_limit" setting. The name of the parameter is the name of the
- master.cf entry ("policy") concatenated with the "_time_limit" suffix.
+ after 1000 seconds. This is too short for a policy daemon that may need to
+ run for as long as the SMTP server process that talks to it. The default
+ time limit is overruled in main.cf with an explicit "policy_time_limit"
+ setting. The name of the parameter is the name of the master.cf entry
+ ("policy") concatenated with the "_time_limit" suffix. See spawn(8) for
+ more information about the time limit parameter.
* Line 2: specify a "0" process limit instead of the default "-", to avoid
"connection refused" and other problems when the smtpd process limit
-The stable Postfix release is called postfix-2.5.x where 2=major
-release number, 5=minor release number, x=patchlevel. The stable
+The stable Postfix release is called postfix-2.6.x where 2=major
+release number, 6=minor release number, x=patchlevel. The stable
release never changes except for patches that address bugs or
emergencies. Patches change the patchlevel and the release date.
New features are developed in snapshot releases. These are called
-postfix-2.6-yyyymmdd where yyyymmdd is the release date (yyyy=year,
+postfix-2.7-yyyymmdd where yyyymmdd is the release date (yyyy=year,
mm=month, dd=day). Patches are never issued for snapshot releases;
instead, a new snapshot is released.
The mail_release_date configuration parameter (format: yyyymmdd)
specifies the release date of a stable release or snapshot release.
-Incompatibility with snapshot 20090428
-======================================
-
-The Postfix SMTP client(!) no longer tries to use the obsolete SSLv2
-protocol by default, as this may prevent the use of modern SSL
-features. Lack of SSLv2 support should never be a problem, since
-SSLv3 was defined in 1996, and TLSv1 in 2006, but you can undo the
-change by specifying empty main.cf values for smtp_tls_protocols
-and lmtp_tls_protocols. The Postfix SMTP server maintains SSLv2
-support for backwards compatibility with ancient clients.
-
-The default Milter protocol version is increased from 2 to 6; this
-enables all available features up to and including Sendmail 8.14.0.
-The new milter_protocol setting may break compatibility with older
-Milter libraries or applications, and may cause Postfix to log
-warning messages such as:
-
- postfix/smtpd[21045]: warning: milter inet:host:port: can't read packet
- header: Unknown error : 0
- postfix/cleanup[15190]: warning: milter inet:host:port: can't read packet
- header: Success
-
-To restore compatibility, specify "milter_protocol = 2" in main.cf.
-
-Major changes with snapshot 20090428
-====================================
-
-The following improvements have been made to the Milter implementation:
-
-- Improved compatibility of the {mail_addr} and {rcpt_addr} macros.
-
-- Support for the {mail_host}, {mail_mailer}, {rcpt_host} and
-{rcpt_mailer} macros.
-
-- Milter applications can now request rejected recipients with the
-SMFIP_RCPT_REJ feature. Rejected recipients are reported with
-{rcpt_mailer} = "error", {rcpt_host} = enhanced status code, and
-{rcpt_addr} = descriptive text. This feature requires "milter_protocol
-= 6" or higher (default as of Postfix 2.6).
-
-- Milters can now replace the envelope sender address with the
-SMFIR_CHGFROM request, and can add recipients with SMFIR_ADDRCPT_PAR.
-These implementations currently ignore ESMTP command parameters
-with a warning message as follows:
-
- postfix/cleanup[40629]: warning: 100B22B3293: cleanup_chg_from:
- ignoring ESMTP arguments "whatever"
-
-Incompatibility with snapshot 20090330
-======================================
-
-Postfix now adds (Resent-) From:, Date:, Message-ID: or To: headers
-only when clients match $local_header_rewrite_clients. Specify
-"always_add_missing_headers = yes" for backwards compatibility.
-Adding such headers can break DKIM signatures that cover headers
-that are not present.
-
-This changes the appearance of Postfix logging: to preserve
-compatibility with existing logfile processing software, Postfix
-will log ``message-id=<>'' for messages without Message-Id header.
-
-Major changes with snapshot 20090212
-====================================
-
-Stress-dependent behavior by default. Under conditions of overload,
-smtpd_timeout is reduced from 300s to to 10s, smtpd_hard_error_limit
-is reduced from 20 to 1, and smtpd_junk_command_limit is reduced
-from 100 to 1. This will reduce the delays for most legitimate mail.
+If you upgrade from Postfix 2.4 or earlier, read RELEASE_NOTES-2.5
+before proceeding.
-Major changes with snapshot 20090121
-====================================
+Major changes - multi-instance support
+--------------------------------------
-Plug-in support for managing multiple Postfix instances. This can
-automatically apply your "postfix start" etc. command to multiple
-Postfix instances, including upgrades to new Postfix versions.
-Multi-instance support allows you to do the following and more:
+[Feature 20090121] Support for managing multiple Postfix instances.
+This can automatically apply your "postfix start" etc. command to
+multiple Postfix instances, including upgrades to new Postfix
+versions. Multi-instance support allows you to do the following
+and more:
- Simplify post-queue content filter configuration by using separate
Postfix instances before and after the filter. This simplifies
at Morgan Stanley. This version will be adapted to the new plug-in
API which makes some simplification possible.
-Major changes with snapshot 20090109
-====================================
+Major changes - milter support
+------------------------------
+
+[Feature 20090428] The following improvements have been made to the
+Milter implementation:
+
+- Improved compatibility of the {mail_addr} and {rcpt_addr} macros.
+
+- Support for the {mail_host}, {mail_mailer}, {rcpt_host} and
+{rcpt_mailer} macros.
+
+- Milter applications can now request rejected recipients with the
+SMFIP_RCPT_REJ feature. Rejected recipients are reported with
+{rcpt_mailer} = "error", {rcpt_host} = enhanced status code, and
+{rcpt_addr} = descriptive text. This feature requires "milter_protocol
+= 6" or higher (default as of Postfix 2.6).
+
+- Milters can now replace the envelope sender address with the
+SMFIR_CHGFROM request, and can add recipients with SMFIR_ADDRCPT_PAR.
+These implementations ignore ESMTP command parameters and log a
+warning message as follows:
+
+ warning: 100B22B3293: cleanup_chg_from: ignoring ESMTP arguments "whatever"
+ warning: 100B22B3293: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
+
+[Incompat 20090428] The default milter_protocol setting is increased
+from 2 to 6; this enables all available features up to and including
+Sendmail 8.14.0. The new milter_protocol setting may break
+compatibility with older Milter libraries or applications, and may
+cause Postfix to log warning messages such as:
+
+ warning: milter inet:host:port: can't read packet header: Unknown error : 0
-Support to selectively disable master(8) listener ports by service
-type or by service name + type. Specify a list of service types
-("inet", "unix", "fifo", or "pass") or "name.type" tuples, where
-"name" is the first field of a master.cf entry and "type" is a
-service type. Examples: to turn off the main SMTP listener port,
-use "master_service_disable = smtp.inet"; to turn off all TCP/IP
-listeners, use "master_service_disable = inet". Changing this
-parameter requires "postfix reload".
+ warning: milter inet:host:port: can't read packet header: Success
-Specify "tcp_windowsize = 65535" (or less) to work around routers
-with broken TCP window scaling implementations. This is perhaps
-more convenient than collecting tcpdump output and tuning kernel
-parameters by hand. With Postfix TCP servers (smtpd(8), qmqpd(8)),
-this feature is implemented by the Postfix master(8) daemon.
+ warning: milter inet:host:port: can't read SMFIC_DATA reply
+ packet header: No such file or directory
+
+To restore compatibility, specify "milter_protocol = 2" in main.cf.
+
+Major changes - security
+------------------------
+
+[Incompat 20080726] When a mailbox file is not owned by its recipient,
+the local and virtual delivery agents now log a warning and defer
+delivery. Specify "strict_mailbox_ownership = no" to ignore such
+ownership discrepancies.
+
+Major changes - smtp server
+---------------------------
+
+[Feature 20080212] check_reverse_client_hostname_access, to make
+access decisions based on the unverified client hostname. For
+safety reasons an OK result is not allowed.
+
+[Feature 20090210] With "reject_tempfail_action = defer", the Postfix
+SMTP server immediately replies with a 4xx status after some temporary
+error, instead of executing an implicit "defer_if_permit" action.
+
+[Feature 20090215] The Postfix SMTP server automatically hangs up
+after replying with "521". This makes overload handling more
+effective. See also RFC 1846 for prior art on this topic.
+
+[Feature 20090228] The Postfix SMTP server maintains a per-session
+"improper command pipelining detected" flag. This flag can be tested
+at any time with reject_unauth_pipelining, and is raised whenever
+a client command is followed by unexpected commands or message
+content. The Postfix SMTP server logs the first command pipelining
+transgression as "improper command pipelining after <command> from
+<hostname>[<hostaddress>]".
+
+[Feature 20090212] Stress-dependent behavior is enabled by default.
+Under conditions of overload, smtpd_timeout is reduced from 300s
+to 10s, smtpd_hard_error_limit is reduced from 20 to 1, and
+smtpd_junk_command_limit is reduced from 100 to 1. This will reduce
+the impact of overload for most legitimate mail.
+
+[Feature 20080629] The Postfix SMTP server's SASL authentication
+was re-structured. With "smtpd_tls_auth_only = yes", SASL support
+is now activated only after a successful TLS handshake. Earlier
+Postfix SMTP server versions could complain about unavailable SASL
+mechanisms during the plaintext phase of the SMTP protocol.
+
+[Incompat 20080510] In the policy delegation protocol, certificate
+common name attributes are now xtext encoded UTF-8. The xtext decoded
+attributes may contain any UTF-8 value except non-printable ASCII
+characters.
+
+Major changes - performance
+---------------------------
+
+[Feature 20090215] The Postfix SMTP server automatically hangs up
+after replying with "521". This makes overload handling more
+effective. See also RFC 1846 for prior art on this topic.
+
+[Feature 20090212] Stress-dependent behavior is enabled by default.
+Under conditions of overload, smtpd_timeout is reduced from 300s
+to 10s, smtpd_hard_error_limit is reduced from 20 to 1, and
+smtpd_junk_command_limit is reduced from 100 to 1. This will reduce
+the negative impact of server overload for most legitimate mail.
+
+[Feature 20090109] Specify "tcp_windowsize = 65535" (or less) to
+work around routers with broken TCP window scaling implementations.
+This is perhaps more convenient than collecting tcpdump output and
+tuning kernel parameters by hand. With Postfix TCP servers (smtpd(8),
+qmqpd(8)), this feature is implemented by the Postfix master(8)
+daemon.
To change this parameter without stopping Postfix, you need to first
terminate all Postfix TCP servers:
Of course you can also do "postfix stop" and "postfix start",
but that is more disruptive.
-Major changes with snapshot 20081010
-====================================
+Major changes - tls
+-------------------
+
+[Incompat 20090428] The Postfix SMTP client(!) no longer tries to
+use the obsolete SSLv2 protocol by default, as this may prevent the
+use of modern SSL features. Lack of SSLv2 support should never be
+a problem, since SSLv3 was defined in 1996, and TLSv1 in 1999. You
+can undo the change by specifying empty main.cf values for
+smtp_tls_protocols and lmtp_tls_protocols. The Postfix SMTP server
+maintains SSLv2 support for backwards compatibility with ancient
+clients.
+
+[Feature 20081010] Controls for the protocols and ciphers that
+Postfix will use with opportunistic TLS. The smtp_tls_protocols,
+smtp_tls_ciphers, and equivalent parameters for lmtp and smtpd
+provide global settings; the SMTP client TLS policy table provides
+ciphers and protocols settings for specific peers. Code by Victor
+Duchovni. Details are given in the TLS_README and postconf(5)
+documents.
+
+[Feature 20081108] Elliptic curve support. This requires OpenSSL
+version 0.9.9 or later.
+
+Major changes - address verification
+------------------------------------
+
+[Incompat 20080428] Postfix SMTP server replies for address
+verification have changed. unverified_recipient_reject_code and
+unverified_sender_reject_code now handle "5XX" rejects only. The
+"4XX" rejects are now controlled with unverified_sender_defer_code
+and unverified_recipient_defer_code.
+
+[Feature 20080428] Finer control over the way Postfix reports address
+verification failures to remote SMTP clients.
-Controls for the protocols and ciphers that Postfix will use with
-opportunistic TLS. The smtp_tls_protocols, smtp_tls_ciphers, and
-equivalent parameters for lmtp and smtpd provide global settings;
-the SMTP client TLS policy table provides ciphers and protocols
-settings for specific peers. Code by Victor Duchovni. Details are
-given in the TLS_README and postconf(5) documents.
+- unverified_sender/recipient_defer_code: the numerical Postfix
+ SMTP server reply code when address verification failed due
+ to some temporary error.
-Incompatibility with snapshot 20080814
-======================================
+- unverified_sender/recipient_reject_reason: fixed text that Postfix
+ will send to the remote SMTP client, instead of sending actual
+ address verification details.
-When a mailbox file is not owned by its recipient, the local and
-virtual delivery agents now log a warning and defer delivery.
-Specify "strict_mailbox_ownership = no" to ignore such ownership
-discrepancies.
+Major changes - dsn
+-------------------
-Incompatibility with snapshot 20080629
-======================================
+[Feature 20090307] New "lmtp_assume_final = yes" flag to send correct
+DSN "success" notifications when LMTP delivery is "final" as opposed
+to delivery into a content filter.
-When TLS support is not compiled in, the Postfix SMTP server no
-longer ignores the "smtpd_tls_auth_only = yes" parameter setting.
-Earlier Postfix SMTP server versions would announce SASL support,
-and would accept SASL login or sender information.
+Major changes - file organization
+---------------------------------
-Incompatibility with snapshot 20080726
-======================================
+[Incompat 20080207] According to discussions on the mailing list,
+too many people are breaking newly installed Postfix by overwriting
+the new /etc/postfix files with versions from an older release, and
+end up with a broken configuration that cannot repair itself. For
+this reason, postfix-script, postfix-files and post-install are
+moved away from /etc/postfix to $daemon_directory.
-When a mailbox file is not owned by its recipient, the local and
-virtual delivery agents now log a warning and defer delivery.
-Specify "strict_mailbox_ownership = no" to ignore such ownership
-discrepancies.
+Major changes - header rewriting
+--------------------------------
-Major changes with snapshot 20080629
-====================================
+[Incompat 20090330] Postfix now adds (Resent-) From:, Date:,
+Message-ID: or To: headers only when clients match
+$local_header_rewrite_clients. Specify "always_add_missing_headers
+= yes" for backwards compatibility. Adding such headers can break
+DKIM signatures that cover headers that are not present.
+compatibility with existing logfile processing software, Postfix
+will log ``message-id=<>'' for messages without Message-Id header.
-The Postfix SMTP server's SASL authentication was re-structured.
-With "smtpd_tls_auth_only = yes", SASL support is now activated
-only after a successful TLS handshake. Earlier Postfix SMTP server
-versions could complain about unavailable SASL mechanisms during
-the plaintext phase of the SMTP protocol.
+Major changes - lmtp client
+---------------------------
-Incompatibility with snapshot 20080510
-======================================
+[Feature 20090307] New "lmtp_assume_final = yes" flag to send correct
+DSN "success" notifications when LMTP delivery is "final" as opposed
+to delivery into a content filter.
-In the policy delegation protocol, certificate common name attributes
-are now xtext encoded UTF-8. The xtext decoded attributes may contain
-any UTF-8 value except non-printable ASCII characters.
+Major changes - logging
+-----------------------
-Incompatibility with snapshot 20080428
-======================================
+[Incompat 20090330] Postfix now adds (Resent-) From:, Date:,
+Message-ID: or To: headers only when clients match
+$local_header_rewrite_clients. Specify "always_add_missing_headers
+= yes" for backwards compatibility. Adding such headers can break
+DKIM signatures that cover headers that are not present.
-Postfix SMTP server replies for address verification have changed.
-unverified_recipient_reject_code and unverified_sender_reject_code
-now handle "5XX" rejects only. The "4XX" rejects are now controlled
-with unverified_sender_defer_code and unverified_recipient_defer_code.
+This changes the appearance of Postfix logging: to preserve
+compatibility with existing logfile processing software, Postfix
+will log ``message-id=<>'' for messages without Message-Id header.
-Major changes with snapshot 20080428
-====================================
+Major changes - mime
+--------------------
-Finer control over the way that Postfix reports address verification
-failures are reported to remote SMTP clients.
+[Feature 20080324] When the "postmap -q -" command reads lookup
+keys from standard input, it now understands RFC822 and MIME message
+format. Specify -h or -b to use headers or body lines as lookup
+keys, and specify -hm or -bm to simulate header_checks or body_checks.
-- unverified_sender/recipient_defer_code: the numerical Postfix
- SMTP server reply code when address verification failed due
- to some temporary error.
+Major changes - miscellaneous
+-----------------------------
-- unverified_sender/recipient_reject_reason: fixed text that Postfix
- will send to the remote SMTP client, instead of sending actual
- address verification details.
+[Feature 20090109] Support to selectively disable master(8) listener
+ports by service type or by service name + type. Specify a list of
+service types ("inet", "unix", "fifo", or "pass") or "name.type"
+tuples, where "name" is the first field of a master.cf entry and
+"type" is a service type. Examples: to turn off the main SMTP
+listener port, use "master_service_disable = smtp.inet"; to turn
+off all TCP/IP listeners, use "master_service_disable = inet".
+Changing this parameter requires "postfix reload".
-Incompatible changes with snapshot 20080207
-===========================================
+Major changes - sasl
+--------------------
-According to discussions on the mailing list, too many people are
-breaking newly installed Postfix by overwriting the new /etc/postfix
-files with versions from an older release, and end up with a broken
-configuration that cannot repair itself. For this reason, postfix-script,
-postfix-files and post-install are moved away from /etc/postfix to
-$daemon_directory.
+[Feature 20090418] The Postfix SMTP server passes more information
+to the Dovecot authentication server: the "TLS is active" flag, the
+server IP address, and the client IP address.
-Incompatible changes with Postfix 2.5.0
-=======================================
+[Feature 20080629] The Postfix SMTP server's SASL authentication
+was re-structured. With "smtpd_tls_auth_only = yes", SASL support
+is now activated only after a successful TLS handshake. Earlier
+Postfix SMTP server versions could complain about unavailable SASL
+mechanisms during the plaintext phase of the SMTP protocol.
-If you upgrade from Postfix 2.4 or earlier, read RELEASE_NOTES-2.5
-before proceeding.
<h2>Introduction</h2>
-<p> Postfix version 2.3 introduces support for the Sendmail version
-8 Milter (mail filter) protocol. This protocol is used by applications
-that run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT),
-SMTP commands (HELO, MAIL FROM, etc.) as well as mail content (headers
-and body). All this happens before mail is queued. </p>
+<p> Postfix implements support for the Sendmail version 8 Milter
+(mail filter) protocol. This protocol is used by applications that
+run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT),
+SMTP commands (HELO, MAIL FROM, etc.) as well as mail content
+(headers and body). All this happens before mail is queued. </p>
<p> The reason for adding Milter support to Postfix is that there
exists a large collection of applications, not only to block unwanted
Having yet another Postfix-specific version of all that software
is a poor use of human and system resources. </p>
-<p> Postfix version 2.4 implements all the requests of Sendmail
-version 8 Milter protocols up to version 4, including message body
-replacement (body replacement is not available with Postfix version
-2.3).
-See, however, the <a href="#workarounds">workarounds</a> and <a
+<p> The Milter protocol has evolved over time, and different Postfix
+versions implement different feature sets. See the <a
+href="#workarounds">workarounds</a> and <a
href="#limitations">limitations</a> sections at the end of this
-document. </p>
+document for differences between Postfix and Sendmail implementations.
+</p>
<p> This document provides information on the following topics: </p>
<h2><a name="plumbing">How Milter applications plug into Postfix </a> </h2>
<p> The Postfix Milter implementation uses two different lists of
-mail filters: one list of filters that are used for SMTP mail only,
-and one list of filters that are used for non-SMTP mail. The two
+mail filters: one list of filters for SMTP mail only,
+and one list of filters for non-SMTP mail. The two
lists have different capabilities, which is unfortunate. Avoiding
this would require major restructuring of Postfix. </p>
followed by a number are Postfix commands or server programs, while
unnumbered names inside shaded areas represent Postfix queues. To
avoid clutter, the path for local submission is simplified (the
-<a href="OVERVIEW.html">OVERVIEW</a> document has a more complete description). </p>
+<a href="OVERVIEW.html">OVERVIEW</a> document has a more complete description of the Postfix
+architecture). </p>
<blockquote>
Postfix currently does not provide such a library, but Sendmail
does. </p>
-<p> On some Linux and *BSD distributions, the Sendmail libmilter
-library is installed by default. With this, applications such as
-<a href="http://sourceforge.net/projects/dkim-milter/">dkim-milter</a>
-and <a href="http://sourceforge.net/projects/sid-milter/">sid-milter</a>
+<ul>
+
+<li> <p> The first option is to use a pre-compiled library. Some
+systems install the Sendmail libmilter library by default. With
+other systems, libmilter may be provided by a package (called
+"sendmail-devel" on some Linux systems). </p>
+
+<p> Once libmilter is installed, applications such as <a
+href="http://sourceforge.net/projects/dkim-milter/">dkim-milter</a> and
+<a href="http://sourceforge.net/projects/sid-milter/">sid-milter</a>
build out of the box without requiring any tinkering:</p>
<blockquote>
</pre>
</blockquote>
-<p> On other platforms you have two options: </p>
-
-<ul>
-
-<li> <p>Install the Sendmail libmilter object library and include
-files. On Linux systems, libmilter may be provided by the
-sendmail-devel package. After installing libmilter, build the
-Milter applications as described in the preceding paragraph. </p>
-
-<li> <p>Don't install the Sendmail libmilter library, but build the
-library from Sendmail source code instead: </p>
+<li> <p> The other option is to build the libmilter library from
+Sendmail source code: </p>
<blockquote>
<pre>
<blockquote>
<pre>
-postfix/smtpd[21045]: warning: milter inet:<i>host</i>:<i>port</i>: can't read packet header: Unknown error : 0
-postfix/cleanup[15190]: warning: milter inet:<i>host</i>:<i>port</i>: can't read packet header: Success
+warning: milter inet:<i>host</i>:<i>port</i>: can't read packet header: Unknown error : 0
+warning: milter inet:<i>host</i>:<i>port</i>: can't read packet header: Success
+warning: milter inet:<i>host</i>:<i>port</i>: can't read SMFIC_DATA reply packet header: No such file or directory
</pre>
</blockquote>
<h3><a name="timeouts">Milter protocol timeouts</a></h3>
<p> Postfix uses different time limits at different Milter protocol
-stages. The table shows wich timeouts are used and when
+stages. The table shows the timeout settings and the corresponding
+protocol stages
(EOH = end of headers; EOM = end of message). </p>
<blockquote>
<table border="1">
-<tr> <th> Parameter </th> <th> Time limit </th> <th> Protocol
-stage</th> </tr>
+<tr> <th> Postfix parameter </th> <th> Time limit </th> <th> Milter
+protocol stage</th> </tr>
<tr> <td> <a href="postconf.5.html#milter_connect_timeout">milter_connect_timeout</a> </td> <td> 30s </td> <td> CONNECT
</td> </tr>
</blockquote>
-<p> Beware: 30s may be too short for applications doing lots 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. </p>
+<p> Beware: 30s may be too short for Milter applications that do
+lots 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. </p>
<h3><a name="macros">Sendmail macro emulation</a></h3>
<p> Postfix emulates a limited number of Sendmail macros, as shown
in the table. Some macro values depend on whether a recipient is
rejected (rejected recipients are available on request by the Milter
-application). Different macros are available at different SMTP
+application). Different macros are available at different Milter
protocol stages (EOH = end-of-header, EOM = end-of-message); their
availability is not
always the same as in Sendmail. See the <a
<table border="1">
-<tr> <th> Name </th> <th> Availability </th> <th> Description </th>
-</tr>
+<tr> <th> Sendmail macro </th> <th> Milter protocol stage </th>
+<th> Description </th> </tr>
-<tr> <td> i </td> <td> DATA, EOH, EOM </td> <td> Queue ID </td> </tr>
+<tr> <td> i </td> <td> DATA, EOH, EOM </td> <td> Queue ID, also
+Postfix queue file name </td> </tr>
-<tr> <td> j </td> <td> Always </td> <td>
value of <a href="postconf.5.html#myhostname">myhostname</a> </td>
+<tr> <td> j </td> <td> Always </td> <td>
Value of <a href="postconf.5.html#myhostname">myhostname</a> </td>
</tr>
<tr> <td> _ </td> <td> Always </td> <td> The validated client name
<tr> <td> {mail_addr} </td> <td> MAIL </td> <td> Sender address
</td> </tr>
-<tr> <td> {mail_host} </td> <td> MAIL (Postfix ≥ 2.6) </td> <td>
-Sender next-hop destination </td> </tr>
+<tr> <td> {mail_host} </td> <td> MAIL (Postfix ≥ 2.6, only with
+<a href="postconf.5.html#smtpd_milters">smtpd_milters</a>) </td> <td> Sender next-hop destination </td> </tr>
-<tr> <td> {mail_mailer} </td> <td> MAIL (Postfix ≥ 2.6) </td>
-<td> Sender mail delivery transport </td> </tr>
+<tr> <td> {mail_mailer} </td> <td> MAIL (Postfix ≥ 2.6, only with
+<a href="postconf.5.html#smtpd_milters">smtpd_milters</a>) </td> <td> Sender mail delivery transport </td> </tr>
<tr> <td> {rcpt_addr} </td> <td> RCPT </td> <td> Recipient address
<br> With rejected recipient: descriptive text </td> </tr>
-<tr> <td> {rcpt_host} </td> <td> RCPT (Postfix ≥ 2.6) </td> <td>
-Recipient next-hop destination <br> With rejected recpient: enhanced
-status code </td> </tr>
+<tr> <td> {rcpt_host} </td> <td> RCPT (Postfix ≥ 2.6, only with
+<a href="postconf.5.html#smtpd_milters">smtpd_milters</a>) </td> <td> Recipient next-hop destination <br> With
+rejected recipient: enhanced status code </td> </tr>
-<tr> <td> {rcpt_mailer} </td> <td> RCPT (Postfix ≥ 2.6) </td>
-<td> Recipient mail delivery transport <br> With rejected recipient:
-"error" </td> </tr>
+<tr> <td> {rcpt_mailer} </td> <td> RCPT (Postfix ≥ 2.6, only with
+<a href="postconf.5.html#smtpd_milters">smtpd_milters</a>) </td> <td> Recipient mail delivery transport <br>
+With rejected recipient: "error" </td> </tr>
<tr> <td> {tls_version} </td> <td> HELO, MAIL, DATA, EOH, EOM </td>
<td> TLS protocol version </td> </tr>
</blockquote>
-<p> Postfix sends specific sets of macros at different SMTP protocol
+<p> Postfix sends specific sets of macros at different Milter protocol
stages. The sets are configured with the parameters as described
in the table (EOH = end of headers; EOM = end of message). The
protocol version is a number that Postfix sends at the beginning
of the Milter protocol handshake. </p>
+<p> As of Sendmail 8.14.0, Milter applications can specify what
+macros they want to receive at different Milter protocol stages.
+An application-specified list takes precedence over a Postfix-specified
+list. </p>
+
<blockquote>
<table border="1">
-<tr> <th> Parameter name </th> <th> Protocol version </th> <th>
-Protocol stage </th> </tr>
+<tr> <th> Postfix parameter </th> <th> Milter protocol version </th>
+<th> Milter protocol stage </th> </tr>
<tr> <td> <a href="postconf.5.html#milter_connect_macros">milter_connect_macros</a> </td> <td> 2 or higher </td> <td>
CONNECT </td> </tr>
<h2><a name="workarounds">Workarounds</a></h2>
-<p> Content filters may break DKIM etc. signatures. If you
-use an SMTP-based content filter, then you should add a line to
-<a href="master.5.html">master.cf</a> with "-o <a href="postconf.5.html#disable_mime_output_conversion">disable_mime_output_conversion</a>=yes" (note: no
-spaces around the "="), as described in the <a
+<ul>
+
+<li> <p> To avoid breaking DKIM etc. signatures with an SMTP-based
+content filter, update the before-filter SMTP client in <a href="master.5.html">master.cf</a>,
+and add a line with "-o <a href="postconf.5.html#disable_mime_output_conversion">disable_mime_output_conversion</a>=yes" (note:
+no spaces around the "="). For details, see the <a
href="FILTER_README.html#advanced_filter">advanced content filter</a>
example. </p>
-<p> 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 aren't true in a Postfix environment. </p>
-
-<ul>
+<pre>
+/etc/postfix/<a href="master.5.html">master.cf</a>:
+ # =============================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =============================================================
+ scan unix - - n - 10 smtp
+ -o <a href="postconf.5.html#smtp_send_xforward_command">smtp_send_xforward_command</a>=yes
+ -o <a href="postconf.5.html#disable_mime_output_conversion">disable_mime_output_conversion</a>=yes
+ -o <a href="postconf.5.html#smtp_generic_maps">smtp_generic_maps</a>=
+</pre>
<li> <p> Some Milter applications use the "<tt>{if_addr}</tt>" macro
to recognize local mail; this macro does not exist in Postfix.
</pre>
</blockquote>
-<p> This happens because those Milter applications expect that the
-queue ID is known <i>before</i> the MTA accepts the MAIL FROM
-(sender) command. Postfix, on the other hand, does not choose a
-queue file name until <i>after</i> it accepts the first valid RCPT
-TO (recipient) command (Postfix queue file names must be unique
-across multiple directories, so the name can't be chosen before the
-file is created; if multiple messages were to use the same queue
-ID <i>simultaneously</i>, mail would be lost). </p>
-
-</ul>
+<p> The problem is that Milter applications expect that the queue
+ID is known <i>before</i> the MTA accepts the MAIL FROM (sender)
+command. Postfix does not choose a queue ID, which is used as the
+queue file name, until <i>after</i> it accepts the first valid RCPT
+TO (recipient) command. </p>
<p> If you experience the ugly header problem, see if a recent
version of the Milter application fixes it. For example, current
versions of dkim-filter and dk-filter already have code that looks
-up the Postfix queue ID at a later protocol stage. </p>
-
-<p> To fix the ugly message header with sid-filter applications,
-we change the source code, so that it does the queue ID lookup after
-Postfix receives the end of the message. </p>
-
-<ul>
-
-<li> <p> Edit the filter source file (named
-<tt>sid-filter/sid-filter.c</tt>). </p>
-
-<li> <p> Look up the <tt>smfilter</tt> table and replace
-<tt>mlfi_eoh</tt> by <tt>NULL</tt>.
+up the Postfix queue ID at a later protocol stage, and sid-filter
+version 1.0.0 no longer includes the queue ID in the message header.
</p>
-<li> <p> Look up the <tt>mlfi_eom()</tt> function and add code near
-the top that calls <tt>mlfi_eoh()</tt> as shown by the <b>bold</b>
-text below: </p>
-
-</ul>
-
-<blockquote>
-<pre>
- assert(ctx != NULL);
-#endif /* !DEBUG */
-<b>
- ret = mlfi_eoh(ctx);
- if (ret != SMFIS_CONTINUE)
- return ret;</b>
-</pre>
-</blockquote>
-
-<p> NOTES: </p>
-
-<ul>
-
-<li> <p> This was tested with sid-milter-0.2.10 and sid-milter-0.2.14. </p>
-
-</ul>
-
-<p> To fix the ugly message header with other Milter applications,
-you will need to do something like this: </p>
+<p> To fix the ugly message header, you will need to add code that
+looks up the Postfix queue ID at some later point im time. The
+example below adds the lookup after the end-of-message. </p>
<ul>
if (jobid != 0)
dfc->mctx_jobid = jobid;
}</b>
-
-/* get hostname; used in the X header and in new MIME boundaries */
</pre>
</blockquote>
<ul>
<li> <p> Different mail filters use slightly different names for
-variables. If the above code does not compile, look for the code
-at the start of the <tt>mlfi_eoh()</tt> routine. </p>
+variables. If the above code does not compile, look elsewhere in
+the mail filter source file for code that looks up the "i" macro
+value, and copy that code. </p>
-<li> <p> This fixes only the ugly message header, but not the WARNING
-message. Fortunately, many Milters log that message only once. </p>
+<li> <p> This change fixes only the ugly message header, but not
+the WARNING message. Fortunately, many Milters log that message
+only once. </p>
+
+</ul>
</ul>
<ul>
+<li> <p> The Milter protocol has evolved over time. Therefore,
+different Postfix versions implement different feature sets. </p>
+
+<table border="1">
+
+<tr> <th> Postfix </th> <th> Supported Milter requests </th>
+</tr>
+
+<tr> <td align="center"> 2.6 </td> <td> All Milter requests of
+Sendmail 8.14.0 (see notes below). </td> </tr>
+
+<tr> <td align="center"> 2.5 </td> <td> All Milter requests of
+Sendmail 8.14.0, except: <br> SMFIP_RCPT_REJ (report rejected
+recipients to the mail filter), <br> SMFIR_CHGFROM (replace sender,
+with optional ESMTP parameters), <br> SMFIR_ADDRCPT_PAR (add
+recipient, with optional ESMTP parameters). </td> </tr>
+
+<tr> <td align="center"> 2.4 </td> <td> All Milter requests of
+Sendmail 8.13.0. </td> </tr>
+
+<tr> <td align="center"> 2.3 </td> <td> All Milter requests of
+Sendmail 8.13.0, except: <br> SMFIR_REPLBODY (replace message body).
+
+</table>
+
<li> <p> For Milter applications that are written in C, you need
to use the Sendmail libmilter library. </p>
-<li> <p> There are TWO sets of mail filters: filters that are used
+<li> <p> Postfix has TWO sets of mail filters: filters that are used
for SMTP mail only (specified with the <a href="postconf.5.html#smtpd_milters">smtpd_milters</a> parameter),
and filters for non-SMTP mail (specified with the <a href="postconf.5.html#non_smtpd_milters">non_smtpd_milters</a>
parameter). The non-SMTP filters are primarily for local submissions.
</p>
-<ul>
-
-<li> <p> When mail is filtered by non-SMTP filters, the Postfix
-<a href="cleanup.8.html">cleanup(8)</a> server has to simulate the SMTP client CONNECT and
-DISCONNECT events, and the SMTP client EHLO, MAIL FROM, RCPT TO and
-DATA commands. This works as expected, with only one exception:
-non-SMTP filters must not REJECT or TEMPFAIL simulated RCPT TO
-commands. When a non-SMTP filter REJECTs or TEMPFAILs a recipient,
+<p> When mail is filtered by <a href="postconf.5.html#non_smtpd_milters">non_smtpd_milters</a>, the Postfix <a href="cleanup.8.html">cleanup(8)</a>
+server has to simulate SMTP client requests. This works as expected,
+with only one exception: <a href="postconf.5.html#non_smtpd_milters">non_smtpd_milters</a> must not REJECT or
+TEMPFAIL simulated RCPT TO commands. When this rule is violated,
Postfix will report a configuration error, and mail will stay in
the queue. </p>
-</ul>
-
<li> <p> Postfix currently does not apply content filters to mail
that is forwarded or aliased internally, or to mail that is generated
internally such as bounces or Postmaster notifications. This may
message header or body, and cannot make modifications to the message
or to the envelope. </p>
-<li> <p> Postfix version 2.6 implements all Sendmail 8.14 Milter
-features, except it ignores the optional ESMTP command parameters
-with requests to replace the sender (SMFIR_CHGFROM), or to append
-a recipient (SMFIR_ADDRCPT_PAR). When a Milter application supplies
-ESMTP command parameters, these are logged as follows: </p>
+<li> <p> Postfix 2.6 ignores the optional ESMTP parameters in
+requests to replace the sender (SMFIR_CHGFROM) or to append a
+recipient (SMFIR_ADDRCPT_PAR). Postfix logs a warning message when
+a Milter application supplies such ESMTP parameters: </p>
<pre>
-postfix/cleanup[40629]: warning: 100B22B3293: cleanup_chg_from: ignoring ESMTP arguments "<i>whatever</i>"
+warning: <i>queue-id</i>: cleanup_chg_from: ignoring ESMTP arguments "<i>whatever</i>"
+warning: <i>queue-id</i>: cleanup_add_rcpt: ignoring ESMTP arguments "<i>whatever</i>"
</pre>
-<p> Specify "<a href="postconf.5.html#milter_protocol">milter_protocol</a> = 6" to enable all available Sendmail
-8.14 and earlier Milter features. </p>
-
-<li> <p> Postfix version 2.5 implements all Sendmail 8.14 Milter
-features except: SMFIP_RCPT_REJ (report rejected recipients to the
-mail filter), SMFIR_CHGFROM (replace sender, with optional ESMTP
-command parameters), and SMFIR_ADDRCPT_PAR (add recipient, with
-optional ESMTP command parameters). </p>
+<li> <p> Postfix 2.3 does not implement requests to replace the
+message body. Milter applications log a warning message when they
+need this unsupported operation: </p>
-<p> Specify "<a href="postconf.5.html#milter_protocol">milter_protocol</a> = 6" to enable all available Sendmail
-8.14 and earlier Milter features. </p>
-
-<li> <p> Postfix 2.4 implements all Sendmail 8.13 Milter features.
-</p>
-
-<p> Specify "<a href="postconf.5.html#milter_protocol">milter_protocol</a> = 4" to enable all available Sendmail
-8.13 and earlier Milter features. </p>
-
-<li> <p> Postfix 2.3 implements all Sendmail 8.13 Milter features
-except requests to replace the message body. Milter applications
-that request this unsupported operation will log a warning like
-
-<blockquote>
<pre>
-<i>application name</i>: st_optionneg[134563840]: 0x3d does not fulfill action requirements 0x1e
+st_optionneg[134563840]: 0x3d does not fulfill action requirements 0x1e
</pre>
-</blockquote>
<p> The solution is to use Postfix version 2.4 or later. </p>
-<p> Specify "<a href="postconf.5.html#milter_protocol">milter_protocol</a> = 4" to enable all available Sendmail
-8.13 and earlier Milter features. </p>
-
<li> <p> Most Milter configuration options are global. Future Postfix
versions may support per-Milter timeouts, per-Milter error handling,
etc. </p>
<li> <p> Lines 2, 11: the Postfix <a href="spawn.8.html">spawn(8)</a> daemon by default kills
its child process after 1000 seconds. This is too short for a
-policy daemon that may run for as long as an SMTP client is connected
-to an SMTP server process. The default time limit is overruled in
+policy daemon that may need to run for as long as the SMTP server
+process that talks to it. The default time limit is overruled in
<a href="postconf.5.html">main.cf</a> with an explicit "policy_time_limit" setting. The name of
the parameter is the name of the <a href="master.5.html">master.cf</a> entry ("policy")
-concatenated with the "_time_limit" suffix. </p>
+concatenated with the "_time_limit" suffix. See <a href="spawn.8.html">spawn(8)</a> for
+more information about the time limit parameter. </p>
<li> <p> Line 2: specify a "0" process limit instead of the default
"-", to avoid "connection refused" and other problems when the smtpd
</pre>
</blockquote>
-<h2><a name="other"> Other measures to off-load zombies </h2>
+<h2><a name="other"> Other measures to off-load zombies </a> </h2>
<p> OpenBSD <a href="http://www.openbsd.org/spamd/">spamd</a>
implements a daemon that handles all connections from "new" clients.
<p>
Optional SMTP server access restrictions in the context of a client
SMTP connection request.
+See <a href="SMTPD_ACCESS_README.html">SMTPD_ACCESS_README</a>, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
Optional access restrictions that the Postfix SMTP server applies
in the context of the SMTP DATA command.
+See <a href="SMTPD_ACCESS_README.html">SMTPD_ACCESS_README</a>, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
(default: empty)</b></DT><DD>
<p> Optional access restrictions that the Postfix SMTP server
-applies in the context of the SMTP END-OF-DATA command. </p>
+applies in the context of the SMTP END-OF-DATA command.
+See <a href="SMTPD_ACCESS_README.html">SMTPD_ACCESS_README</a>, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
+</p>
<p> This feature is available in Postfix 2.2 and later. </p>
<p>
Optional SMTP server access restrictions in the context of a client
ETRN request.
+See <a href="SMTPD_ACCESS_README.html">SMTPD_ACCESS_README</a>, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
Optional restrictions that the Postfix SMTP server applies in the
context of the SMTP HELO command.
+See <a href="SMTPD_ACCESS_README.html">SMTPD_ACCESS_README</a>, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
The access restrictions that the Postfix SMTP server applies in
the context of the RCPT TO command.
+See <a href="SMTPD_ACCESS_README.html">SMTPD_ACCESS_README</a>, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
Optional restrictions that the Postfix SMTP server applies in the
context of the MAIL FROM command.
+See <a href="SMTPD_ACCESS_README.html">SMTPD_ACCESS_README</a>, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
.SH smtpd_client_restrictions (default: empty)
Optional SMTP server access restrictions in the context of a client
SMTP connection request.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
.PP
The default is to allow all connection requests.
.PP
.SH smtpd_data_restrictions (default: empty)
Optional access restrictions that the Postfix SMTP server applies
in the context of the SMTP DATA command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
.PP
This feature is available in Postfix 2.0 and later.
.PP
.SH smtpd_end_of_data_restrictions (default: empty)
Optional access restrictions that the Postfix SMTP server
applies in the context of the SMTP END-OF-DATA command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
.PP
This feature is available in Postfix 2.2 and later.
.PP
.SH smtpd_etrn_restrictions (default: empty)
Optional SMTP server access restrictions in the context of a client
ETRN request.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
.PP
The Postfix ETRN implementation accepts only destinations that are
eligible for the Postfix "fast flush" service. See the ETRN_README
.SH smtpd_helo_restrictions (default: empty)
Optional restrictions that the Postfix SMTP server applies in the
context of the SMTP HELO command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
.PP
The default is to permit everything.
.PP
.SH smtpd_recipient_restrictions (default: permit_mynetworks, reject_unauth_destination)
The access restrictions that the Postfix SMTP server applies in
the context of the RCPT TO command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
.PP
By default, the Postfix SMTP server accepts:
.IP \(bu
.SH smtpd_sender_restrictions (default: empty)
Optional restrictions that the Postfix SMTP server applies in the
context of the MAIL FROM command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
.PP
The default is to permit everything.
.PP
<h2>Introduction</h2>
-<p> Postfix version 2.3 introduces support for the Sendmail version
-8 Milter (mail filter) protocol. This protocol is used by applications
-that run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT),
-SMTP commands (HELO, MAIL FROM, etc.) as well as mail content (headers
-and body). All this happens before mail is queued. </p>
+<p> Postfix implements support for the Sendmail version 8 Milter
+(mail filter) protocol. This protocol is used by applications that
+run outside the MTA to inspect SMTP events (CONNECT, DISCONNECT),
+SMTP commands (HELO, MAIL FROM, etc.) as well as mail content
+(headers and body). All this happens before mail is queued. </p>
<p> The reason for adding Milter support to Postfix is that there
exists a large collection of applications, not only to block unwanted
Having yet another Postfix-specific version of all that software
is a poor use of human and system resources. </p>
-<p> Postfix version 2.4 implements all the requests of Sendmail
-version 8 Milter protocols up to version 4, including message body
-replacement (body replacement is not available with Postfix version
-2.3).
-See, however, the <a href="#workarounds">workarounds</a> and <a
+<p> The Milter protocol has evolved over time, and different Postfix
+versions implement different feature sets. See the <a
+href="#workarounds">workarounds</a> and <a
href="#limitations">limitations</a> sections at the end of this
-document. </p>
+document for differences between Postfix and Sendmail implementations.
+</p>
<p> This document provides information on the following topics: </p>
<h2><a name="plumbing">How Milter applications plug into Postfix </a> </h2>
<p> The Postfix Milter implementation uses two different lists of
-mail filters: one list of filters that are used for SMTP mail only,
-and one list of filters that are used for non-SMTP mail. The two
+mail filters: one list of filters for SMTP mail only,
+and one list of filters for non-SMTP mail. The two
lists have different capabilities, which is unfortunate. Avoiding
this would require major restructuring of Postfix. </p>
followed by a number are Postfix commands or server programs, while
unnumbered names inside shaded areas represent Postfix queues. To
avoid clutter, the path for local submission is simplified (the
-OVERVIEW document has a more complete description). </p>
+OVERVIEW document has a more complete description of the Postfix
+architecture). </p>
<blockquote>
Postfix currently does not provide such a library, but Sendmail
does. </p>
-<p> On some Linux and *BSD distributions, the Sendmail libmilter
-library is installed by default. With this, applications such as
-<a href="http://sourceforge.net/projects/dkim-milter/">dkim-milter</a>
-and <a href="http://sourceforge.net/projects/sid-milter/">sid-milter</a>
+<ul>
+
+<li> <p> The first option is to use a pre-compiled library. Some
+systems install the Sendmail libmilter library by default. With
+other systems, libmilter may be provided by a package (called
+"sendmail-devel" on some Linux systems). </p>
+
+<p> Once libmilter is installed, applications such as <a
+href="http://sourceforge.net/projects/dkim-milter/">dkim-milter</a> and
+<a href="http://sourceforge.net/projects/sid-milter/">sid-milter</a>
build out of the box without requiring any tinkering:</p>
<blockquote>
</pre>
</blockquote>
-<p> On other platforms you have two options: </p>
-
-<ul>
-
-<li> <p>Install the Sendmail libmilter object library and include
-files. On Linux systems, libmilter may be provided by the
-sendmail-devel package. After installing libmilter, build the
-Milter applications as described in the preceding paragraph. </p>
-
-<li> <p>Don't install the Sendmail libmilter library, but build the
-library from Sendmail source code instead: </p>
+<li> <p> The other option is to build the libmilter library from
+Sendmail source code: </p>
<blockquote>
<pre>
<blockquote>
<pre>
-postfix/smtpd[21045]: warning: milter inet:<i>host</i>:<i>port</i>: can't read packet header: Unknown error : 0
-postfix/cleanup[15190]: warning: milter inet:<i>host</i>:<i>port</i>: can't read packet header: Success
+warning: milter inet:<i>host</i>:<i>port</i>: can't read packet header: Unknown error : 0
+warning: milter inet:<i>host</i>:<i>port</i>: can't read packet header: Success
+warning: milter inet:<i>host</i>:<i>port</i>: can't read SMFIC_DATA reply packet header: No such file or directory
</pre>
</blockquote>
<h3><a name="timeouts">Milter protocol timeouts</a></h3>
<p> Postfix uses different time limits at different Milter protocol
-stages. The table shows wich timeouts are used and when
+stages. The table shows the timeout settings and the corresponding
+protocol stages
(EOH = end of headers; EOM = end of message). </p>
<blockquote>
<table border="1">
-<tr> <th> Parameter </th> <th> Time limit </th> <th> Protocol
-stage</th> </tr>
+<tr> <th> Postfix parameter </th> <th> Time limit </th> <th> Milter
+protocol stage</th> </tr>
<tr> <td> milter_connect_timeout </td> <td> 30s </td> <td> CONNECT
</td> </tr>
</blockquote>
-<p> Beware: 30s may be too short for applications doing lots 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. </p>
+<p> Beware: 30s may be too short for Milter applications that do
+lots 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. </p>
<h3><a name="macros">Sendmail macro emulation</a></h3>
<p> Postfix emulates a limited number of Sendmail macros, as shown
in the table. Some macro values depend on whether a recipient is
rejected (rejected recipients are available on request by the Milter
-application). Different macros are available at different SMTP
+application). Different macros are available at different Milter
protocol stages (EOH = end-of-header, EOM = end-of-message); their
availability is not
always the same as in Sendmail. See the <a
<table border="1">
-<tr> <th> Name </th> <th> Availability </th> <th> Description </th>
-</tr>
+<tr> <th> Sendmail macro </th> <th> Milter protocol stage </th>
+<th> Description </th> </tr>
-<tr> <td> i </td> <td> DATA, EOH, EOM </td> <td> Queue ID </td> </tr>
+<tr> <td> i </td> <td> DATA, EOH, EOM </td> <td> Queue ID, also
+Postfix queue file name </td> </tr>
-<tr> <td> j </td> <td> Always </td> <td> value of myhostname </td>
+<tr> <td> j </td> <td> Always </td> <td> Value of myhostname </td>
</tr>
<tr> <td> _ </td> <td> Always </td> <td> The validated client name
<tr> <td> {mail_addr} </td> <td> MAIL </td> <td> Sender address
</td> </tr>
-<tr> <td> {mail_host} </td> <td> MAIL (Postfix ≥ 2.6) </td> <td>
-Sender next-hop destination </td> </tr>
+<tr> <td> {mail_host} </td> <td> MAIL (Postfix ≥ 2.6, only with
+smtpd_milters) </td> <td> Sender next-hop destination </td> </tr>
-<tr> <td> {mail_mailer} </td> <td> MAIL (Postfix ≥ 2.6) </td>
-<td> Sender mail delivery transport </td> </tr>
+<tr> <td> {mail_mailer} </td> <td> MAIL (Postfix ≥ 2.6, only with
+smtpd_milters) </td> <td> Sender mail delivery transport </td> </tr>
<tr> <td> {rcpt_addr} </td> <td> RCPT </td> <td> Recipient address
<br> With rejected recipient: descriptive text </td> </tr>
-<tr> <td> {rcpt_host} </td> <td> RCPT (Postfix ≥ 2.6) </td> <td>
-Recipient next-hop destination <br> With rejected recpient: enhanced
-status code </td> </tr>
+<tr> <td> {rcpt_host} </td> <td> RCPT (Postfix ≥ 2.6, only with
+smtpd_milters) </td> <td> Recipient next-hop destination <br> With
+rejected recipient: enhanced status code </td> </tr>
-<tr> <td> {rcpt_mailer} </td> <td> RCPT (Postfix ≥ 2.6) </td>
-<td> Recipient mail delivery transport <br> With rejected recipient:
-"error" </td> </tr>
+<tr> <td> {rcpt_mailer} </td> <td> RCPT (Postfix ≥ 2.6, only with
+smtpd_milters) </td> <td> Recipient mail delivery transport <br>
+With rejected recipient: "error" </td> </tr>
<tr> <td> {tls_version} </td> <td> HELO, MAIL, DATA, EOH, EOM </td>
<td> TLS protocol version </td> </tr>
</blockquote>
-<p> Postfix sends specific sets of macros at different SMTP protocol
+<p> Postfix sends specific sets of macros at different Milter protocol
stages. The sets are configured with the parameters as described
in the table (EOH = end of headers; EOM = end of message). The
protocol version is a number that Postfix sends at the beginning
of the Milter protocol handshake. </p>
+<p> As of Sendmail 8.14.0, Milter applications can specify what
+macros they want to receive at different Milter protocol stages.
+An application-specified list takes precedence over a Postfix-specified
+list. </p>
+
<blockquote>
<table border="1">
-<tr> <th> Parameter name </th> <th> Protocol version </th> <th>
-Protocol stage </th> </tr>
+<tr> <th> Postfix parameter </th> <th> Milter protocol version </th>
+<th> Milter protocol stage </th> </tr>
<tr> <td> milter_connect_macros </td> <td> 2 or higher </td> <td>
CONNECT </td> </tr>
<h2><a name="workarounds">Workarounds</a></h2>
-<p> Content filters may break DKIM etc. signatures. If you
-use an SMTP-based content filter, then you should add a line to
-master.cf with "-o disable_mime_output_conversion=yes" (note: no
-spaces around the "="), as described in the <a
+<ul>
+
+<li> <p> To avoid breaking DKIM etc. signatures with an SMTP-based
+content filter, update the before-filter SMTP client in master.cf,
+and add a line with "-o disable_mime_output_conversion=yes" (note:
+no spaces around the "="). For details, see the <a
href="FILTER_README.html#advanced_filter">advanced content filter</a>
example. </p>
-<p> 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 aren't true in a Postfix environment. </p>
-
-<ul>
+<pre>
+/etc/postfix/master.cf:
+ # =============================================================
+ # service type private unpriv chroot wakeup maxproc command
+ # (yes) (yes) (yes) (never) (100)
+ # =============================================================
+ scan unix - - n - 10 smtp
+ -o smtp_send_xforward_command=yes
+ -o disable_mime_output_conversion=yes
+ -o smtp_generic_maps=
+</pre>
<li> <p> Some Milter applications use the "<tt>{if_addr}</tt>" macro
to recognize local mail; this macro does not exist in Postfix.
</pre>
</blockquote>
-<p> This happens because those Milter applications expect that the
-queue ID is known <i>before</i> the MTA accepts the MAIL FROM
-(sender) command. Postfix, on the other hand, does not choose a
-queue file name until <i>after</i> it accepts the first valid RCPT
-TO (recipient) command (Postfix queue file names must be unique
-across multiple directories, so the name can't be chosen before the
-file is created; if multiple messages were to use the same queue
-ID <i>simultaneously</i>, mail would be lost). </p>
-
-</ul>
+<p> The problem is that Milter applications expect that the queue
+ID is known <i>before</i> the MTA accepts the MAIL FROM (sender)
+command. Postfix does not choose a queue ID, which is used as the
+queue file name, until <i>after</i> it accepts the first valid RCPT
+TO (recipient) command. </p>
<p> If you experience the ugly header problem, see if a recent
version of the Milter application fixes it. For example, current
versions of dkim-filter and dk-filter already have code that looks
-up the Postfix queue ID at a later protocol stage. </p>
-
-<p> To fix the ugly message header with sid-filter applications,
-we change the source code, so that it does the queue ID lookup after
-Postfix receives the end of the message. </p>
-
-<ul>
-
-<li> <p> Edit the filter source file (named
-<tt>sid-filter/sid-filter.c</tt>). </p>
-
-<li> <p> Look up the <tt>smfilter</tt> table and replace
-<tt>mlfi_eoh</tt> by <tt>NULL</tt>.
+up the Postfix queue ID at a later protocol stage, and sid-filter
+version 1.0.0 no longer includes the queue ID in the message header.
</p>
-<li> <p> Look up the <tt>mlfi_eom()</tt> function and add code near
-the top that calls <tt>mlfi_eoh()</tt> as shown by the <b>bold</b>
-text below: </p>
-
-</ul>
-
-<blockquote>
-<pre>
- assert(ctx != NULL);
-#endif /* !DEBUG */
-<b>
- ret = mlfi_eoh(ctx);
- if (ret != SMFIS_CONTINUE)
- return ret;</b>
-</pre>
-</blockquote>
-
-<p> NOTES: </p>
-
-<ul>
-
-<li> <p> This was tested with sid-milter-0.2.10 and sid-milter-0.2.14. </p>
-
-</ul>
-
-<p> To fix the ugly message header with other Milter applications,
-you will need to do something like this: </p>
+<p> To fix the ugly message header, you will need to add code that
+looks up the Postfix queue ID at some later point im time. The
+example below adds the lookup after the end-of-message. </p>
<ul>
if (jobid != 0)
dfc->mctx_jobid = jobid;
}</b>
-
-/* get hostname; used in the X header and in new MIME boundaries */
</pre>
</blockquote>
<ul>
<li> <p> Different mail filters use slightly different names for
-variables. If the above code does not compile, look for the code
-at the start of the <tt>mlfi_eoh()</tt> routine. </p>
+variables. If the above code does not compile, look elsewhere in
+the mail filter source file for code that looks up the "i" macro
+value, and copy that code. </p>
-<li> <p> This fixes only the ugly message header, but not the WARNING
-message. Fortunately, many Milters log that message only once. </p>
+<li> <p> This change fixes only the ugly message header, but not
+the WARNING message. Fortunately, many Milters log that message
+only once. </p>
+
+</ul>
</ul>
<ul>
+<li> <p> The Milter protocol has evolved over time. Therefore,
+different Postfix versions implement different feature sets. </p>
+
+<table border="1">
+
+<tr> <th> Postfix </th> <th> Supported Milter requests </th>
+</tr>
+
+<tr> <td align="center"> 2.6 </td> <td> All Milter requests of
+Sendmail 8.14.0 (see notes below). </td> </tr>
+
+<tr> <td align="center"> 2.5 </td> <td> All Milter requests of
+Sendmail 8.14.0, except: <br> SMFIP_RCPT_REJ (report rejected
+recipients to the mail filter), <br> SMFIR_CHGFROM (replace sender,
+with optional ESMTP parameters), <br> SMFIR_ADDRCPT_PAR (add
+recipient, with optional ESMTP parameters). </td> </tr>
+
+<tr> <td align="center"> 2.4 </td> <td> All Milter requests of
+Sendmail 8.13.0. </td> </tr>
+
+<tr> <td align="center"> 2.3 </td> <td> All Milter requests of
+Sendmail 8.13.0, except: <br> SMFIR_REPLBODY (replace message body).
+
+</table>
+
<li> <p> For Milter applications that are written in C, you need
to use the Sendmail libmilter library. </p>
-<li> <p> There are TWO sets of mail filters: filters that are used
+<li> <p> Postfix has TWO sets of mail filters: filters that are used
for SMTP mail only (specified with the smtpd_milters parameter),
and filters for non-SMTP mail (specified with the non_smtpd_milters
parameter). The non-SMTP filters are primarily for local submissions.
</p>
-<ul>
-
-<li> <p> When mail is filtered by non-SMTP filters, the Postfix
-cleanup(8) server has to simulate the SMTP client CONNECT and
-DISCONNECT events, and the SMTP client EHLO, MAIL FROM, RCPT TO and
-DATA commands. This works as expected, with only one exception:
-non-SMTP filters must not REJECT or TEMPFAIL simulated RCPT TO
-commands. When a non-SMTP filter REJECTs or TEMPFAILs a recipient,
+<p> When mail is filtered by non_smtpd_milters, the Postfix cleanup(8)
+server has to simulate SMTP client requests. This works as expected,
+with only one exception: non_smtpd_milters must not REJECT or
+TEMPFAIL simulated RCPT TO commands. When this rule is violated,
Postfix will report a configuration error, and mail will stay in
the queue. </p>
-</ul>
-
<li> <p> Postfix currently does not apply content filters to mail
that is forwarded or aliased internally, or to mail that is generated
internally such as bounces or Postmaster notifications. This may
message header or body, and cannot make modifications to the message
or to the envelope. </p>
-<li> <p> Postfix version 2.6 implements all Sendmail 8.14 Milter
-features, except it ignores the optional ESMTP command parameters
-with requests to replace the sender (SMFIR_CHGFROM), or to append
-a recipient (SMFIR_ADDRCPT_PAR). When a Milter application supplies
-ESMTP command parameters, these are logged as follows: </p>
+<li> <p> Postfix 2.6 ignores the optional ESMTP parameters in
+requests to replace the sender (SMFIR_CHGFROM) or to append a
+recipient (SMFIR_ADDRCPT_PAR). Postfix logs a warning message when
+a Milter application supplies such ESMTP parameters: </p>
<pre>
-postfix/cleanup[40629]: warning: 100B22B3293: cleanup_chg_from: ignoring ESMTP arguments "<i>whatever</i>"
+warning: <i>queue-id</i>: cleanup_chg_from: ignoring ESMTP arguments "<i>whatever</i>"
+warning: <i>queue-id</i>: cleanup_add_rcpt: ignoring ESMTP arguments "<i>whatever</i>"
</pre>
-<p> Specify "milter_protocol = 6" to enable all available Sendmail
-8.14 and earlier Milter features. </p>
-
-<li> <p> Postfix version 2.5 implements all Sendmail 8.14 Milter
-features except: SMFIP_RCPT_REJ (report rejected recipients to the
-mail filter), SMFIR_CHGFROM (replace sender, with optional ESMTP
-command parameters), and SMFIR_ADDRCPT_PAR (add recipient, with
-optional ESMTP command parameters). </p>
+<li> <p> Postfix 2.3 does not implement requests to replace the
+message body. Milter applications log a warning message when they
+need this unsupported operation: </p>
-<p> Specify "milter_protocol = 6" to enable all available Sendmail
-8.14 and earlier Milter features. </p>
-
-<li> <p> Postfix 2.4 implements all Sendmail 8.13 Milter features.
-</p>
-
-<p> Specify "milter_protocol = 4" to enable all available Sendmail
-8.13 and earlier Milter features. </p>
-
-<li> <p> Postfix 2.3 implements all Sendmail 8.13 Milter features
-except requests to replace the message body. Milter applications
-that request this unsupported operation will log a warning like
-
-<blockquote>
<pre>
-<i>application name</i>: st_optionneg[134563840]: 0x3d does not fulfill action requirements 0x1e
+st_optionneg[134563840]: 0x3d does not fulfill action requirements 0x1e
</pre>
-</blockquote>
<p> The solution is to use Postfix version 2.4 or later. </p>
-<p> Specify "milter_protocol = 4" to enable all available Sendmail
-8.13 and earlier Milter features. </p>
-
<li> <p> Most Milter configuration options are global. Future Postfix
versions may support per-Milter timeouts, per-Milter error handling,
etc. </p>
<li> <p> Lines 2, 11: the Postfix spawn(8) daemon by default kills
its child process after 1000 seconds. This is too short for a
-policy daemon that may run for as long as an SMTP client is connected
-to an SMTP server process. The default time limit is overruled in
+policy daemon that may need to run for as long as the SMTP server
+process that talks to it. The default time limit is overruled in
main.cf with an explicit "policy_time_limit" setting. The name of
the parameter is the name of the master.cf entry ("policy")
-concatenated with the "_time_limit" suffix. </p>
+concatenated with the "_time_limit" suffix. See spawn(8) for
+more information about the time limit parameter. </p>
<li> <p> Line 2: specify a "0" process limit instead of the default
"-", to avoid "connection refused" and other problems when the smtpd
</pre>
</blockquote>
-<h2><a name="other"> Other measures to off-load zombies </h2>
+<h2><a name="other"> Other measures to off-load zombies </a> </h2>
<p> OpenBSD <a href="http://www.openbsd.org/spamd/">spamd</a>
implements a daemon that handles all connections from "new" clients.
<p>
Optional SMTP server access restrictions in the context of a client
SMTP connection request.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
Optional SMTP server access restrictions in the context of a client
ETRN request.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
Optional restrictions that the Postfix SMTP server applies in the
context of the SMTP HELO command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
The access restrictions that the Postfix SMTP server applies in
the context of the RCPT TO command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
Optional restrictions that the Postfix SMTP server applies in the
context of the MAIL FROM command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
<p>
Optional access restrictions that the Postfix SMTP server applies
in the context of the SMTP DATA command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
</p>
<p>
%PARAM smtpd_end_of_data_restrictions
<p> Optional access restrictions that the Postfix SMTP server
-applies in the context of the SMTP END-OF-DATA command. </p>
+applies in the context of the SMTP END-OF-DATA command.
+See SMTPD_ACCESS_README, section "Delayed evaluation of SMTP access
+restriction lists" for a discussion of evaluation context and time.
+</p>
<p> This feature is available in Postfix 2.2 and later. </p>
cleanup_masquerade_internal(clean_addr, cleanup_masq_domains);
}
CLEANUP_OUT_BUF(state, REC_TYPE_FROM, clean_addr);
- if (state->sender == 0)
- state->sender = mystrdup(STR(clean_addr));
+ if (state->sender) /* XXX Can't happen */
+ myfree(state->sender);
+ state->sender = mystrdup(STR(clean_addr)); /* Used by Milter client */
if ((state->flags & CLEANUP_FLAG_BCC_OK)
&& *STR(clean_addr)
&& cleanup_send_bcc_maps
}
cleanup_out_recipient(state, state->dsn_orcpt, state->dsn_notify,
state->orig_rcpt, STR(clean_addr));
- if (state->recip == 0)
- state->recip = mystrdup(STR(clean_addr));
+ if (state->recip) /* This can happen */
+ myfree(state->recip);
+ state->recip = mystrdup(STR(clean_addr)); /* Used by Milter client */
if ((state->flags & CLEANUP_FLAG_BCC_OK)
&& *STR(clean_addr)
&& cleanup_rcpt_bcc_maps
if (cleanup_milters != 0
&& state->milters == 0
&& CLEANUP_MILTER_OK(state))
- cleanup_milter_emul_rcpt(state, cleanup_milters, buf);
+ cleanup_milter_emul_rcpt(state, cleanup_milters, state->recip);
myfree(state->orig_rcpt);
state->orig_rcpt = 0;
if (state->dsn_orcpt != 0) {
if (cleanup_milters != 0
&& state->milters == 0
&& CLEANUP_MILTER_OK(state))
- cleanup_milter_emul_mail(state, cleanup_milters, buf);
+ cleanup_milter_emul_mail(state, cleanup_milters, state->sender);
return;
}
if (mapped_type == REC_TYPE_DSN_ENVID) {
if (cleanup_milters != 0
&& state->milters == 0
&& CLEANUP_MILTER_OK(state))
- cleanup_milter_emul_rcpt(state, cleanup_milters, buf);
+ cleanup_milter_emul_rcpt(state, cleanup_milters, state->recip);
myfree(state->orig_rcpt);
state->orig_rcpt = 0;
if (state->dsn_orcpt != 0) {
*
* For safety we keep the test for null pointers in input. It's cheap.
*/
-#define DSB_TRUNCATE(s) (STR(s)[0] = 0)
+#define DSB_TRUNCATE(s) \
+ do { VSTRING_RESET(s); VSTRING_TERMINATE(s); } while (0)
#define NULL_OR_EMPTY(s) ((s) == 0 || *(s) == 0)
extern char *var_tls_rand_exch_name;
#define VAR_TLS_RAND_SOURCE "tls_random_source"
-#ifdef HAS_DEV_URANDOM
-#define DEF_TLS_RAND_SOURCE "dev:/dev/urandom"
+#ifdef PREFERRED_RAND_SOURCE
+#define DEF_TLS_RAND_SOURCE PREFERRED_RAND_SOURCE
#else
#define DEF_TLS_RAND_SOURCE ""
#endif
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20090428"
-#define MAIL_VERSION_NUMBER "2.6.0-RC3"
+#define MAIL_RELEASE_DATE "20090511"
+#define MAIL_VERSION_NUMBER "2.6.0"
#ifdef SNAPSHOT
# define MAIL_VERSION_DATE "-" MAIL_RELEASE_DATE
int alone = 0;
int zerolimit = 0;
WATCHDOG *watchdog;
+ char *oname;
char *oval;
char *generation;
int msg_vstream_needed = 0;
break;
case 'o':
/* XXX Use split_nameval() */
- if ((oval = split_at(optarg, '=')) == 0)
+ oname = mystrdup(optarg);
+ if ((oval = split_at(oname, '=')) == 0)
oval = "";
- mail_conf_update(optarg, oval);
- if (strcmp(optarg, VAR_SYSLOG_NAME) == 0)
+ mail_conf_update(oname, oval);
+ if (strcmp(oname, VAR_SYSLOG_NAME) == 0)
redo_syslog_init = 1;
break;
case 's':
int alone = 0;
int zerolimit = 0;
WATCHDOG *watchdog;
+ char *oname;
char *oval;
char *generation;
int msg_vstream_needed = 0;
break;
case 'o':
/* XXX Use split_nameval() */
- if ((oval = split_at(optarg, '=')) == 0)
+ oname = mystrdup(optarg);
+ if ((oval = split_at(oname, '=')) == 0)
oval = "";
- mail_conf_update(optarg, oval);
- if (strcmp(optarg, VAR_SYSLOG_NAME) == 0)
+ mail_conf_update(oname, oval);
+ if (strcmp(oname, VAR_SYSLOG_NAME) == 0)
redo_syslog_init = 1;
break;
case 's':
int alone = 0;
int zerolimit = 0;
WATCHDOG *watchdog;
+ char *oname;
char *oval;
char *generation;
int msg_vstream_needed = 0;
break;
case 'o':
/* XXX Use split_nameval() */
- if ((oval = split_at(optarg, '=')) == 0)
+ oname = mystrdup(optarg);
+ if ((oval = split_at(oname, '=')) == 0)
oval = "";
- mail_conf_update(optarg, oval);
- if (strcmp(optarg, VAR_SYSLOG_NAME) == 0)
+ mail_conf_update(oname, oval);
+ if (strcmp(oname, VAR_SYSLOG_NAME) == 0)
redo_syslog_init = 1;
break;
case 's':
MILTER8_DATA_STRING, milter->body,
MILTER8_DATA_END) != 0)
MILTER8_EVENT_BREAK(milter->def_reply);
- } else
- STR(milter->body)[0] = 0;
+ } else {
+ VSTRING_RESET(milter->body);
+ VSTRING_TERMINATE(milter->body);
+ }
/* Skip to the next request after previous edit error. */
if (edit_resp)
continue;
MILTER8_DATA_STRING, milter->body,
MILTER8_DATA_END) != 0)
MILTER8_EVENT_BREAK(milter->def_reply);
- } else
- STR(milter->body)[0] = 0;
+ } else {
+ VSTRING_RESET(milter->body);
+ VSTRING_TERMINATE(milter->body);
+ }
/* Skip to the next request after previous edit error. */
if (edit_resp)
continue;
/* __FreeBSD_version version is major+minor */
#if __FreeBSD_version >= 220000
-#define HAS_DEV_URANDOM /* introduced in 2.1.5 */
+#define PREFERRED_RAND_SOURCE "dev:/dev/urandom" /* introduced 2.1.5 */
#endif
#if __FreeBSD_version >= 300000
#define HAS_FUTIMES /* XXX maybe earlier */
#endif
+#if (defined(OpenBSD) && OpenBSD >= 199608)
+#define PREFERRED_RAND_SOURCE "dev:/dev/arandom" /* XXX earlier */
+#endif
+
#if OpenBSD >= 200000 /* XXX */
#define HAS_ISSETUGID
-#define HAS_DEV_URANDOM /* XXX probably earlier */
#endif
#if OpenBSD >= 200200 /* XXX */
#if __NetBSD_Version__ >= 103000000 /* XXX maybe earlier */
#undef DEF_MAILBOX_LOCK
#define DEF_MAILBOX_LOCK "flock, dotlock"
-#define HAS_DEV_URANDOM /* XXX probably earlier */
+#define PREFERRED_RAND_SOURCE "dev:/dev/urandom" /* XXX maybe earlier */
#endif
#if __NetBSD_Version__ >= 105000000
# define HAS_CLOSEFROM
#endif
#ifndef NO_DEV_URANDOM
-# define HAS_DEV_URANDOM
+# define PREFERRED_RAND_SOURCE "dev:/dev/urandom"
#endif
#ifndef NO_FUTIMESAT
# define HAS_FUTIMESAT
#else
# define CANT_WRITE_BEFORE_SENDING_FD
#endif
-#define HAS_DEV_URANDOM /* introduced in 1.1 */
+#define PREFERRED_RAND_SOURCE "dev:/dev/urandom" /* introduced in 1.1 */
#ifndef NO_EPOLL
# define EVENTS_STYLE EVENTS_STYLE_EPOLL /* introduced in 2.5 */
#endif
#endif
#define CANT_USE_SEND_RECV_MSG
#define DEF_SMTP_CACHE_DEMAND 0
-#define HAS_DEV_URANDOM
+#define PREFERRED_RAND_SOURCE "dev:/dev/urandom"
#endif
/*
projects / thirdparty / postfix.git / commitdiff
