PPoossttffiixx XXFFOORRWWAARRDD HHoowwttoo

-------------------------------------------------------------------------------

PPuurrppoossee ooff tthhee XXFFOORRWWAARRDD eexxtteennssiioonn ttoo SSMMTTPP

The XFORWARD command targets the following problem:

  * Logging after SMTP-based content filter. With the deployment of Internet-
    >MTA1->filter->MTA2 style content filter applications, the logging of
    client and message identifying information changes when MTA1 gives the mail
    to the content filter. To simplify the interpretation of MTA2 logging, it
    would help if MTA1 could forward remote client and/or message identifying
    information through the content filter to MTA2, so that the information
    could be logged as part of mail handling transactions.

This extension is implemented as a separate EMSTP command, and can be used to
transmit client or message attributes incrementally. It is not implemented by
passing additional parameters via the MAIL FROM command, because doing so would
require extending the MAIL FROM command length limit by another 600 or more
characters beyond the space that is already needed to support other extensions
such as AUTH.

XXFFOORRWWAARRDD CCoommmmaanndd ssyynnttaaxx

An example of a client-server conversation is given at the end of this
document.

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 the XFORWARD request at any time except in the middle of a
mail delivery transaction (i.e. between MAIL and 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
whitespace. Although command and attribute names are shown in upper case, they
are in fact case insensitive.

    xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value )

    attribute-name = ( NAME | ADDR | PROTO | HELO | SOURCE )

    attribute-value = xtext

  * Attribute values are xtext encoded as per RFC 1891.

  * 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 PROTO attribute specifies the mail protocol for receiving mail from the
    up-stream host. This may be an SMTP or non-SMTP protocol name of up to 64
    characters, or [UNAVAILABLE] when the information is unavailable.

  * The HELO attribute specifies the hostname that the up-stream host announced
    itself with (not necessarily via the SMTP HELO command), or [UNAVAILABLE]
    when the information is unavailable. The hostname may be a non-DNS
    hostname.

  * The SOURCE attribute specifies LOCAL when the message was received from a
    source that is local with respect to the up-stream host (for example, the
    message originated from the up-stream host itself), REMOTE for all other
    mail, or [UNAVAILABLE] when the information is unavailable. The down-stream
    MTA may decide to enable features such as header munging or address
    qualification with mail from local sources but not other sources.

Note 1: an attribute-value element must not be longer than 255 characters
(specific attributes may impose shorter lengths). After xtext decoding,
attribute values must not contain control characters, non-ASCII characters,
whitespace, or other characters that are special in message headers.

Note 2: DNS hostnames can be up to 255 characters long. The XFORWARD client
implementation must not send XFORWARD commands that 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 xtext encode
attribute values. Servers that wish to interoperate with these older
implementations should be prepared to receive unencoded information.

XXFFOORRWWAARRDD SSeerrvveerr rreessppoonnssee

Upon receipt of a correctly formatted XFORWARD command, the server stores the
specified attribute values, and erases the attributes whose value was specified
as [UNAVAILABLE]. All XFORWARD attributes are reset to the real client
information after the MAIL FROM command completes.

XXFFOORRWWAARRDD SSeerrvveerr rreeppllyy ccooddeess

     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
    |CCooddee|MMeeaanniinngg                         |
    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
    |250 |success                         |
    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
    |421 |unable to proceed, disconnecting|
    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
    |501 |bad command parameter syntax    |
    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
    |503 |mail transaction in progress    |
    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
    |550 |insufficient authorization      |
    |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |

XXFFOORRWWAARRDD EExxaammppllee

In the following example, information sent by the client is shown in bold font.

    220 server.example.com ESMTP Postfix
    EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
    250-server.example.com
    250-PIPELINING
    250-SIZE 10240000
    250-VRFY
    250-ETRN
    250-XFORWARD NAME ADDR PROTO HELO
    250 8BITMIME
    XXFFOORRWWAARRDD NNAAMMEE==ssppiikkee..ppoorrccuuppiinnee..oorrgg AADDDDRR==116688..110000..118899..22 PPRROOTTOO==EESSMMTTPP
    250 Ok
    XXFFOORRWWAARRDD HHEELLOO==ssppiikkee..ppoorrccuuppiinnee..oorrgg
    250 Ok
    MMAAIILL FFRROOMM::<<wwiieettssee@@ppoorrccuuppiinnee..oorrgg>>
    250 Ok
    RRCCPPTT TTOO::<<uusseerr@@eexxaammppllee..ccoomm>>
    250 Ok
    DDAATTAA
    354 End data with <CR><LF>.<CR><LF>
    .. .. ..mmeessssaaggee ccoonntteenntt.. .. ..
    ..
    250 Ok: queued as 3CF6B2AAE8
    QQUUIITT
    221 Bye

SSeeccuurriittyy

The XFORWARD command changes audit trails. Use of this command must be
restricted to authorized clients.

SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg

SMTP connection caching makes it possible to deliver multiple messages within
the same SMTP session. The XFORWARD attributes are reset after the MAIL FROM
command completes, so there is no risk of information leakage.

RReeffeerreenncceess

Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891,
January 1996.

