Re: XCLIENT, XFORWARD: widely used, standardisation?

On Wed, Jun 01, 2005 at 05:25:45PM +0100, Richard Dawe wrote:

> (1) How widely used is XCLIENT? Do you know of any ISPs or other
> organisations using XCLIENT to pass information about the originating
> server around?

In the Postfix architecture XCLIENT is primarily intented for testing.
While it also supports fetchmail and similar re-injection scenarios, where
the sender wants to be treated as though it were the client specified in
the XCLIENT command, such use is not recommended. Downstream rejection
of mail creates backscatter.

What is used more frequently is XFORWARD, which makes the original client
information available (for logging and content filters), but does not
impersonate the original client directly. This allows proxy filters
to apply appropriate content policies/scores, while the real client's
identity is used for SMTP acceess control, ...

So if Message-Labs is to harmonize with trusted Postfix clients, you
want to implement XFORWARD, not XCLIENT.

> (2) I saw that some SMTP proxies support XCLIENT. Do any MTAs support
> XCLIENT and/or XFORWARD?

The need for these commands emerged with the introduction of the pre-queue
proxy filter in Postfix 2.1:

http://www.postfix.org/SMTPD_PROXY_README.html

I am not aware of support for these in any other MTA.

> (3) Do you have any plans to standardise XCLIENT and XFORWARD?

This would be nice, because SMTP proxy filter vendors would be able to
implement MTA-neutral filters that would not need to parse the multitude
of Received header formats from various MTAs or know which Received
header represents the entry-point into the organization's network.

This said, most of the gain is in the logs of single-host multi-stage
Postfix configurations, where XFORWARD ensures correct logging by
secondary stages. And so the requirement is mostly that proxies not
remove, reject or damage the XFORWARD command (i.e. just transparently
forward what they don't understand). There is no need for the proxy
to implement support for XFORWARD (the administrator can configure
a regexp to identify the first point-of-entry Received header).

Things get more complex when relaying occurs accross organization
boundaries, and one (say MessageLabs) has to determine the point of
origin in email converging from multiple organizations MTAs, ...

One can see in this situation how it would be useful for you to have a
standard. Such a standard has not been a priority here, because we have
not focused the needs of externally hosted content-filter providers.
This said it would not be unwelcome.

> I actually started writing an Internet draft on a similar mechanism to
> XCLIENT, but based on extra parameters the MAIL FROM. But rather than
> creating another SMTP extension, it would seem sensible to use a
> pre-existing extension like XCLIENT.
>

By all means propose something useful and see whether the IETF will
back a standard in this space. XCLIENT was chosen over MAIL FROM in part
because the size of the data being sent would make the already bloated
MAIL FROM substantially bigger, and potentially create interoperability
issues with firewalls that limit SMTP commands to 1000 bytes or similar.

The IETF on the other hand may be disinclined to expand the set of
SMTP verbs, or simply disinclined to standardize protocols for private
relay arrangements that are not relevant for the general case of domain
to other domain mail. Good luck.

What I really would like to see standardize by the way (but have not
taken the time to propose properly) is my TLS client session key
generation trick that makes TLS session caching work for most
split-brain server caches (logical MX hosts with multiple IPs that
are physically separate hosts, or single IP addresses that map onto
multiple hosts via load-balancers).

--
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomo@postfix.org?body=unsubscribe%20p ostfix-users>