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 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 in order 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 ) * 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 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. Note 1: Attribute values must not be longer than 255 characters (specific attributes may impose shorter lengths), must not contain control characters, non-ASCII characters, whitespace, or other characters that are special in message headers. Future attributes that may violate this should use xtext encoding as described in RFC 1891. 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. The XFORWARD server reply codes are as follows: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |CCooddee|MMeeaanniinngg | |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | |250 |success | |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | |501 |bad command parameter syntax | |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | |503 |mail transaction in progress | |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | |421 |unable to proceed, disconnecting| |_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | 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::<> 250 Ok RRCCPPTT TTOO::<> 250 Ok DDAATTAA 354 End data with . .. .. ..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.