xref: /netbsd-src/external/ibm-public/postfix/dist/proto/XCLIENT_README.html (revision 7330f729ccf0bd976a06f95fad452fe774fc7fd1)
1<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
2        "http://www.w3.org/TR/html4/loose.dtd">
3
4<html>
5
6<head>
7
8<title>Postfix XCLIENT Howto</title>
9
10<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
11
12</head>
13
14<body>
15
16<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix XCLIENT Howto</h1>
17
18<hr>
19
20<h2>Purpose of the XCLIENT extension to SMTP</h2>
21
22<p> When an SMTP server announces support for the XCLIENT command,
23an SMTP client may send information that overrides one or more
24client-related session attributes. The XCLIENT command targets the
25following problems: </p>
26
27<ol>
28
29    <li> <p> Access control tests.  SMTP server access rules are
30    difficult to verify when decisions can be triggered only by
31    remote clients.  In order to facilitate access rule testing,
32    an authorized SMTP client test program needs the ability to
33    override the SMTP server's idea of the SMTP client hostname,
34    network address, and other client information, for the entire
35    duration of an SMTP session.  </p>
36
37    <li> <p> Client software that downloads mail from an up-stream
38    mail server and injects it into a local MTA via SMTP. In order
39    to take advantage of the local MTA's SMTP server access rules,
40    the client software needs the ability to override the SMTP
41    server's idea of the remote client name, client address and
42    other information.  Such information can typically be extracted
43    from the up-stream mail server's Received:  message header. </p>
44
45    <li> <p> Post-filter access control and logging. With
46    Internet-&gt;filter-&gt;MTA style content filter applications,
47    the filter can be simplified if it can delegate decisions
48    concerning mail relay and other access control to the MTA. This
49    is especially useful when the filter acts as a transparent
50    proxy for SMTP commands.  This requires that the filter can
51    override the MTA's idea of the SMTP client hostname, network
52    address, and other information. </p>
53
54</ol>
55
56<h2>XCLIENT Command syntax</h2>
57
58<p> An example client-server conversation is given at the end
59of this document. </p>
60
61<p> In SMTP server EHLO replies, the keyword associated with this
62extension is XCLIENT. It is followed by the names of the attributes
63that the XCLIENT implementation supports.  </p>
64
65<p> The XCLIENT command may be sent at any time, except in the
66middle of a mail delivery transaction (i.e.  between MAIL and DOT,
67or MAIL and RSET).  The XCLIENT command may be pipelined when the
68server supports ESMTP command pipelining. To avoid triggering
69spamware detectors, the command should be sent at the end of a
70command group.  </p>
71
72<p> The syntax of XCLIENT requests is described below.  Upper case
73and quoted strings specify terminals, lowercase strings specify
74meta terminals, and SP is whitespace.  Although command and attribute
75names are shown in upper case, they are in fact case insensitive.
76</p>
77
78<blockquote>
79<p>
80    xclient-command = XCLIENT 1*( SP attribute-name"="attribute-value )
81</p>
82<p>
83    attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | LOGIN )
84</p>
85<p>
86    attribute-value = xtext
87</p>
88</blockquote>
89
90<ul>
91
92    <li> <p> Attribute values are xtext encoded as per RFC 1891.
93    </p>
94
95    <li> <p> The NAME attribute specifies an SMTP client hostname
96    (not an SMTP client address), [UNAVAILABLE] when client hostname
97    lookup failed due to a permanent error, or [TEMPUNAVAIL] when
98    the lookup error condition was transient. </p>
99
100    <li> <p> The ADDR attribute specifies an SMTP client numerical
101    IPv4 network address, an IPv6 address prefixed with IPV6:, or
102    [UNAVAILABLE] when the address information is unavailable.
103    Address information is not enclosed with []. </p>
104
105    <li> <p> The PORT attribute specifies the SMTP client TCP port
106    number as a decimal number, or [UNAVAILABLE] when the information
107    is unavailable.  </p>
108
109    <li> <p> The PROTO attribute specifies either SMTP or ESMTP.
110    </p>
111
112    <li> <p> The HELO attribute specifies an SMTP HELO parameter
113    value, or the value [UNAVAILABLE] when the information is
114    unavailable.  </p>
115
116    <li> <p> The LOGIN attribute specifies a SASL login name, or
117    the value [UNAVAILABLE] when the information is unavailable.
118    </p>
119
120</ul>
121
122<p> Note 1: syntactically valid NAME and HELO attribute-value
123elements can be up to 255 characters long. The client must not send
124XCLIENT commands that exceed the 512 character limit for SMTP
125commands. To avoid exceeding the limit the client should send the
126information in multiple XCLIENT commands; for example, send NAME
127and ADDR last, after HELO and PROTO. Once ADDR is sent, the client
128is usually no longer authorized to send XCLIENT commands. </p>
129
130<p> Note 2: [UNAVAILABLE], [TEMPUNAVAIL] and IPV6:  may be specified
131in upper case, lower case or mixed case. </p>
132
133<p> Note 3: Postfix implementations prior to version 2.3 do not
134xtext encode attribute values. Servers that wish to interoperate
135with these older implementations should be prepared to receive
136unencoded information. </p>
137
138<p> Note 4: Some Postfix implementations do not implement the PORT
139or LOGIN attributes.  </p>
140
141<h2>XCLIENT Server response</h2>
142
143<p> Upon receipt of a correctly formatted XCLIENT command, the
144server resets state to the initial SMTP greeting protocol stage.
145Depending on the outcome of optional access decisions, the server
146responds with 220 or with a suitable rejection code.
147
148<p> For practical reasons it is not always possible to reset the
149complete server state to the initial SMTP greeting protocol stage:
150</p>
151
152<ul>
153
154<li> <p> TLS session information may not be reset, because turning off
155TLS leaves the connection in an undefined state.  Consequently, the
156server may not announce STARTTLS when TLS is already active, and
157access decisions may be influenced by client certificate information
158that was received prior to the XCLIENT command. </p>
159
160<li> <p> The SMTP server must not reset attributes that were received
161with the last XCLIENT command. This includes HELO or PROTO attributes.
162</p>
163
164</ul>
165
166<p> NOTE: Postfix implementations prior to version 2.3 do not jump
167back to the initial SMTP greeting protocol stage.  These older
168implementations will not correctly simulate connection-level access
169decisions under some conditions.  </p>
170
171<h2> XCLIENT server reply codes </h2>
172
173<blockquote>
174
175<table border="1" bgcolor="#f0f0ff">
176
177<tr> <th> Code </th> <th> Meaning </th> </tr>
178
179<tr> <td> 220 </td> <td> success  </td> </tr>
180
181<tr> <td> 421 </td> <td> unable to proceed, disconnecting </td> </tr>
182
183<tr> <td> 501 </td> <td> bad command parameter syntax </td> </tr>
184
185<tr> <td> 503 </td> <td> mail transaction in progress </td> </tr>
186
187<tr> <td> 550 </td> <td> insufficient authorization </td> </tr>
188
189<tr> <td> other </td> <td> connection rejected by connection-level
190access decision </td> </tr>
191
192</table>
193
194</blockquote>
195
196<h2>XCLIENT Example</h2>
197
198<p> In the example, the client impersonates a mail originating
199system by passing all SMTP client information via the XCLIENT
200command.  Information sent by the client is shown in bold font.
201</p>
202
203<blockquote>
204<pre>
205220 server.example.com ESMTP Postfix
206<b>EHLO client.example.com</b>
207250-server.example.com
208250-PIPELINING
209250-SIZE 10240000
210250-VRFY
211250-ETRN
212250-XCLIENT NAME ADDR PROTO HELO
213250 8BITMIME
214<b>XCLIENT NAME=spike.porcupine.org ADDR=168.100.189.2</b>
215220 server.example.com ESMTP Postfix
216<b>EHLO spike.porcupine.org</b>
217250-server.example.com
218250-PIPELINING
219250-SIZE 10240000
220250-VRFY
221250-ETRN
222250-XCLIENT NAME ADDR PROTO HELO
223250 8BITMIME
224<b>MAIL FROM:&lt;wietse@porcupine.org&gt;</b>
225250 Ok
226<b>RCPT TO:&lt;user@example.com&gt;</b>
227250 Ok
228<b>DATA</b>
229354 End data with &lt;CR&gt;&lt;LF&gt;.&lt;CR&gt;&lt;LF&gt;
230<b>. . .<i>message content</i>. . .</b>
231<b>.</b>
232250 Ok: queued as 763402AAE6
233<b>QUIT</b>
234221 Bye
235</pre>
236</blockquote>
237
238<h2>Security</h2>
239
240<p> The XCLIENT command changes audit trails and/or SMTP client
241access permissions. Use of this command must be restricted to
242authorized SMTP clients. </p>
243
244<h2>SMTP connection caching</h2>
245
246<p> XCLIENT attributes persist until the end of an SMTP session.
247If one session is used to deliver mail on behalf of different SMTP
248clients, the XCLIENT attributes need to be reset as appropriate
249before each MAIL FROM command. </p>
250
251<h2> References </h2>
252
253<p> Moore, K, "SMTP Service Extension for Delivery Status Notifications",
254RFC 1891, January 1996. </p>
255
256</body>
257
258</html>
259