20081003
- Bugfix (introduced Postfix 2.1): the introduction of XFORWARD
- support introduced cosmetic errors in the logging of client
- attributes and in local(8)/pipe(8) $name expansion. Postfix
- did not propagate that a message originated as a local
- submission, and it sometimes failed to distinguish between
- local submissions and submissions from clients with unknown
- hostname etc. attributes. This also involves a minor change
- to the XFORWARD protocol. Files: smtpd/smtpd.c, qmqpd/qmqpd.c,
- smtp/smtp_proto.c, cleanup/cleanup_envelope.c, proto/XFORWARD.html.
+ Bugfix (introduced Postfix 2.1): when XFORWARD support was
+ introduced with Postfix 2.1, the specification failed to
+ clearly distinguish between missing and non-existent client
+ information. This ambiguity affected the implementation:
+ in $name expansions by delivery agents, unknown client
+ hostnames could became empty strings (as if a submission
+ was local), and local submissions could appear to originate
+ from an SMTP-based content filter. This was fixed with a
+ a minor semantic change to the XFORWARD protocol. Files:
+ smtpd/smtpd.c, qmqpd/qmqpd.c, smtp/smtp_proto.c,
+ cleanup/cleanup_envelope.c, proto/XFORWARD.html.
Feature: a DUNNO lookup result in per_sender_relayhost_maps
stops the search without replacing the next-hop destination.
File: trivial-rewrite/resolve.c.
+
+20081005
+
+ Further refinements to the handling of missing or non-existent
+ remote client attributes. Files: smtpd/smtpd.c, smtpd/smtpd.h.
+
+ The XFORWARD specification of the ADDR attribute did not
+ agree with the actual on-the-wire protocol. The spec has
+ been updated. File: proto/XFORWARD_README.html.
XFORWARD. The keyword is followed by the names of the attributes that the
XFORWARD implementation supports.
-The client may send one or more XFORWARD requests at any time except in the
-middle of a mail delivery transaction (i.e. between MAIL and RSET or DOT). The
-command may be pipelined when the server supports ESMTP command pipelining.
+After receiving the server's announcement for XFORWARD support, the client may
+send one or more XFORWARD requests at any time except in the middle of a mail
+delivery transaction (i.e. between MAIL and RSET or DOT). The command may be
+pipelined when the server supports ESMTP command pipelining.
The syntax of XFORWARD requests is described below. Upper case and quoted
strings specify terminals, lowercase strings specify meta terminals, and SP is
* The NAME attribute specifies the up-stream hostname, or [UNAVAILABLE] when
the information is unavailable. The hostname may be a non-DNS hostname.
- * The ADDR attribute specifies the up-stream network address, or
- [UNAVAILABLE] when the information is unavailable. Address information is
- not enclosed with []. The address may be a non-IP address.
+ * The ADDR attribute specifies the up-stream network address: a numerical
+ IPv4 network address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE]
+ when the address information is unavailable. Address information is not
+ enclosed with [].
* The PORT attribute specifies an up-stream client TCP port number in
decimal, or [UNAVAILABLE] when the information is unavailable.
Note 3: [UNAVAILABLE] may be specified in upper case, lower case or mixed case.
-Note 4: the XFORWARD server implementation must not mix information from the
-current SMTP session with forwarded information from an up-stream session.
-
-Note 5: Postfix implementations prior to version 2.3 do not xtext encode
+Note 4: Postfix implementations prior to version 2.3 do not xtext encode
attribute values. Servers that wish to interoperate with these older
implementations should be prepared to receive unencoded information.
X\bXF\bFO\bOR\bRW\bWA\bAR\bRD\bD S\bSe\ber\brv\bve\ber\br o\bop\bpe\ber\bra\bat\bti\bio\bon\bn
+The server maintains a set of XFORWARD attributes with forwarded information,
+in addition the current SMTP session attributes. Normally, all XFORWARD
+attributes are in the undefined state, and the server uses the current SMTP
+session attributes for logging purposes.
+
Upon receipt of an initial XFORWARD command, the SMTP server initializes all
XFORWARD attributes to [UNAVAILABLE]. With each valid XFORWARD command, the
-server overwrites attributes with the specified values, and erases attributes
-whose value is specified as [UNAVAILABLE].
+server updates XFORWARD attributes with the specified values.
+
+When both the NAME and ADDR attributes have the value [UNAVAILABLE], the MAIL
+FROM transaction corresponds to a local submission. In this case the server
+must also treat the HELO, PORT and PROTO attributes as [UNAVAILABLE].
-When both the NAME and ADDR attributes have a value of [UNAVAILABLE], the next
-MAIL FROM transaction corresponds to a local submission. In this case the SMTP
-server must ignore the PORT and PROTO attributes. This behavior is available
-with Postfix version 2.6.
+When the server uses XFORWARD attributes for logging purposes, it must not mix
+XFORWARD attributes with attributes from the current SMTP session.
-At the end of each MAIL FROM transaction (i.e. RSET or DOT), all XFORWARD
-attributes are reset to the real client information, and the SMTP server is
-ready to receive another initial XFORWARD command.
+At the end of each MAIL FROM transaction (i.e. RSET or DOT), the server resets
+all XFORWARD attributes to the undefined state, and is ready to receive another
+initial XFORWARD command.
X\bXF\bFO\bOR\bRW\bWA\bAR\bRD\bD S\bSe\ber\brv\bve\ber\br r\bre\bep\bpl\bly\by c\bco\bod\bde\bes\bs
extension is XFORWARD. The keyword is followed by the names of the
attributes that the XFORWARD implementation supports. </p>
-<p> The client may send one or more XFORWARD requests at any time
-except in
+<p> After receiving the server's announcement for XFORWARD support,
+the client may send one or more XFORWARD requests at any time except
+in
the middle of a mail delivery transaction (i.e. between MAIL and
RSET or DOT). The command may be pipelined when the server supports
ESMTP command pipelining. </p>
hostname may be a non-DNS hostname. </p>
<li> <p> The ADDR attribute specifies the up-stream network
- address, or [UNAVAILABLE] when the information is unavailable.
- Address information is not enclosed with []. The address may
- be a non-IP address. </p>
+ address: a numerical IPv4 network address, an IPv6 address
+ prefixed with IPV6:, or [UNAVAILABLE] when the address information
+ is unavailable. Address information is not enclosed with [].
+ </p>
<li> <p> The PORT attribute specifies an up-stream client TCP
port number in decimal, or [UNAVAILABLE] when the information
<p> Note 3: [UNAVAILABLE] may be specified in upper case, lower
case or mixed case. </p>
-<p> Note 4: the XFORWARD server implementation must not mix
-information from the current SMTP session with forwarded information
-from an up-stream session. </p>
-
-<p> Note 5: Postfix implementations prior to version 2.3 do not
+<p> Note 4: Postfix implementations prior to version 2.3 do not
xtext encode attribute values. Servers that wish to interoperate
with these older implementations should be prepared to receive
unencoded information. </p>
<h2> XFORWARD Server operation </h2>
+<p> The server maintains a set of XFORWARD attributes with forwarded
+information, in addition the current SMTP session attributes.
+Normally, all XFORWARD attributes are in the undefined state, and
+the server uses the current SMTP session attributes for logging
+purposes. </p>
+
<p> Upon receipt of an initial XFORWARD command, the SMTP server
initializes all XFORWARD attributes to [UNAVAILABLE]. With each
-valid XFORWARD command, the server overwrites attributes with the
-specified values, and erases attributes whose value is specified
-as [UNAVAILABLE]. </p>
+valid XFORWARD command, the server updates XFORWARD attributes with
+the specified values. </p>
+
+<p> When both the NAME and ADDR attributes have the value [UNAVAILABLE],
+the MAIL FROM transaction corresponds to a local submission. In
+this case the server must also treat the HELO, PORT and PROTO
+attributes as [UNAVAILABLE]. </p>
-<p> When both the NAME and ADDR attributes have a value of
-[UNAVAILABLE], the next MAIL FROM transaction corresponds to a local
-submission. In this case the SMTP server must ignore the PORT and
-PROTO attributes. This behavior is available with Postfix version
-2.6. </p>
+<p> When the server uses XFORWARD attributes for logging purposes,
+it must not mix XFORWARD attributes with attributes from the current
+SMTP session. </p>
<p> At the end of each MAIL FROM transaction (i.e. RSET or DOT),
-all XFORWARD attributes are reset to the real client information,
-and the SMTP server is ready to receive another initial XFORWARD
-command. </p>
+the server resets all XFORWARD attributes to the undefined state,
+and is ready to receive another initial XFORWARD command. </p>
<h2> XFORWARD Server reply codes </h2>
<p> A sender-dependent override for the global <a href="postconf.5.html#relayhost">relayhost</a> parameter
setting. The tables are searched by the envelope sender address and
@domain. A lookup result of DUNNO terminates the search without
-overriding the global <a href="postconf.5.html#relayhost">relayhost</a> parameter setting. This information
-is overruled with <a href="postconf.5.html#relay_transport">relay_transport</a>,
+overriding the global <a href="postconf.5.html#relayhost">relayhost</a> parameter setting (Postfix 2.6 and
+
later). This information is overruled with <a href="postconf.5.html#relay_transport">relay_transport</a>,
<a href="postconf.5.html#default_transport">default_transport</a> and with the <a href="transport.5.html">transport(5)</a> table. </p>
<p> For safety reasons, this feature does not allow $number
A sender-dependent override for the global relayhost parameter
setting. The tables are searched by the envelope sender address and
@domain. A lookup result of DUNNO terminates the search without
-overriding the global relayhost parameter setting. This information
-is overruled with relay_transport,
+overriding the global relayhost parameter setting (Postfix 2.6 and
+later). This information is overruled with relay_transport,
default_transport and with the \fBtransport\fR(5) table.
.PP
For safety reasons, this feature does not allow $number
extension is XFORWARD. The keyword is followed by the names of the
attributes that the XFORWARD implementation supports. </p>
-<p> The client may send one or more XFORWARD requests at any time
-except in
+<p> After receiving the server's announcement for XFORWARD support,
+the client may send one or more XFORWARD requests at any time except
+in
the middle of a mail delivery transaction (i.e. between MAIL and
RSET or DOT). The command may be pipelined when the server supports
ESMTP command pipelining. </p>
hostname may be a non-DNS hostname. </p>
<li> <p> The ADDR attribute specifies the up-stream network
- address, or [UNAVAILABLE] when the information is unavailable.
- Address information is not enclosed with []. The address may
- be a non-IP address. </p>
+ address: a numerical IPv4 network address, an IPv6 address
+ prefixed with IPV6:, or [UNAVAILABLE] when the address information
+ is unavailable. Address information is not enclosed with [].
+ </p>
<li> <p> The PORT attribute specifies an up-stream client TCP
port number in decimal, or [UNAVAILABLE] when the information
<p> Note 3: [UNAVAILABLE] may be specified in upper case, lower
case or mixed case. </p>
-<p> Note 4: the XFORWARD server implementation must not mix
-information from the current SMTP session with forwarded information
-from an up-stream session. </p>
-
-<p> Note 5: Postfix implementations prior to version 2.3 do not
+<p> Note 4: Postfix implementations prior to version 2.3 do not
xtext encode attribute values. Servers that wish to interoperate
with these older implementations should be prepared to receive
unencoded information. </p>
<h2> XFORWARD Server operation </h2>
+<p> The server maintains a set of XFORWARD attributes with forwarded
+information, in addition the current SMTP session attributes.
+Normally, all XFORWARD attributes are in the undefined state, and
+the server uses the current SMTP session attributes for logging
+purposes. </p>
+
<p> Upon receipt of an initial XFORWARD command, the SMTP server
initializes all XFORWARD attributes to [UNAVAILABLE]. With each
-valid XFORWARD command, the server overwrites attributes with the
-specified values, and erases attributes whose value is specified
-as [UNAVAILABLE]. </p>
+valid XFORWARD command, the server updates XFORWARD attributes with
+the specified values. </p>
+
+<p> When both the NAME and ADDR attributes have the value [UNAVAILABLE],
+the MAIL FROM transaction corresponds to a local submission. In
+this case the server must also treat the HELO, PORT and PROTO
+attributes as [UNAVAILABLE]. </p>
-<p> When both the NAME and ADDR attributes have a value of
-[UNAVAILABLE], the next MAIL FROM transaction corresponds to a local
-submission. In this case the SMTP server must ignore the PORT and
-PROTO attributes. This behavior is available with Postfix version
-2.6. </p>
+<p> When the server uses XFORWARD attributes for logging purposes,
+it must not mix XFORWARD attributes with attributes from the current
+SMTP session. </p>
<p> At the end of each MAIL FROM transaction (i.e. RSET or DOT),
-all XFORWARD attributes are reset to the real client information,
-and the SMTP server is ready to receive another initial XFORWARD
-command. </p>
+the server resets all XFORWARD attributes to the undefined state,
+and is ready to receive another initial XFORWARD command. </p>
<h2> XFORWARD Server reply codes </h2>
<p> A sender-dependent override for the global relayhost parameter
setting. The tables are searched by the envelope sender address and
@domain. A lookup result of DUNNO terminates the search without
-overriding the global relayhost parameter setting. This information
-is overruled with relay_transport,
+overriding the global relayhost parameter setting (Postfix 2.6 and
+later). This information is overruled with relay_transport,
default_transport and with the transport(5) table. </p>
<p> For safety reasons, this feature does not allow $number
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20081003"
+#define MAIL_RELEASE_DATE "20081005"
#define MAIL_VERSION_NUMBER "2.6"
#ifdef SNAPSHOT
/*
* Forwarded client attributes. These propagate original client
* information through an SMTP-based content filter, to improve
- * the logging from an after-filter MTA. They are also used in
- * $name expansions by the local(8) and pipe(8) delivery agents.
+ * the logging from an after-filter MTA.
*
- * In the case of a forwarded remote submission, store original
- * client attributes in our own internal representation: either
- * actual values or "unknown". This fixes a problem that was
- * introduced with Postfix 2.1: "unknown" got treated the same
- * way as "non-existent". As before, we don't store non-existent
- * HELO attributes.
+ * In the case of a remote submission, send all client attributes,
+ * including ones with missing values. Otherwise, an unknown
+ * client hostname would be treated as a non-existent hostname
+ * (i.e. local submission).
*
* In the case of a forwarded local submission, specify explicitly
- * that the original client attributes are non-existent. This
- * fixes another problem that was introduced with Postfix 2.1:
- * forwarded local submissions could not override the content
- * filter's own client attributes, so the message would appear to
- * originate from the content filter. To make this work we
- * introduced one change to the XFORWARD protocol: when both NAME
- * and ADDR values are [UNAVAILABLE], this is a local submission.
+ * that the original client attributes are non-existent.
+ * Otherwise, the real client attributes would be used, and mail
+ * would appear to come from the content filter.
*/
- if (state->xforward.flags & SMTPD_STATE_XFORWARD_CLIENT_MASK) {
- if (MAIL_ATTR_IS_KNOWN(FORWARD_NAME(state))
- || MAIL_ATTR_IS_KNOWN(FORWARD_ADDR(state))) {
+ if (SMTPD_HAVE_XFORWARD_ATTR(state)) {
+ if (MAIL_ATTR_IS_KNOWN(state->xforward.name)
+ || MAIL_ATTR_IS_KNOWN(state->xforward.addr)) {
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
- MAIL_ATTR_LOG_CLIENT_NAME, FORWARD_NAME(state));
+ MAIL_ATTR_LOG_CLIENT_NAME, state->xforward.name);
+ /* XXX Backwards compatibility: include IPv6: prefix. */
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
- MAIL_ATTR_LOG_CLIENT_ADDR, FORWARD_ADDR(state));
+ MAIL_ATTR_LOG_CLIENT_ADDR, state->xforward.rfc_addr);
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
- MAIL_ATTR_LOG_CLIENT_PORT, FORWARD_PORT(state));
- if (FORWARD_HELO(state))
+ MAIL_ATTR_LOG_CLIENT_PORT, state->xforward.port);
+ if (state->xforward.helo_name)
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
- MAIL_ATTR_LOG_HELO_NAME, FORWARD_HELO(state));
+ MAIL_ATTR_LOG_HELO_NAME, state->xforward.helo_name);
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
- MAIL_ATTR_LOG_PROTO_NAME, FORWARD_PROTO(state));
+ MAIL_ATTR_LOG_PROTO_NAME, state->xforward.protocol);
} else {
/* Local submission. See also qmgr_message_read(). */
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
MAIL_ATTR_ACT_CLIENT_NAME, state->name);
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
MAIL_ATTR_ACT_REVERSE_CLIENT_NAME, state->reverse_name);
+ /* XXX Backwards compatibility: include IPv6: prefix. */
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
- MAIL_ATTR_ACT_CLIENT_ADDR, state->addr);
+ MAIL_ATTR_ACT_CLIENT_ADDR, state->rfc_addr);
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
MAIL_ATTR_ACT_CLIENT_PORT, state->port);
if (state->helo_name)
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
MAIL_ATTR_ACT_HELO_NAME, state->helo_name);
+ rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%s",
+ MAIL_ATTR_ACT_PROTO_NAME, state->protocol);
rec_fprintf(state->cleanup, REC_TYPE_ATTR, "%s=%u",
MAIL_ATTR_ACT_CLIENT_AF, state->addr_family);
#define SMTPD_CMD_UNKNOWN "UNKNOWN"
/*
- * Representation of unknown client information within smtpd processes. This
- * is not the representation that Postfix uses in queue files, in queue
- * manager delivery requests, or in XCLIENT/XFORWARD commands!
+ * Representation of missing and non-existent client information. Throughout
+ * Postfix, we use the "unknown" string value for missing client information
+ * (e.g., unknown remote client hostname), and we use the empty string or
+ * null pointer for non-existent client information (e.g., no HELO command,
+ * or local submission).
+ *
+ * When XFORWARD support was introduced with Postfix 2.1, the specification
+ * failed to clearly distinguish between missing and non-existent client
+ * information. This ambiguity affected the implementation: unknown client
+ * hostnames could become empty strings (as if a submission was local), and
+ * local submissions could appear to originate from an SMTP-based content
+ * filter. This was corrected during the Postfix 2.6 development cycle by
+ * introducing one semantic change to the XFORWARD protocol: when both NAME
+ * and ADDR values are [UNAVAILABLE], this is a local submission.
*/
#define CLIENT_ATTR_UNKNOWN "unknown"
* current SMTP session with forwarded information from an up-stream
* session.
*/
+#define SMTPD_HAVE_XFORWARD_ATTR(s) \
+ ((s)->xforward.flags & SMTPD_STATE_XFORWARD_INIT)
#define FORWARD_CLIENT_ATTR(s, a) \
- (((s)->xforward.flags & SMTPD_STATE_XFORWARD_CLIENT_MASK) ? \
- (s)->xforward.a : (s)->a)
+ (SMTPD_HAVE_XFORWARD_ATTR(s) ? (s)->xforward.a : (s)->a)
#define FORWARD_ADDR(s) FORWARD_CLIENT_ATTR((s), rfc_addr)
#define FORWARD_NAME(s) FORWARD_CLIENT_ATTR((s), name)
projects / thirdparty / postfix.git / commitdiff
