| rev |
line source |
|
yuuji@0
|
1
|
|
yuuji@0
|
2
|
|
yuuji@0
|
3
|
|
yuuji@0
|
4
|
|
yuuji@0
|
5
|
|
yuuji@0
|
6
|
|
yuuji@0
|
7 Network Working Group C. Newman
|
|
yuuji@0
|
8 Request for Comments: 4468 Sun Microsystems
|
|
yuuji@0
|
9 Updates: 3463 May 2006
|
|
yuuji@0
|
10 Category: Standards Track
|
|
yuuji@0
|
11
|
|
yuuji@0
|
12
|
|
yuuji@0
|
13 Message Submission BURL Extension
|
|
yuuji@0
|
14
|
|
yuuji@0
|
15 Status of This Memo
|
|
yuuji@0
|
16
|
|
yuuji@0
|
17 This document specifies an Internet standards track protocol for the
|
|
yuuji@0
|
18 Internet community, and requests discussion and suggestions for
|
|
yuuji@0
|
19 improvements. Please refer to the current edition of the "Internet
|
|
yuuji@0
|
20 Official Protocol Standards" (STD 1) for the standardization state
|
|
yuuji@0
|
21 and status of this protocol. Distribution of this memo is unlimited.
|
|
yuuji@0
|
22
|
|
yuuji@0
|
23 Copyright Notice
|
|
yuuji@0
|
24
|
|
yuuji@0
|
25 Copyright (C) The Internet Society (2006).
|
|
yuuji@0
|
26
|
|
yuuji@0
|
27 Abstract
|
|
yuuji@0
|
28
|
|
yuuji@0
|
29 The submission profile of Simple Mail Transfer Protocol (SMTP)
|
|
yuuji@0
|
30 provides a standard way for an email client to submit a complete
|
|
yuuji@0
|
31 message for delivery. This specification extends the submission
|
|
yuuji@0
|
32 profile by adding a new BURL command that can be used to fetch
|
|
yuuji@0
|
33 submission data from an Internet Message Access Protocol (IMAP)
|
|
yuuji@0
|
34 server. This permits a mail client to inject content from an IMAP
|
|
yuuji@0
|
35 server into the SMTP infrastructure without downloading it to the
|
|
yuuji@0
|
36 client and uploading it back to the server.
|
|
yuuji@0
|
37
|
|
yuuji@0
|
38
|
|
yuuji@0
|
39
|
|
yuuji@0
|
40
|
|
yuuji@0
|
41
|
|
yuuji@0
|
42
|
|
yuuji@0
|
43
|
|
yuuji@0
|
44
|
|
yuuji@0
|
45
|
|
yuuji@0
|
46
|
|
yuuji@0
|
47
|
|
yuuji@0
|
48
|
|
yuuji@0
|
49
|
|
yuuji@0
|
50
|
|
yuuji@0
|
51
|
|
yuuji@0
|
52
|
|
yuuji@0
|
53
|
|
yuuji@0
|
54
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Newman Standards Track [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 Table of Contents
|
|
yuuji@0
|
64
|
|
yuuji@0
|
65 1. Introduction ....................................................2
|
|
yuuji@0
|
66 2. Conventions Used in This Document ...............................2
|
|
yuuji@0
|
67 3. BURL Submission Extension .......................................3
|
|
yuuji@0
|
68 3.1. SMTP Submission Extension Registration .....................3
|
|
yuuji@0
|
69 3.2. BURL Transaction ...........................................3
|
|
yuuji@0
|
70 3.3. The BURL IMAP Options ......................................4
|
|
yuuji@0
|
71 3.4. Examples ...................................................5
|
|
yuuji@0
|
72 3.5. Formal Syntax ..............................................6
|
|
yuuji@0
|
73 4. 8-Bit and Binary ................................................7
|
|
yuuji@0
|
74 5. Updates to RFC 3463 .............................................7
|
|
yuuji@0
|
75 6. Response Codes ..................................................7
|
|
yuuji@0
|
76 7. IANA Considerations .............................................9
|
|
yuuji@0
|
77 8. Security Considerations .........................................9
|
|
yuuji@0
|
78 9. References .....................................................11
|
|
yuuji@0
|
79 9.1. Normative References ......................................11
|
|
yuuji@0
|
80 9.2. Informative References ....................................12
|
|
yuuji@0
|
81 Appendix A. Acknowledgements .....................................13
|
|
yuuji@0
|
82
|
|
yuuji@0
|
83 1. Introduction
|
|
yuuji@0
|
84
|
|
yuuji@0
|
85 This specification defines an extension to the standard Message
|
|
yuuji@0
|
86 Submission [RFC4409] protocol to permit data to be fetched from an
|
|
yuuji@0
|
87 IMAP server at message submission time. This MAY be used in
|
|
yuuji@0
|
88 conjunction with the CHUNKING [RFC3030] mechanism so that chunks of
|
|
yuuji@0
|
89 the message can come from an external IMAP server. This provides the
|
|
yuuji@0
|
90 ability to forward an email message without first downloading it to
|
|
yuuji@0
|
91 the client.
|
|
yuuji@0
|
92
|
|
yuuji@0
|
93 2. Conventions Used in This Document
|
|
yuuji@0
|
94
|
|
yuuji@0
|
95 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
|
|
yuuji@0
|
96 in this document are to be interpreted as defined in "Key words for
|
|
yuuji@0
|
97 use in RFCs to Indicate Requirement Levels" [RFC2119].
|
|
yuuji@0
|
98
|
|
yuuji@0
|
99 The formal syntax uses the Augmented Backus-Naur Form (ABNF)
|
|
yuuji@0
|
100 [RFC4234] notation including the core rules defined in Appendix B of
|
|
yuuji@0
|
101 RFC 4234.
|
|
yuuji@0
|
102
|
|
yuuji@0
|
103
|
|
yuuji@0
|
104
|
|
yuuji@0
|
105
|
|
yuuji@0
|
106
|
|
yuuji@0
|
107
|
|
yuuji@0
|
108
|
|
yuuji@0
|
109
|
|
yuuji@0
|
110
|
|
yuuji@0
|
111
|
|
yuuji@0
|
112
|
|
yuuji@0
|
113
|
|
yuuji@0
|
114 Newman Standards Track [Page 2]
|
|
yuuji@0
|
115
|
|
yuuji@0
|
116 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 3. BURL Submission Extension
|
|
yuuji@0
|
120
|
|
yuuji@0
|
121 This section defines the BURL submission extension.
|
|
yuuji@0
|
122
|
|
yuuji@0
|
123 3.1. SMTP Submission Extension Registration
|
|
yuuji@0
|
124
|
|
yuuji@0
|
125 1. The name of this submission extension is "BURL". This extends
|
|
yuuji@0
|
126 the Message Submission protocol on port 587 and MUST NOT be
|
|
yuuji@0
|
127 advertised by a regular SMTP [RFC2821] server on port 25 that
|
|
yuuji@0
|
128 acts as a relay for incoming mail from other SMTP relays.
|
|
yuuji@0
|
129
|
|
yuuji@0
|
130 2. The EHLO keyword value associated with the extension is "BURL".
|
|
yuuji@0
|
131
|
|
yuuji@0
|
132 3. The BURL EHLO keyword will have zero or more arguments. The only
|
|
yuuji@0
|
133 argument defined at this time is the "imap" argument, which MUST
|
|
yuuji@0
|
134 be present in order to use IMAP URLs with BURL. Clients MUST
|
|
yuuji@0
|
135 ignore other arguments after the BURL EHLO keyword unless they
|
|
yuuji@0
|
136 are defined by a subsequent IETF standards track specification.
|
|
yuuji@0
|
137 The arguments that appear after the BURL EHLO keyword may change
|
|
yuuji@0
|
138 subsequent to the use of SMTP AUTH [RFC2554], so a server that
|
|
yuuji@0
|
139 advertises BURL with no arguments prior to authentication
|
|
yuuji@0
|
140 indicates that BURL is supported but authentication is required
|
|
yuuji@0
|
141 to use it.
|
|
yuuji@0
|
142
|
|
yuuji@0
|
143 4. This extension adds the BURL SMTP verb. This verb is used as a
|
|
yuuji@0
|
144 replacement for the DATA command and is only permitted during a
|
|
yuuji@0
|
145 mail transaction after at least one successful RCPT TO.
|
|
yuuji@0
|
146
|
|
yuuji@0
|
147 3.2. BURL Transaction
|
|
yuuji@0
|
148
|
|
yuuji@0
|
149 A simple BURL transaction will consist of MAIL FROM, one or more RCPT
|
|
yuuji@0
|
150 TO headers, and a BURL command with the "LAST" tag. The BURL command
|
|
yuuji@0
|
151 will include an IMAP URL pointing to a fully formed message ready for
|
|
yuuji@0
|
152 injection into the SMTP infrastructure. If PIPELINING [RFC2920] is
|
|
yuuji@0
|
153 advertised, the client MAY send the entire transaction in one round
|
|
yuuji@0
|
154 trip. If no valid RCPT TO address is supplied, the BURL command will
|
|
yuuji@0
|
155 simply fail, and no resolution of the BURL URL argument will be
|
|
yuuji@0
|
156 performed. If at least one valid RCPT TO address is supplied, then
|
|
yuuji@0
|
157 the BURL URL argument will be resolved before the server responds to
|
|
yuuji@0
|
158 the command.
|
|
yuuji@0
|
159
|
|
yuuji@0
|
160 A more sophisticated BURL transaction MAY occur when the server also
|
|
yuuji@0
|
161 advertises CHUNKING [RFC3030]. In this case, the BURL and BDAT
|
|
yuuji@0
|
162 commands may be interleaved until one of them terminates the
|
|
yuuji@0
|
163 transaction with the "LAST" argument. If PIPELINING [RFC2920] is
|
|
yuuji@0
|
164 also advertised, then the client may pipeline the entire transaction
|
|
yuuji@0
|
165 in one round-trip. However, it MUST wait for the results of the
|
|
yuuji@0
|
166 "LAST" BDAT or BURL command prior to initiating a new transaction.
|
|
yuuji@0
|
167
|
|
yuuji@0
|
168
|
|
yuuji@0
|
169
|
|
yuuji@0
|
170 Newman Standards Track [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 The BURL command directs the server to fetch the data object to which
|
|
yuuji@0
|
176 the URL refers and include it in the message. If the URL fetch
|
|
yuuji@0
|
177 fails, the server will fail the entire transaction.
|
|
yuuji@0
|
178
|
|
yuuji@0
|
179 3.3. The BURL IMAP Options
|
|
yuuji@0
|
180
|
|
yuuji@0
|
181 When "imap" is present in the space-separated list of arguments
|
|
yuuji@0
|
182 following the BURL EHLO keyword, it indicates that the BURL command
|
|
yuuji@0
|
183 supports the URLAUTH [RFC4467] extended form of IMAP URLs [RFC2192]
|
|
yuuji@0
|
184 and that the submit server is configured with the necessary
|
|
yuuji@0
|
185 credentials to resolve "urlauth=submit+" IMAP URLs for the submit
|
|
yuuji@0
|
186 server's domain.
|
|
yuuji@0
|
187
|
|
yuuji@0
|
188 Subsequent to a successful SMTP AUTH command, the submission server
|
|
yuuji@0
|
189 MAY indicate a prearranged trust relationship with a specific IMAP
|
|
yuuji@0
|
190 server by including a BURL EHLO keyword argument of the form
|
|
yuuji@0
|
191 "imap://imap.example.com". In this case, the submission server will
|
|
yuuji@0
|
192 permit a regular IMAP URL referring to messages or parts of messages
|
|
yuuji@0
|
193 on imap.example.com that the user who authenticated to the submit
|
|
yuuji@0
|
194 server can access. Note that this form does not imply that the
|
|
yuuji@0
|
195 submit server supports URLAUTH URLs; the submit server must advertise
|
|
yuuji@0
|
196 both "imap" and "imap://imap.example.com" to indicate support for
|
|
yuuji@0
|
197 both extended and non-extended URL forms.
|
|
yuuji@0
|
198
|
|
yuuji@0
|
199 When the submit server connects to the IMAP server, it acts as an
|
|
yuuji@0
|
200 IMAP client and thus is subject to both the mandatory-to-implement
|
|
yuuji@0
|
201 IMAP capabilities in Section 6.1.1 of RFC 3501, and the security
|
|
yuuji@0
|
202 considerations in Section 11 of RFC 3501. Specifically, this
|
|
yuuji@0
|
203 requires that the submit server implement a configuration that uses
|
|
yuuji@0
|
204 STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the
|
|
yuuji@0
|
205 IMAP server.
|
|
yuuji@0
|
206
|
|
yuuji@0
|
207 When the submit server resolves a URLAUTH IMAP URL, it uses submit
|
|
yuuji@0
|
208 server credentials when authenticating to the IMAP server. The
|
|
yuuji@0
|
209 authentication identity and password used for submit credentials MUST
|
|
yuuji@0
|
210 be configurable. The string "submit" is suggested as a default value
|
|
yuuji@0
|
211 for the authentication identity, with no default for the password.
|
|
yuuji@0
|
212 Typically, the authorization identity is empty in this case; thus the
|
|
yuuji@0
|
213 IMAP server will derive the authorization identity from the
|
|
yuuji@0
|
214 authentication identity. If the IMAP URL uses the "submit+" access
|
|
yuuji@0
|
215 identifier prefix, the submit server MUST refuse the BURL command
|
|
yuuji@0
|
216 unless the userid in the URL's <access> token matches the submit
|
|
yuuji@0
|
217 client's authorization identity.
|
|
yuuji@0
|
218
|
|
yuuji@0
|
219 When the submit server resolves a regular IMAP URL, it uses the
|
|
yuuji@0
|
220 submit client's authorization identity when authenticating to the
|
|
yuuji@0
|
221 IMAP server. If both the submit client and the submit server's
|
|
yuuji@0
|
222 embedded IMAP client use SASL PLAIN (or the equivalent), the submit
|
|
yuuji@0
|
223
|
|
yuuji@0
|
224
|
|
yuuji@0
|
225
|
|
yuuji@0
|
226 Newman Standards Track [Page 4]
|
|
yuuji@0
|
227
|
|
yuuji@0
|
228 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 server SHOULD forward the client's credentials if and only if the
|
|
yuuji@0
|
232 submit server knows that the IMAP server is in the same
|
|
yuuji@0
|
233 administrative domain. If the submit server supports SASL mechanisms
|
|
yuuji@0
|
234 other than PLAIN, it MUST implement a configuration in which the
|
|
yuuji@0
|
235 submit server's embedded IMAP client uses STARTTLS and SASL PLAIN
|
|
yuuji@0
|
236 with the submit server's authentication identity and password (for
|
|
yuuji@0
|
237 the respective IMAP server) and the submit client's authorization
|
|
yuuji@0
|
238 identity.
|
|
yuuji@0
|
239
|
|
yuuji@0
|
240 3.4. Examples
|
|
yuuji@0
|
241
|
|
yuuji@0
|
242 In examples, "C:" and "S:" indicate lines sent by the client and
|
|
yuuji@0
|
243 server, respectively. If a single "C:" or "S:" label applies to
|
|
yuuji@0
|
244 multiple lines, then the line breaks between those lines are for
|
|
yuuji@0
|
245 editorial clarity only and are not part of the actual protocol
|
|
yuuji@0
|
246 exchange.
|
|
yuuji@0
|
247
|
|
yuuji@0
|
248 Two successful submissions (without and with pipelining) follow:
|
|
yuuji@0
|
249
|
|
yuuji@0
|
250 <SSL/TLS encryption layer negotiated>
|
|
yuuji@0
|
251 C: EHLO potter.example.com
|
|
yuuji@0
|
252 S: 250-owlry.example.com
|
|
yuuji@0
|
253 S: 250-8BITMIME
|
|
yuuji@0
|
254 S: 250-BURL imap
|
|
yuuji@0
|
255 S: 250-AUTH PLAIN
|
|
yuuji@0
|
256 S: 250-DSN
|
|
yuuji@0
|
257 S: 250 ENHANCEDSTATUSCODES
|
|
yuuji@0
|
258 C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
|
|
yuuji@0
|
259 S: 235 2.7.0 PLAIN authentication successful.
|
|
yuuji@0
|
260 C: MAIL FROM:<harry@gryffindor.example.com>
|
|
yuuji@0
|
261 S: 250 2.5.0 Address Ok.
|
|
yuuji@0
|
262 C: RCPT TO:<ron@gryffindor.example.com>
|
|
yuuji@0
|
263 S: 250 2.1.5 ron@gryffindor.example.com OK.
|
|
yuuji@0
|
264 C: BURL imap://harry@gryffindor.example.com/outbox
|
|
yuuji@0
|
265 ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
|
|
yuuji@0
|
266 :internal:91354a473744909de610943775f92038 LAST
|
|
yuuji@0
|
267 S: 250 2.5.0 Ok.
|
|
yuuji@0
|
268
|
|
yuuji@0
|
269 <SSL/TLS encryption layer negotiated>
|
|
yuuji@0
|
270 C: EHLO potter.example.com
|
|
yuuji@0
|
271 S: 250-owlry.example.com
|
|
yuuji@0
|
272 S: 250-8BITMIME
|
|
yuuji@0
|
273 S: 250-PIPELINING
|
|
yuuji@0
|
274 S: 250-BURL imap
|
|
yuuji@0
|
275 S: 250-AUTH PLAIN
|
|
yuuji@0
|
276 S: 250-DSN
|
|
yuuji@0
|
277 S: 250 ENHANCEDSTATUSCODES
|
|
yuuji@0
|
278 C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
|
|
yuuji@0
|
279
|
|
yuuji@0
|
280
|
|
yuuji@0
|
281
|
|
yuuji@0
|
282 Newman Standards Track [Page 5]
|
|
yuuji@0
|
283
|
|
yuuji@0
|
284 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
285
|
|
yuuji@0
|
286
|
|
yuuji@0
|
287 C: MAIL FROM:<harry@gryffindor.example.com>
|
|
yuuji@0
|
288 C: RCPT TO:<ron@gryffindor.example.com>
|
|
yuuji@0
|
289 C: BURL imap://harry@gryffindor.example.com/outbox
|
|
yuuji@0
|
290 ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
|
|
yuuji@0
|
291 :internal:91354a473744909de610943775f92038 LAST
|
|
yuuji@0
|
292 S: 235 2.7.0 PLAIN authentication successful.
|
|
yuuji@0
|
293 S: 250 2.5.0 Address Ok.
|
|
yuuji@0
|
294 S: 250 2.1.5 ron@gryffindor.example.com OK.
|
|
yuuji@0
|
295 S: 250 2.5.0 Ok.
|
|
yuuji@0
|
296
|
|
yuuji@0
|
297 Note that PIPELINING of the AUTH command is only permitted if the
|
|
yuuji@0
|
298 selected mechanism can be completed in one round trip, a client
|
|
yuuji@0
|
299 initial response is provided, and no SASL security layer is
|
|
yuuji@0
|
300 negotiated. This is possible for PLAIN and EXTERNAL, but not for
|
|
yuuji@0
|
301 most other SASL mechanisms.
|
|
yuuji@0
|
302
|
|
yuuji@0
|
303 Some examples of failure cases:
|
|
yuuji@0
|
304
|
|
yuuji@0
|
305 C: MAIL FROM:<harry@gryffindor.example.com>
|
|
yuuji@0
|
306 C: RCPT TO:<malfoy@slitherin.example.com>
|
|
yuuji@0
|
307 C: BURL imap://harry@gryffindor.example.com/outbox
|
|
yuuji@0
|
308 ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
|
|
yuuji@0
|
309 :internal:91354a473744909de610943775f92038 LAST
|
|
yuuji@0
|
310 S: 250 2.5.0 Address Ok.
|
|
yuuji@0
|
311 S: 550 5.7.1 Relaying not allowed: malfoy@slitherin.example.com
|
|
yuuji@0
|
312 S: 554 5.5.0 No recipients have been specified.
|
|
yuuji@0
|
313
|
|
yuuji@0
|
314 C: MAIL FROM:<harry@gryffindor.example.com>
|
|
yuuji@0
|
315 C: RCPT TO:<ron@gryffindor.example.com>
|
|
yuuji@0
|
316 C: BURL imap://harry@gryffindor.example.com/outbox
|
|
yuuji@0
|
317 ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
|
|
yuuji@0
|
318 :internal:71354a473744909de610943775f92038 LAST
|
|
yuuji@0
|
319 S: 250 2.5.0 Address Ok.
|
|
yuuji@0
|
320 S: 250 2.1.5 ron@gryffindor.example.com OK.
|
|
yuuji@0
|
321 S: 554 5.7.0 IMAP URL authorization failed
|
|
yuuji@0
|
322
|
|
yuuji@0
|
323 3.5. Formal Syntax
|
|
yuuji@0
|
324
|
|
yuuji@0
|
325 The following syntax specification inherits ABNF [RFC4234] and
|
|
yuuji@0
|
326 Uniform Resource Identifiers [RFC3986].
|
|
yuuji@0
|
327
|
|
yuuji@0
|
328 burl-param = "imap" / ("imap://" authority)
|
|
yuuji@0
|
329 ; parameter to BURL EHLO keyword
|
|
yuuji@0
|
330
|
|
yuuji@0
|
331 burl-cmd = "BURL" SP absolute-URI [SP end-marker] CRLF
|
|
yuuji@0
|
332
|
|
yuuji@0
|
333 end-marker = "LAST"
|
|
yuuji@0
|
334
|
|
yuuji@0
|
335
|
|
yuuji@0
|
336
|
|
yuuji@0
|
337
|
|
yuuji@0
|
338 Newman Standards Track [Page 6]
|
|
yuuji@0
|
339
|
|
yuuji@0
|
340 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
341
|
|
yuuji@0
|
342
|
|
yuuji@0
|
343 4. 8-Bit and Binary
|
|
yuuji@0
|
344
|
|
yuuji@0
|
345 A submit server that advertises BURL MUST also advertise 8BITMIME
|
|
yuuji@0
|
346 [RFC1652] and perform the down conversion described in that
|
|
yuuji@0
|
347 specification on the resulting complete message if 8-bit data is
|
|
yuuji@0
|
348 received with the BURL command and passed to a 7-bit server. If the
|
|
yuuji@0
|
349 URL argument to BURL refers to binary data, then the submit server
|
|
yuuji@0
|
350 MAY refuse the command or down convert as described in Binary SMTP
|
|
yuuji@0
|
351 [RFC3030].
|
|
yuuji@0
|
352
|
|
yuuji@0
|
353 The Submit server MAY refuse to accept a BURL command or combination
|
|
yuuji@0
|
354 of BURL and BDAT commands that result in un-encoded 8-bit data in
|
|
yuuji@0
|
355 mail or MIME [RFC2045] headers. Alternatively, the server MAY accept
|
|
yuuji@0
|
356 such data and down convert to MIME header encoding [RFC2047].
|
|
yuuji@0
|
357
|
|
yuuji@0
|
358 5. Updates to RFC 3463
|
|
yuuji@0
|
359
|
|
yuuji@0
|
360 SMTP or Submit servers that advertise ENHANCEDSTATUSCODES [RFC2034]
|
|
yuuji@0
|
361 use enhanced status codes defined in RFC 3463 [RFC3463]. The BURL
|
|
yuuji@0
|
362 extension introduces new error cases that that RFC did not consider.
|
|
yuuji@0
|
363 The following additional enhanced status codes are defined by this
|
|
yuuji@0
|
364 specification:
|
|
yuuji@0
|
365
|
|
yuuji@0
|
366 X.6.6 Message content not available
|
|
yuuji@0
|
367
|
|
yuuji@0
|
368 The message content could not be fetched from a remote system.
|
|
yuuji@0
|
369 This may be useful as a permanent or persistent temporary
|
|
yuuji@0
|
370 notification.
|
|
yuuji@0
|
371
|
|
yuuji@0
|
372 X.7.8 Trust relationship required
|
|
yuuji@0
|
373
|
|
yuuji@0
|
374 The submission server requires a configured trust relationship
|
|
yuuji@0
|
375 with a third-party server in order to access the message content.
|
|
yuuji@0
|
376
|
|
yuuji@0
|
377 6. Response Codes
|
|
yuuji@0
|
378
|
|
yuuji@0
|
379 This section includes example response codes to the BURL command.
|
|
yuuji@0
|
380 Other text may be used with the same response codes. This list is
|
|
yuuji@0
|
381 not exhaustive, and BURL clients MUST tolerate any valid SMTP
|
|
yuuji@0
|
382 response code. Most of these examples include the appropriate
|
|
yuuji@0
|
383 enhanced status code [RFC3463].
|
|
yuuji@0
|
384
|
|
yuuji@0
|
385 554 5.5.0 No recipients have been specified
|
|
yuuji@0
|
386
|
|
yuuji@0
|
387 This response code occurs when BURL is used (for example, with
|
|
yuuji@0
|
388 PIPELINING) and all RCPT TOs failed.
|
|
yuuji@0
|
389
|
|
yuuji@0
|
390
|
|
yuuji@0
|
391
|
|
yuuji@0
|
392
|
|
yuuji@0
|
393
|
|
yuuji@0
|
394 Newman Standards Track [Page 7]
|
|
yuuji@0
|
395
|
|
yuuji@0
|
396 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
397
|
|
yuuji@0
|
398
|
|
yuuji@0
|
399 503 5.5.0 Valid RCPT TO required before BURL
|
|
yuuji@0
|
400
|
|
yuuji@0
|
401 This response code is an alternative to the previous one when BURL
|
|
yuuji@0
|
402 is used (for example, with PIPELINING) and all RCPT TOs failed.
|
|
yuuji@0
|
403
|
|
yuuji@0
|
404 554 5.6.3 Conversion required but not supported
|
|
yuuji@0
|
405
|
|
yuuji@0
|
406 This response code occurs when the URL points to binary data and
|
|
yuuji@0
|
407 the implementation does not support down conversion to base64.
|
|
yuuji@0
|
408 This can also be used if the URL points to message data with 8-bit
|
|
yuuji@0
|
409 content in headers and the server does not down convert such
|
|
yuuji@0
|
410 content.
|
|
yuuji@0
|
411
|
|
yuuji@0
|
412 554 5.3.4 Message too big for system
|
|
yuuji@0
|
413
|
|
yuuji@0
|
414 The message (subsequent to URL resolution) is larger than the
|
|
yuuji@0
|
415 per-message size limit for this server.
|
|
yuuji@0
|
416
|
|
yuuji@0
|
417 554 5.7.8 URL resolution requires trust relationship
|
|
yuuji@0
|
418
|
|
yuuji@0
|
419 The submit server does not have a trust relationship with the IMAP
|
|
yuuji@0
|
420 server specified in the URL argument to BURL.
|
|
yuuji@0
|
421
|
|
yuuji@0
|
422 552 5.2.2 Mailbox full
|
|
yuuji@0
|
423
|
|
yuuji@0
|
424 The recipient is local, the submit server supports direct
|
|
yuuji@0
|
425 delivery, and the recipient has exceeded his quota and any grace
|
|
yuuji@0
|
426 period for delivery attempts.
|
|
yuuji@0
|
427
|
|
yuuji@0
|
428 554 5.6.6 IMAP URL resolution failed
|
|
yuuji@0
|
429
|
|
yuuji@0
|
430 The IMAP URLFETCH command returned an error or no data.
|
|
yuuji@0
|
431
|
|
yuuji@0
|
432 250 2.5.0 Waiting for additional BURL or BDAT commands
|
|
yuuji@0
|
433
|
|
yuuji@0
|
434 A BURL command without the "LAST" modifier was sent. The URL for
|
|
yuuji@0
|
435 this BURL command was successfully resolved, but the content will
|
|
yuuji@0
|
436 not necessarily be committed to persistent storage until the rest
|
|
yuuji@0
|
437 of the message content is collected. For example, a Unix server
|
|
yuuji@0
|
438 may have written the content to a queue file buffer, but may not
|
|
yuuji@0
|
439 yet have performed an fsync() operation. If the server loses
|
|
yuuji@0
|
440 power, the content can still be lost.
|
|
yuuji@0
|
441
|
|
yuuji@0
|
442 451 4.4.1 IMAP server unavailable
|
|
yuuji@0
|
443
|
|
yuuji@0
|
444 The connection to the IMAP server to resolve the URL failed.
|
|
yuuji@0
|
445
|
|
yuuji@0
|
446
|
|
yuuji@0
|
447
|
|
yuuji@0
|
448
|
|
yuuji@0
|
449
|
|
yuuji@0
|
450 Newman Standards Track [Page 8]
|
|
yuuji@0
|
451
|
|
yuuji@0
|
452 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
453
|
|
yuuji@0
|
454
|
|
yuuji@0
|
455 250 2.5.0 Ok.
|
|
yuuji@0
|
456
|
|
yuuji@0
|
457 The URL was successfully resolved, and the complete message data
|
|
yuuji@0
|
458 has been committed to persistent storage.
|
|
yuuji@0
|
459
|
|
yuuji@0
|
460 250 2.6.4 MIME header conversion with loss performed
|
|
yuuji@0
|
461
|
|
yuuji@0
|
462 The URL pointed to message data that included mail or MIME headers
|
|
yuuji@0
|
463 with 8-bit data. This data was converted to MIME header encoding
|
|
yuuji@0
|
464 [RFC2047], but the submit server may not have correctly guessed
|
|
yuuji@0
|
465 the unlabeled character set.
|
|
yuuji@0
|
466
|
|
yuuji@0
|
467 7. IANA Considerations
|
|
yuuji@0
|
468
|
|
yuuji@0
|
469 The "BURL" SMTP extension as described in Section 3 has been
|
|
yuuji@0
|
470 registered. This registration has been marked for use by message
|
|
yuuji@0
|
471 submission [RFC4409] only in the registry.
|
|
yuuji@0
|
472
|
|
yuuji@0
|
473 8. Security Considerations
|
|
yuuji@0
|
474
|
|
yuuji@0
|
475 Modern SMTP submission servers often include content-based security
|
|
yuuji@0
|
476 and denial-of-service defense mechanisms such as virus filtering,
|
|
yuuji@0
|
477 size limits, server-generated signatures, spam filtering, etc.
|
|
yuuji@0
|
478 Implementations of BURL should fetch the URL content prior to
|
|
yuuji@0
|
479 application of such content-based mechanisms in order to preserve
|
|
yuuji@0
|
480 their function.
|
|
yuuji@0
|
481
|
|
yuuji@0
|
482 Clients that generate unsolicited bulk email or email with viruses
|
|
yuuji@0
|
483 could use this mechanism to compensate for a slow link between the
|
|
yuuji@0
|
484 client and submit server. In particular, this mechanism would make
|
|
yuuji@0
|
485 it feasible for a programmable cell phone or other device on a slow
|
|
yuuji@0
|
486 link to become a significant source of unsolicited bulk email and/or
|
|
yuuji@0
|
487 viruses. This makes it more important for submit server vendors
|
|
yuuji@0
|
488 implementing BURL to have auditing and/or defenses against such
|
|
yuuji@0
|
489 denial-of-service attacks including mandatory authentication, logging
|
|
yuuji@0
|
490 that associates unique client identifiers with mail transactions,
|
|
yuuji@0
|
491 limits on reuse of the same IMAP URL, rate limits, recipient count
|
|
yuuji@0
|
492 limits, and content filters.
|
|
yuuji@0
|
493
|
|
yuuji@0
|
494 Transfer of the URLAUTH [RFC4467] form of IMAP URLs in the clear can
|
|
yuuji@0
|
495 expose the authorization token to network eavesdroppers.
|
|
yuuji@0
|
496 Implementations that support such URLs can address this issue by
|
|
yuuji@0
|
497 using a strong confidentiality protection mechanism. For example,
|
|
yuuji@0
|
498 the SMTP STARTTLS [RFC3207] and the IMAP STARTTLS [RFC3501]
|
|
yuuji@0
|
499 extensions, in combination with a configuration setting that requires
|
|
yuuji@0
|
500 their use with such IMAP URLs, would address this concern.
|
|
yuuji@0
|
501
|
|
yuuji@0
|
502
|
|
yuuji@0
|
503
|
|
yuuji@0
|
504
|
|
yuuji@0
|
505
|
|
yuuji@0
|
506 Newman Standards Track [Page 9]
|
|
yuuji@0
|
507
|
|
yuuji@0
|
508 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
509
|
|
yuuji@0
|
510
|
|
yuuji@0
|
511 Use of a prearranged trust relationship between a submit server and a
|
|
yuuji@0
|
512 specific IMAP server introduces security considerations. A
|
|
yuuji@0
|
513 compromise of the submit server should not automatically compromise
|
|
yuuji@0
|
514 all accounts on the IMAP server, so trust relationships involving
|
|
yuuji@0
|
515 super-user proxy credentials are strongly discouraged. A system that
|
|
yuuji@0
|
516 requires the submit server to authenticate to the IMAP server with
|
|
yuuji@0
|
517 submit credentials and subsequently requires a URLAUTH URL to fetch
|
|
yuuji@0
|
518 any content addresses this concern. A trusted third party model for
|
|
yuuji@0
|
519 proxy credentials (such as that provided by Kerberos 5 [RFC4120])
|
|
yuuji@0
|
520 would also suffice.
|
|
yuuji@0
|
521
|
|
yuuji@0
|
522 When a client uses SMTP STARTTLS to send a BURL command that
|
|
yuuji@0
|
523 references non-public information, there is a user expectation that
|
|
yuuji@0
|
524 the entire message content will be treated confidentially. To
|
|
yuuji@0
|
525 address this expectation, the message submission server SHOULD use
|
|
yuuji@0
|
526 STARTTLS or a mechanism providing equivalent data confidentiality
|
|
yuuji@0
|
527 when fetching the content referenced by that URL.
|
|
yuuji@0
|
528
|
|
yuuji@0
|
529 A legitimate user of a submit server may try to compromise other
|
|
yuuji@0
|
530 accounts on the server by providing an IMAP URLAUTH URL that points
|
|
yuuji@0
|
531 to a server under that user's control that is designed to undermine
|
|
yuuji@0
|
532 the security of the submit server. For this reason, the IMAP client
|
|
yuuji@0
|
533 code that the submit server uses must be robust with respect to
|
|
yuuji@0
|
534 arbitrary input sizes (including large IMAP literals) and arbitrary
|
|
yuuji@0
|
535 delays from the IMAP server. Requiring a prearranged trust
|
|
yuuji@0
|
536 relationship between a submit server and the IMAP server also
|
|
yuuji@0
|
537 addresses this concern.
|
|
yuuji@0
|
538
|
|
yuuji@0
|
539 An authorized user of the submit server could set up a fraudulent
|
|
yuuji@0
|
540 IMAP server and pass a URL for that server to the submit server. The
|
|
yuuji@0
|
541 submit server might then contact the fraudulent IMAP server to
|
|
yuuji@0
|
542 authenticate with submit credentials and fetch content. There are
|
|
yuuji@0
|
543 several ways to mitigate this potential attack. A submit server that
|
|
yuuji@0
|
544 only uses submit credentials with a fixed set of trusted IMAP servers
|
|
yuuji@0
|
545 will not be vulnerable to exposure of those credentials. A submit
|
|
yuuji@0
|
546 server can treat the IMAP server as untrusted and include defenses
|
|
yuuji@0
|
547 for buffer overflows, denial-of-service slowdowns, and other
|
|
yuuji@0
|
548 potential attacks. Finally, because authentication is required to
|
|
yuuji@0
|
549 use BURL, it is possible to keep a secure audit trail and use that to
|
|
yuuji@0
|
550 detect and punish the offending party.
|
|
yuuji@0
|
551
|
|
yuuji@0
|
552
|
|
yuuji@0
|
553
|
|
yuuji@0
|
554
|
|
yuuji@0
|
555
|
|
yuuji@0
|
556
|
|
yuuji@0
|
557
|
|
yuuji@0
|
558
|
|
yuuji@0
|
559
|
|
yuuji@0
|
560
|
|
yuuji@0
|
561
|
|
yuuji@0
|
562 Newman Standards Track [Page 10]
|
|
yuuji@0
|
563
|
|
yuuji@0
|
564 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
565
|
|
yuuji@0
|
566
|
|
yuuji@0
|
567 9. References
|
|
yuuji@0
|
568
|
|
yuuji@0
|
569 9.1. Normative References
|
|
yuuji@0
|
570
|
|
yuuji@0
|
571 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
|
|
yuuji@0
|
572 Crocker, "SMTP Service Extension for
|
|
yuuji@0
|
573 8bit-MIMEtransport", RFC 1652, July 1994.
|
|
yuuji@0
|
574
|
|
yuuji@0
|
575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
yuuji@0
|
576 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
yuuji@0
|
577
|
|
yuuji@0
|
578 [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192,
|
|
yuuji@0
|
579 September 1997.
|
|
yuuji@0
|
580
|
|
yuuji@0
|
581 [RFC2554] Myers, J., "SMTP Service Extension for Authentication",
|
|
yuuji@0
|
582 RFC 2554, March 1999.
|
|
yuuji@0
|
583
|
|
yuuji@0
|
584 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
|
|
yuuji@0
|
585 April 2001.
|
|
yuuji@0
|
586
|
|
yuuji@0
|
587 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP
|
|
yuuji@0
|
588 over Transport Layer Security", RFC 3207,
|
|
yuuji@0
|
589 February 2002.
|
|
yuuji@0
|
590
|
|
yuuji@0
|
591 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
|
|
yuuji@0
|
592 VERSION 4rev1", RFC 3501, March 2003.
|
|
yuuji@0
|
593
|
|
yuuji@0
|
594 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
|
|
yuuji@0
|
595 "Uniform Resource Identifier (URI): Generic Syntax",
|
|
yuuji@0
|
596 STD 66, RFC 3986, January 2005.
|
|
yuuji@0
|
597
|
|
yuuji@0
|
598 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
|
yuuji@0
|
599 Specifications: ABNF", RFC 4234, October 2005.
|
|
yuuji@0
|
600
|
|
yuuji@0
|
601 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for
|
|
yuuji@0
|
602 Mail", RFC 4409, April 2006.
|
|
yuuji@0
|
603
|
|
yuuji@0
|
604 [RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) -
|
|
yuuji@0
|
605 URLAUTH Extension", RFC 4467, May 2006.
|
|
yuuji@0
|
606
|
|
yuuji@0
|
607
|
|
yuuji@0
|
608
|
|
yuuji@0
|
609
|
|
yuuji@0
|
610
|
|
yuuji@0
|
611
|
|
yuuji@0
|
612
|
|
yuuji@0
|
613
|
|
yuuji@0
|
614
|
|
yuuji@0
|
615
|
|
yuuji@0
|
616
|
|
yuuji@0
|
617
|
|
yuuji@0
|
618 Newman Standards Track [Page 11]
|
|
yuuji@0
|
619
|
|
yuuji@0
|
620 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
621
|
|
yuuji@0
|
622
|
|
yuuji@0
|
623 9.2. Informative References
|
|
yuuji@0
|
624
|
|
yuuji@0
|
625 [RFC2034] Freed, N., "SMTP Service Extension for Returning
|
|
yuuji@0
|
626 Enhanced Error Codes", RFC 2034, October 1996.
|
|
yuuji@0
|
627
|
|
yuuji@0
|
628 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
|
|
yuuji@0
|
629 Mail Extensions (MIME) Part One: Format of Internet
|
|
yuuji@0
|
630 Message Bodies", RFC 2045, November 1996.
|
|
yuuji@0
|
631
|
|
yuuji@0
|
632 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
|
|
yuuji@0
|
633 Extensions) Part Three: Message Header Extensions for
|
|
yuuji@0
|
634 Non-ASCII Text", RFC 2047, November 1996.
|
|
yuuji@0
|
635
|
|
yuuji@0
|
636 [RFC2920] Freed, N., "SMTP Service Extension for Command
|
|
yuuji@0
|
637 Pipelining", STD 60, RFC 2920, September 2000.
|
|
yuuji@0
|
638
|
|
yuuji@0
|
639 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for
|
|
yuuji@0
|
640 Transmission of Large and Binary MIME Messages",
|
|
yuuji@0
|
641 RFC 3030, December 2000.
|
|
yuuji@0
|
642
|
|
yuuji@0
|
643 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
|
|
yuuji@0
|
644 RFC 3463, January 2003.
|
|
yuuji@0
|
645
|
|
yuuji@0
|
646 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
|
|
yuuji@0
|
647 Kerberos Network Authentication Service (V5)", RFC
|
|
yuuji@0
|
648 4120, July 2005.
|
|
yuuji@0
|
649
|
|
yuuji@0
|
650 [SASL-PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in
|
|
yuuji@0
|
651 Progress, March 2005.
|
|
yuuji@0
|
652
|
|
yuuji@0
|
653
|
|
yuuji@0
|
654
|
|
yuuji@0
|
655
|
|
yuuji@0
|
656
|
|
yuuji@0
|
657
|
|
yuuji@0
|
658
|
|
yuuji@0
|
659
|
|
yuuji@0
|
660
|
|
yuuji@0
|
661
|
|
yuuji@0
|
662
|
|
yuuji@0
|
663
|
|
yuuji@0
|
664
|
|
yuuji@0
|
665
|
|
yuuji@0
|
666
|
|
yuuji@0
|
667
|
|
yuuji@0
|
668
|
|
yuuji@0
|
669
|
|
yuuji@0
|
670
|
|
yuuji@0
|
671
|
|
yuuji@0
|
672
|
|
yuuji@0
|
673
|
|
yuuji@0
|
674 Newman Standards Track [Page 12]
|
|
yuuji@0
|
675
|
|
yuuji@0
|
676 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
677
|
|
yuuji@0
|
678
|
|
yuuji@0
|
679 Appendix A. Acknowledgements
|
|
yuuji@0
|
680
|
|
yuuji@0
|
681 This document is a product of the lemonade WG. Many thanks are due
|
|
yuuji@0
|
682 to all the participants of that working group for their input. Mark
|
|
yuuji@0
|
683 Crispin was instrumental in the conception of this mechanism. Thanks
|
|
yuuji@0
|
684 to Randall Gellens, Alexey Melnikov, Sam Hartman, Ned Freed, Dave
|
|
yuuji@0
|
685 Cridland, Peter Coates, and Mark Crispin for review comments on the
|
|
yuuji@0
|
686 document. Thanks to the RFC Editor for correcting the author's
|
|
yuuji@0
|
687 grammar mistakes. Thanks to Ted Hardie, Randall Gellens, Mark
|
|
yuuji@0
|
688 Crispin, Pete Resnick, and Greg Vaudreuil for extremely interesting
|
|
yuuji@0
|
689 debates comparing this proposal and alternatives. Thanks to the
|
|
yuuji@0
|
690 lemonade WG chairs Eric Burger and Glenn Parsons for concluding the
|
|
yuuji@0
|
691 debate at the correct time and making sure this document got
|
|
yuuji@0
|
692 completed.
|
|
yuuji@0
|
693
|
|
yuuji@0
|
694 Author's Address
|
|
yuuji@0
|
695
|
|
yuuji@0
|
696 Chris Newman
|
|
yuuji@0
|
697 Sun Microsystems
|
|
yuuji@0
|
698 3401 Centrelake Dr., Suite 410
|
|
yuuji@0
|
699 Ontario, CA 91761
|
|
yuuji@0
|
700 US
|
|
yuuji@0
|
701
|
|
yuuji@0
|
702 EMail: chris.newman@sun.com
|
|
yuuji@0
|
703
|
|
yuuji@0
|
704
|
|
yuuji@0
|
705
|
|
yuuji@0
|
706
|
|
yuuji@0
|
707
|
|
yuuji@0
|
708
|
|
yuuji@0
|
709
|
|
yuuji@0
|
710
|
|
yuuji@0
|
711
|
|
yuuji@0
|
712
|
|
yuuji@0
|
713
|
|
yuuji@0
|
714
|
|
yuuji@0
|
715
|
|
yuuji@0
|
716
|
|
yuuji@0
|
717
|
|
yuuji@0
|
718
|
|
yuuji@0
|
719
|
|
yuuji@0
|
720
|
|
yuuji@0
|
721
|
|
yuuji@0
|
722
|
|
yuuji@0
|
723
|
|
yuuji@0
|
724
|
|
yuuji@0
|
725
|
|
yuuji@0
|
726
|
|
yuuji@0
|
727
|
|
yuuji@0
|
728
|
|
yuuji@0
|
729
|
|
yuuji@0
|
730 Newman Standards Track [Page 13]
|
|
yuuji@0
|
731
|
|
yuuji@0
|
732 RFC 4468 Message Submission BURL Extension May 2006
|
|
yuuji@0
|
733
|
|
yuuji@0
|
734
|
|
yuuji@0
|
735 Full Copyright Statement
|
|
yuuji@0
|
736
|
|
yuuji@0
|
737 Copyright (C) The Internet Society (2006).
|
|
yuuji@0
|
738
|
|
yuuji@0
|
739 This document is subject to the rights, licenses and restrictions
|
|
yuuji@0
|
740 contained in BCP 78, and except as set forth therein, the authors
|
|
yuuji@0
|
741 retain all their rights.
|
|
yuuji@0
|
742
|
|
yuuji@0
|
743 This document and the information contained herein are provided on an
|
|
yuuji@0
|
744 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
yuuji@0
|
745 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|
yuuji@0
|
746 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|
yuuji@0
|
747 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|
yuuji@0
|
748 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
yuuji@0
|
749 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
yuuji@0
|
750
|
|
yuuji@0
|
751 Intellectual Property
|
|
yuuji@0
|
752
|
|
yuuji@0
|
753 The IETF takes no position regarding the validity or scope of any
|
|
yuuji@0
|
754 Intellectual Property Rights or other rights that might be claimed to
|
|
yuuji@0
|
755 pertain to the implementation or use of the technology described in
|
|
yuuji@0
|
756 this document or the extent to which any license under such rights
|
|
yuuji@0
|
757 might or might not be available; nor does it represent that it has
|
|
yuuji@0
|
758 made any independent effort to identify any such rights. Information
|
|
yuuji@0
|
759 on the procedures with respect to rights in RFC documents can be
|
|
yuuji@0
|
760 found in BCP 78 and BCP 79.
|
|
yuuji@0
|
761
|
|
yuuji@0
|
762 Copies of IPR disclosures made to the IETF Secretariat and any
|
|
yuuji@0
|
763 assurances of licenses to be made available, or the result of an
|
|
yuuji@0
|
764 attempt made to obtain a general license or permission for the use of
|
|
yuuji@0
|
765 such proprietary rights by implementers or users of this
|
|
yuuji@0
|
766 specification can be obtained from the IETF on-line IPR repository at
|
|
yuuji@0
|
767 http://www.ietf.org/ipr.
|
|
yuuji@0
|
768
|
|
yuuji@0
|
769 The IETF invites any interested party to bring to its attention any
|
|
yuuji@0
|
770 copyrights, patents or patent applications, or other proprietary
|
|
yuuji@0
|
771 rights that may cover technology that may be required to implement
|
|
yuuji@0
|
772 this standard. Please address the information to the IETF at
|
|
yuuji@0
|
773 ietf-ipr@ietf.org.
|
|
yuuji@0
|
774
|
|
yuuji@0
|
775 Acknowledgement
|
|
yuuji@0
|
776
|
|
yuuji@0
|
777 Funding for the RFC Editor function is provided by the IETF
|
|
yuuji@0
|
778 Administrative Support Activity (IASA).
|
|
yuuji@0
|
779
|
|
yuuji@0
|
780
|
|
yuuji@0
|
781
|
|
yuuji@0
|
782
|
|
yuuji@0
|
783
|
|
yuuji@0
|
784
|
|
yuuji@0
|
785
|
|
yuuji@0
|
786 Newman Standards Track [Page 14]
|
|
yuuji@0
|
787
|
