mir/postfix
2
0
Fork 0
mirror of https://github.com/vdukhovni/postfix synced 2025-08-30 21:55:20 +00:00
Code Issues Releases Wiki Activity

postfix-2.6-20081005

Browse Source
This commit is contained in:
Wietse Venema
2008-10-05 00:00:00 -05:00
committed by Viktor Dukhovni
parent 853d6c4eab
commit aa0f99a969
10 changed files with 142 additions and 107 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
postfix/HISTORY
View File

@@ -14659,16 +14659,27 @@ Apologies for any names omitted.
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.

43
postfix/README_FILES/XFORWARD_README
View File

@@ -32,9 +32,10 @@ In SMTP server EHLO replies, the keyword associated with this extension is
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
@@ -52,9 +53,10 @@ are in fact case insensitive.
* 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.
@@ -86,28 +88,31 @@ limit for SMTP commands.
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.
XXFFOORRWWAARRDD SSeerrvveerr ooppeerraattiioonn
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 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 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].
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.
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), the server resets
all XFORWARD attributes to the undefined state, and is ready to receive another
initial XFORWARD command.
XXFFOORRWWAARRDD SSeerrvveerr rreeppllyy ccooddeess

47
postfix/html/XFORWARD_README.html
View File

@@ -55,8 +55,9 @@ of this document. </p>
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>
@@ -89,9 +90,10 @@ names are shown in upper case, they are in fact case insensitive.
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
@@ -131,33 +133,36 @@ exceed the 512 character limit for SMTP commands. </p>
<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 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 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 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>

4
postfix/html/postconf.5.html
View File

@@ -7304,8 +7304,8 @@ Example:
<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

4
postfix/man/man5/postconf.5
View File

@@ -4114,8 +4114,8 @@ sender_canonical_maps = hash:/etc/postfix/sender_canonical
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

47
postfix/proto/XFORWARD_README.html
View File

@@ -55,8 +55,9 @@ of this document. </p>
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>
@@ -89,9 +90,10 @@ names are shown in upper case, they are in fact case insensitive.
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
@@ -131,33 +133,36 @@ exceed the 512 character limit for SMTP commands. </p>
<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 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 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 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>

4
postfix/proto/postconf.proto
View File

@@ -9340,8 +9340,8 @@ is placed into the Postfix configuration directory. </p>
<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

2
postfix/src/global/mail_version.h
View File

@@ -20,7 +20,7 @@
* 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

47
postfix/src/smtpd/smtpd.c
View File

@@ -1756,39 +1756,33 @@ static int mail_open_stream(SMTPD_STATE *state)
/*
* 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",
@@ -1816,13 +1810,16 @@ static int mail_open_stream(SMTPD_STATE *state)
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);

22
postfix/src/smtpd/smtpd.h
View File

@@ -228,9 +228,20 @@ extern void smtpd_state_reset(SMTPD_STATE *);
#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"
@@ -305,9 +316,10 @@ extern void smtpd_peer_reset(SMTPD_STATE *state);
* 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)