1
2
3
4
5
6
7Network Working Group G. White
8Request for Comments: 4865 Independent
9Updates: 3463, 3464 G. Vaudreuil
10Category: Standards Track Alcatel-Lucent
11 May 2007
12
13
14 SMTP Submission Service Extension for Future Message Release
15
16Status of This Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24Copyright Notice
25
26 Copyright (C) The IETF Trust (2007).
27
28Abstract
29
30 This memo defines an extension to the SMTP submission protocol for a
31 client to indicate a future time for the message to be released for
32 delivery. This extension permits a client to use server-based
33 storage for a message that should be held in queue until an appointed
34 time in the future. This is useful for clients which do not have
35 local storage or are otherwise unable to release a message for
36 delivery at an appointed time.
37
381. Introduction
39
40 There is a widely used feature within the voice messaging community
41 to compose and send a message for delivery in the future. This is
42 useful for sending announcements to be heard at the beginning of a
43 work day, to send birthday greetings a day or so ahead, or to use as
44 a lightweight facility to build a personal reminder service.
45
46 This extension uses the SMTP submission protocol [n3] to allow a
47 client, when submitting a message, to indicate a future time for the
48 message to be released for delivery.
49
50
51
52
53
54
55
56
57
58White & Vaudreuil Standards Track [Page 1]
59
60RFC 4865 SMTP Future Message Release May 2007
61
62
632. Terminology
64
65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
67 document are to be interpreted as described in [n1].
68
693. Framework
70
71 The Future Message Release service extension for SMTP submission uses
72 the SMTP service extension mechanism [n4] to extend the SMTP
73 submission protocol [n3]. The following SMTP submission service
74 extension is hereby defined:
75
76 The name of the SMTP submission service extension is "Future Message
77 Release".
78
79 1) The Extended Hello (EHLO) keyword associated with this service
80 extension is "FUTURERELEASE".
81
82 2) Two required parameters, the max-future-release-interval and the
83 max-future-release-date-time, are combined with the EHLO keyword in
84 the manner specified in [n4].
85
86 The max-future-release-interval is a positive integer indicating the
87 maximum amount of time for which the message submission server (MSA)
88 will hold messages for future release.
89
90 Using ABNF [n2], the syntax of this parameter is as follows:
91
92 future-release-integer = %x31-39 *8DIGIT ../smtpserver/server.go:1461
93 ; integer in the range 1-999999999
94 ; measured in seconds
95
96 max-future-release-interval = future-release-integer
97
98 The max-future-release-date-time is a timestamp, normalized to ../smtpserver/server.go:907
99 Universal Coordinated Time (UTC), indicating the most remote date
100 and time in the future until which the MSA will hold messages for
101 future release.
102
103 Using ABNF [n2], the syntax of this parameter is as follows:
104
105 max-future-release-date-time = date-time
106
107 where the format of date-time is defined in [n10].
108
109
110
111
112
113
114White & Vaudreuil Standards Track [Page 2]
115
116RFC 4865 SMTP Future Message Release May 2007
117
118
119 3) When forming the portion of the EHLO reply containing the
120 FUTURERELEASE keyword, the keyword is followed by the max-future-
121 release-interval, and then the max-future-release-date-time. The
122 keyword and two values are delimited by spaces.
123
124 For example, the ABNF for a continuation line in the EHLO response
125 that contains the FUTURERELEASE keyword is:
126
127 line = "250-FUTURERELEASE" SP max-future-release-interval ../smtpserver/server.go:906
128 SP max-future-release-date-time
129
130 4) One required parameter, the hold-param, is added to the MAIL
131 command using either the keyword "HOLDFOR" or the keyword
132 "HOLDUNTIL".
133
134 The HOLDFOR parameter value is a future-release-interval, which is
135 a positive integer indicating the amount of time the message is to
136 be held by the MSA before release.
137
138 The HOLDUNTIL parameter value is a future-release-date-time, which
139 is a timestamp, normalized to UTC, indicating the future date and
140 time until which the message is to be held by the MSA before
141 release.
142
143 Using ABNF [n2], the syntax of this parameter is as follows:
144
145 future-release-interval = future-release-integer
146
147 future-release-date-time = Internet-style-date-time-UTC 4865-eid2040:1 ../smtpserver/parse.go:461
148
149 hold-for-param = "HOLDFOR=" future-release-interval
150
151 hold-until-param = "HOLDUNTIL=" future-release-date-time
152
153 hold-param = hold-for-param / hold-until-param
154
155 The absence of this parameter on the MAIL command does not imply a
156 default value for this parameter.
157
158 5) The maximum length of a MAIL command is increased by 34 characters
159 by the possible addition of the hold-param.
160
161 6) No additional SMTP verbs are defined by this extension.
162
163 7) This service extension is appropriate only for the SMTP submission ../smtpserver/server.go:1449
164 protocol [n3]. This service extension is not appropriate for
165 standard SMTP [n4].
166
167
168
169
170White & Vaudreuil Standards Track [Page 3]
171
172RFC 4865 SMTP Future Message Release May 2007
173
174
1754. Behavior
176
177 It is unfortunate to define two seemingly identical ways to indicate
178 a future message release time. When the client has both accurate
179 time and accurate time zone information, either interval or date-time
180 can be trivially calculated from the other. However, in the current
181 world of clients, there are clients with accurate local time but no
182 indication of their time zone, and clients without a suitably
183 accurate clock. Based on the limited facilities available to these
184 time-challenged clients, it is likely that only one or the other of
185 these mechanisms will be useful.
186
187 It is believed that servers will have accurate time, and can
188 trivially convert between these mechanisms. It is also accepted that
189 the protocol and implementation overhead of offering these two
190 mechanisms is low, and that few interoperability challenges are
191 anticipated.
192
1934.1. SMTP Client
194
195 1) An SMTP client preparing to use Future Message Release MUST first
196 verify that the MSA supports this extension.
197
198 2) An SMTP client using Future Message Release MUST include one, and
199 only one, hold-param with the MAIL command.
200
201 3) An SMTP client using Future Message Release with the "for" option
202 of the hold-param MUST ensure that the future-release-interval is
203 less than or equal to the max-future-release-interval advertised
204 by the MSA.
205
206 4) An SMTP client using Future Message Release with the "until"
207 option of the hold-param MUST ensure that the future-release-
208 date-time is earlier than or equal to the max-future-release-
209 date-time advertised by the MSA.
210
2114.2. MSA
212
213 1) An MSA supporting Future Message Release MUST comply with the SMTP
214 submission protocol as described in [n3].
215
216 2) An MSA supporting Future Message Release MUST NOT advertise this
217 support (i.e. include the FUTURERELEASE keyword in its EHLO reply)
218 on any port other than the submission port.
219
220
221
222
223
224
225
226White & Vaudreuil Standards Track [Page 4]
227
228RFC 4865 SMTP Future Message Release May 2007
229
230
231 3) An MSA supporting Future Message Release MUST include the
232 FUTURERELEASE keyword, and associated max-future-release-interval
233 and max-future-release-date-time parameters, in its reply to the
234 EHLO command.
235
236 4) An MSA supporting Future Message Release MUST accept a MAIL
237 command containing a valid hold-param, given that the MAIL command
238 contains no other errors.
239
240 5) An MSA that accepts a message with a request for Future Message
241 Release indicating the "for" option MUST NOT release the message
242 until the amount of time specified in the future-release-interval
243 elapses.
244
245 6) An MSA that accepts a message with a request for Future Message
246 Release indicating the "until" option MUST NOT release the message
247 until the date and time indicated by the future-release-date-time
248 occurs.
249
250 7) An MSA supporting Future Message Release MUST reject a MAIL ../smtpserver/server.go:1463
251 command containing the "for" option specifying a value that is
252 greater than the advertised max-future-release-interval, or
253 otherwise invalid.
254
255 8) An MSA supporting Future Message Release MUST reject a MAIL ../smtpserver/server.go:1475
256 command containing the "until" option specifying a value that is
257 later than the advertised max-future-release-date-time, or
258 otherwise invalid.
259
260 9) An MSA supporting Future Message Release MUST reject a MAIL ../smtpserver/server.go:1454
261 command containing more than one hold-param.
262
263 10) An MSA supporting Future Message Release, when rejecting a MAIL 4865:267 ../smtpserver/server.go:1458
264 command per items 7, 8, or 9, above, SHOULD supply the reply code
265 501 (syntax error in parameters or arguments [n4]) in the reply.
266
267 11) An MSA supporting Future Message Release, when rejecting a MAIL 4865:263 ../smtpserver/server.go:1458
268 command per items 7, 8, or 9, above, SHOULD supply the Enhanced
269 Mail System Status Code 5.5.4 (invalid command arguments [i1]) in
270 the reply.
271
272
273
274
275
276
277
278
279
280
281
282White & Vaudreuil Standards Track [Page 5]
283
284RFC 4865 SMTP Future Message Release May 2007
285
286
2875. Protocol Interactions
288
2895.1. Interaction with the DSN SMTP Service Extensions
290
291 The Delivery Status Notification (DSN) service extension is described
292 in [n7], and DSN message format is described in [n8].
293
2945.1.1. SMTP Client Interaction with DSN
295
296 1) An SMTP client MUST NOT request Future Message Release when
297 sending a DSN to the MSA.
298
2995.1.2. MSA Interaction with DSN
300
301 1) If an MSA generates a DSN for a message that includes a Future
302 Message Release request, the MSA MUST include an Arrival-Date
303 field in the machine-readable body part of the DSN.
304
305 2) If an MSA generates a DSN for a message that includes a Future ../queue/queue.go:180 ../smtpserver/server.go:335
306 Message Release request, the MSA MUST include a Future-Release-
307 Request field in the machine-readable body part of the DSN. The
308 value of this field is the value of the HOLD parameter contained
309 in the MAIL command of the original message.
310
311 The Future-Release-Request field is an extension to the set of DSN
312 per-message fields described in [n8]. Using ABNF [n2], the syntax
313 of this new field is as follows:
314
315 orig-hold-param-value = ("for;" future-release-interval) / ../dsn/dsn.go:54
316 ("until;" future-release-date-time)
317 ; this is the value of the HOLD param from
318 ; the MAIL command of the original message
319
320 future-release-request-field = "Future-Release-Request:" ../dsn/dsn.go:240
321 orig-hold-param-value
322
3235.2. Interaction with the DELIVERBY SMTP Service Extension
324
325 If an MSA supports the Future Message release and Deliver By service
326 extensions, it is possible for an SMTP client to make simultaneous
327 requests for future message release and deliver-by times when
328 submitting a message. A problem will occur if the future message
329 release time is farther in the future than the deliver-by time. In
330 order to honor the deliver-by request, the future message release
331 request has to be ignored. In order to honor the future message
332 release request, the deliver-by request has to be ignored. This
333 section addresses that problem. The Deliver By extension is
334 described in [n6].
335
336
337
338White & Vaudreuil Standards Track [Page 6]
339
340RFC 4865 SMTP Future Message Release May 2007
341
342
3435.2.1. SMTP Client Interaction with DELIVERBY
344
345 1) When an SMTP client wishes to use the Future Message Release and
346 Deliver By extensions with the same message, the client MUST
347 ensure that the specified deliver-by time is farther in the future
348 than the specified ("until" option) or implied ("for" option)
349 future message release time.
350
3515.2.2. MSA Interaction with DELIVERBY
352
353 1) If an MSA supports Future Message Release and Deliver By
354 extensions, and receives a message requesting the use of both
355 extensions, the MSA MUST reject the MAIL command if it determines
356 that the future message release time is farther in the future than
357 the deliver-by time.
358
359 2) When an MSA is rejecting a MAIL command per item 1, above, it
360 SHOULD supply the reply code 501 (syntax error in parameters or
361 arguments [n4]) in the reply.
362
363 3) When an MSA is rejecting a MAIL command per item 1, above, it
364 SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid
365 command arguments [i1]) in the reply.
366
3675.3. Interaction with the MDN Function
368
369 The Message Disposition Notification (MDN) function is described in
370 [n9].
371
3725.3.1. SMTP Client Interaction with MDN
373
374 1) An SMTP client MUST NOT request Future Message Release when
375 sending an MDN to the MSA.
376
3776. Security Considerations
378
379 The Future Message Release service extension presents a number of
380 security considerations:
381
382 1) Unauthorized future-release messages provide a means to overwhelm
383 the storage of an MSA. The authorization mechanisms required for
384 the base mail submission protocol [n3] are expected to provide
385 appropriate defense against such attacks.
386
387 2) Authorized future message release without a per-user quota may todo: ../smtpserver/server.go:2157
388 also provide a way to overwhelm an MSA's storage. An MSA's future
389 release message storage SHOULD be subject to a per-user quota.
390
391
392
393
394White & Vaudreuil Standards Track [Page 7]
395
396RFC 4865 SMTP Future Message Release May 2007
397
398
399 3) If an MSA is imposing a per-user quota on future-release message
400 storage, and detects that an incoming future-release message will
401 exceed the user's future-release message storage quota, the MSA
402 MUST reject the MAIL command.
403
404 4) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply
405 the reply code 552 (requested mail action aborted: exceeded
406 storage allocation [n4]) in the reply.
407
408 5) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply
409 the new Enhanced Mail System Status Code defined for this purpose.
410 This new status code updates [i1].
411
412 X.7.16 Future release per-user message quota exceeded 6710:878 todo spec: ../smtp/codes.go:135
413
414 There is insufficient per-user quota to queue the message for
415 future release. This code suggests the client can submit again
416 only after the per-user queue has drained.
417
418 X.7.17 Future release system message quota exceeded 7293:1137 todo spec: ../smtp/codes.go:136
419
420 There is insufficient system quota to queue the message for
421 future release. This code suggests the client can submit again
422 after the system queue has drained.
423
424 6) Inaccurate time on the MSA may result in premature or delayed
425 release of messages. Both HOLDUNTIL and HOLDFOR request
426 mechanisms are sensitive to inaccurate or changing clocks on the
427 MSA.
428
429 7) Some element of deception is inherent in the future message
430 release concept. The message release time is intentionally
431 delayed past the time it would otherwise be released; hence, the
432 message delivery time is delayed past the time it would otherwise
433 be delivered. This extension provides no mechanism for hiding
434 this from the message recipient. The RFC 2822 [n5] message
435 header, and specifically the Date field, remain unchanged after
436 submission. While a sending client MAY elect to place the
437 future-message-release-time as the date in the Date field, there
438 is no requirement or expectation that the Received fields and
439 other trace information be modified by the transport system to
440 further this deception.
441
442
443
444
445
446
447
448
449
450White & Vaudreuil Standards Track [Page 8]
451
452RFC 4865 SMTP Future Message Release May 2007
453
454
4557. IANA Considerations
456
457 This extension has been added to the list of SMTP Service Extensions
458 on the Mail Parameters Web page.
459
4608. Acknowledgments
461
462 Much of the credit for this document is due to the LEMONADE working
463 group. Through many revisions, the discussion resulted in
464 fundamental new understandings of this protocol and corresponding
465 refinement of the implied requirements and protocol. Special thanks
466 to those who patiently lead the WG to understand that doing both
467 interval and date-time was the pragmatically correct approach to the
468 needs of diverse clients.
469
4709. Normative References
471
472 [n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
473 Levels", BCP 14, RFC 2119, March 1997.
474
475 [n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
476 Specifications: ABNF", RFC 4234, October 2005.
477
478 [n3] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC
479 4409, April 2006.
480
481 [n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
482 2001.
483
484 [n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
485
486 [n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June
487 2000.
488
489 [n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
490 Extension for Delivery Status Notifications (DSNs)", RFC 3461,
491 January 2003.
492
493 [n8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
494 Delivery Status Notifications", RFC 3464, January 2003.
495
496 [n9] Hansen, T. and G. Vaudreuil, "Message Disposition
497 Notification", RFC 3798, May 2004.
498
499 [n10] Klyne, G. and C. Newman, "Date and Time on the Internet:
500 Timestamps", RFC 3339, July 2002
501
502
503
504
505
506White & Vaudreuil Standards Track [Page 9]
507
508RFC 4865 SMTP Future Message Release May 2007
509
510
51110. Informative References
512
513 [i1] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
514 January 2003.
515
516Authors' Addresses
517
518 Gregory A. White
519 6519 Camille Ave.
520 Dallas, TX 75252
521 USA
522 EMail: g.a.white@tx.rr.com
523
524 Gregory M. Vaudreuil
525 Alcatel-Lucent
526 9489 Bartgis Ct
527 Frederick, MD 21702
528 USA
529 EMail: GregV@ieee.org
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562White & Vaudreuil Standards Track [Page 10]
563
564RFC 4865 SMTP Future Message Release May 2007
565
566
567Full Copyright Statement
568
569 Copyright (C) The IETF Trust (2007).
570
571 This document is subject to the rights, licenses and restrictions
572 contained in BCP 78, and except as set forth therein, the authors
573 retain all their rights.
574
575 This document and the information contained herein are provided on an
576 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
577 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
578 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
579 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
580 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
582
583Intellectual Property
584
585 The IETF takes no position regarding the validity or scope of any
586 Intellectual Property Rights or other rights that might be claimed to
587 pertain to the implementation or use of the technology described in
588 this document or the extent to which any license under such rights
589 might or might not be available; nor does it represent that it has
590 made any independent effort to identify any such rights. Information
591 on the procedures with respect to rights in RFC documents can be
592 found in BCP 78 and BCP 79.
593
594 Copies of IPR disclosures made to the IETF Secretariat and any
595 assurances of licenses to be made available, or the result of an
596 attempt made to obtain a general license or permission for the use of
597 such proprietary rights by implementers or users of this
598 specification can be obtained from the IETF on-line IPR repository at
599 http://www.ietf.org/ipr.
600
601 The IETF invites any interested party to bring to its attention any
602 copyrights, patents or patent applications, or other proprietary
603 rights that may cover technology that may be required to implement
604 this standard. Please address the information to the IETF at
605 ietf-ipr@ietf.org.
606
607Acknowledgement
608
609 Funding for the RFC Editor function is currently provided by the
610 Internet Society.
611
612
613
614
615
616
617
618White & Vaudreuil Standards Track [Page 11]
619
620