1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
|
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Postfix XFORWARD Howto</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel='stylesheet' type='text/css' href='postfix-doc.css'>
</head>
<body>
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix XFORWARD Howto</h1>
<hr>
<h2>Purpose of the XFORWARD extension to SMTP</h2>
<p> When an SMTP server announces support for the XFORWARD command,
an SMTP client may send information that overrides one or more
client-related logging attributes. The XFORWARD command targets
the following problem: </p>
<ul>
<li> <p> 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. </p>
</ul>
<p> This extension is implemented as a separate ESMTP 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 to support other extensions such
as AUTH and DSN. </p>
<h2>XFORWARD Command syntax</h2>
<p> An example of a client-server conversation is given at the end
of this document. </p>
<p> 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. </p>
<p> After receiving the server's announcement for XFORWARD support,
the client may send XFORWARD requests at any time except in
the middle of a mail delivery transaction (i.e. between MAIL and
RSET or DOT). The command may be pipelined when the server supports
ESMTP command pipelining. </p>
<p> 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.
</p>
<blockquote>
<p>
xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value )
</p>
<p>
attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | IDENT | SOURCE )
</p>
<p>
attribute-value = xtext
</p>
</blockquote>
<ul>
<li> <p> Attribute values are xtext encoded as per RFC 1891.
</p>
<li> <p> The NAME attribute specifies the up-stream hostname,
or [UNAVAILABLE] when the information is unavailable. The
hostname may be a non-DNS hostname. </p>
<li> <p> The ADDR attribute specifies the up-stream network
address: a numerical IPv4 network address, an IPv6 address
prefixed with IPV6:, or [UNAVAILABLE] when the address information
is unavailable. Address information is not enclosed with [].
</p>
<li> <p> The PORT attribute specifies an up-stream client TCP
port number in decimal, or [UNAVAILABLE] when the information
is unavailable. </p>
<li> <p> The PROTO attribute specifies the mail protocol for
receiving mail from the up-stream host. This may be an SMTP or
non-SMTP protocol name of up to 64 characters, or [UNAVAILABLE]
when the information is unavailable. </p>
<li> <p> 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. </p>
<li> <p> The IDENT attribute specifies a local message identifier
on the up-stream host, or [UNAVAILABLE] when the information
is unavailable. The down-stream MTA may log this information
together with its own local message identifier to facilitate
message tracking across MTAs. </p>
<li> <p> The SOURCE attribute specifies LOCAL when the message
was received from a source that is local with respect to the
up-stream host (for example, the message originated from the
up-stream host itself), REMOTE for all other mail, or [UNAVAILABLE]
when the information is unavailable. The down-stream MTA may
decide to enable features such as header munging or address
qualification with mail from local sources but not other sources.
</p>
</ul>
<p> Note 1: an attribute-value element must not be longer than
255 characters (specific attributes may impose shorter lengths).
After xtext decoding, attribute values must not contain control
characters, non-ASCII characters, whitespace, or other characters
that are special in message headers. </p>
<p> 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. </p>
<p> Note 3: [UNAVAILABLE] may be specified in upper case, lower
case or mixed case. </p>
<p> Note 4: Postfix implementations prior to version 2.3 do not
xtext encode attribute values. Servers that wish to interoperate
with these older implementations should be prepared to receive
unencoded information. </p>
<h2> XFORWARD Server operation </h2>
<p> The server maintains a set of XFORWARD attributes with forwarded
information, in addition the current SMTP session attributes.
Normally, all XFORWARD attributes are in the undefined state, and
the server uses the current SMTP session attributes for logging
purposes. </p>
<p> Upon receipt of an initial XFORWARD command, the SMTP server
initializes all XFORWARD attributes to [UNAVAILABLE]. With each
valid XFORWARD command, the server updates XFORWARD attributes with
the specified values. </p>
<p> The server must not mix client attributes from XFORWARD with
client attributes from the current SMTP session. </p>
<p> At the end of each MAIL FROM transaction (i.e. RSET or DOT),
the server resets all XFORWARD attributes to the undefined state,
and is ready to receive another initial XFORWARD command. </p>
<h2> XFORWARD Server reply codes </h2>
<blockquote>
<table bgcolor="#f0f0ff" border="1">
<tr> <th> Code </th> <th> Meaning </th> </tr>
<tr> <td> 250 </td> <td> success </td> </tr>
<tr> <td> 421 </td> <td> unable to proceed, disconnecting </td> </tr>
<tr> <td> 501 </td> <td> bad command parameter syntax </td> </tr>
<tr> <td> 503 </td> <td> mail transaction in progress </td> </tr>
<tr> <td> 550 </td> <td> insufficient authorization </td> </tr>
</table>
</blockquote>
<h2>XFORWARD Example</h2>
<p> In the following example, information sent by the client is
shown in bold font. </p>
<blockquote>
<pre>
220 server.example.com ESMTP Postfix
<b>EHLO client.example.com</b>
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-XFORWARD NAME ADDR PROTO HELO
250 8BITMIME
<b>XFORWARD NAME=spike.porcupine.org ADDR=168.100.189.2 PROTO=ESMTP </b>
250 Ok
<b>XFORWARD HELO=spike.porcupine.org</b>
250 Ok
<b>MAIL FROM:<wietse@porcupine.org></b>
250 Ok
<b>RCPT TO:<user@example.com></b>
250 Ok
<b>DATA</b>
354 End data with <CR><LF>.<CR><LF>
<b>. . .<i>message content</i>. . .</b>
<b>.</b>
250 Ok: queued as 3CF6B2AAE8
<b>QUIT</b>
221 Bye
</pre>
</blockquote>
<h2>Security</h2>
<p> The XFORWARD command changes audit trails. Use of this command
must be restricted to authorized clients. </p>
<h2>SMTP connection caching</h2>
<p> SMTP connection caching makes it possible to deliver multiple
messages within the same SMTP session. The XFORWARD attributes are
reset after the MAIL FROM transaction completes (after RSET or DOT),
so there is no risk of information leakage. </p>
<h2> References </h2>
<p> Moore, K, "SMTP Service Extension for Delivery Status Notifications",
RFC 1891, January 1996. </p>
</body>
</html>
|
