Purpose of the XCLIENT extension to SMTP
========================================

The XCLIENT command targets the following problems:

1 - Access control tests. SMTP server access rules are difficult
to verify when decisions can be triggered only by remote clients.
In order to facilitate access rule testing, an authorized SMTP
client test program needs the ability to override the SMTP server's
idea of the SMTP client hostname, network address, and other client
information, for the entire duration of an SMTP session.

2 - Client software that downloads mail from an up-stream mail
server and injects it into a local MTA via SMTP. In order to take
advantage of the local MTA's SMTP server access rules, the client
software needs the ability to override the SMTP server's idea of
the remote client name, client address and other information.  Such
information can typically be extracted from the up-stream mail
server's Received:  message header.

3 - Post-filter access control and logging. With Internet->filter->MTA
style content filter applications, the filter can be simplified if
it can delegate decisions concerning mail relay and other access
control to the MTA. This is especially useful when the filter acts
as a transparent proxy for SMTP commands. As in the other examples,
this requires that the filter can override the MTA's idea of the
SMTP client hostname, network address, and other information.

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

In SMTP server EHLO replies, the keyword associated with this
extension is XCLIENT. It is followed by the names of the attributes
that the XCLIENT 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.

    xclient-command = XCLIENT 1*( SP name"="value )

    name = ( NAME | ADDR | PROTO | HELO )

The XCLIENT 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 XCLIENT reply codes are as follows:

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

The NAME attribute specifies an SMTP client hostname (not an SMTP
client address), [UNAVAILABLE] when client hostname lookup failed
due to a permanent error, or [TEMPUNAVAIL] when the lookup error
condition was transient.

The ADDR attribute specifies an SMTP client 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 PROTO attribute specifies either SMTP or ESMTP.

The HELO attribute specifies an SMTP HELO parameter value, or the
value [UNAVAILABLE] when the information is unavailable.

Note 1: syntactically valid NAME and HELO attributes can be up to
255 characters long. The client must not send XCLIENT commands that
exceed the 512 character limit for SMTP commands.

Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6:  may be specified in
upper case, lower case or mixed case.

Security
========

The XCLIENT command changes audit trails and/or SMTP client access
permissions. Use of this command must be restricted to authorized
SMTP clients. However, the XCLIENT command should not override its
own access control mechanism.

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

XCLIENT attributes persist until the end of an SMTP session.  If
one session is used to deliver mail from different SMTP clients,
the XCLIENT attributes need to be reset as appropriate in between
deliveries.
