20060510
Preliminary TLS_README and postconf(5) changes completed.
+ Victor Duchovni.
Added smtp_tls_policy_maps and smtp_tls_protocols features
to the smtp/lmtp client, changed smtp_tls_cipherlist to
- only apply when TLS is mandatory.
+ only apply when TLS is mandatory. Victor Duchovni.
20060512
Destinations that share a common server may have distinct
TLS protocol and cipherlist requirements, with mandatory
TLS add the protocol and cipherlist values to the TLS session
- lookup key.
+ lookup key. Victor Duchovni.
20060516
The smtp_tls_policy_maps table now implements parent domain
matching for destinations that are bare domains (without
- enclosin [] or optional :port suffix). This allows one to
+ enclosing [] or optional :port suffix). This allows one to
set TLS policy for a domain and all sub-domains. Victor
Duchovni.
20060519
The same parameter can bind to different variables in
- different daemons, ignore the variable name when eliminating
+ different daemons. Ignore the variable name when eliminating
duplicates in extract.awk. Victor Duchovni.
20060523
after an opportunistic TLS handshake fails. Specify
"smtp_sasl_auth_enforce = no" to deliver mail anyway. File:
smtp/smtp_proto.c. See workaround 20060711 for sender-dependent
- SASL passwords.
+ SASL passwords. This was undone with the 20060719 workaround.
20060709
after the header label and ":" in an interesting manner.
It eats one space (not tab). File: milter/milter8.c.
- Workaround: if sender-depedendent SASL passwords are enabled,
+ Workaround: if sender-dependent SASL passwords are enabled,
don't defer delivery when a SASL password exists but the
server doesn't announce SASL support. File: smtp/smtp_proto.c.
+ This was undone with the 20060719 workaround.
Cleanup: format of cleanup milter reject messages. File:
cleanup_milter.c.
Bugfix (bug introduced with Postfix 2.2): the Postfix SMTP
client enforced Mandatory TLS only when talking to an ESMTP
- server. Victor Duchovni. File: src/smtp/smtp_proto.c.
+ server; enforcement did not happen if Postfix could somehow
+ be forced to send HELO instead of EHLO. Victor Duchovni.
+ File: src/smtp/smtp_proto.c.
20060718
Moreover, when mail has passed through an external content
filter, we don't have sufficient information to reproduce
the exact same SMTP events and Sendmail macros that Milters
- received when the mail originally arrived in Postfix. File:
- pickup/pickup.c.
+ received when the mail originally arrived in Postfix. This
+ change does not affect Milter applications that run behind
+ an after-queue content filter. File: pickup/pickup.c.
Bugfix: Milters received a truncated ORCPT=xxx parameter
due to destructive parsing of something that didn't have
to be preserved before Milter support was added to Postfix.
File: smtpd/smtpd.c.
+20060724
+
+ Bugfix: when updating the same header multiple times, the
+ Postfix Milter client created a queue file that caused
+ delivery agents to loop. File: cleanup/cleanup_milter.c.
+
Wish list:
Add M flag (enable multi-recipient delivery) to pipe daemon.
Some BSD systems ship with multiple Berkeley DB implementations. Normally,
Postfix builds with the default DB version that ships with the system.
-To build Postfix on BSD systems with a specific DB version, use a variant of
+To build Postfix on BSD systems with a non-default DB version, use a variant of
the following commands:
% make tidy
B\bBe\ber\brk\bke\bel\ble\bey\by D\bDB\bB i\bis\bss\bsu\bue\bes\bs
Warning: if you can't compile Postfix because the file "db.h" isn't found, then
-you MUST install the Berkeley DB development package (package name: db???-
-devel-???) that comes with your Linux system. Only that package contains the
-files that correspond to the Berkeley DB version that is used by the system
-library routines.
+you MUST install the Berkeley DB development package (name: db???-devel-???)
+that matches your system library. You can find out what is installed with the
+rpm command. For example:
+
+ $ r\brp\bpm\bm -\b-q\bqf\bf /\b/u\bus\bsr\br/\b/l\bli\bib\bb/\b/l\bli\bib\bbd\bdb\bb.\b.s\bso\bo
+ db4-4.3.29-2
+
+This means that you need to install db4-devel-4.3.29-2 (on some systems,
+specify /lib/libdb.so in the rpm query).
DO NOT download some Berkeley DB version from the network. Every Postfix
program will dump core when it is built with a different Berkeley DB version
This is simply the DNS name of the server that the Postfix SMTP client
connects to; this name may be obtained from other DNS lookups, such as
MX lookups or CNAME lookups. Use of the hostname lookup key is
- discouraged; always use the next-hop destination instead. The hostname
- lookup key may not behave as you expect when SMTP connection caching is
- enabled (with the smtp_connection_cache_destinations or
- smtp_connection_cache_on_demand configuration parameter). Multiple
- hostnames may resolve to the same IP address, and the hostname from the
- SMTP connection cache overrides the hostname that Postfix uses for TLS
- policy lookup or server certificate verification.
+ discouraged; always use the next-hop destination instead.
next-hop destination
This is normally the domain portion of the recipient address, but it
may be overridden by information from the transport(5) table, from the
no guarantee that Postfix is connected to the right server. To avoid this
loophole, take all of the following steps:
- 1. Use a dedicated transport that does not cache SMTP connections. Otherwise,
- the hostname from the SMTP connection cache overrides the hostname that
- Postfix uses for TLS policy lookup and server certificate verification.
+ 1. Use a dedicated message delivery transport (for example, "securetls") as
+ illustrated below.
2. Eliminate MX lookups. Specify local transport(5) table entries for
sensitive domains with explicit securetls:[mailhost] or securetls:
/etc/postfix/master.cf:
securetls unix - - n - 100 smtp
- -o smtp_connection_cache_on_demand=no
- -o smtp_connection_cache_destinations=
-o smtp_enforce_tls=yes
-o smtp_tls_enforce_peername=yes
Normally, Postfix builds with the default DB version that ships
with the system. </p>
-<p> To build Postfix on BSD systems with a specific DB version,
+<p> To build Postfix on BSD systems with a non-default DB version,
use a variant of the following commands: </p>
<blockquote>
<p> Warning: if you can't compile Postfix because the file "db.h"
isn't found, then you MUST install the Berkeley DB development
-package (package name: db???-devel-???) that comes with your Linux
-system. Only that package contains the files that correspond to the
-Berkeley DB version that is used by the system library routines.
+package (name: db???-devel-???) that matches your system library.
+You can find out what is installed with the rpm command. For example:
</p>
+<blockquote>
+<pre>
+$ <b>rpm -qf /usr/lib/libdb.so</b>
+db4-4.3.29-2
+</pre>
+</blockquote>
+
+<p> This means that you need to install db4-devel-4.3.29-2 (on
+some systems, specify <tt>/lib/libdb.so</tt> in the rpm query). </p>
+
<p> DO NOT download some Berkeley DB version from the network.
Every Postfix program will dump core when it is built with a different
Berkeley DB version than the version that is used by the system
name of the server that the Postfix SMTP client connects to; this
name may be obtained from other DNS lookups, such as MX lookups or
CNAME lookups. Use of the hostname lookup key is discouraged; always
-use the next-hop destination instead. The hostname lookup key may
-not behave as you expect when SMTP connection caching is enabled
-(with the <a href="postconf.5.html#smtp_connection_cache_destinations">smtp_connection_cache_destinations</a> or
-<a href="postconf.5.html#smtp_connection_cache_on_demand">smtp_connection_cache_on_demand</a> configuration parameter). Multiple
-hostnames may resolve to the same IP address, and the hostname from
-the SMTP connection cache overrides the hostname that Postfix uses
-for TLS policy lookup or server certificate verification. </dd>
+use the next-hop destination instead. </dd>
<dt> next-hop destination </dt> <dd> This is normally the domain portion
of the recipient address, but it may be overridden by information from
<ol>
-<li> <p> Use a dedicated transport that does not cache SMTP
-connections. Otherwise, the hostname from the SMTP connection cache
-overrides the hostname that Postfix uses for TLS policy lookup and
-server certificate verification. </p>
+<li> <p> Use a dedicated message delivery transport (for example,
+"securetls") as illustrated below. </p>
<li> <p> Eliminate MX lookups. Specify local <a href="transport.5.html">transport(5)</a> table
entries for sensitive domains with explicit securetls:[<i>mailhost</i>]
/etc/postfix/<a href="master.5.html">master.cf</a>:
securetls unix - - n - 100 smtp
- -o <a href="postconf.5.html#smtp_connection_cache_on_demand">smtp_connection_cache_on_demand</a>=no
- -o <a href="postconf.5.html#smtp_connection_cache_destinations">smtp_connection_cache_destinations</a>=
-o <a href="postconf.5.html#smtp_enforce_tls">smtp_enforce_tls</a>=yes
-o <a href="postconf.5.html#smtp_tls_enforce_peername">smtp_tls_enforce_peername</a>=yes
</pre>
discouraged. Always use the full destination nexthop (enclosed in
[] with a possible ":port" suffix). A recipient domain or MX-enabled
transport next-hop with no port suffix may look like a bare hostname,
-but is still a suitable <i>destination</i>. The hostname lookup key
-may not behave as you expect when SMTP connection caching is enabled
-(see <a href="postconf.5.html#smtp_connection_cache_destinations">smtp_connection_cache_destinations</a> and
-<a href="postconf.5.html#smtp_connection_cache_on_demand">smtp_connection_cache_on_demand</a>). Different hostnames may resolve
-to the same IP address, and the hostname from the SMTP connection
-cache overrides the hostname that Postfix uses for TLS policy lookup
-and server certificate verification. </p>
+but is still a suitable <i>destination</i>. </p>
<p> Specify a next-hop destination or server hostname on the left-hand
side; no wildcards are allowed. The next-hop destination is either
Options:
<b>-c</b> <i>config</i><b>_</b><i>dir</i>
- The <b>main.cf</b> configuration file is in the named
+ The <a href="postconf.5.html"><b>main.cf</b></a> configuration file is in the named
directory instead of the default configuration
directory. See also the MAIL_CONFIG environment
setting below.
case.
A requeued message is moved to the <b>maildrop</b> queue,
- from where it is copied by the pickup daemon to a
- new file whose name is guaranteed to match the new
- queue file inode number. The new queue file is sub-
- jected again to mail address rewriting and substi-
- tution. This is useful when rewriting rules or vir-
- tual mappings have changed.
+ from where it is copied by the <a href="pickup.8.html"><b>pickup</b>(8)</a> and
+ <a href="cleanup.8.html"><b>cleanup</b>(8)</a> daemons to a new queue file. In many
+ respects its handling differs from that of a new
+ local submission.
+
+ <b>o</b> The message is not subjected to the
+ <a href="postconf.5.html#smtpd_milters">smtpd_milters</a> or <a href="postconf.5.html#non_smtpd_milters">non_smtpd_milters</a> settings.
+ When mail has passed through an external
+ content filter, this would produce incorrect
+ results with Milter applications that depend
+ on original SMTP connection state informa-
+ tion.
+
+ <b>o</b> The message is subjected again to mail
+ address rewriting and substitution. This is
+ useful when rewriting rules or virtual map-
+ pings have changed.
+
+ The address rewriting context (local or
+ remote) is the same as when the message was
+ received.
+
+ <b>o</b> The message is subjected to the same <a href="postconf.5.html#content_filter">con</a>-
+ <a href="postconf.5.html#content_filter">tent_filter</a> settings (if any) as used for
+ new local mail submissions. This is useful
+ when <a href="postconf.5.html#content_filter">content_filter</a> settings have changed.
Warning: Postfix queue IDs are reused. There is a
very small possibility that <a href="postsuper.1.html"><b>postsuper</b>(1)</a> requeues
<b>ENVIRONMENT</b>
MAIL_CONFIG
- Directory with the <b>main.cf</b> file.
+ Directory with the <a href="postconf.5.html"><b>main.cf</b></a> file.
<b>BUGS</b>
Mail that is not sanitized by Postfix (i.e. mail in the
<b>maildrop</b> queue) cannot be placed "on hold".
<b>CONFIGURATION PARAMETERS</b>
- The following <b>main.cf</b> parameters are especially relevant
+ The following <a href="postconf.5.html"><b>main.cf</b></a> parameters are especially relevant
to this program. The text below provides only a parameter
summary. See <a href="postconf.5.html"><b>postconf</b>(5)</a> for more details including exam-
ples.
<b><a href="postconf.5.html#config_directory">config_directory</a> (see 'postconf -d' output)</b>
- The default location of the Postfix main.cf and
- master.cf configuration files.
+ The default location of the Postfix <a href="postconf.5.html">main.cf</a> and
+ <a href="master.5.html">master.cf</a> configuration files.
<b><a href="postconf.5.html#hash_queue_depth">hash_queue_depth</a> (1)</b>
The number of subdirectory levels for queue direc-
work around it. But we should avoid inconsistency. If Postfix can
make macro X available at Milter protocol stage Y, then it must
also be able to make that macro available at all later Milter
-protocol stages, even those that are handled by a different Postfix
-process.
+protocol stages, even when some of those stages are handled by a
+different Postfix process.
Thus, when adding Milter support for a specific Sendmail-like macro
to the SMTP server:
We might want to take a similar approach with external (signing or
blocking) content filters: don't filter mail that has already been
-filtered. Unfortunately, this is complicated by the fact that mail
-can make multiple iterations through Postfix (for example, when
-multiple external content filters are configured). Mail that was
-caught by "postsuper -r" somewhere in the middle if this trip should
-not be allowed to slip past any filters. To achieve this, we would
-have to preserve its current "content_filter" record that specifies
-what needs to be done next. This is the opposite of normal "postsuper
--r" usage, which is most often intended to remove unwanted
-"content_filter" records. We could add a postsuper command-line
-option to re-queue and preserve "content_filter" records, but is
-is unlikely that humans will ever be able to use this correctly.
+filtered, and don't filter mail that didn't need to be filtered.
+Such mail can be recognized by the absence of a "content_filter"
+record. To make the implementation efficient, the cleanup server
+would have to record the presence of a "content_filter" record in
+the queue file header.
Message envelope or content modifications
=========================================
Specify \fB-r ALL\fR to requeue all messages. As a safety
measure, the word \fBALL\fR must be specified in upper case.
.sp
-A requeued message is moved to the \fBmaildrop\fR queue, from
-where it is copied by the pickup daemon to a new file whose name
-is guaranteed to match the new queue file inode number. The
-new queue file is subjected again to mail address rewriting and
-substitution. This is useful when rewriting rules or virtual
-mappings have changed.
+A requeued message is moved to the \fBmaildrop\fR queue,
+from where it is copied by the \fBpickup\fR(8) and
+\fBcleanup\fR(8) daemons to a new queue file. In many
+respects its handling differs from that of a new local
+submission.
+.RS
+.IP \(bu
+The message is not subjected to the smtpd_milters or
+non_smtpd_milters settings. When mail has passed through
+an external content filter, this would produce incorrect
+results with Milter applications that depend on original
+SMTP connection state information.
+.IP \(bu
+The message is subjected again to mail address rewriting
+and substitution. This is useful when rewriting rules or
+virtual mappings have changed.
.sp
+The address rewriting context (local or remote) is the same
+as when the message was received.
+.IP \(bu
+The message is subjected to the same content_filter settings
+(if any) as used for new local mail submissions. This is
+useful when content_filter settings have changed.
+.RE
+.IP
Warning: Postfix queue IDs are reused.
There is a very small possibility that \fBpostsuper\fR(1) requeues
the wrong message file when it is executed while the Postfix mail
discouraged. Always use the full destination nexthop (enclosed in
[] with a possible ":port" suffix). A recipient domain or MX-enabled
transport next-hop with no port suffix may look like a bare hostname,
-but is still a suitable \fIdestination\fR. The hostname lookup key
-may not behave as you expect when SMTP connection caching is enabled
-(see smtp_connection_cache_destinations and
-smtp_connection_cache_on_demand). Different hostnames may resolve
-to the same IP address, and the hostname from the SMTP connection
-cache overrides the hostname that Postfix uses for TLS policy lookup
-and server certificate verification.
+but is still a suitable \fIdestination\fR.
.PP
Specify a next-hop destination or server hostname on the left-hand
side; no wildcards are allowed. The next-hop destination is either
Normally, Postfix builds with the default DB version that ships
with the system. </p>
-<p> To build Postfix on BSD systems with a specific DB version,
+<p> To build Postfix on BSD systems with a non-default DB version,
use a variant of the following commands: </p>
<blockquote>
<p> Warning: if you can't compile Postfix because the file "db.h"
isn't found, then you MUST install the Berkeley DB development
-package (package name: db???-devel-???) that comes with your Linux
-system. Only that package contains the files that correspond to the
-Berkeley DB version that is used by the system library routines.
+package (name: db???-devel-???) that matches your system library.
+You can find out what is installed with the rpm command. For example:
</p>
+<blockquote>
+<pre>
+$ <b>rpm -qf /usr/lib/libdb.so</b>
+db4-4.3.29-2
+</pre>
+</blockquote>
+
+<p> This means that you need to install db4-devel-4.3.29-2 (on
+some systems, specify <tt>/lib/libdb.so</tt> in the rpm query). </p>
+
<p> DO NOT download some Berkeley DB version from the network.
Every Postfix program will dump core when it is built with a different
Berkeley DB version than the version that is used by the system
name of the server that the Postfix SMTP client connects to; this
name may be obtained from other DNS lookups, such as MX lookups or
CNAME lookups. Use of the hostname lookup key is discouraged; always
-use the next-hop destination instead. The hostname lookup key may
-not behave as you expect when SMTP connection caching is enabled
-(with the smtp_connection_cache_destinations or
-smtp_connection_cache_on_demand configuration parameter). Multiple
-hostnames may resolve to the same IP address, and the hostname from
-the SMTP connection cache overrides the hostname that Postfix uses
-for TLS policy lookup or server certificate verification. </dd>
+use the next-hop destination instead. </dd>
<dt> next-hop destination </dt> <dd> This is normally the domain portion
of the recipient address, but it may be overridden by information from
<ol>
-<li> <p> Use a dedicated transport that does not cache SMTP
-connections. Otherwise, the hostname from the SMTP connection cache
-overrides the hostname that Postfix uses for TLS policy lookup and
-server certificate verification. </p>
+<li> <p> Use a dedicated message delivery transport (for example,
+"securetls") as illustrated below. </p>
<li> <p> Eliminate MX lookups. Specify local transport(5) table
entries for sensitive domains with explicit securetls:[<i>mailhost</i>]
/etc/postfix/master.cf:
securetls unix - - n - 100 smtp
- -o smtp_connection_cache_on_demand=no
- -o smtp_connection_cache_destinations=
-o smtp_enforce_tls=yes
-o smtp_tls_enforce_peername=yes
</pre>
discouraged. Always use the full destination nexthop (enclosed in
[] with a possible ":port" suffix). A recipient domain or MX-enabled
transport next-hop with no port suffix may look like a bare hostname,
-but is still a suitable <i>destination</i>. The hostname lookup key
-may not behave as you expect when SMTP connection caching is enabled
-(see smtp_connection_cache_destinations and
-smtp_connection_cache_on_demand). Different hostnames may resolve
-to the same IP address, and the hostname from the SMTP connection
-cache overrides the hostname that Postfix uses for TLS policy lookup
-and server certificate verification. </p>
+but is still a suitable <i>destination</i>. </p>
<p> Specify a next-hop destination or server hostname on the left-hand
side; no wildcards are allowed. The next-hop destination is either
* The lookup result will never be a pointer record.
*
* Index 1 is the first matching header instance.
+ *
+ * XXX When a header is updated repeatedly we create jumps to jumps. To
+ * eliminate this, rewrite the loop below so that we can start with the
+ * pointer record that points to the header that's being edited.
*/
#define DONT_SAVE_RECORD 0
#define NO_PTR_BACKUP 0
avail_space += read_offset - saved_read_offset;
jumped = 1;
}
- if (rec_goto(state->dst, STR(rec_buf)) < 0) {
+ if (rec_goto(state->dst, STR(rec_buf)) < 0
+ || (read_offset = vstream_ftell(state->dst)) < 0) {
msg_warn("%s: read file %s: %m", myname, cleanup_path);
CLEANUP_UPD_HEADER_RETURN(cleanup_milter_error(state,
errno));
msg_warn("bad add_header argument count: %d", argv->argc);
} else {
flatten_args(arg_buf, argv->argv + 2);
- cleanup_add_header(state, argv->argv[2], STR(arg_buf));
+ cleanup_add_header(state, argv->argv[1], STR(arg_buf));
}
} else if (strcmp(argv->argv[0], "ins_header") == 0) {
if (argv->argc < 3) {
del_header 2 X-Test-Header
ins_header 3 X-Test-Header test header value 3
upd_header 1 X X-replaced-header replacement header text
+upd_header 1 X X-replaced-header replacement header text
+upd_header 1 X X-replaced-header replacement header text
close
1353 pointer_record: 1193
1193 deleted_text: X-Test-Header: test header value 1
1229 pointer_record: 1370
- 1370 regular_text: X: X-replaced-header replacement header text
- 1416 pointer_record: 881
+ 1370 pointer_record: 1433
+ 1433 pointer_record: 1496
+ 1496 regular_text: X: X-replaced-header replacement header text
+ 1542 pointer_record: 881
881 regular_text: Y: 1234567
893 regular_text: Message-Id: <20060514010427.E0F703D1E36@tail.porcupine.org>
954 regular_text: Date: Sat, 13 May 2006 21:04:18 -0400 (EDT)
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20060722"
+#define MAIL_RELEASE_DATE "20060724"
#define MAIL_VERSION_NUMBER "2.4"
#ifdef SNAPSHOT
* mail system against unreasonable inputs. This also requires that we
* limit the size of envelope records written by the local posting agent.
*
- * Allow attribute records if the queue file is owned by the mail system
- * (postsuper -r) or if the attribute specifies the MIME body type
- * (sendmail -B).
+ * Records with named attributes are filtered by postdrop(1).
*
* We must allow PTR records here because of "postsuper -r".
*/
/*
* XXX Workaround: REC_TYPE_FILT (used in envelopes) == REC_TYPE_CONT
* (used in message content).
+ *
+ * As documented in postsuper(1), ignore content filter record.
*/
if (*expected != REC_TYPE_CONTENT[0]) {
if (type == REC_TYPE_FILT)
}
/*
- * Add content inspection transport.
+ * Add content inspection transport. See also postsuper(1).
*/
if (*var_filter_xport)
rec_fprintf(cleanup, REC_TYPE_FILT, "%s", var_filter_xport);
* For messages belonging to $mail_owner also log the maildrop queue id.
* This supports message tracking for mail requeued via "postsuper -r".
*/
- if (info->st.st_uid == var_owner_uid) {
+#define MAIL_IS_REQUEUED(info) \
+ ((info)->st.st_uid == var_owner_uid && ((info)->st.st_mode & S_IROTH) == 0)
+
+ if (MAIL_IS_REQUEUED(info)) {
msg_info("%s: uid=%d from=<%s> orig_id=%s", info->id,
(int) info->st.st_uid, info->sender,
((name = strrchr(info->path, '/')) != 0 ?
cleanup_flags =
input_transp_cleanup(CLEANUP_FLAG_BOUNCE | CLEANUP_FLAG_MASK_EXTERNAL,
pickup_input_transp_mask);
- if (info->st.st_uid == var_owner_uid && (info->st.st_mode & S_IROTH) == 0)
+ /* As documented in postsuper(1). */
+ if (MAIL_IS_REQUEUED(info))
cleanup_flags &= ~CLEANUP_FLAG_MILTER;
cleanup = mail_connect_wait(MAIL_CLASS_PUBLIC, var_cleanup_service);
/* Specify \fB-r ALL\fR to requeue all messages. As a safety
/* measure, the word \fBALL\fR must be specified in upper case.
/* .sp
-/* A requeued message is moved to the \fBmaildrop\fR queue, from
-/* where it is copied by the pickup daemon to a new file whose name
-/* is guaranteed to match the new queue file inode number. The
-/* new queue file is subjected again to mail address rewriting and
-/* substitution. This is useful when rewriting rules or virtual
-/* mappings have changed.
+/* A requeued message is moved to the \fBmaildrop\fR queue,
+/* from where it is copied by the \fBpickup\fR(8) and
+/* \fBcleanup\fR(8) daemons to a new queue file. In many
+/* respects its handling differs from that of a new local
+/* submission.
+/* .RS
+/* .IP \(bu
+/* The message is not subjected to the smtpd_milters or
+/* non_smtpd_milters settings. When mail has passed through
+/* an external content filter, this would produce incorrect
+/* results with Milter applications that depend on original
+/* SMTP connection state information.
+/* .IP \(bu
+/* The message is subjected again to mail address rewriting
+/* and substitution. This is useful when rewriting rules or
+/* virtual mappings have changed.
/* .sp
+/* The address rewriting context (local or remote) is the same
+/* as when the message was received.
+/* .IP \(bu
+/* The message is subjected to the same content_filter settings
+/* (if any) as used for new local mail submissions. This is
+/* useful when content_filter settings have changed.
+/* .RE
+/* .IP
/* Warning: Postfix queue IDs are reused.
/* There is a very small possibility that \fBpostsuper\fR(1) requeues
/* the wrong message file when it is executed while the Postfix mail
projects / thirdparty / postfix.git / commitdiff
