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
|
PPoossttffiixx XXFFOORRWWAARRDD HHoowwttoo
-------------------------------------------------------------------------------
PPuurrppoossee ooff tthhee XXFFOORRWWAARRDD eexxtteennssiioonn ttoo SSMMTTPP
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:
* 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 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.
XXFFOORRWWAARRDD CCoommmmaanndd ssyynnttaaxx
An example of a client-server conversation is given at the end of this
document.
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.
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.
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.
xforward-command = XFORWARD 1*( SP attribute-name"="attribute-value )
attribute-name = ( NAME | ADDR | PORT | PROTO | HELO | IDENT | SOURCE )
attribute-value = xtext
* Attribute values are xtext encoded as per RFC 1891.
* 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: 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 [].
* The PORT attribute specifies an up-stream client TCP port number in
decimal, or [UNAVAILABLE] when the information is unavailable.
* 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.
* 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.
* 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.
* 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.
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.
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.
Note 3: [UNAVAILABLE] may be specified in upper case, lower case or mixed case.
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.
XXFFOORRWWAARRDD SSeerrvveerr ooppeerraattiioonn
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.
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.
The server must not mix client attributes from XFORWARD with client attributes
from the current SMTP session.
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.
XXFFOORRWWAARRDD SSeerrvveerr rreeppllyy ccooddeess
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|CCooddee|MMeeaanniinngg |
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|250 |success |
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|421 |unable to proceed, disconnecting|
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|501 |bad command parameter syntax |
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|503 |mail transaction in progress |
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|550 |insufficient authorization |
|_ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
XXFFOORRWWAARRDD EExxaammppllee
In the following example, information sent by the client is shown in bold font.
220 server.example.com ESMTP Postfix
EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-XFORWARD NAME ADDR PROTO HELO
250 8BITMIME
XXFFOORRWWAARRDD NNAAMMEE==ssppiikkee..ppoorrccuuppiinnee..oorrgg AADDDDRR==116688..110000..118899..22 PPRROOTTOO==EESSMMTTPP
250 Ok
XXFFOORRWWAARRDD HHEELLOO==ssppiikkee..ppoorrccuuppiinnee..oorrgg
250 Ok
MMAAIILL FFRROOMM::<<wwiieettssee@@ppoorrccuuppiinnee..oorrgg>>
250 Ok
RRCCPPTT TTOO::<<uusseerr@@eexxaammppllee..ccoomm>>
250 Ok
DDAATTAA
354 End data with <CR><LF>.<CR><LF>
.. .. ..mmeessssaaggee ccoonntteenntt.. .. ..
..
250 Ok: queued as 3CF6B2AAE8
QQUUIITT
221 Bye
SSeeccuurriittyy
The XFORWARD command changes audit trails. Use of this command must be
restricted to authorized clients.
SSMMTTPP ccoonnnneeccttiioonn ccaacchhiinngg
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.
RReeffeerreenncceess
Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891,
January 1996.
|
