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.
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
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 |
|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
|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\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 recpient: |
| | |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 |
headers; EOM = end of message). The protocol version is a number that Postfix
sends at the beginning of the Milter protocol handshake.
+As of Sendmail 8.14.0, Milter applications can specify what macros they want to
+receive at different protocol stages. In that case, the application-specified
+list takes precedence over Postfix configuration.
+
_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\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 |
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 */
-
- 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;
-
-NOTES:
-
- * This was tested with sid-milter-0.2.10 and sid-milter-0.2.14.
+protocol stage, and sid-filter version 1.0.0 no longer includes the queue ID in
+the message header.
To fix the ugly message header with other Milter applications, you will need to
do something like this:
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. |
+ |_\b _\b _\b _\b _\b _\b _\b _\b|_\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\b _\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.
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"
-
- Specify "milter_protocol = 6" to enable all available Sendmail 8.14 and
- earlier Milter features.
+ * Postfix 2.6 ignores the optional ESMTP parameters in requests to replace
+ the sender (SMFIR_CHGFROM) or to append a recipient (SMFIR_ADDRCPT_PAR).
+ When a Milter application supplies such ESMTP parameters, Postfix will log
+ a warning:
- * 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).
+ warning: queue-id: cleanup_chg_from: ignoring ESMTP arguments "whatever"
+ warning: queue-id: cleanup_add_rcpt: ignoring ESMTP arguments "whatever"
- Specify "milter_protocol = 6" to enable all available Sendmail 8.14 and
- earlier Milter features.
+ * Postfix 2.3 does not implement requests to replace the message body. Milter
+ applications that need this unsupported operation will log a warning:
- * 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 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
+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.
-The default Milter protocol version is increased from 2 to 6; this
+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:
- 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
To restore compatibility, specify "milter_protocol = 2" in main.cf.
- 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:
+and log a warning message as follows:
- postfix/cleanup[40629]: warning: 100B22B3293: cleanup_chg_from:
- ignoring ESMTP arguments "whatever"
+ warning: 100B22B3293: cleanup_chg_from: ignoring ESMTP arguments "whatever"
Incompatibility with snapshot 20090330
======================================
<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>
<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>
</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>
<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 recpient: 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>
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 protocol stages. In that
+case, the application-specified list takes precedence over Postfix
+configuration. </p>
+
<blockquote>
<table border="1">
<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>
<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. </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).
+</p>
+
+</table>
+
<li> <p> For Milter applications that are written in C, you need
to use the Sendmail libmilter library. </p>
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). When a Milter application supplies
+such ESMTP parameters, Postfix will log a warning: </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>
-
-<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
+<li> <p> Postfix 2.3 does not implement requests to replace the
+message body. Milter applications that need this unsupported operation
+will log a warning:
-<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
<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>
<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>
</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>
<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 recpient: 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>
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 protocol stages. In that
+case, the application-specified list takes precedence over Postfix
+configuration. </p>
+
<blockquote>
<table border="1">
<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>
<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. </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).
+</p>
+
+</table>
+
<li> <p> For Milter applications that are written in C, you need
to use the Sendmail libmilter library. </p>
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). When a Milter application supplies
+such ESMTP parameters, Postfix will log a warning: </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>
-
-<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
+<li> <p> Postfix 2.3 does not implement requests to replace the
+message body. Milter applications that need this unsupported operation
+will log a warning:
-<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
<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_RELEASE_DATE "20090510"
#define MAIL_VERSION_NUMBER "2.7"
#ifdef SNAPSHOT
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
/*