From: Wietse Venema Date: Sun, 5 Oct 2008 05:00:00 +0000 (-0500) Subject: postfix-2.6-20081005 X-Git-Tag: v2.6.0-RC1~17 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=aa0f99a9694d6208ddc232c9220a454239366450;p=thirdparty%2Fpostfix.git postfix-2.6-20081005 --- diff --git a/postfix/HISTORY b/postfix/HISTORY index df86a0a7c..76772ac85 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -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. diff --git a/postfix/README_FILES/XFORWARD_README b/postfix/README_FILES/XFORWARD_README index 40c5cb200..0ad4e7587 100644 --- a/postfix/README_FILES/XFORWARD_README +++ b/postfix/README_FILES/XFORWARD_README @@ -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 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. XXFFOORRWWAARRDD SSeerrvveerr rreeppllyy ccooddeess diff --git a/postfix/html/XFORWARD_README.html b/postfix/html/XFORWARD_README.html index 90f408a9a..9eddd6170 100644 --- a/postfix/html/XFORWARD_README.html +++ b/postfix/html/XFORWARD_README.html @@ -55,8 +55,9 @@ of this document.

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 +

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.

@@ -89,9 +90,10 @@ names are shown in upper case, they are in fact case insensitive. 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.

    + 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 @@ -131,33 +133,36 @@ exceed the 512 character 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 +

    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.

    XFORWARD Server operation

    +

    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].

    +valid XFORWARD command, the 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.

    +the server resets all XFORWARD attributes to the undefined state, +and is ready to receive another initial XFORWARD command.

    XFORWARD Server reply codes

    diff --git a/postfix/html/postconf.5.html b/postfix/html/postconf.5.html index 5b2039f1b..bc1080e74 100644 --- a/postfix/html/postconf.5.html +++ b/postfix/html/postconf.5.html @@ -7304,8 +7304,8 @@ Example:

    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.

    For safety reasons, this feature does not allow $number diff --git a/postfix/man/man5/postconf.5 b/postfix/man/man5/postconf.5 index e61646f80..263f792ae 100644 --- a/postfix/man/man5/postconf.5 +++ b/postfix/man/man5/postconf.5 @@ -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 diff --git a/postfix/proto/XFORWARD_README.html b/postfix/proto/XFORWARD_README.html index a99fb13f1..0cff1389e 100644 --- a/postfix/proto/XFORWARD_README.html +++ b/postfix/proto/XFORWARD_README.html @@ -55,8 +55,9 @@ of this document.

    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 +

    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.

    @@ -89,9 +90,10 @@ names are shown in upper case, they are in fact case insensitive. 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.

    + 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 @@ -131,33 +133,36 @@ exceed the 512 character 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 +

    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.

    XFORWARD Server operation

    +

    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].

    +valid XFORWARD command, the 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.

    +the server resets all XFORWARD attributes to the undefined state, +and is ready to receive another initial XFORWARD command.

    XFORWARD Server reply codes

    diff --git a/postfix/proto/postconf.proto b/postfix/proto/postconf.proto index 8ac9def8e..6b45f1d36 100644 --- a/postfix/proto/postconf.proto +++ b/postfix/proto/postconf.proto @@ -9340,8 +9340,8 @@ is placed into the Postfix configuration directory.

    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.

    For safety reasons, this feature does not allow $number diff --git a/postfix/src/global/mail_version.h b/postfix/src/global/mail_version.h index 83cc90ac8..06af0b44d 100644 --- a/postfix/src/global/mail_version.h +++ b/postfix/src/global/mail_version.h @@ -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 diff --git a/postfix/src/smtpd/smtpd.c b/postfix/src/smtpd/smtpd.c index 09e608ace..340d504ae 100644 --- a/postfix/src/smtpd/smtpd.c +++ b/postfix/src/smtpd/smtpd.c @@ -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); diff --git a/postfix/src/smtpd/smtpd.h b/postfix/src/smtpd/smtpd.h index f00d07852..71184151d 100644 --- a/postfix/src/smtpd/smtpd.h +++ b/postfix/src/smtpd/smtpd.h @@ -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)