Purpose of the XFORWARD extension to SMTP
========================================

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 needed by other extensions such as AUTH.

Command syntax
==============

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 general command syntax 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 name"="value )

    name = ( NAME | ADDR | PROTO | HELO )

The XFORWARD command can be sent at any time except in the middle
of a mail delivery transaction (i.e.  between MAIL and DOT).  The
command may be pipelined if the server EHLO reply announces ESMTP
pipelining support.

The XFORWARD reply codes are as follows:

   Code | Meaning
   -----|------------
    250 | success 
    501 | bad command parameter syntax
    503 | mail transaction in progress
    421 | unable to proceed

The information specified with XFORWARD attributes is not limited
to DNS hostnames, IP addresses or SMTP protocol names.  Attribute
values may contain arbitrary text, must not be longer than 255
characters (specific attributes may imposer shorter lengths), must
not contain control characters, non-ASCII characters, whitespace,
or other characters that are special in message headers.

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: 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 2: [UNAVAILABLE] may be specified in upper case, lower case
or mixed case.

Note 3: the XFORWARD server implementation must not mix information
from the current SMTP session with forwarded information from an
up-stream session.

Security
========

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

SMTP connection caching
=======================

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.
