Commit
Author: Kevin Schoon [me@kevinschoon.com]
Hash: 5fbd4ca060b8fa0f393829245f54c66f6b8566dd
Timestamp: Sun, 28 Jul 2024 13:38:04 +0000 (6 months ago)

+9846 -92 +/-9 browse
make message parsing work, support more commands, refactor
1diff --git a/Cargo.lock b/Cargo.lock
2index 90c9ea4..f80ce72 100644
3--- a/Cargo.lock
4+++ b/Cargo.lock
5 @@ -30,12 +30,208 @@ dependencies = [
6 ]
7
8 [[package]]
9+ name = "aho-corasick"
10+ version = "1.1.3"
11+ source = "registry+https://github.com/rust-lang/crates.io-index"
12+ checksum = "8e60d3430d3a69478ad0993f19238d2df97c507009a52b3c10addcd7f6bcb916"
13+ dependencies = [
14+ "memchr",
15+ ]
16+
17+ [[package]]
18 name = "allocator-api2"
19 version = "0.2.18"
20 source = "registry+https://github.com/rust-lang/crates.io-index"
21 checksum = "5c6cb57a04249c6480766f7f7cef5467412af1490f8d1e243141daddada3264f"
22
23 [[package]]
24+ name = "async-channel"
25+ version = "1.9.0"
26+ source = "registry+https://github.com/rust-lang/crates.io-index"
27+ checksum = "81953c529336010edd6d8e358f886d9581267795c61b19475b71314bffa46d35"
28+ dependencies = [
29+ "concurrent-queue",
30+ "event-listener 2.5.3",
31+ "futures-core",
32+ ]
33+
34+ [[package]]
35+ name = "async-channel"
36+ version = "2.3.1"
37+ source = "registry+https://github.com/rust-lang/crates.io-index"
38+ checksum = "89b47800b0be77592da0afd425cc03468052844aff33b84e33cc696f64e77b6a"
39+ dependencies = [
40+ "concurrent-queue",
41+ "event-listener-strategy",
42+ "futures-core",
43+ "pin-project-lite",
44+ ]
45+
46+ [[package]]
47+ name = "async-executor"
48+ version = "1.13.0"
49+ source = "registry+https://github.com/rust-lang/crates.io-index"
50+ checksum = "d7ebdfa2ebdab6b1760375fa7d6f382b9f486eac35fc994625a00e89280bdbb7"
51+ dependencies = [
52+ "async-task",
53+ "concurrent-queue",
54+ "fastrand 2.1.0",
55+ "futures-lite 2.3.0",
56+ "slab",
57+ ]
58+
59+ [[package]]
60+ name = "async-fs"
61+ version = "1.6.0"
62+ source = "registry+https://github.com/rust-lang/crates.io-index"
63+ checksum = "279cf904654eeebfa37ac9bb1598880884924aab82e290aa65c9e77a0e142e06"
64+ dependencies = [
65+ "async-lock 2.8.0",
66+ "autocfg",
67+ "blocking",
68+ "futures-lite 1.13.0",
69+ ]
70+
71+ [[package]]
72+ name = "async-io"
73+ version = "1.13.0"
74+ source = "registry+https://github.com/rust-lang/crates.io-index"
75+ checksum = "0fc5b45d93ef0529756f812ca52e44c221b35341892d3dcc34132ac02f3dd2af"
76+ dependencies = [
77+ "async-lock 2.8.0",
78+ "autocfg",
79+ "cfg-if",
80+ "concurrent-queue",
81+ "futures-lite 1.13.0",
82+ "log",
83+ "parking",
84+ "polling 2.8.0",
85+ "rustix 0.37.27",
86+ "slab",
87+ "socket2 0.4.10",
88+ "waker-fn",
89+ ]
90+
91+ [[package]]
92+ name = "async-io"
93+ version = "2.3.3"
94+ source = "registry+https://github.com/rust-lang/crates.io-index"
95+ checksum = "0d6baa8f0178795da0e71bc42c9e5d13261aac7ee549853162e66a241ba17964"
96+ dependencies = [
97+ "async-lock 3.4.0",
98+ "cfg-if",
99+ "concurrent-queue",
100+ "futures-io",
101+ "futures-lite 2.3.0",
102+ "parking",
103+ "polling 3.7.2",
104+ "rustix 0.38.34",
105+ "slab",
106+ "tracing",
107+ "windows-sys 0.52.0",
108+ ]
109+
110+ [[package]]
111+ name = "async-lock"
112+ version = "2.8.0"
113+ source = "registry+https://github.com/rust-lang/crates.io-index"
114+ checksum = "287272293e9d8c41773cec55e365490fe034813a2f172f502d6ddcf75b2f582b"
115+ dependencies = [
116+ "event-listener 2.5.3",
117+ ]
118+
119+ [[package]]
120+ name = "async-lock"
121+ version = "3.4.0"
122+ source = "registry+https://github.com/rust-lang/crates.io-index"
123+ checksum = "ff6e472cdea888a4bd64f342f09b3f50e1886d32afe8df3d663c01140b811b18"
124+ dependencies = [
125+ "event-listener 5.3.1",
126+ "event-listener-strategy",
127+ "pin-project-lite",
128+ ]
129+
130+ [[package]]
131+ name = "async-net"
132+ version = "1.8.0"
133+ source = "registry+https://github.com/rust-lang/crates.io-index"
134+ checksum = "0434b1ed18ce1cf5769b8ac540e33f01fa9471058b5e89da9e06f3c882a8c12f"
135+ dependencies = [
136+ "async-io 1.13.0",
137+ "blocking",
138+ "futures-lite 1.13.0",
139+ ]
140+
141+ [[package]]
142+ name = "async-process"
143+ version = "1.8.1"
144+ source = "registry+https://github.com/rust-lang/crates.io-index"
145+ checksum = "ea6438ba0a08d81529c69b36700fa2f95837bfe3e776ab39cde9c14d9149da88"
146+ dependencies = [
147+ "async-io 1.13.0",
148+ "async-lock 2.8.0",
149+ "async-signal",
150+ "blocking",
151+ "cfg-if",
152+ "event-listener 3.1.0",
153+ "futures-lite 1.13.0",
154+ "rustix 0.38.34",
155+ "windows-sys 0.48.0",
156+ ]
157+
158+ [[package]]
159+ name = "async-signal"
160+ version = "0.2.9"
161+ source = "registry+https://github.com/rust-lang/crates.io-index"
162+ checksum = "dfb3634b73397aa844481f814fad23bbf07fdb0eabec10f2eb95e58944b1ec32"
163+ dependencies = [
164+ "async-io 2.3.3",
165+ "async-lock 3.4.0",
166+ "atomic-waker",
167+ "cfg-if",
168+ "futures-core",
169+ "futures-io",
170+ "rustix 0.38.34",
171+ "signal-hook-registry",
172+ "slab",
173+ "windows-sys 0.52.0",
174+ ]
175+
176+ [[package]]
177+ name = "async-stream"
178+ version = "0.3.5"
179+ source = "registry+https://github.com/rust-lang/crates.io-index"
180+ checksum = "cd56dd203fef61ac097dd65721a419ddccb106b2d2b70ba60a6b529f03961a51"
181+ dependencies = [
182+ "async-stream-impl",
183+ "futures-core",
184+ "pin-project-lite",
185+ ]
186+
187+ [[package]]
188+ name = "async-stream-impl"
189+ version = "0.3.5"
190+ source = "registry+https://github.com/rust-lang/crates.io-index"
191+ checksum = "16e62a023e7c117e27523144c5d2459f4397fcc3cab0085af8e2224f643a0193"
192+ dependencies = [
193+ "proc-macro2",
194+ "quote",
195+ "syn",
196+ ]
197+
198+ [[package]]
199+ name = "async-task"
200+ version = "4.7.1"
201+ source = "registry+https://github.com/rust-lang/crates.io-index"
202+ checksum = "8b75356056920673b02621b35afd0f7dda9306d03c79a30f5c56c44cf256e3de"
203+
204+ [[package]]
205+ name = "atomic-waker"
206+ version = "1.1.2"
207+ source = "registry+https://github.com/rust-lang/crates.io-index"
208+ checksum = "1505bd5d3d116872e7271a6d4e16d81d0c8570876c8de68093a09ac269d8aac0"
209+
210+ [[package]]
211 name = "autocfg"
212 version = "1.3.0"
213 source = "registry+https://github.com/rust-lang/crates.io-index"
214 @@ -57,10 +253,38 @@ dependencies = [
215 ]
216
217 [[package]]
218+ name = "base64"
219+ version = "0.13.1"
220+ source = "registry+https://github.com/rust-lang/crates.io-index"
221+ checksum = "9e1b586273c5702936fe7b7d6896644d8be71e6314cfe09d3167c95f712589e8"
222+
223+ [[package]]
224+ name = "bitflags"
225+ version = "1.3.2"
226+ source = "registry+https://github.com/rust-lang/crates.io-index"
227+ checksum = "bef38d45163c2f1dde094a7dfd33ccf595c92905c8f8f4fdc18d06fb1037718a"
228+
229+ [[package]]
230 name = "bitflags"
231 version = "2.6.0"
232 source = "registry+https://github.com/rust-lang/crates.io-index"
233 checksum = "b048fb63fd8b5923fc5aa7b340d8e156aec7ec02f0c78fa8a6ddc2613f6f71de"
234+ dependencies = [
235+ "serde",
236+ ]
237+
238+ [[package]]
239+ name = "blocking"
240+ version = "1.6.1"
241+ source = "registry+https://github.com/rust-lang/crates.io-index"
242+ checksum = "703f41c54fc768e63e091340b424302bb1c29ef4aa0c7f10fe849dfb114d29ea"
243+ dependencies = [
244+ "async-channel 2.3.1",
245+ "async-task",
246+ "futures-io",
247+ "futures-lite 2.3.0",
248+ "piper",
249+ ]
250
251 [[package]]
252 name = "bytes"
253 @@ -81,6 +305,222 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
254 checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
255
256 [[package]]
257+ name = "concurrent-queue"
258+ version = "2.5.0"
259+ source = "registry+https://github.com/rust-lang/crates.io-index"
260+ checksum = "4ca0197aee26d1ae37445ee532fefce43251d24cc7c166799f4d46817f1d3973"
261+ dependencies = [
262+ "crossbeam-utils",
263+ ]
264+
265+ [[package]]
266+ name = "core-foundation"
267+ version = "0.9.4"
268+ source = "registry+https://github.com/rust-lang/crates.io-index"
269+ checksum = "91e195e091a93c46f7102ec7818a2aa394e1e1771c3ab4825963fa03e45afb8f"
270+ dependencies = [
271+ "core-foundation-sys",
272+ "libc",
273+ ]
274+
275+ [[package]]
276+ name = "core-foundation-sys"
277+ version = "0.8.6"
278+ source = "registry+https://github.com/rust-lang/crates.io-index"
279+ checksum = "06ea2b9bc92be3c2baa9334a323ebca2d6f074ff852cd1d7b11064035cd3868f"
280+
281+ [[package]]
282+ name = "crc32fast"
283+ version = "1.4.2"
284+ source = "registry+https://github.com/rust-lang/crates.io-index"
285+ checksum = "a97769d94ddab943e4510d138150169a2758b5ef3eb191a9ee688de3e23ef7b3"
286+ dependencies = [
287+ "cfg-if",
288+ ]
289+
290+ [[package]]
291+ name = "crossbeam-utils"
292+ version = "0.8.20"
293+ source = "registry+https://github.com/rust-lang/crates.io-index"
294+ checksum = "22ec99545bb0ed0ea7bb9b8e1e9122ea386ff8a48c0922e43f36d45ab09e0e80"
295+
296+ [[package]]
297+ name = "data-encoding"
298+ version = "2.6.0"
299+ source = "registry+https://github.com/rust-lang/crates.io-index"
300+ checksum = "e8566979429cf69b49a5c740c60791108e86440e8be149bbea4fe54d2c32d6e2"
301+
302+ [[package]]
303+ name = "encoding"
304+ version = "0.2.33"
305+ source = "registry+https://github.com/rust-lang/crates.io-index"
306+ checksum = "6b0d943856b990d12d3b55b359144ff341533e516d94098b1d3fc1ac666d36ec"
307+ dependencies = [
308+ "encoding-index-japanese",
309+ "encoding-index-korean",
310+ "encoding-index-simpchinese",
311+ "encoding-index-singlebyte",
312+ "encoding-index-tradchinese",
313+ ]
314+
315+ [[package]]
316+ name = "encoding-index-japanese"
317+ version = "1.20141219.5"
318+ source = "registry+https://github.com/rust-lang/crates.io-index"
319+ checksum = "04e8b2ff42e9a05335dbf8b5c6f7567e5591d0d916ccef4e0b1710d32a0d0c91"
320+ dependencies = [
321+ "encoding_index_tests",
322+ ]
323+
324+ [[package]]
325+ name = "encoding-index-korean"
326+ version = "1.20141219.5"
327+ source = "registry+https://github.com/rust-lang/crates.io-index"
328+ checksum = "4dc33fb8e6bcba213fe2f14275f0963fd16f0a02c878e3095ecfdf5bee529d81"
329+ dependencies = [
330+ "encoding_index_tests",
331+ ]
332+
333+ [[package]]
334+ name = "encoding-index-simpchinese"
335+ version = "1.20141219.5"
336+ source = "registry+https://github.com/rust-lang/crates.io-index"
337+ checksum = "d87a7194909b9118fc707194baa434a4e3b0fb6a5a757c73c3adb07aa25031f7"
338+ dependencies = [
339+ "encoding_index_tests",
340+ ]
341+
342+ [[package]]
343+ name = "encoding-index-singlebyte"
344+ version = "1.20141219.5"
345+ source = "registry+https://github.com/rust-lang/crates.io-index"
346+ checksum = "3351d5acffb224af9ca265f435b859c7c01537c0849754d3db3fdf2bfe2ae84a"
347+ dependencies = [
348+ "encoding_index_tests",
349+ ]
350+
351+ [[package]]
352+ name = "encoding-index-tradchinese"
353+ version = "1.20141219.5"
354+ source = "registry+https://github.com/rust-lang/crates.io-index"
355+ checksum = "fd0e20d5688ce3cab59eb3ef3a2083a5c77bf496cb798dc6fcdb75f323890c18"
356+ dependencies = [
357+ "encoding_index_tests",
358+ ]
359+
360+ [[package]]
361+ name = "encoding_index_tests"
362+ version = "0.1.4"
363+ source = "registry+https://github.com/rust-lang/crates.io-index"
364+ checksum = "a246d82be1c9d791c5dfde9a2bd045fc3cbba3fa2b11ad558f27d01712f00569"
365+
366+ [[package]]
367+ name = "encoding_rs"
368+ version = "0.8.34"
369+ source = "registry+https://github.com/rust-lang/crates.io-index"
370+ checksum = "b45de904aa0b010bce2ab45264d0631681847fa7b6f2eaa7dab7619943bc4f59"
371+ dependencies = [
372+ "cfg-if",
373+ ]
374+
375+ [[package]]
376+ name = "errno"
377+ version = "0.3.9"
378+ source = "registry+https://github.com/rust-lang/crates.io-index"
379+ checksum = "534c5cf6194dfab3db3242765c03bbe257cf92f22b38f6bc0c58d59108a820ba"
380+ dependencies = [
381+ "libc",
382+ "windows-sys 0.52.0",
383+ ]
384+
385+ [[package]]
386+ name = "event-listener"
387+ version = "2.5.3"
388+ source = "registry+https://github.com/rust-lang/crates.io-index"
389+ checksum = "0206175f82b8d6bf6652ff7d71a1e27fd2e4efde587fd368662814d6ec1d9ce0"
390+
391+ [[package]]
392+ name = "event-listener"
393+ version = "3.1.0"
394+ source = "registry+https://github.com/rust-lang/crates.io-index"
395+ checksum = "d93877bcde0eb80ca09131a08d23f0a5c18a620b01db137dba666d18cd9b30c2"
396+ dependencies = [
397+ "concurrent-queue",
398+ "parking",
399+ "pin-project-lite",
400+ ]
401+
402+ [[package]]
403+ name = "event-listener"
404+ version = "5.3.1"
405+ source = "registry+https://github.com/rust-lang/crates.io-index"
406+ checksum = "6032be9bd27023a771701cc49f9f053c751055f71efb2e0ae5c15809093675ba"
407+ dependencies = [
408+ "concurrent-queue",
409+ "parking",
410+ "pin-project-lite",
411+ ]
412+
413+ [[package]]
414+ name = "event-listener-strategy"
415+ version = "0.5.2"
416+ source = "registry+https://github.com/rust-lang/crates.io-index"
417+ checksum = "0f214dc438f977e6d4e3500aaa277f5ad94ca83fbbd9b1a15713ce2344ccc5a1"
418+ dependencies = [
419+ "event-listener 5.3.1",
420+ "pin-project-lite",
421+ ]
422+
423+ [[package]]
424+ name = "fastrand"
425+ version = "1.9.0"
426+ source = "registry+https://github.com/rust-lang/crates.io-index"
427+ checksum = "e51093e27b0797c359783294ca4f0a911c270184cb10f85783b118614a1501be"
428+ dependencies = [
429+ "instant",
430+ ]
431+
432+ [[package]]
433+ name = "fastrand"
434+ version = "2.1.0"
435+ source = "registry+https://github.com/rust-lang/crates.io-index"
436+ checksum = "9fc0510504f03c51ada170672ac806f1f105a88aa97a5281117e1ddc3368e51a"
437+
438+ [[package]]
439+ name = "flate2"
440+ version = "1.0.30"
441+ source = "registry+https://github.com/rust-lang/crates.io-index"
442+ checksum = "5f54427cfd1c7829e2a139fcefea601bf088ebca651d2bf53ebc600eac295dae"
443+ dependencies = [
444+ "crc32fast",
445+ "miniz_oxide",
446+ ]
447+
448+ [[package]]
449+ name = "foreign-types"
450+ version = "0.3.2"
451+ source = "registry+https://github.com/rust-lang/crates.io-index"
452+ checksum = "f6f339eb8adc052cd2ca78910fda869aefa38d22d5cb648e6485e4d3fc06f3b1"
453+ dependencies = [
454+ "foreign-types-shared",
455+ ]
456+
457+ [[package]]
458+ name = "foreign-types-shared"
459+ version = "0.1.1"
460+ source = "registry+https://github.com/rust-lang/crates.io-index"
461+ checksum = "00b0228411908ca8685dba7fc2cdd70ec9990a6e753e89b6ac91a84c40fbaf4b"
462+
463+ [[package]]
464+ name = "form_urlencoded"
465+ version = "1.2.1"
466+ source = "registry+https://github.com/rust-lang/crates.io-index"
467+ checksum = "e13624c2627564efccf4934284bdd98cbaa14e79b0b5a141218e507b3a823456"
468+ dependencies = [
469+ "percent-encoding",
470+ ]
471+
472+ [[package]]
473 name = "futures"
474 version = "0.3.30"
475 source = "registry+https://github.com/rust-lang/crates.io-index"
476 @@ -129,6 +569,34 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
477 checksum = "a44623e20b9681a318efdd71c299b6b222ed6f231972bfe2f224ebad6311f0c1"
478
479 [[package]]
480+ name = "futures-lite"
481+ version = "1.13.0"
482+ source = "registry+https://github.com/rust-lang/crates.io-index"
483+ checksum = "49a9d51ce47660b1e808d3c990b4709f2f415d928835a17dfd16991515c46bce"
484+ dependencies = [
485+ "fastrand 1.9.0",
486+ "futures-core",
487+ "futures-io",
488+ "memchr",
489+ "parking",
490+ "pin-project-lite",
491+ "waker-fn",
492+ ]
493+
494+ [[package]]
495+ name = "futures-lite"
496+ version = "2.3.0"
497+ source = "registry+https://github.com/rust-lang/crates.io-index"
498+ checksum = "52527eb5074e35e9339c6b4e8d12600c7128b68fb25dcb9fa9dec18f7c25f3a5"
499+ dependencies = [
500+ "fastrand 2.1.0",
501+ "futures-core",
502+ "futures-io",
503+ "parking",
504+ "pin-project-lite",
505+ ]
506+
507+ [[package]]
508 name = "futures-macro"
509 version = "0.3.30"
510 source = "registry+https://github.com/rust-lang/crates.io-index"
511 @@ -170,6 +638,17 @@ dependencies = [
512 ]
513
514 [[package]]
515+ name = "getrandom"
516+ version = "0.2.15"
517+ source = "registry+https://github.com/rust-lang/crates.io-index"
518+ checksum = "c4567c8db10ae91089c99af84c68c38da3ec2f087c3f82960bcdbf3656b6f4d7"
519+ dependencies = [
520+ "cfg-if",
521+ "libc",
522+ "wasi",
523+ ]
524+
525+ [[package]]
526 name = "gimli"
527 version = "0.29.0"
528 source = "registry+https://github.com/rust-lang/crates.io-index"
529 @@ -177,6 +656,12 @@ checksum = "40ecd4077b5ae9fd2e9e169b102c6c330d0605168eb0e8bf79952b256dbefffd"
530
531 [[package]]
532 name = "hashbrown"
533+ version = "0.12.3"
534+ source = "registry+https://github.com/rust-lang/crates.io-index"
535+ checksum = "8a9ee70c43aaf417c914396645a0fa852624801b24ebb7ae78fe8272889ac888"
536+
537+ [[package]]
538+ name = "hashbrown"
539 version = "0.14.5"
540 source = "registry+https://github.com/rust-lang/crates.io-index"
541 checksum = "e5274423e17b7c9fc20b6e7e208532f9b19825d82dfd615708b70edd83df41f1"
542 @@ -192,6 +677,59 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
543 checksum = "d231dfb89cfffdbc30e7fc41579ed6066ad03abda9e567ccafae602b97ec5024"
544
545 [[package]]
546+ name = "hermit-abi"
547+ version = "0.4.0"
548+ source = "registry+https://github.com/rust-lang/crates.io-index"
549+ checksum = "fbf6a919d6cf397374f7dfeeea91d974c7c0a7221d0d0f4f20d859d329e53fcc"
550+
551+ [[package]]
552+ name = "idna"
553+ version = "0.5.0"
554+ source = "registry+https://github.com/rust-lang/crates.io-index"
555+ checksum = "634d9b1461af396cad843f47fdba5597a4f9e6ddd4bfb6ff5d85028c25cb12f6"
556+ dependencies = [
557+ "unicode-bidi",
558+ "unicode-normalization",
559+ ]
560+
561+ [[package]]
562+ name = "indexmap"
563+ version = "1.9.3"
564+ source = "registry+https://github.com/rust-lang/crates.io-index"
565+ checksum = "bd070e393353796e801d209ad339e89596eb4c8d430d18ede6a1cced8fafbd99"
566+ dependencies = [
567+ "autocfg",
568+ "hashbrown 0.12.3",
569+ "serde",
570+ ]
571+
572+ [[package]]
573+ name = "instant"
574+ version = "0.1.13"
575+ source = "registry+https://github.com/rust-lang/crates.io-index"
576+ checksum = "e0242819d153cba4b4b05a5a8f2a7e9bbf97b6055b2a002b395c96b5ff3c0222"
577+ dependencies = [
578+ "cfg-if",
579+ ]
580+
581+ [[package]]
582+ name = "io-lifetimes"
583+ version = "1.0.11"
584+ source = "registry+https://github.com/rust-lang/crates.io-index"
585+ checksum = "eae7b9aee968036d54dce06cebaefd919e4472e753296daccd6d344e3e2df0c2"
586+ dependencies = [
587+ "hermit-abi 0.3.9",
588+ "libc",
589+ "windows-sys 0.48.0",
590+ ]
591+
592+ [[package]]
593+ name = "itoa"
594+ version = "1.0.11"
595+ source = "registry+https://github.com/rust-lang/crates.io-index"
596+ checksum = "49f1f14873335454500d59611f1cf4a4b0f786f9ac11f4312a78e4cf2566695b"
597+
598+ [[package]]
599 name = "lazy_static"
600 version = "1.5.0"
601 source = "registry+https://github.com/rust-lang/crates.io-index"
602 @@ -204,6 +742,28 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
603 checksum = "97b3888a4aecf77e811145cadf6eef5901f4782c53886191b2f693f24761847c"
604
605 [[package]]
606+ name = "libloading"
607+ version = "0.7.4"
608+ source = "registry+https://github.com/rust-lang/crates.io-index"
609+ checksum = "b67380fd3b2fbe7527a606e18729d21c6f3951633d0500574c4dc22d2d638b9f"
610+ dependencies = [
611+ "cfg-if",
612+ "winapi",
613+ ]
614+
615+ [[package]]
616+ name = "linux-raw-sys"
617+ version = "0.3.8"
618+ source = "registry+https://github.com/rust-lang/crates.io-index"
619+ checksum = "ef53942eb7bf7ff43a617b3e2c1c4a5ecf5944a7c1bc12d7ee39bbb15e5c1519"
620+
621+ [[package]]
622+ name = "linux-raw-sys"
623+ version = "0.4.14"
624+ source = "registry+https://github.com/rust-lang/crates.io-index"
625+ checksum = "78b3ae25bc7c8c38cec158d1f2757ee79e9b3740fbc7ccf0e59e4b08d793fa89"
626+
627+ [[package]]
628 name = "lock_api"
629 version = "0.4.12"
630 source = "registry+https://github.com/rust-lang/crates.io-index"
631 @@ -220,17 +780,30 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
632 checksum = "a7a70ba024b9dc04c27ea2f0c0548feb474ec5c54bba33a7f72f873a39d07b24"
633
634 [[package]]
635+ name = "mail-parser"
636+ version = "0.9.3"
637+ source = "registry+https://github.com/rust-lang/crates.io-index"
638+ checksum = "ed5a1335c3a964788c90cb42ae04a34b5f2628e89566949ce3bd4ada695c0bcd"
639+ dependencies = [
640+ "encoding_rs",
641+ "serde",
642+ ]
643+
644+ [[package]]
645 name = "maitred"
646 version = "0.1.0"
647 dependencies = [
648 "bytes",
649 "futures",
650+ "mail-parser",
651+ "melib",
652 "smtp-proto",
653 "thiserror",
654 "tokio",
655 "tokio-stream",
656 "tokio-util",
657 "tracing",
658+ "url",
659 ]
660
661 [[package]]
662 @@ -245,10 +818,60 @@ dependencies = [
663 ]
664
665 [[package]]
666- name = "memchr"
667- version = "2.7.4"
668+ name = "melib"
669+ version = "0.8.6"
670+ source = "registry+https://github.com/rust-lang/crates.io-index"
671+ checksum = "4f233699ab6a71d41529624e3d9600c8a3a208874fcf4ec4a05778314afdd2e7"
672+ dependencies = [
673+ "async-stream",
674+ "base64",
675+ "bitflags 2.6.0",
676+ "data-encoding",
677+ "encoding",
678+ "encoding_rs",
679+ "flate2",
680+ "futures",
681+ "indexmap",
682+ "libc",
683+ "libloading",
684+ "log",
685+ "native-tls",
686+ "nix",
687+ "nom",
688+ "polling 2.8.0",
689+ "regex",
690+ "serde",
691+ "serde_derive",
692+ "serde_json",
693+ "serde_path_to_error",
694+ "smallvec",
695+ "smol",
696+ "socket2 0.5.7",
697+ "unicode-segmentation",
698+ "uuid",
699+ "xdg",
700+ ]
701+
702+ [[package]]
703+ name = "memchr"
704+ version = "2.7.4"
705+ source = "registry+https://github.com/rust-lang/crates.io-index"
706+ checksum = "78ca9ab1a0babb1e7d5695e3530886289c18cf2f87ec19a575a0abdce112e3a3"
707+
708+ [[package]]
709+ name = "memoffset"
710+ version = "0.9.1"
711+ source = "registry+https://github.com/rust-lang/crates.io-index"
712+ checksum = "488016bfae457b036d996092f6cb448677611ce4449e970ceaf42695203f218a"
713+ dependencies = [
714+ "autocfg",
715+ ]
716+
717+ [[package]]
718+ name = "minimal-lexical"
719+ version = "0.2.1"
720 source = "registry+https://github.com/rust-lang/crates.io-index"
721- checksum = "78ca9ab1a0babb1e7d5695e3530886289c18cf2f87ec19a575a0abdce112e3a3"
722+ checksum = "68354c5c6bd36d73ff3feceb05efa59b6acb7626617f4962be322a825e61f79a"
723
724 [[package]]
725 name = "miniz_oxide"
726 @@ -265,10 +888,49 @@ version = "1.0.1"
727 source = "registry+https://github.com/rust-lang/crates.io-index"
728 checksum = "4569e456d394deccd22ce1c1913e6ea0e54519f577285001215d33557431afe4"
729 dependencies = [
730- "hermit-abi",
731+ "hermit-abi 0.3.9",
732 "libc",
733 "wasi",
734- "windows-sys",
735+ "windows-sys 0.52.0",
736+ ]
737+
738+ [[package]]
739+ name = "native-tls"
740+ version = "0.2.12"
741+ source = "registry+https://github.com/rust-lang/crates.io-index"
742+ checksum = "a8614eb2c83d59d1c8cc974dd3f920198647674a0a035e1af1fa58707e317466"
743+ dependencies = [
744+ "libc",
745+ "log",
746+ "openssl",
747+ "openssl-probe",
748+ "openssl-sys",
749+ "schannel",
750+ "security-framework",
751+ "security-framework-sys",
752+ "tempfile",
753+ ]
754+
755+ [[package]]
756+ name = "nix"
757+ version = "0.27.1"
758+ source = "registry+https://github.com/rust-lang/crates.io-index"
759+ checksum = "2eb04e9c688eff1c89d72b407f168cf79bb9e867a9d3323ed6c01519eb9cc053"
760+ dependencies = [
761+ "bitflags 2.6.0",
762+ "cfg-if",
763+ "libc",
764+ "memoffset",
765+ ]
766+
767+ [[package]]
768+ name = "nom"
769+ version = "7.1.3"
770+ source = "registry+https://github.com/rust-lang/crates.io-index"
771+ checksum = "d273983c5a657a70a3e8f2a01329822f3b8c8172b73826411a55751e404a0a4a"
772+ dependencies = [
773+ "memchr",
774+ "minimal-lexical",
775 ]
776
777 [[package]]
778 @@ -297,12 +959,62 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
779 checksum = "3fdb12b2476b595f9358c5161aa467c2438859caa136dec86c26fdd2efe17b92"
780
781 [[package]]
782+ name = "openssl"
783+ version = "0.10.66"
784+ source = "registry+https://github.com/rust-lang/crates.io-index"
785+ checksum = "9529f4786b70a3e8c61e11179af17ab6188ad8d0ded78c5529441ed39d4bd9c1"
786+ dependencies = [
787+ "bitflags 2.6.0",
788+ "cfg-if",
789+ "foreign-types",
790+ "libc",
791+ "once_cell",
792+ "openssl-macros",
793+ "openssl-sys",
794+ ]
795+
796+ [[package]]
797+ name = "openssl-macros"
798+ version = "0.1.1"
799+ source = "registry+https://github.com/rust-lang/crates.io-index"
800+ checksum = "a948666b637a0f465e8564c73e89d4dde00d72d4d473cc972f390fc3dcee7d9c"
801+ dependencies = [
802+ "proc-macro2",
803+ "quote",
804+ "syn",
805+ ]
806+
807+ [[package]]
808+ name = "openssl-probe"
809+ version = "0.1.5"
810+ source = "registry+https://github.com/rust-lang/crates.io-index"
811+ checksum = "ff011a302c396a5197692431fc1948019154afc178baf7d8e37367442a4601cf"
812+
813+ [[package]]
814+ name = "openssl-sys"
815+ version = "0.9.103"
816+ source = "registry+https://github.com/rust-lang/crates.io-index"
817+ checksum = "7f9e8deee91df40a943c71b917e5874b951d32a802526c85721ce3b776c929d6"
818+ dependencies = [
819+ "cc",
820+ "libc",
821+ "pkg-config",
822+ "vcpkg",
823+ ]
824+
825+ [[package]]
826 name = "overload"
827 version = "0.1.1"
828 source = "registry+https://github.com/rust-lang/crates.io-index"
829 checksum = "b15813163c1d831bf4a13c3610c05c0d03b39feb07f7e09fa234dac9b15aaf39"
830
831 [[package]]
832+ name = "parking"
833+ version = "2.2.0"
834+ source = "registry+https://github.com/rust-lang/crates.io-index"
835+ checksum = "bb813b8af86854136c6922af0598d719255ecb2179515e6e7730d468f05c9cae"
836+
837+ [[package]]
838 name = "parking_lot"
839 version = "0.12.3"
840 source = "registry+https://github.com/rust-lang/crates.io-index"
841 @@ -322,10 +1034,16 @@ dependencies = [
842 "libc",
843 "redox_syscall",
844 "smallvec",
845- "windows-targets",
846+ "windows-targets 0.52.6",
847 ]
848
849 [[package]]
850+ name = "percent-encoding"
851+ version = "2.3.1"
852+ source = "registry+https://github.com/rust-lang/crates.io-index"
853+ checksum = "e3148f5046208a5d56bcfc03053e3ca6334e51da8dfb19b6cdc8b306fae3283e"
854+
855+ [[package]]
856 name = "pin-project-lite"
857 version = "0.2.14"
858 source = "registry+https://github.com/rust-lang/crates.io-index"
859 @@ -338,6 +1056,54 @@ source = "registry+https://github.com/rust-lang/crates.io-index"
860 checksum = "8b870d8c151b6f2fb93e84a13146138f05d02ed11c7e7c54f8826aaaf7c9f184"
861
862 [[package]]
863+ name = "piper"
864+ version = "0.2.3"
865+ source = "registry+https://github.com/rust-lang/crates.io-index"
866+ checksum = "ae1d5c74c9876f070d3e8fd503d748c7d974c3e48da8f41350fa5222ef9b4391"
867+ dependencies = [
868+ "atomic-waker",
869+ "fastrand 2.1.0",
870+ "futures-io",
871+ ]
872+
873+ [[package]]
874+ name = "pkg-config"
875+ version = "0.3.30"
876+ source = "registry+https://github.com/rust-lang/crates.io-index"
877+ checksum = "d231b230927b5e4ad203db57bbcbee2802f6bce620b1e4a9024a07d94e2907ec"
878+
879+ [[package]]
880+ name = "polling"
881+ version = "2.8.0"
882+ source = "registry+https://github.com/rust-lang/crates.io-index"
883+ checksum = "4b2d323e8ca7996b3e23126511a523f7e62924d93ecd5ae73b333815b0eb3dce"
884+ dependencies = [
885+ "autocfg",
886+ "bitflags 1.3.2",
887+ "cfg-if",
888+ "concurrent-queue",
889+ "libc",
890+ "log",
891+ "pin-project-lite",
892+ "windows-sys 0.48.0",
893+ ]
894+
895+ [[package]]
896+ name = "polling"
897+ version = "3.7.2"
898+ source = "registry+https://github.com/rust-lang/crates.io-index"
899+ checksum = "a3ed00ed3fbf728b5816498ecd316d1716eecaced9c0c8d2c5a6740ca214985b"
900+ dependencies = [
901+ "cfg-if",
902+ "concurrent-queue",
903+ "hermit-abi 0.4.0",
904+ "pin-project-lite",
905+ "rustix 0.38.34",
906+ "tracing",
907+ "windows-sys 0.52.0",
908+ ]
909+
910+ [[package]]
911 name = "proc-macro2"
912 version = "1.0.86"
913 source = "registry+https://github.com/rust-lang/crates.io-index"
914 @@ -361,22 +1127,116 @@ version = "0.5.3"
915 source = "registry+https://github.com/rust-lang/crates.io-index"
916 checksum = "2a908a6e00f1fdd0dfd9c0eb08ce85126f6d8bbda50017e74bc4a4b7d4a926a4"
917 dependencies = [
918- "bitflags",
919+ "bitflags 2.6.0",
920+ ]
921+
922+ [[package]]
923+ name = "regex"
924+ version = "1.10.5"
925+ source = "registry+https://github.com/rust-lang/crates.io-index"
926+ checksum = "b91213439dad192326a0d7c6ee3955910425f441d7038e0d6933b0aec5c4517f"
927+ dependencies = [
928+ "aho-corasick",
929+ "memchr",
930+ "regex-automata",
931+ "regex-syntax",
932+ ]
933+
934+ [[package]]
935+ name = "regex-automata"
936+ version = "0.4.7"
937+ source = "registry+https://github.com/rust-lang/crates.io-index"
938+ checksum = "38caf58cc5ef2fed281f89292ef23f6365465ed9a41b7a7754eb4e26496c92df"
939+ dependencies = [
940+ "aho-corasick",
941+ "memchr",
942+ "regex-syntax",
943 ]
944
945 [[package]]
946+ name = "regex-syntax"
947+ version = "0.8.4"
948+ source = "registry+https://github.com/rust-lang/crates.io-index"
949+ checksum = "7a66a03ae7c801facd77a29370b4faec201768915ac14a721ba36f20bc9c209b"
950+
951+ [[package]]
952 name = "rustc-demangle"
953 version = "0.1.24"
954 source = "registry+https://github.com/rust-lang/crates.io-index"
955 checksum = "719b953e2095829ee67db738b3bfa9fa368c94900df327b3f07fe6e794d2fe1f"
956
957 [[package]]
958+ name = "rustix"
959+ version = "0.37.27"
960+ source = "registry+https://github.com/rust-lang/crates.io-index"
961+ checksum = "fea8ca367a3a01fe35e6943c400addf443c0f57670e6ec51196f71a4b8762dd2"
962+ dependencies = [
963+ "bitflags 1.3.2",
964+ "errno",
965+ "io-lifetimes",
966+ "libc",
967+ "linux-raw-sys 0.3.8",
968+ "windows-sys 0.48.0",
969+ ]
970+
971+ [[package]]
972+ name = "rustix"
973+ version = "0.38.34"
974+ source = "registry+https://github.com/rust-lang/crates.io-index"
975+ checksum = "70dc5ec042f7a43c4a73241207cecc9873a06d45debb38b329f8541d85c2730f"
976+ dependencies = [
977+ "bitflags 2.6.0",
978+ "errno",
979+ "libc",
980+ "linux-raw-sys 0.4.14",
981+ "windows-sys 0.52.0",
982+ ]
983+
984+ [[package]]
985+ name = "ryu"
986+ version = "1.0.18"
987+ source = "registry+https://github.com/rust-lang/crates.io-index"
988+ checksum = "f3cb5ba0dc43242ce17de99c180e96db90b235b8a9fdc9543c96d2209116bd9f"
989+
990+ [[package]]
991+ name = "schannel"
992+ version = "0.1.23"
993+ source = "registry+https://github.com/rust-lang/crates.io-index"
994+ checksum = "fbc91545643bcf3a0bbb6569265615222618bdf33ce4ffbbd13c4bbd4c093534"
995+ dependencies = [
996+ "windows-sys 0.52.0",
997+ ]
998+
999+ [[package]]
1000 name = "scopeguard"
1001 version = "1.2.0"
1002 source = "registry+https://github.com/rust-lang/crates.io-index"
1003 checksum = "94143f37725109f92c262ed2cf5e59bce7498c01bcc1502d7b9afe439a4e9f49"
1004
1005 [[package]]
1006+ name = "security-framework"
1007+ version = "2.11.1"
1008+ source = "registry+https://github.com/rust-lang/crates.io-index"
1009+ checksum = "897b2245f0b511c87893af39b033e5ca9cce68824c4d7e7630b5a1d339658d02"
1010+ dependencies = [
1011+ "bitflags 2.6.0",
1012+ "core-foundation",
1013+ "core-foundation-sys",
1014+ "libc",
1015+ "security-framework-sys",
1016+ ]
1017+
1018+ [[package]]
1019+ name = "security-framework-sys"
1020+ version = "2.11.1"
1021+ source = "registry+https://github.com/rust-lang/crates.io-index"
1022+ checksum = "75da29fe9b9b08fe9d6b22b5b4bcbc75d8db3aa31e639aa56bb62e9d46bfceaf"
1023+ dependencies = [
1024+ "core-foundation-sys",
1025+ "libc",
1026+ ]
1027+
1028+ [[package]]
1029 name = "serde"
1030 version = "1.0.204"
1031 source = "registry+https://github.com/rust-lang/crates.io-index"
1032 @@ -397,6 +1257,33 @@ dependencies = [
1033 ]
1034
1035 [[package]]
1036+ name = "serde_json"
1037+ version = "1.0.120"
1038+ source = "registry+https://github.com/rust-lang/crates.io-index"
1039+ checksum = "4e0d21c9a8cae1235ad58a00c11cb40d4b1e5c784f1ef2c537876ed6ffd8b7c5"
1040+ dependencies = [
1041+ "itoa",
1042+ "ryu",
1043+ "serde",
1044+ ]
1045+
1046+ [[package]]
1047+ name = "serde_path_to_error"
1048+ version = "0.1.16"
1049+ source = "registry+https://github.com/rust-lang/crates.io-index"
1050+ checksum = "af99884400da37c88f5e9146b7f1fd0fbcae8f6eec4e9da38b67d05486f814a6"
1051+ dependencies = [
1052+ "itoa",
1053+ "serde",
1054+ ]
1055+
1056+ [[package]]
1057+ name = "sha1_smol"
1058+ version = "1.0.1"
1059+ source = "registry+https://github.com/rust-lang/crates.io-index"
1060+ checksum = "bbfa15b3dddfee50a0fff136974b3e1bde555604ba463834a7eb7deb6417705d"
1061+
1062+ [[package]]
1063 name = "sharded-slab"
1064 version = "0.1.7"
1065 source = "registry+https://github.com/rust-lang/crates.io-index"
1066 @@ -428,6 +1315,26 @@ name = "smallvec"
1067 version = "1.13.2"
1068 source = "registry+https://github.com/rust-lang/crates.io-index"
1069 checksum = "3c5e1a9a646d36c3599cd173a41282daf47c44583ad367b8e6837255952e5c67"
1070+ dependencies = [
1071+ "serde",
1072+ ]
1073+
1074+ [[package]]
1075+ name = "smol"
1076+ version = "1.3.0"
1077+ source = "registry+https://github.com/rust-lang/crates.io-index"
1078+ checksum = "13f2b548cd8447f8de0fdf1c592929f70f4fc7039a05e47404b0d096ec6987a1"
1079+ dependencies = [
1080+ "async-channel 1.9.0",
1081+ "async-executor",
1082+ "async-fs",
1083+ "async-io 1.13.0",
1084+ "async-lock 2.8.0",
1085+ "async-net",
1086+ "async-process",
1087+ "blocking",
1088+ "futures-lite 1.13.0",
1089+ ]
1090
1091 [[package]]
1092 name = "smtp-proto"
1093 @@ -440,12 +1347,22 @@ dependencies = [
1094
1095 [[package]]
1096 name = "socket2"
1097+ version = "0.4.10"
1098+ source = "registry+https://github.com/rust-lang/crates.io-index"
1099+ checksum = "9f7916fc008ca5542385b89a3d3ce689953c143e9304a9bf8beec1de48994c0d"
1100+ dependencies = [
1101+ "libc",
1102+ "winapi",
1103+ ]
1104+
1105+ [[package]]
1106+ name = "socket2"
1107 version = "0.5.7"
1108 source = "registry+https://github.com/rust-lang/crates.io-index"
1109 checksum = "ce305eb0b4296696835b71df73eb912e0f1ffd2556a501fcede6e0c50349191c"
1110 dependencies = [
1111 "libc",
1112- "windows-sys",
1113+ "windows-sys 0.52.0",
1114 ]
1115
1116 [[package]]
1117 @@ -460,6 +1377,18 @@ dependencies = [
1118 ]
1119
1120 [[package]]
1121+ name = "tempfile"
1122+ version = "3.10.1"
1123+ source = "registry+https://github.com/rust-lang/crates.io-index"
1124+ checksum = "85b77fafb263dd9d05cbeac119526425676db3784113aa9295c88498cbf8bff1"
1125+ dependencies = [
1126+ "cfg-if",
1127+ "fastrand 2.1.0",
1128+ "rustix 0.38.34",
1129+ "windows-sys 0.52.0",
1130+ ]
1131+
1132+ [[package]]
1133 name = "thiserror"
1134 version = "1.0.63"
1135 source = "registry+https://github.com/rust-lang/crates.io-index"
1136 @@ -490,6 +1419,21 @@ dependencies = [
1137 ]
1138
1139 [[package]]
1140+ name = "tinyvec"
1141+ version = "1.8.0"
1142+ source = "registry+https://github.com/rust-lang/crates.io-index"
1143+ checksum = "445e881f4f6d382d5f27c034e25eb92edd7c784ceab92a0937db7f2e9471b938"
1144+ dependencies = [
1145+ "tinyvec_macros",
1146+ ]
1147+
1148+ [[package]]
1149+ name = "tinyvec_macros"
1150+ version = "0.1.1"
1151+ source = "registry+https://github.com/rust-lang/crates.io-index"
1152+ checksum = "1f3ccbac311fea05f86f61904b462b55fb3df8837a366dfc601a0161d0532f20"
1153+
1154+ [[package]]
1155 name = "tokio"
1156 version = "1.39.2"
1157 source = "registry+https://github.com/rust-lang/crates.io-index"
1158 @@ -502,9 +1446,9 @@ dependencies = [
1159 "parking_lot",
1160 "pin-project-lite",
1161 "signal-hook-registry",
1162- "socket2",
1163+ "socket2 0.5.7",
1164 "tokio-macros",
1165- "windows-sys",
1166+ "windows-sys 0.52.0",
1167 ]
1168
1169 [[package]]
1170 @@ -541,7 +1485,7 @@ dependencies = [
1171 "futures-io",
1172 "futures-sink",
1173 "futures-util",
1174- "hashbrown",
1175+ "hashbrown 0.14.5",
1176 "pin-project-lite",
1177 "slab",
1178 "tokio",
1179 @@ -606,24 +1550,79 @@ dependencies = [
1180 ]
1181
1182 [[package]]
1183+ name = "unicode-bidi"
1184+ version = "0.3.15"
1185+ source = "registry+https://github.com/rust-lang/crates.io-index"
1186+ checksum = "08f95100a766bf4f8f28f90d77e0a5461bbdb219042e7679bebe79004fed8d75"
1187+
1188+ [[package]]
1189 name = "unicode-ident"
1190 version = "1.0.12"
1191 source = "registry+https://github.com/rust-lang/crates.io-index"
1192 checksum = "3354b9ac3fae1ff6755cb6db53683adb661634f67557942dea4facebec0fee4b"
1193
1194 [[package]]
1195+ name = "unicode-normalization"
1196+ version = "0.1.23"
1197+ source = "registry+https://github.com/rust-lang/crates.io-index"
1198+ checksum = "a56d1686db2308d901306f92a263857ef59ea39678a5458e7cb17f01415101f5"
1199+ dependencies = [
1200+ "tinyvec",
1201+ ]
1202+
1203+ [[package]]
1204+ name = "unicode-segmentation"
1205+ version = "1.11.0"
1206+ source = "registry+https://github.com/rust-lang/crates.io-index"
1207+ checksum = "d4c87d22b6e3f4a18d4d40ef354e97c90fcb14dd91d7dc0aa9d8a1172ebf7202"
1208+
1209+ [[package]]
1210+ name = "url"
1211+ version = "2.5.2"
1212+ source = "registry+https://github.com/rust-lang/crates.io-index"
1213+ checksum = "22784dbdf76fdde8af1aeda5622b546b422b6fc585325248a2bf9f5e41e94d6c"
1214+ dependencies = [
1215+ "form_urlencoded",
1216+ "idna",
1217+ "percent-encoding",
1218+ ]
1219+
1220+ [[package]]
1221+ name = "uuid"
1222+ version = "1.10.0"
1223+ source = "registry+https://github.com/rust-lang/crates.io-index"
1224+ checksum = "81dfa00651efa65069b0b6b651f4aaa31ba9e3c3ce0137aaad053604ee7e0314"
1225+ dependencies = [
1226+ "getrandom",
1227+ "serde",
1228+ "sha1_smol",
1229+ ]
1230+
1231+ [[package]]
1232 name = "valuable"
1233 version = "0.1.0"
1234 source = "registry+https://github.com/rust-lang/crates.io-index"
1235 checksum = "830b7e5d4d90034032940e4ace0d9a9a057e7a45cd94e6c007832e39edb82f6d"
1236
1237 [[package]]
1238+ name = "vcpkg"
1239+ version = "0.2.15"
1240+ source = "registry+https://github.com/rust-lang/crates.io-index"
1241+ checksum = "accd4ea62f7bb7a82fe23066fb0957d48ef677f6eeb8215f372f52e48bb32426"
1242+
1243+ [[package]]
1244 name = "version_check"
1245 version = "0.9.5"
1246 source = "registry+https://github.com/rust-lang/crates.io-index"
1247 checksum = "0b928f33d975fc6ad9f86c8f283853ad26bdd5b10b7f1542aa2fa15e2289105a"
1248
1249 [[package]]
1250+ name = "waker-fn"
1251+ version = "1.2.0"
1252+ source = "registry+https://github.com/rust-lang/crates.io-index"
1253+ checksum = "317211a0dc0ceedd78fb2ca9a44aed3d7b9b26f81870d485c07122b4350673b7"
1254+
1255+ [[package]]
1256 name = "wasi"
1257 version = "0.11.0+wasi-snapshot-preview1"
1258 source = "registry+https://github.com/rust-lang/crates.io-index"
1259 @@ -653,11 +1652,35 @@ checksum = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f"
1260
1261 [[package]]
1262 name = "windows-sys"
1263+ version = "0.48.0"
1264+ source = "registry+https://github.com/rust-lang/crates.io-index"
1265+ checksum = "677d2418bec65e3338edb076e806bc1ec15693c5d0104683f2efe857f61056a9"
1266+ dependencies = [
1267+ "windows-targets 0.48.5",
1268+ ]
1269+
1270+ [[package]]
1271+ name = "windows-sys"
1272 version = "0.52.0"
1273 source = "registry+https://github.com/rust-lang/crates.io-index"
1274 checksum = "282be5f36a8ce781fad8c8ae18fa3f9beff57ec1b52cb3de0789201425d9a33d"
1275 dependencies = [
1276- "windows-targets",
1277+ "windows-targets 0.52.6",
1278+ ]
1279+
1280+ [[package]]
1281+ name = "windows-targets"
1282+ version = "0.48.5"
1283+ source = "registry+https://github.com/rust-lang/crates.io-index"
1284+ checksum = "9a2fa6e2155d7247be68c096456083145c183cbbbc2764150dda45a87197940c"
1285+ dependencies = [
1286+ "windows_aarch64_gnullvm 0.48.5",
1287+ "windows_aarch64_msvc 0.48.5",
1288+ "windows_i686_gnu 0.48.5",
1289+ "windows_i686_msvc 0.48.5",
1290+ "windows_x86_64_gnu 0.48.5",
1291+ "windows_x86_64_gnullvm 0.48.5",
1292+ "windows_x86_64_msvc 0.48.5",
1293 ]
1294
1295 [[package]]
1296 @@ -666,30 +1689,48 @@ version = "0.52.6"
1297 source = "registry+https://github.com/rust-lang/crates.io-index"
1298 checksum = "9b724f72796e036ab90c1021d4780d4d3d648aca59e491e6b98e725b84e99973"
1299 dependencies = [
1300- "windows_aarch64_gnullvm",
1301- "windows_aarch64_msvc",
1302- "windows_i686_gnu",
1303+ "windows_aarch64_gnullvm 0.52.6",
1304+ "windows_aarch64_msvc 0.52.6",
1305+ "windows_i686_gnu 0.52.6",
1306 "windows_i686_gnullvm",
1307- "windows_i686_msvc",
1308- "windows_x86_64_gnu",
1309- "windows_x86_64_gnullvm",
1310- "windows_x86_64_msvc",
1311+ "windows_i686_msvc 0.52.6",
1312+ "windows_x86_64_gnu 0.52.6",
1313+ "windows_x86_64_gnullvm 0.52.6",
1314+ "windows_x86_64_msvc 0.52.6",
1315 ]
1316
1317 [[package]]
1318 name = "windows_aarch64_gnullvm"
1319+ version = "0.48.5"
1320+ source = "registry+https://github.com/rust-lang/crates.io-index"
1321+ checksum = "2b38e32f0abccf9987a4e3079dfb67dcd799fb61361e53e2882c3cbaf0d905d8"
1322+
1323+ [[package]]
1324+ name = "windows_aarch64_gnullvm"
1325 version = "0.52.6"
1326 source = "registry+https://github.com/rust-lang/crates.io-index"
1327 checksum = "32a4622180e7a0ec044bb555404c800bc9fd9ec262ec147edd5989ccd0c02cd3"
1328
1329 [[package]]
1330 name = "windows_aarch64_msvc"
1331+ version = "0.48.5"
1332+ source = "registry+https://github.com/rust-lang/crates.io-index"
1333+ checksum = "dc35310971f3b2dbbf3f0690a219f40e2d9afcf64f9ab7cc1be722937c26b4bc"
1334+
1335+ [[package]]
1336+ name = "windows_aarch64_msvc"
1337 version = "0.52.6"
1338 source = "registry+https://github.com/rust-lang/crates.io-index"
1339 checksum = "09ec2a7bb152e2252b53fa7803150007879548bc709c039df7627cabbd05d469"
1340
1341 [[package]]
1342 name = "windows_i686_gnu"
1343+ version = "0.48.5"
1344+ source = "registry+https://github.com/rust-lang/crates.io-index"
1345+ checksum = "a75915e7def60c94dcef72200b9a8e58e5091744960da64ec734a6c6e9b3743e"
1346+
1347+ [[package]]
1348+ name = "windows_i686_gnu"
1349 version = "0.52.6"
1350 source = "registry+https://github.com/rust-lang/crates.io-index"
1351 checksum = "8e9b5ad5ab802e97eb8e295ac6720e509ee4c243f69d781394014ebfe8bbfa0b"
1352 @@ -702,29 +1743,59 @@ checksum = "0eee52d38c090b3caa76c563b86c3a4bd71ef1a819287c19d586d7334ae8ed66"
1353
1354 [[package]]
1355 name = "windows_i686_msvc"
1356+ version = "0.48.5"
1357+ source = "registry+https://github.com/rust-lang/crates.io-index"
1358+ checksum = "8f55c233f70c4b27f66c523580f78f1004e8b5a8b659e05a4eb49d4166cca406"
1359+
1360+ [[package]]
1361+ name = "windows_i686_msvc"
1362 version = "0.52.6"
1363 source = "registry+https://github.com/rust-lang/crates.io-index"
1364 checksum = "240948bc05c5e7c6dabba28bf89d89ffce3e303022809e73deaefe4f6ec56c66"
1365
1366 [[package]]
1367 name = "windows_x86_64_gnu"
1368+ version = "0.48.5"
1369+ source = "registry+https://github.com/rust-lang/crates.io-index"
1370+ checksum = "53d40abd2583d23e4718fddf1ebec84dbff8381c07cae67ff7768bbf19c6718e"
1371+
1372+ [[package]]
1373+ name = "windows_x86_64_gnu"
1374 version = "0.52.6"
1375 source = "registry+https://github.com/rust-lang/crates.io-index"
1376 checksum = "147a5c80aabfbf0c7d901cb5895d1de30ef2907eb21fbbab29ca94c5b08b1a78"
1377
1378 [[package]]
1379 name = "windows_x86_64_gnullvm"
1380+ version = "0.48.5"
1381+ source = "registry+https://github.com/rust-lang/crates.io-index"
1382+ checksum = "0b7b52767868a23d5bab768e390dc5f5c55825b6d30b86c844ff2dc7414044cc"
1383+
1384+ [[package]]
1385+ name = "windows_x86_64_gnullvm"
1386 version = "0.52.6"
1387 source = "registry+https://github.com/rust-lang/crates.io-index"
1388 checksum = "24d5b23dc417412679681396f2b49f3de8c1473deb516bd34410872eff51ed0d"
1389
1390 [[package]]
1391 name = "windows_x86_64_msvc"
1392+ version = "0.48.5"
1393+ source = "registry+https://github.com/rust-lang/crates.io-index"
1394+ checksum = "ed94fce61571a4006852b7389a063ab983c02eb1bb37b47f8272ce92d06d9538"
1395+
1396+ [[package]]
1397+ name = "windows_x86_64_msvc"
1398 version = "0.52.6"
1399 source = "registry+https://github.com/rust-lang/crates.io-index"
1400 checksum = "589f6da84c646204747d1270a2a5661ea66ed1cced2631d546fdfb155959f9ec"
1401
1402 [[package]]
1403+ name = "xdg"
1404+ version = "2.5.2"
1405+ source = "registry+https://github.com/rust-lang/crates.io-index"
1406+ checksum = "213b7324336b53d2414b2db8537e56544d981803139155afa84f76eeebb7a546"
1407+
1408+ [[package]]
1409 name = "zerocopy"
1410 version = "0.7.35"
1411 source = "registry+https://github.com/rust-lang/crates.io-index"
1412 diff --git a/maitred/Cargo.toml b/maitred/Cargo.toml
1413index af22925..81236de 100644
1414--- a/maitred/Cargo.toml
1415+++ b/maitred/Cargo.toml
1416 @@ -6,9 +6,12 @@ edition = "2021"
1417 [dependencies]
1418 bytes = "1.6.1"
1419 futures = "0.3.30"
1420+ mail-parser = { version = "0.9.3", features = ["serde", "serde_support"] }
1421+ melib = { version = "0.8.6", default-features = false, features = ["base64", "smtp"] }
1422 smtp-proto = { version = "0.1.5", features = ["serde", "serde_support"] }
1423 thiserror = "1.0.63"
1424 tokio = { version = "1.39.2", features = ["full"] }
1425 tokio-stream = { version = "0.1.15", features = ["full"] }
1426 tokio-util = { version = "0.7.11", features = ["full"] }
1427 tracing = { version = "0.1.40", features = ["log"] }
1428+ url = "2.5.2"
1429 diff --git a/maitred/src/error.rs b/maitred/src/error.rs
1430index 05d6c21..f6a2bd1 100644
1431--- a/maitred/src/error.rs
1432+++ b/maitred/src/error.rs
1433 @@ -1,4 +1,8 @@
1434- use smtp_proto::{Error as SmtpError};
1435+ use std::string::FromUtf8Error;
1436+
1437+ use melib::error::Error as MelibError;
1438+ use smtp_proto::Error as SmtpError;
1439+ use url::ParseError;
1440
1441 #[derive(Debug, thiserror::Error)]
1442 pub enum Error {
1443 @@ -8,4 +12,10 @@ pub enum Error {
1444 Io(#[from] std::io::Error),
1445 #[error("Smtp failure: {0}")]
1446 Smtp(#[from] SmtpError),
1447+ #[error("Melib error: {0}")]
1448+ Melib(#[from] MelibError),
1449+ #[error("Failed to parse Url: {0}")]
1450+ UrlParsing(#[from] ParseError),
1451+ #[error("Failed to read UTF8: {0}")]
1452+ Utf8(#[from] FromUtf8Error)
1453 }
1454 diff --git a/maitred/src/lib.rs b/maitred/src/lib.rs
1455index 0c51127..e11ad6a 100644
1456--- a/maitred/src/lib.rs
1457+++ b/maitred/src/lib.rs
1458 @@ -1,5 +1,6 @@
1459 mod error;
1460 mod server;
1461+ mod session;
1462 mod transport;
1463
1464 pub use error::Error;
1465 diff --git a/maitred/src/server.rs b/maitred/src/server.rs
1466index d17e807..ccc7fb6 100644
1467--- a/maitred/src/server.rs
1468+++ b/maitred/src/server.rs
1469 @@ -1,30 +1,13 @@
1470 use futures::SinkExt;
1471- use smtp_proto::{Request, Response};
1472+ use smtp_proto::Request;
1473 use tokio::net::{TcpListener, TcpStream};
1474 use tokio_stream::StreamExt;
1475 use tokio_util::codec::Framed;
1476
1477 use crate::error::Error;
1478+ use crate::session::Session;
1479 use crate::transport::Transport;
1480
1481- /// State of an active SMTP session
1482- #[derive(Default)]
1483- struct Session {
1484- // all previous commands excluding
1485- pub history: Vec<Request<String>>,
1486- // message body
1487- pub body: Vec<u8>,
1488- }
1489-
1490- impl Session {
1491- /// If the session is in data transfer mode
1492- pub fn data_transfer(self) -> bool {
1493- self.history
1494- .last()
1495- .is_some_and(|req| matches!(req, Request::Data))
1496- }
1497- }
1498-
1499 pub struct Server {
1500 addr: String,
1501 }
1502 @@ -54,60 +37,32 @@ impl Server {
1503 let transport = Transport::default();
1504 let mut framed = Framed::new(stream, transport);
1505 let mut session = Session::default();
1506- 'outer: while let Some(request) = framed.next().await {
1507- tracing::debug!("Processing SMTP request: {:?}", request);
1508+ let mut finished = false;
1509+ while let Some(request) = framed.next().await {
1510 match request {
1511- Ok(req) => {
1512- session.history.push(req.clone());
1513- match req {
1514- Request::Ehlo { host } => {
1515- framed
1516- .send(Response::new(250, 0, 0, 0, format!("Hello {}", host)))
1517- .await?;
1518- }
1519- Request::Lhlo { host } => todo!(),
1520- Request::Helo { host } => {
1521- framed
1522- .send(Response::new(250, 0, 0, 0, format!("Hello {}", host)))
1523- .await?;
1524- }
1525- Request::Mail { from } => {}
1526- Request::Rcpt { to } => {}
1527- Request::Bdat {
1528- chunk_size,
1529- is_last,
1530- } => todo!(),
1531- Request::Auth {
1532- mechanism,
1533- initial_response,
1534- } => todo!(),
1535- Request::Noop { value } => todo!(),
1536- Request::Vrfy { value } => todo!(),
1537- Request::Expn { value } => todo!(),
1538- Request::Help { value } => todo!(),
1539- Request::Etrn { name } => todo!(),
1540- Request::Atrn { domains } => todo!(),
1541- Request::Burl { uri, is_last } => todo!(),
1542- Request::StartTls => todo!(),
1543- Request::Data => {
1544- tracing::info!("Client starting transfer");
1545- // FIXME: read messages here, likely need to wrap
1546- // Request in another enum and implement in the
1547- // decoder
1548- unimplemented!("fixme")
1549+ Ok(command) => {
1550+ if matches!(command.0, Request::Quit) {
1551+ finished = true;
1552+ }
1553+
1554+ match session.process(&command.0, command.1) {
1555+ Ok(resp) => {
1556+ tracing::debug!("Returning response: {:?}", resp);
1557+ framed.send(resp).await?;
1558 }
1559- Request::Rset => todo!(),
1560- Request::Quit => {
1561- framed
1562- .send(Response::new(221, 0, 0, 0, "Ciao!".to_string()))
1563- .await?;
1564- break 'outer;
1565+ Err(err) => {
1566+ tracing::warn!("Client error: {:?}", err);
1567+ framed.send(err).await?;
1568 }
1569- }
1570+ };
1571 }
1572 Err(err) => {
1573 tracing::warn!("Socket closed with error: {:?}", err)
1574 }
1575+ };
1576+
1577+ if finished {
1578+ break;
1579 }
1580 }
1581 tracing::info!("Connection closed");
1582 @@ -119,6 +74,7 @@ impl Server {
1583 tracing::info!("Mail server listening @ {}", self.addr);
1584 loop {
1585 let (socket, _) = listener.accept().await.unwrap();
1586+ // TODO: timeout
1587 if let Err(err) = self.process(socket).await {
1588 tracing::warn!("Client encountered an error: {:?}", err);
1589 }
1590 diff --git a/maitred/src/session.rs b/maitred/src/session.rs
1591new file mode 100644
1592index 0000000..44a50be
1593--- /dev/null
1594+++ b/maitred/src/session.rs
1595 @@ -0,0 +1,116 @@
1596+ use bytes::Bytes;
1597+ use mail_parser::{Addr, Message, MessageParser};
1598+ use melib::Address;
1599+ use smtp_proto::{Request, Response};
1600+ use url::Host;
1601+
1602+ use crate::error::Error;
1603+ use crate::transport::Command;
1604+
1605+ /// State of an active SMTP session
1606+ #[derive(Default)]
1607+ pub(crate) struct Session<'a> {
1608+ /// all previous commands excluding
1609+ pub history: Vec<Request<String>>,
1610+ /// message body
1611+ pub body: Option<Message<'a>>,
1612+ /// mailto address
1613+ pub mail_to: Option<Address>,
1614+ /// rcpt address
1615+ pub rcpt_to: Option<Address>,
1616+ pub hostname: Option<Host>,
1617+ }
1618+
1619+ impl Session<'_> {
1620+ pub fn reset(&mut self) {
1621+ self.body = None;
1622+ self.mail_to = None;
1623+ self.rcpt_to = None;
1624+ self.hostname = None;
1625+ }
1626+
1627+ /// Statefully process the SMTP command with optional data payload, any
1628+ /// error returned is passed back to the caller.
1629+ /// FIXME: Not at all reasonable yet
1630+ pub fn process(
1631+ &mut self,
1632+ req: &Request<String>,
1633+ data: Option<Bytes>,
1634+ ) -> Result<Response<String>, Response<String>> {
1635+ self.history.push(req.clone());
1636+ match req {
1637+ Request::Ehlo { host } => {
1638+ self.hostname = Some(
1639+ Host::parse(host).map_err(|e| Response::new(500, 0, 0, 0, e.to_string()))?,
1640+ );
1641+ Ok(Response::new(250, 0, 0, 0, format!("Hello {}", host)))
1642+ }
1643+ Request::Lhlo { host } => {
1644+ self.hostname = Some(
1645+ Host::parse(host).map_err(|e| Response::new(500, 0, 0, 0, e.to_string()))?,
1646+ );
1647+ Ok(Response::new(250, 0, 0, 0, format!("Hello {}", host)))
1648+ }
1649+ Request::Helo { host } => {
1650+ self.hostname = Some(
1651+ Host::parse(host).map_err(|e| Response::new(500, 0, 0, 0, e.to_string()))?,
1652+ );
1653+ Ok(Response::new(250, 0, 0, 0, format!("Hello {}", host)))
1654+ }
1655+ Request::Mail { from } => {
1656+ let mail_to = Address::try_from(from.address.as_str()).map_err(|e| {
1657+ Response::new(
1658+ 500,
1659+ 0,
1660+ 0,
1661+ 0,
1662+ format!("Cannot parse: {} {}", from.address, e),
1663+ )
1664+ })?;
1665+ self.mail_to = Some(mail_to.clone());
1666+ Ok(Response::new(250, 0, 0, 0, mail_to.to_string()))
1667+ }
1668+ Request::Rcpt { to } => {
1669+ let mail_to = Address::try_from(to.address.as_str()).map_err(|e| {
1670+ Response::new(500, 0, 0, 0, format!("Cannot parse: {} {}", to.address, e))
1671+ })?;
1672+ self.mail_to = Some(mail_to.clone());
1673+ Ok(Response::new(250, 0, 0, 0, mail_to.to_string()))
1674+ }
1675+ Request::Bdat {
1676+ chunk_size: _,
1677+ is_last: _,
1678+ } => {
1679+ let message_payload = data.expect("data returned without a payload").to_vec();
1680+ let parser = MessageParser::new();
1681+ let result = parser.parse(&message_payload);
1682+ tracing::info!("Parsed message successfully: {:?}", result);
1683+ Ok(Response::new(200, 0, 0, 0, "Message processed".to_string()))
1684+ }
1685+ Request::Auth {
1686+ mechanism,
1687+ initial_response,
1688+ } => todo!(),
1689+ Request::Noop { value } => todo!(),
1690+ Request::Vrfy { value } => todo!(),
1691+ Request::Expn { value } => todo!(),
1692+ Request::Help { value } => todo!(),
1693+ Request::Etrn { name } => todo!(),
1694+ Request::Atrn { domains } => todo!(),
1695+ Request::Burl { uri, is_last } => todo!(),
1696+ Request::StartTls => todo!(),
1697+ Request::Data => {
1698+ let message_payload = data.expect("data returned without a payload").to_vec();
1699+ let parser = MessageParser::new();
1700+ let result = parser.parse(&message_payload);
1701+ tracing::info!("Parsed message successfully: {:?}", result);
1702+ Ok(Response::new(200, 0, 0, 0, "Message processed".to_string()))
1703+ }
1704+ Request::Rset => {
1705+ self.reset();
1706+ Ok(Response::new(200, 0, 0, 0, "".to_string()))
1707+ }
1708+ Request::Quit => Ok(Response::new(221, 0, 0, 0, "Ciao!".to_string())),
1709+ }
1710+ }
1711+ }
1712 diff --git a/maitred/src/transport.rs b/maitred/src/transport.rs
1713index 6001ac8..fa2dabe 100644
1714--- a/maitred/src/transport.rs
1715+++ b/maitred/src/transport.rs
1716 @@ -1,7 +1,8 @@
1717- use std::io::Write;
1718+ use std::sync::Arc;
1719+ use std::{fmt::Display, io::Write};
1720
1721- use bytes::BytesMut;
1722- use smtp_proto::request::receiver::RequestReceiver;
1723+ use bytes::{Bytes, BytesMut};
1724+ use smtp_proto::request::receiver::{BdatReceiver, DataReceiver, RequestReceiver};
1725 pub use smtp_proto::{Request, Response};
1726 use tokio_util::codec::{Decoder, Encoder};
1727
1728 @@ -18,10 +19,26 @@ impl Write for Wrapper<'_> {
1729 }
1730 }
1731
1732+ pub(crate) enum Receiver {
1733+ Data(DataReceiver),
1734+ Bdat(BdatReceiver),
1735+ }
1736+
1737+ /// Command from the client with an optional attached payload.
1738+ pub(crate) struct Command(pub Request<String>, pub Option<Bytes>);
1739+
1740+ impl Display for Command {
1741+ fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
1742+ write!(f, "{:?}", self.0)
1743+ }
1744+ }
1745+
1746 /// SMTP Transport
1747 #[derive(Default)]
1748- pub struct Transport {
1749+ pub(crate) struct Transport {
1750+ receiver: Option<Box<Receiver>>,
1751 prev: Option<Request<String>>,
1752+ buf: Vec<u8>,
1753 }
1754
1755 impl Encoder<Response<String>> for Transport {
1756 @@ -34,17 +51,79 @@ impl Encoder<Response<String>> for Transport {
1757 }
1758
1759 impl Decoder for Transport {
1760- type Item = Request<String>;
1761+ type Item = Command;
1762 type Error = crate::Error;
1763
1764 fn decode(&mut self, src: &mut BytesMut) -> Result<Option<Self::Item>, Self::Error> {
1765 if src.is_empty() {
1766 return Ok(None);
1767 }
1768+ if let Some(rec) = self.receiver.as_mut() {
1769+ let chunk_size = src.len();
1770+ tracing::debug!("Reading {} bytes of data stream", chunk_size);
1771+ match rec.as_mut() {
1772+ Receiver::Data(data_receiver) => {
1773+ let chunk = src.split_to(src.len());
1774+ if data_receiver.ingest(&mut chunk.iter(), &mut self.buf) {
1775+ tracing::debug!("Finished parsing data stream");
1776+ let payload = Bytes::copy_from_slice(&self.buf);
1777+ self.buf.clear();
1778+ self.receiver = None;
1779+ return Ok(Some(Command(
1780+ self.prev
1781+ .as_ref()
1782+ .expect("missing previous command")
1783+ .clone(),
1784+ Some(payload),
1785+ )));
1786+ } else {
1787+ return Ok(None);
1788+ }
1789+ }
1790+ Receiver::Bdat(bdat_receiver) => {
1791+ let chunk = src.split_to(src.len());
1792+ if bdat_receiver.ingest(&mut chunk.iter(), &mut self.buf) {
1793+ tracing::debug!("Finished parsing data stream");
1794+ let payload = Bytes::copy_from_slice(&self.buf);
1795+ self.buf.clear();
1796+ self.receiver = None;
1797+ return Ok(Some(Command(
1798+ self.prev
1799+ .as_ref()
1800+ .expect("missing previous command")
1801+ .clone(),
1802+ Some(payload),
1803+ )));
1804+ } else {
1805+ return Ok(None);
1806+ }
1807+ }
1808+ }
1809+ };
1810+
1811 let mut r = RequestReceiver::default();
1812 let buf = src.split_to(src.len());
1813 let request = r.ingest(&mut buf.iter(), buf.to_vec().as_slice())?;
1814 self.prev = Some(request.clone());
1815- Ok(Some(request))
1816+ match request {
1817+ Request::Bdat {
1818+ chunk_size,
1819+ is_last,
1820+ } => {
1821+ tracing::info!("Starting binary data transfer");
1822+ self.receiver = Some(Box::new(Receiver::Bdat(BdatReceiver::new(
1823+ chunk_size, is_last,
1824+ ))));
1825+ self.buf.clear();
1826+ Ok(None)
1827+ }
1828+ Request::Data => {
1829+ tracing::info!("Starting data transfer");
1830+ self.receiver = Some(Box::new(Receiver::Data(DataReceiver::new())));
1831+ self.buf.clear();
1832+ Ok(None)
1833+ }
1834+ _ => Ok(Some(Command(request, None))),
1835+ }
1836 }
1837 }
1838 diff --git a/rfcs/rfc5321.txt b/rfcs/rfc5321.txt
1839new file mode 100644
1840index 0000000..4c33ddd
1841--- /dev/null
1842+++ b/rfcs/rfc5321.txt
1843 @@ -0,0 +1,5323 @@
1844+
1845+
1846+
1847+
1848+
1849+
1850+ Network Working Group J. Klensin
1851+ Request for Comments: 5321 October 2008
1852+ Obsoletes: 2821
1853+ Updates: 1123
1854+ Category: Standards Track
1855+
1856+
1857+ Simple Mail Transfer Protocol
1858+
1859+ Status of This Memo
1860+
1861+ This document specifies an Internet standards track protocol for the
1862+ Internet community, and requests discussion and suggestions for
1863+ improvements. Please refer to the current edition of the "Internet
1864+ Official Protocol Standards" (STD 1) for the standardization state
1865+ and status of this protocol. Distribution of this memo is unlimited.
1866+
1867+ Abstract
1868+
1869+ This document is a specification of the basic protocol for Internet
1870+ electronic mail transport. It consolidates, updates, and clarifies
1871+ several previous documents, making all or parts of most of them
1872+ obsolete. It covers the SMTP extension mechanisms and best practices
1873+ for the contemporary Internet, but does not provide details about
1874+ particular extensions. Although SMTP was designed as a mail
1875+ transport and delivery protocol, this specification also contains
1876+ information that is important to its use as a "mail submission"
1877+ protocol for "split-UA" (User Agent) mail reading systems and mobile
1878+ environments.
1879+
1880+
1881+
1882+
1883+
1884+
1885+
1886+
1887+
1888+
1889+
1890+
1891+
1892+
1893+
1894+
1895+
1896+
1897+
1898+
1899+
1900+
1901+ Klensin Standards Track [Page 1]
1902+
1903+ RFC 5321 SMTP October 2008
1904+
1905+
1906+ Table of Contents
1907+
1908+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1909+ 1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5
1910+ 1.2. History and Context for This Document . . . . . . . . . . 5
1911+ 1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
1912+ 2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7
1913+ 2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7
1914+ 2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9
1915+ 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9
1916+ 2.2.2. Definition and Registration of Extensions . . . . . . 10
1917+ 2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11
1918+ 2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
1919+ 2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
1920+ 2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12
1921+ 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12
1922+ 2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
1923+ 2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13
1924+ 2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14
1925+ 2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14
1926+ 2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14
1927+ 2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15
1928+ 2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
1929+ 2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15
1930+ 2.4. General Syntax Principles and Transaction Model . . . . . 16
1931+ 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
1932+ 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18
1933+ 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18
1934+ 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19
1935+ 3.4. Forwarding for Address Correction or Updating . . . . . . 21
1936+ 3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22
1937+ 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
1938+ 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24
1939+ 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25
1940+ 3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26
1941+ 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26
1942+ 3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26
1943+ 3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26
1944+ 3.6.3. Message Submission Servers as Relays . . . . . . . . . 27
1945+ 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28
1946+ 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28
1947+ 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29
1948+ 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29
1949+ 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29
1950+ 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30
1951+ 3.8. Terminating Sessions and Connections . . . . . . . . . . . 30
1952+ 3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31
1953+ 3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31
1954+
1955+
1956+
1957+ Klensin Standards Track [Page 2]
1958+
1959+ RFC 5321 SMTP October 2008
1960+
1961+
1962+ 3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31
1963+ 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32
1964+ 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32
1965+ 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32
1966+ 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
1967+ 4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43
1968+ 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44
1969+ 4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46
1970+ 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
1971+ 4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48
1972+ 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50
1973+ 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52
1974+ 4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
1975+ 4.2.5. Reply Codes after DATA and the Subsequent
1976+ <CRLF>.<CRLF> . . . . . . . . . . . . . . . . . . . . 53
1977+ 4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54
1978+ 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54
1979+ 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55
1980+ 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57
1981+ 4.5. Additional Implementation Issues . . . . . . . . . . . . . 61
1982+ 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61
1983+ 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62
1984+ 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
1985+ 4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62
1986+ 4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63
1987+ 4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63
1988+ 4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63
1989+ 4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63
1990+ 4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63
1991+ 4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63
1992+ 4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63
1993+ 4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64
1994+ 4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64
1995+ 4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
1996+ 4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65
1997+ 4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65
1998+ 4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65
1999+ 4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65
2000+ 4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66
2001+ 4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66
2002+ 4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66
2003+ 4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66
2004+ 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66
2005+ 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68
2006+ 5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69
2007+ 5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69
2008+ 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71
2009+ 6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71
2010+
2011+
2012+
2013+ Klensin Standards Track [Page 3]
2014+
2015+ RFC 5321 SMTP October 2008
2016+
2017+
2018+ 6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71
2019+ 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
2020+ 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
2021+ 6.4. Compensating for Irregularities . . . . . . . . . . . . . 73
2022+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
2023+ 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
2024+ 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
2025+ 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
2026+ 7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77
2027+ 7.5. Information Disclosure in Announcements . . . . . . . . . 77
2028+ 7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78
2029+ 7.7. Information Disclosure in Message Forwarding . . . . . . . 78
2030+ 7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78
2031+ 7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
2032+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
2033+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
2034+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2035+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
2036+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 82
2037+ Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85
2038+ Appendix B. Generating SMTP Commands from RFC 822 Header
2039+ Fields . . . . . . . . . . . . . . . . . . . . . . . 85
2040+ Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86
2041+ Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
2042+ D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88
2043+ D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89
2044+ D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90
2045+ D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92
2046+ Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92
2047+ Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93
2048+ F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2049+ F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
2050+ F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2051+ F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
2052+ F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94
2053+ F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 94
2054+
2055+
2056+
2057+
2058+
2059+
2060+
2061+
2062+
2063+
2064+
2065+
2066+
2067+
2068+
2069+ Klensin Standards Track [Page 4]
2070+
2071+ RFC 5321 SMTP October 2008
2072+
2073+
2074+ 1. Introduction
2075+
2076+ 1.1. Transport of Electronic Mail
2077+
2078+ The objective of the Simple Mail Transfer Protocol (SMTP) is to
2079+ transfer mail reliably and efficiently.
2080+
2081+ SMTP is independent of the particular transmission subsystem and
2082+ requires only a reliable ordered data stream channel. While this
2083+ document specifically discusses transport over TCP, other transports
2084+ are possible. Appendices to RFC 821 [1] describe some of them.
2085+
2086+ An important feature of SMTP is its capability to transport mail
2087+ across multiple networks, usually referred to as "SMTP mail relaying"
2088+ (see Section 3.6). A network consists of the mutually-TCP-accessible
2089+ hosts on the public Internet, the mutually-TCP-accessible hosts on a
2090+ firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
2091+ environment utilizing a non-TCP transport-level protocol. Using
2092+ SMTP, a process can transfer mail to another process on the same
2093+ network or to some other network via a relay or gateway process
2094+ accessible to both networks.
2095+
2096+ In this way, a mail message may pass through a number of intermediate
2097+ relay or gateway hosts on its path from sender to ultimate recipient.
2098+ The Mail eXchanger mechanisms of the domain name system (RFC 1035
2099+ [2], RFC 974 [12], and Section 5 of this document) are used to
2100+ identify the appropriate next-hop destination for a message being
2101+ transported.
2102+
2103+ 1.2. History and Context for This Document
2104+
2105+ This document is a specification of the basic protocol for the
2106+ Internet electronic mail transport. It consolidates, updates and
2107+ clarifies, but does not add new or change existing functionality of
2108+ the following:
2109+
2110+ o the original SMTP (Simple Mail Transfer Protocol) specification of
2111+ RFC 821 [1],
2112+
2113+ o domain name system requirements and implications for mail
2114+ transport from RFC 1035 [2] and RFC 974 [12],
2115+
2116+ o the clarifications and applicability statements in RFC 1123 [3],
2117+ and
2118+
2119+ o material drawn from the SMTP Extension mechanisms in RFC 1869
2120+ [13].
2121+
2122+
2123+
2124+
2125+ Klensin Standards Track [Page 5]
2126+
2127+ RFC 5321 SMTP October 2008
2128+
2129+
2130+ o Editorial and clarification changes to RFC 2821 [14] to bring that
2131+ specification to Draft Standard.
2132+
2133+ It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC
2134+ 1123 (replacing the mail transport materials of RFC 1123). However,
2135+ RFC 821 specifies some features that were not in significant use in
2136+ the Internet by the mid-1990s and (in appendices) some additional
2137+ transport models. Those sections are omitted here in the interest of
2138+ clarity and brevity; readers needing them should refer to RFC 821.
2139+
2140+ It also includes some additional material from RFC 1123 that required
2141+ amplification. This material has been identified in multiple ways,
2142+ mostly by tracking flaming on various lists and newsgroups and
2143+ problems of unusual readings or interpretations that have appeared as
2144+ the SMTP extensions have been deployed. Where this specification
2145+ moves beyond consolidation and actually differs from earlier
2146+ documents, it supersedes them technically as well as textually.
2147+
2148+ Although SMTP was designed as a mail transport and delivery protocol,
2149+ this specification also contains information that is important to its
2150+ use as a "mail submission" protocol, as recommended for Post Office
2151+ Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501
2152+ [17]). In general, the separate mail submission protocol specified
2153+ in RFC 4409 [18] is now preferred to direct use of SMTP; more
2154+ discussion of that subject appears in that document.
2155+
2156+ Section 2.3 provides definitions of terms specific to this document.
2157+ Except when the historical terminology is necessary for clarity, this
2158+ document uses the current 'client' and 'server' terminology to
2159+ identify the sending and receiving SMTP processes, respectively.
2160+
2161+ A companion document, RFC 5322 [4], discusses message header sections
2162+ and bodies and specifies formats and structures for them.
2163+
2164+ 1.3. Document Conventions
2165+
2166+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
2167+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
2168+ document are to be interpreted as described in RFC 2119 [5]. As each
2169+ of these terms was intentionally and carefully chosen to improve the
2170+ interoperability of email, each use of these terms is to be treated
2171+ as a conformance requirement.
2172+
2173+ Because this document has a long history and to avoid the risk of
2174+ various errors and of confusing readers and documents that point to
2175+ this one, most examples and the domain names they contain are
2176+ preserved from RFC 2821. Readers are cautioned that these are
2177+
2178+
2179+
2180+
2181+ Klensin Standards Track [Page 6]
2182+
2183+ RFC 5321 SMTP October 2008
2184+
2185+
2186+ illustrative examples that should not actually be used in either code
2187+ or configuration files.
2188+
2189+ 2. The SMTP Model
2190+
2191+ 2.1. Basic Structure
2192+
2193+ The SMTP design can be pictured as:
2194+
2195+ +----------+ +----------+
2196+ +------+ | | | |
2197+ | User |<-->| | SMTP | |
2198+ +------+ | Client- |Commands/Replies| Server- |
2199+ +------+ | SMTP |<-------------->| SMTP | +------+
2200+ | File |<-->| | and Mail | |<-->| File |
2201+ |System| | | | | |System|
2202+ +------+ +----------+ +----------+ +------+
2203+ SMTP client SMTP server
2204+
2205+ When an SMTP client has a message to transmit, it establishes a two-
2206+ way transmission channel to an SMTP server. The responsibility of an
2207+ SMTP client is to transfer mail messages to one or more SMTP servers,
2208+ or report its failure to do so.
2209+
2210+ The means by which a mail message is presented to an SMTP client, and
2211+ how that client determines the identifier(s) ("names") of the
2212+ domain(s) to which mail messages are to be transferred, is a local
2213+ matter, and is not addressed by this document. In some cases, the
2214+ designated domain(s), or those determined by an SMTP client, will
2215+ identify the final destination(s) of the mail message. In other
2216+ cases, common with SMTP clients associated with implementations of
2217+ the POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17])
2218+ protocols, or when the SMTP client is inside an isolated transport
2219+ service environment, the domain determined will identify an
2220+ intermediate destination through which all mail messages are to be
2221+ relayed. SMTP clients that transfer all traffic regardless of the
2222+ target domains associated with the individual messages, or that do
2223+ not maintain queues for retrying message transmissions that initially
2224+ cannot be completed, may otherwise conform to this specification but
2225+ are not considered fully-capable. Fully-capable SMTP
2226+ implementations, including the relays used by these less capable
2227+ ones, and their destinations, are expected to support all of the
2228+ queuing, retrying, and alternate address functions discussed in this
2229+ specification. In many situations and configurations, the less-
2230+ capable clients discussed above SHOULD be using the message
2231+ submission protocol (RFC 4409 [18]) rather than SMTP.
2232+
2233+
2234+
2235+
2236+
2237+ Klensin Standards Track [Page 7]
2238+
2239+ RFC 5321 SMTP October 2008
2240+
2241+
2242+ The means by which an SMTP client, once it has determined a target
2243+ domain, determines the identity of an SMTP server to which a copy of
2244+ a message is to be transferred, and then performs that transfer, is
2245+ covered by this document. To effect a mail transfer to an SMTP
2246+ server, an SMTP client establishes a two-way transmission channel to
2247+ that SMTP server. An SMTP client determines the address of an
2248+ appropriate host running an SMTP server by resolving a destination
2249+ domain name to either an intermediate Mail eXchanger host or a final
2250+ target host.
2251+
2252+ An SMTP server may be either the ultimate destination or an
2253+ intermediate "relay" (that is, it may assume the role of an SMTP
2254+ client after receiving the message) or "gateway" (that is, it may
2255+ transport the message further using some protocol other than SMTP).
2256+ SMTP commands are generated by the SMTP client and sent to the SMTP
2257+ server. SMTP replies are sent from the SMTP server to the SMTP
2258+ client in response to the commands.
2259+
2260+ In other words, message transfer can occur in a single connection
2261+ between the original SMTP-sender and the final SMTP-recipient, or can
2262+ occur in a series of hops through intermediary systems. In either
2263+ case, once the server has issued a success response at the end of the
2264+ mail data, a formal handoff of responsibility for the message occurs:
2265+ the protocol requires that a server MUST accept responsibility for
2266+ either delivering the message or properly reporting the failure to do
2267+ so (see Sections 6.1, 6.2, and 7.8, below).
2268+
2269+ Once the transmission channel is established and initial handshaking
2270+ is completed, the SMTP client normally initiates a mail transaction.
2271+ Such a transaction consists of a series of commands to specify the
2272+ originator and destination of the mail and transmission of the
2273+ message content (including any lines in the header section or other
2274+ structure) itself. When the same message is sent to multiple
2275+ recipients, this protocol encourages the transmission of only one
2276+ copy of the data for all recipients at the same destination (or
2277+ intermediate relay) host.
2278+
2279+ The server responds to each command with a reply; replies may
2280+ indicate that the command was accepted, that additional commands are
2281+ expected, or that a temporary or permanent error condition exists.
2282+ Commands specifying the sender or recipients may include server-
2283+ permitted SMTP service extension requests, as discussed in
2284+ Section 2.2. The dialog is purposely lock-step, one-at-a-time,
2285+ although this can be modified by mutually agreed upon extension
2286+ requests such as command pipelining (RFC 2920 [19]).
2287+
2288+ Once a given mail message has been transmitted, the client may either
2289+ request that the connection be shut down or may initiate other mail
2290+
2291+
2292+
2293+ Klensin Standards Track [Page 8]
2294+
2295+ RFC 5321 SMTP October 2008
2296+
2297+
2298+ transactions. In addition, an SMTP client may use a connection to an
2299+ SMTP server for ancillary services such as verification of email
2300+ addresses or retrieval of mailing list subscriber addresses.
2301+
2302+ As suggested above, this protocol provides mechanisms for the
2303+ transmission of mail. Historically, this transmission normally
2304+ occurred directly from the sending user's host to the receiving
2305+ user's host when the two hosts are connected to the same transport
2306+ service. When they are not connected to the same transport service,
2307+ transmission occurs via one or more relay SMTP servers. A very
2308+ common case in the Internet today involves submission of the original
2309+ message to an intermediate, "message submission" server, which is
2310+ similar to a relay but has some additional properties; such servers
2311+ are discussed in Section 2.3.10 and at some length in RFC 4409 [18].
2312+ An intermediate host that acts as either an SMTP relay or as a
2313+ gateway into some other transmission environment is usually selected
2314+ through the use of the domain name service (DNS) Mail eXchanger
2315+ mechanism.
2316+
2317+ Usually, intermediate hosts are determined via the DNS MX record, not
2318+ by explicit "source" routing (see Section 5 and Appendix C and
2319+ Appendix F.2).
2320+
2321+ 2.2. The Extension Model
2322+
2323+ 2.2.1. Background
2324+
2325+ In an effort that started in 1990, approximately a decade after RFC
2326+ 821 was completed, the protocol was modified with a "service
2327+ extensions" model that permits the client and server to agree to
2328+ utilize shared functionality beyond the original SMTP requirements.
2329+ The SMTP extension mechanism defines a means whereby an extended SMTP
2330+ client and server may recognize each other, and the server can inform
2331+ the client as to the service extensions that it supports.
2332+
2333+ Contemporary SMTP implementations MUST support the basic extension
2334+ mechanisms. For instance, servers MUST support the EHLO command even
2335+ if they do not implement any specific extensions and clients SHOULD
2336+ preferentially utilize EHLO rather than HELO. (However, for
2337+ compatibility with older conforming implementations, SMTP clients and
2338+ servers MUST support the original HELO mechanisms as a fallback.)
2339+ Unless the different characteristics of HELO must be identified for
2340+ interoperability purposes, this document discusses only EHLO.
2341+
2342+ SMTP is widely deployed and high-quality implementations have proven
2343+ to be very robust. However, the Internet community now considers
2344+ some services to be important that were not anticipated when the
2345+ protocol was first designed. If support for those services is to be
2346+
2347+
2348+
2349+ Klensin Standards Track [Page 9]
2350+
2351+ RFC 5321 SMTP October 2008
2352+
2353+
2354+ added, it must be done in a way that permits older implementations to
2355+ continue working acceptably. The extension framework consists of:
2356+
2357+ o The SMTP command EHLO, superseding the earlier HELO,
2358+
2359+ o a registry of SMTP service extensions,
2360+
2361+ o additional parameters to the SMTP MAIL and RCPT commands, and
2362+
2363+ o optional replacements for commands defined in this protocol, such
2364+ as for DATA in non-ASCII transmissions (RFC 3030 [20]).
2365+
2366+ SMTP's strength comes primarily from its simplicity. Experience with
2367+ many protocols has shown that protocols with few options tend towards
2368+ ubiquity, whereas protocols with many options tend towards obscurity.
2369+
2370+ Each and every extension, regardless of its benefits, must be
2371+ carefully scrutinized with respect to its implementation, deployment,
2372+ and interoperability costs. In many cases, the cost of extending the
2373+ SMTP service will likely outweigh the benefit.
2374+
2375+ 2.2.2. Definition and Registration of Extensions
2376+
2377+ The IANA maintains a registry of SMTP service extensions. A
2378+ corresponding EHLO keyword value is associated with each extension.
2379+ Each service extension registered with the IANA must be defined in a
2380+ formal Standards-Track or IESG-approved Experimental protocol
2381+ document. The definition must include:
2382+
2383+ o the textual name of the SMTP service extension;
2384+
2385+ o the EHLO keyword value associated with the extension;
2386+
2387+ o the syntax and possible values of parameters associated with the
2388+ EHLO keyword value;
2389+
2390+ o any additional SMTP verbs associated with the extension
2391+ (additional verbs will usually be, but are not required to be, the
2392+ same as the EHLO keyword value);
2393+
2394+ o any new parameters the extension associates with the MAIL or RCPT
2395+ verbs;
2396+
2397+ o a description of how support for the extension affects the
2398+ behavior of a server and client SMTP; and
2399+
2400+
2401+
2402+
2403+
2404+
2405+ Klensin Standards Track [Page 10]
2406+
2407+ RFC 5321 SMTP October 2008
2408+
2409+
2410+ o the increment by which the extension is increasing the maximum
2411+ length of the commands MAIL and/or RCPT, over that specified in
2412+ this Standard.
2413+
2414+ In addition, any EHLO keyword value starting with an upper or lower
2415+ case "X" refers to a local SMTP service extension used exclusively
2416+ through bilateral agreement. Keywords beginning with "X" MUST NOT be
2417+ used in a registered service extension. Conversely, keyword values
2418+ presented in the EHLO response that do not begin with "X" MUST
2419+ correspond to a Standard, Standards-Track, or IESG-approved
2420+ Experimental SMTP service extension registered with IANA. A
2421+ conforming server MUST NOT offer non-"X"-prefixed keyword values that
2422+ are not described in a registered extension.
2423+
2424+ Additional verbs and parameter names are bound by the same rules as
2425+ EHLO keywords; specifically, verbs beginning with "X" are local
2426+ extensions that may not be registered or standardized. Conversely,
2427+ verbs not beginning with "X" must always be registered.
2428+
2429+ 2.2.3. Special Issues with Extensions
2430+
2431+ Extensions that change fairly basic properties of SMTP operation are
2432+ permitted. The text in other sections of this document must be
2433+ understood in that context. In particular, extensions can change the
2434+ minimum limits specified in Section 4.5.3, can change the ASCII
2435+ character set requirement as mentioned above, or can introduce some
2436+ optional modes of message handling.
2437+
2438+ In particular, if an extension implies that the delivery path
2439+ normally supports special features of that extension, and an
2440+ intermediate SMTP system finds a next hop that does not support the
2441+ required extension, it MAY choose, based on the specific extension
2442+ and circumstances, to requeue the message and try later and/or try an
2443+ alternate MX host. If this strategy is employed, the timeout to fall
2444+ back to an unextended format (if one is available) SHOULD be less
2445+ than the normal timeout for bouncing as undeliverable (e.g., if
2446+ normal timeout is three days, the requeue timeout before attempting
2447+ to transmit the mail without the extension might be one day).
2448+
2449+ 2.3. SMTP Terminology
2450+
2451+ 2.3.1. Mail Objects
2452+
2453+ SMTP transports a mail object. A mail object contains an envelope
2454+ and content.
2455+
2456+ The SMTP envelope is sent as a series of SMTP protocol units
2457+ (described in Section 3). It consists of an originator address (to
2458+
2459+
2460+
2461+ Klensin Standards Track [Page 11]
2462+
2463+ RFC 5321 SMTP October 2008
2464+
2465+
2466+ which error reports should be directed), one or more recipient
2467+ addresses, and optional protocol extension material. Historically,
2468+ variations on the reverse-path (originator) address specification
2469+ command (MAIL) could be used to specify alternate delivery modes,
2470+ such as immediate display; those variations have now been deprecated
2471+ (see Appendix F and Appendix F.6).
2472+
2473+ The SMTP content is sent in the SMTP DATA protocol unit and has two
2474+ parts: the header section and the body. If the content conforms to
2475+ other contemporary standards, the header section consists of a
2476+ collection of header fields, each consisting of a header name, a
2477+ colon, and data, structured as in the message format specification
2478+ (RFC 5322 [4]); the body, if structured, is defined according to MIME
2479+ (RFC 2045 [21]). The content is textual in nature, expressed using
2480+ the US-ASCII repertoire [6]. Although SMTP extensions (such as
2481+ "8BITMIME", RFC 1652 [22]) may relax this restriction for the content
2482+ body, the content header fields are always encoded using the US-ASCII
2483+ repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24])
2484+ define an algorithm for representing header values outside the US-
2485+ ASCII repertoire, while still encoding them using the US-ASCII
2486+ repertoire.
2487+
2488+ 2.3.2. Senders and Receivers
2489+
2490+ In RFC 821, the two hosts participating in an SMTP transaction were
2491+ described as the "SMTP-sender" and "SMTP-receiver". This document
2492+ has been changed to reflect current industry terminology and hence
2493+ refers to them as the "SMTP client" (or sometimes just "the client")
2494+ and "SMTP server" (or just "the server"), respectively. Since a
2495+ given host may act both as server and client in a relay situation,
2496+ "receiver" and "sender" terminology is still used where needed for
2497+ clarity.
2498+
2499+ 2.3.3. Mail Agents and Message Stores
2500+
2501+ Additional mail system terminology became common after RFC 821 was
2502+ published and, where convenient, is used in this specification. In
2503+ particular, SMTP servers and clients provide a mail transport service
2504+ and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
2505+ Agents" (MUAs or UAs) are normally thought of as the sources and
2506+ targets of mail. At the source, an MUA might collect mail to be
2507+ transmitted from a user and hand it off to an MTA; the final
2508+ ("delivery") MTA would be thought of as handing the mail off to an
2509+ MUA (or at least transferring responsibility to it, e.g., by
2510+ depositing the message in a "message store"). However, while these
2511+ terms are used with at least the appearance of great precision in
2512+ other environments, the implied boundaries between MUAs and MTAs
2513+ often do not accurately match common, and conforming, practices with
2514+
2515+
2516+
2517+ Klensin Standards Track [Page 12]
2518+
2519+ RFC 5321 SMTP October 2008
2520+
2521+
2522+ Internet mail. Hence, the reader should be cautious about inferring
2523+ the strong relationships and responsibilities that might be implied
2524+ if these terms were used elsewhere.
2525+
2526+ 2.3.4. Host
2527+
2528+ For the purposes of this specification, a host is a computer system
2529+ attached to the Internet (or, in some cases, to a private TCP/IP
2530+ network) and supporting the SMTP protocol. Hosts are known by names
2531+ (see the next section); they SHOULD NOT be identified by numerical
2532+ addresses, i.e., by address literals as described in Section 4.1.2.
2533+
2534+ 2.3.5. Domain Names
2535+
2536+ A domain name (or often just a "domain") consists of one or more
2537+ components, separated by dots if more than one appears. In the case
2538+ of a top-level domain used by itself in an email address, a single
2539+ string is used without any dots. This makes the requirement,
2540+ described in more detail below, that only fully-qualified domain
2541+ names appear in SMTP transactions on the public Internet,
2542+ particularly important where top-level domains are involved. These
2543+ components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
2544+ for SMTP purposes to consist of a sequence of letters, digits, and
2545+ hyphens drawn from the ASCII character set [6]. Domain names are
2546+ used as names of hosts and of other entities in the domain name
2547+ hierarchy. For example, a domain may refer to an alias (label of a
2548+ CNAME RR) or the label of Mail eXchanger records to be used to
2549+ deliver mail instead of representing a host name. See RFC 1035 [2]
2550+ and Section 5 of this specification.
2551+
2552+ The domain name, as described in this document and in RFC 1035 [2],
2553+ is the entire, fully-qualified name (often referred to as an "FQDN").
2554+ A domain name that is not in FQDN form is no more than a local alias.
2555+ Local aliases MUST NOT appear in any SMTP transaction.
2556+
2557+ Only resolvable, fully-qualified domain names (FQDNs) are permitted
2558+ when domain names are used in SMTP. In other words, names that can
2559+ be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
2560+ in Section 5) are permitted, as are CNAME RRs whose targets can be
2561+ resolved, in turn, to MX or address RRs. Local nicknames or
2562+ unqualified names MUST NOT be used. There are two exceptions to the
2563+ rule requiring FQDNs:
2564+
2565+ o The domain name given in the EHLO command MUST be either a primary
2566+ host name (a domain name that resolves to an address RR) or, if
2567+ the host has no name, an address literal, as described in
2568+ Section 4.1.3 and discussed further in the EHLO discussion of
2569+ Section 4.1.4.
2570+
2571+
2572+
2573+ Klensin Standards Track [Page 13]
2574+
2575+ RFC 5321 SMTP October 2008
2576+
2577+
2578+ o The reserved mailbox name "postmaster" may be used in a RCPT
2579+ command without domain qualification (see Section 4.1.1.3) and
2580+ MUST be accepted if so used.
2581+
2582+ 2.3.6. Buffer and State Table
2583+
2584+ SMTP sessions are stateful, with both parties carefully maintaining a
2585+ common view of the current state. In this document, we model this
2586+ state by a virtual "buffer" and a "state table" on the server that
2587+ may be used by the client to, for example, "clear the buffer" or
2588+ "reset the state table", causing the information in the buffer to be
2589+ discarded and the state to be returned to some previous state.
2590+
2591+ 2.3.7. Commands and Replies
2592+
2593+ SMTP commands and, unless altered by a service extension, message
2594+ data, are transmitted from the sender to the receiver via the
2595+ transmission channel in "lines".
2596+
2597+ An SMTP reply is an acknowledgment (positive or negative) sent in
2598+ "lines" from receiver to sender via the transmission channel in
2599+ response to a command. The general form of a reply is a numeric
2600+ completion code (indicating failure or success) usually followed by a
2601+ text string. The codes are for use by programs and the text is
2602+ usually intended for human users. RFC 3463 [25], specifies further
2603+ structuring of the reply strings, including the use of supplemental
2604+ and more specific completion codes (see also RFC 5248 [26]).
2605+
2606+ 2.3.8. Lines
2607+
2608+ Lines consist of zero or more data characters terminated by the
2609+ sequence ASCII character "CR" (hex value 0D) followed immediately by
2610+ ASCII character "LF" (hex value 0A). This termination sequence is
2611+ denoted as <CRLF> in this document. Conforming implementations MUST
2612+ NOT recognize or generate any other character or character sequence
2613+ as a line terminator. Limits MAY be imposed on line lengths by
2614+ servers (see Section 4).
2615+
2616+ In addition, the appearance of "bare" "CR" or "LF" characters in text
2617+ (i.e., either without the other) has a long history of causing
2618+ problems in mail implementations and applications that use the mail
2619+ system as a tool. SMTP client implementations MUST NOT transmit
2620+ these characters except when they are intended as line terminators
2621+ and then MUST, as indicated above, transmit them only as a <CRLF>
2622+ sequence.
2623+
2624+
2625+
2626+
2627+
2628+
2629+ Klensin Standards Track [Page 14]
2630+
2631+ RFC 5321 SMTP October 2008
2632+
2633+
2634+ 2.3.9. Message Content and Mail Data
2635+
2636+ The terms "message content" and "mail data" are used interchangeably
2637+ in this document to describe the material transmitted after the DATA
2638+ command is accepted and before the end of data indication is
2639+ transmitted. Message content includes the message header section and
2640+ the possibly structured message body. The MIME specification (RFC
2641+ 2045 [21]) provides the standard mechanisms for structured message
2642+ bodies.
2643+
2644+ 2.3.10. Originator, Delivery, Relay, and Gateway Systems
2645+
2646+ This specification makes a distinction among four types of SMTP
2647+ systems, based on the role those systems play in transmitting
2648+ electronic mail. An "originating" system (sometimes called an SMTP
2649+ originator) introduces mail into the Internet or, more generally,
2650+ into a transport service environment. A "delivery" SMTP system is
2651+ one that receives mail from a transport service environment and
2652+ passes it to a mail user agent or deposits it in a message store that
2653+ a mail user agent is expected to subsequently access. A "relay" SMTP
2654+ system (usually referred to just as a "relay") receives mail from an
2655+ SMTP client and transmits it, without modification to the message
2656+ data other than adding trace information, to another SMTP server for
2657+ further relaying or for delivery.
2658+
2659+ A "gateway" SMTP system (usually referred to just as a "gateway")
2660+ receives mail from a client system in one transport environment and
2661+ transmits it to a server system in another transport environment.
2662+ Differences in protocols or message semantics between the transport
2663+ environments on either side of a gateway may require that the gateway
2664+ system perform transformations to the message that are not permitted
2665+ to SMTP relay systems. For the purposes of this specification,
2666+ firewalls that rewrite addresses should be considered as gateways,
2667+ even if SMTP is used on both sides of them (see RFC 2979 [27]).
2668+
2669+ 2.3.11. Mailbox and Address
2670+
2671+ As used in this specification, an "address" is a character string
2672+ that identifies a user to whom mail will be sent or a location into
2673+ which mail will be deposited. The term "mailbox" refers to that
2674+ depository. The two terms are typically used interchangeably unless
2675+ the distinction between the location in which mail is placed (the
2676+ mailbox) and a reference to it (the address) is important. An
2677+ address normally consists of user and domain specifications. The
2678+ standard mailbox naming convention is defined to be
2679+ "local-part@domain"; contemporary usage permits a much broader set of
2680+ applications than simple "user names". Consequently, and due to a
2681+ long history of problems when intermediate hosts have attempted to
2682+
2683+
2684+
2685+ Klensin Standards Track [Page 15]
2686+
2687+ RFC 5321 SMTP October 2008
2688+
2689+
2690+ optimize transport by modifying them, the local-part MUST be
2691+ interpreted and assigned semantics only by the host specified in the
2692+ domain part of the address.
2693+
2694+ 2.4. General Syntax Principles and Transaction Model
2695+
2696+ SMTP commands and replies have a rigid syntax. All commands begin
2697+ with a command verb. All replies begin with a three digit numeric
2698+ code. In some commands and replies, arguments are required following
2699+ the verb or reply code. Some commands do not accept arguments (after
2700+ the verb), and some reply codes are followed, sometimes optionally,
2701+ by free form text. In both cases, where text appears, it is
2702+ separated from the verb or reply code by a space character. Complete
2703+ definitions of commands and replies appear in Section 4.
2704+
2705+ Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
2706+ and extension name keywords) are not case sensitive, with the sole
2707+ exception in this specification of a mailbox local-part (SMTP
2708+ Extensions may explicitly specify case-sensitive elements). That is,
2709+ a command verb, an argument value other than a mailbox local-part,
2710+ and free form text MAY be encoded in upper case, lower case, or any
2711+ mixture of upper and lower case with no impact on its meaning. The
2712+ local-part of a mailbox MUST BE treated as case sensitive.
2713+ Therefore, SMTP implementations MUST take care to preserve the case
2714+ of mailbox local-parts. In particular, for some hosts, the user
2715+ "smith" is different from the user "Smith". However, exploiting the
2716+ case sensitivity of mailbox local-parts impedes interoperability and
2717+ is discouraged. Mailbox domains follow normal DNS rules and are
2718+ hence not case sensitive.
2719+
2720+ A few SMTP servers, in violation of this specification (and RFC 821)
2721+ require that command verbs be encoded by clients in upper case.
2722+ Implementations MAY wish to employ this encoding to accommodate those
2723+ servers.
2724+
2725+ The argument clause consists of a variable-length character string
2726+ ending with the end of the line, i.e., with the character sequence
2727+ <CRLF>. The receiver will take no action until this sequence is
2728+ received.
2729+
2730+ The syntax for each command is shown with the discussion of that
2731+ command. Common elements and parameters are shown in Section 4.1.2.
2732+
2733+ Commands and replies are composed of characters from the ASCII
2734+ character set [6]. When the transport service provides an 8-bit byte
2735+ (octet) transmission channel, each 7-bit character is transmitted,
2736+ right justified, in an octet with the high-order bit cleared to zero.
2737+ More specifically, the unextended SMTP service provides 7-bit
2738+
2739+
2740+
2741+ Klensin Standards Track [Page 16]
2742+
2743+ RFC 5321 SMTP October 2008
2744+
2745+
2746+ transport only. An originating SMTP client that has not successfully
2747+ negotiated an appropriate extension with a particular server (see the
2748+ next paragraph) MUST NOT transmit messages with information in the
2749+ high-order bit of octets. If such messages are transmitted in
2750+ violation of this rule, receiving SMTP servers MAY clear the high-
2751+ order bit or reject the message as invalid. In general, a relay SMTP
2752+ SHOULD assume that the message content it has received is valid and,
2753+ assuming that the envelope permits doing so, relay it without
2754+ inspecting that content. Of course, if the content is mislabeled and
2755+ the data path cannot accept the actual content, this may result in
2756+ the ultimate delivery of a severely garbled message to the recipient.
2757+ Delivery SMTP systems MAY reject such messages, or return them as
2758+ undeliverable, rather than deliver them. In the absence of a server-
2759+ offered extension explicitly permitting it, a sending SMTP system is
2760+ not permitted to send envelope commands in any character set other
2761+ than US-ASCII. Receiving systems SHOULD reject such commands,
2762+ normally using "500 syntax error - invalid character" replies.
2763+
2764+ 8-bit message content transmission MAY be requested of the server by
2765+ a client using extended SMTP facilities, notably the "8BITMIME"
2766+ extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP
2767+ servers. However, it MUST NOT be construed as authorization to
2768+ transmit unrestricted 8-bit material, nor does 8BITMIME authorize
2769+ transmission of any envelope material in other than ASCII. 8BITMIME
2770+ MUST NOT be requested by senders for material with the high bit on
2771+ that is not in MIME format with an appropriate content-transfer
2772+ encoding; servers MAY reject such messages.
2773+
2774+ The metalinguistic notation used in this document corresponds to the
2775+ "Augmented BNF" used in other Internet mail system documents. The
2776+ reader who is not familiar with that syntax should consult the ABNF
2777+ specification in RFC 5234 [7]. Metalanguage terms used in running
2778+ text are surrounded by pointed brackets (e.g., <CRLF>) for clarity.
2779+ The reader is cautioned that the grammar expressed in the
2780+ metalanguage is not comprehensive. There are many instances in which
2781+ provisions in the text constrain or otherwise modify the syntax or
2782+ semantics implied by the grammar.
2783+
2784+ 3. The SMTP Procedures: An Overview
2785+
2786+ This section contains descriptions of the procedures used in SMTP:
2787+ session initiation, mail transaction, forwarding mail, verifying
2788+ mailbox names and expanding mailing lists, and opening and closing
2789+ exchanges. Comments on relaying, a note on mail domains, and a
2790+ discussion of changing roles are included at the end of this section.
2791+ Several complete scenarios are presented in Appendix D.
2792+
2793+
2794+
2795+
2796+
2797+ Klensin Standards Track [Page 17]
2798+
2799+ RFC 5321 SMTP October 2008
2800+
2801+
2802+ 3.1. Session Initiation
2803+
2804+ An SMTP session is initiated when a client opens a connection to a
2805+ server and the server responds with an opening message.
2806+
2807+ SMTP server implementations MAY include identification of their
2808+ software and version information in the connection greeting reply
2809+ after the 220 code, a practice that permits more efficient isolation
2810+ and repair of any problems. Implementations MAY make provision for
2811+ SMTP servers to disable the software and version announcement where
2812+ it causes security concerns. While some systems also identify their
2813+ contact point for mail problems, this is not a substitute for
2814+ maintaining the required "postmaster" address (see Section 4).
2815+
2816+ The SMTP protocol allows a server to formally reject a mail session
2817+ while still allowing the initial connection as follows: a 554
2818+ response MAY be given in the initial connection opening message
2819+ instead of the 220. A server taking this approach MUST still wait
2820+ for the client to send a QUIT (see Section 4.1.1.10) before closing
2821+ the connection and SHOULD respond to any intervening commands with
2822+ "503 bad sequence of commands". Since an attempt to make an SMTP
2823+ connection to such a system is probably in error, a server returning
2824+ a 554 response on connection opening SHOULD provide enough
2825+ information in the reply text to facilitate debugging of the sending
2826+ system.
2827+
2828+ 3.2. Client Initiation
2829+
2830+ Once the server has sent the greeting (welcoming) message and the
2831+ client has received it, the client normally sends the EHLO command to
2832+ the server, indicating the client's identity. In addition to opening
2833+ the session, use of EHLO indicates that the client is able to process
2834+ service extensions and requests that the server provide a list of the
2835+ extensions it supports. Older SMTP systems that are unable to
2836+ support service extensions, and contemporary clients that do not
2837+ require service extensions in the mail session being initiated, MAY
2838+ use HELO instead of EHLO. Servers MUST NOT return the extended EHLO-
2839+ style response to a HELO command. For a particular connection
2840+ attempt, if the server returns a "command not recognized" response to
2841+ EHLO, the client SHOULD be able to fall back and send HELO.
2842+
2843+ In the EHLO command, the host sending the command identifies itself;
2844+ the command may be interpreted as saying "Hello, I am <domain>" (and,
2845+ in the case of EHLO, "and I support service extension requests").
2846+
2847+
2848+
2849+
2850+
2851+
2852+
2853+ Klensin Standards Track [Page 18]
2854+
2855+ RFC 5321 SMTP October 2008
2856+
2857+
2858+ 3.3. Mail Transactions
2859+
2860+ There are three steps to SMTP mail transactions. The transaction
2861+ starts with a MAIL command that gives the sender identification. (In
2862+ general, the MAIL command may be sent only when no mail transaction
2863+ is in progress; see Section 4.1.4.) A series of one or more RCPT
2864+ commands follows, giving the receiver information. Then, a DATA
2865+ command initiates transfer of the mail data and is terminated by the
2866+ "end of mail" data indicator, which also confirms the transaction.
2867+
2868+ The first step in the procedure is the MAIL command.
2869+
2870+ MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
2871+
2872+ This command tells the SMTP-receiver that a new mail transaction is
2873+ starting and to reset all its state tables and buffers, including any
2874+ recipients or mail data. The <reverse-path> portion of the first or
2875+ only argument contains the source mailbox (between "<" and ">"
2876+ brackets), which can be used to report errors (see Section 4.2 for a
2877+ discussion of error reporting). If accepted, the SMTP server returns
2878+ a "250 OK" reply. If the mailbox specification is not acceptable for
2879+ some reason, the server MUST return a reply indicating whether the
2880+ failure is permanent (i.e., will occur again if the client tries to
2881+ send the same address again) or temporary (i.e., the address might be
2882+ accepted if the client tries again later). Despite the apparent
2883+ scope of this requirement, there are circumstances in which the
2884+ acceptability of the reverse-path may not be determined until one or
2885+ more forward-paths (in RCPT commands) can be examined. In those
2886+ cases, the server MAY reasonably accept the reverse-path (with a 250
2887+ reply) and then report problems after the forward-paths are received
2888+ and examined. Normally, failures produce 550 or 553 replies.
2889+
2890+ Historically, the <reverse-path> was permitted to contain more than
2891+ just a mailbox; however, contemporary systems SHOULD NOT use source
2892+ routing (see Appendix C).
2893+
2894+ The optional <mail-parameters> are associated with negotiated SMTP
2895+ service extensions (see Section 2.2).
2896+
2897+ The second step in the procedure is the RCPT command. This step of
2898+ the procedure can be repeated any number of times.
2899+
2900+ RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
2901+
2902+ The first or only argument to this command includes a forward-path
2903+ (normally a mailbox and domain, always surrounded by "<" and ">"
2904+ brackets) identifying one recipient. If accepted, the SMTP server
2905+ returns a "250 OK" reply and stores the forward-path. If the
2906+
2907+
2908+
2909+ Klensin Standards Track [Page 19]
2910+
2911+ RFC 5321 SMTP October 2008
2912+
2913+
2914+ recipient is known not to be a deliverable address, the SMTP server
2915+ returns a 550 reply, typically with a string such as "no such user -
2916+ " and the mailbox name (other circumstances and reply codes are
2917+ possible).
2918+
2919+ The <forward-path> can contain more than just a mailbox.
2920+ Historically, the <forward-path> was permitted to contain a source
2921+ routing list of hosts and the destination mailbox; however,
2922+ contemporary SMTP clients SHOULD NOT utilize source routes (see
2923+ Appendix C). Servers MUST be prepared to encounter a list of source
2924+ routes in the forward-path, but they SHOULD ignore the routes or MAY
2925+ decline to support the relaying they imply. Similarly, servers MAY
2926+ decline to accept mail that is destined for other hosts or systems.
2927+ These restrictions make a server useless as a relay for clients that
2928+ do not support full SMTP functionality. Consequently, restricted-
2929+ capability clients MUST NOT assume that any SMTP server on the
2930+ Internet can be used as their mail processing (relaying) site. If a
2931+ RCPT command appears without a previous MAIL command, the server MUST
2932+ return a 503 "Bad sequence of commands" response. The optional
2933+ <rcpt-parameters> are associated with negotiated SMTP service
2934+ extensions (see Section 2.2).
2935+
2936+ Since it has been a common source of errors, it is worth noting that
2937+ spaces are not permitted on either side of the colon following FROM
2938+ in the MAIL command or TO in the RCPT command. The syntax is exactly
2939+ as given above.
2940+
2941+ The third step in the procedure is the DATA command (or some
2942+ alternative specified in a service extension).
2943+
2944+ DATA <CRLF>
2945+
2946+ If accepted, the SMTP server returns a 354 Intermediate reply and
2947+ considers all succeeding lines up to but not including the end of
2948+ mail data indicator to be the message text. When the end of text is
2949+ successfully received and stored, the SMTP-receiver sends a "250 OK"
2950+ reply.
2951+
2952+ Since the mail data is sent on the transmission channel, the end of
2953+ mail data must be indicated so that the command and reply dialog can
2954+ be resumed. SMTP indicates the end of the mail data by sending a
2955+ line containing only a "." (period or full stop). A transparency
2956+ procedure is used to prevent this from interfering with the user's
2957+ text (see Section 4.5.2).
2958+
2959+ The end of mail data indicator also confirms the mail transaction and
2960+ tells the SMTP server to now process the stored recipients and mail
2961+
2962+
2963+
2964+
2965+ Klensin Standards Track [Page 20]
2966+
2967+ RFC 5321 SMTP October 2008
2968+
2969+
2970+ data. If accepted, the SMTP server returns a "250 OK" reply. The
2971+ DATA command can fail at only two points in the protocol exchange:
2972+
2973+ If there was no MAIL, or no RCPT, command, or all such commands were
2974+ rejected, the server MAY return a "command out of sequence" (503) or
2975+ "no valid recipients" (554) reply in response to the DATA command.
2976+ If one of those replies (or any other 5yz reply) is received, the
2977+ client MUST NOT send the message data; more generally, message data
2978+ MUST NOT be sent unless a 354 reply is received.
2979+
2980+ If the verb is initially accepted and the 354 reply issued, the DATA
2981+ command should fail only if the mail transaction was incomplete (for
2982+ example, no recipients), if resources were unavailable (including, of
2983+ course, the server unexpectedly becoming unavailable), or if the
2984+ server determines that the message should be rejected for policy or
2985+ other reasons.
2986+
2987+ However, in practice, some servers do not perform recipient
2988+ verification until after the message text is received. These servers
2989+ SHOULD treat a failure for one or more recipients as a "subsequent
2990+ failure" and return a mail message as discussed in Section 6 and, in
2991+ particular, in Section 6.1. Using a "550 mailbox not found" (or
2992+ equivalent) reply code after the data are accepted makes it difficult
2993+ or impossible for the client to determine which recipients failed.
2994+
2995+ When the RFC 822 format ([28], [4]) is being used, the mail data
2996+ include the header fields such as those named Date, Subject, To, Cc,
2997+ and From. Server SMTP systems SHOULD NOT reject messages based on
2998+ perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message
2999+ header section or message body. In particular, they MUST NOT reject
3000+ messages in which the numbers of Resent-header fields do not match or
3001+ Resent-to appears without Resent-from and/or Resent-date.
3002+
3003+ Mail transaction commands MUST be used in the order discussed above.
3004+
3005+ 3.4. Forwarding for Address Correction or Updating
3006+
3007+ Forwarding support is most often required to consolidate and simplify
3008+ addresses within, or relative to, some enterprise and less frequently
3009+ to establish addresses to link a person's prior address with a
3010+ current one. Silent forwarding of messages (without server
3011+ notification to the sender), for security or non-disclosure purposes,
3012+ is common in the contemporary Internet.
3013+
3014+ In both the enterprise and the "new address" cases, information
3015+ hiding (and sometimes security) considerations argue against exposure
3016+ of the "final" address through the SMTP protocol as a side effect of
3017+ the forwarding activity. This may be especially important when the
3018+
3019+
3020+
3021+ Klensin Standards Track [Page 21]
3022+
3023+ RFC 5321 SMTP October 2008
3024+
3025+
3026+ final address may not even be reachable by the sender. Consequently,
3027+ the "forwarding" mechanisms described in Section 3.2 of RFC 821, and
3028+ especially the 251 (corrected destination) and 551 reply codes from
3029+ RCPT must be evaluated carefully by implementers and, when they are
3030+ available, by those configuring systems (see also Section 7.4).
3031+
3032+ In particular:
3033+
3034+ o Servers MAY forward messages when they are aware of an address
3035+ change. When they do so, they MAY either provide address-updating
3036+ information with a 251 code, or may forward "silently" and return
3037+ a 250 code. However, if a 251 code is used, they MUST NOT assume
3038+ that the client will actually update address information or even
3039+ return that information to the user.
3040+
3041+ Alternately,
3042+
3043+ o Servers MAY reject messages or return them as non-deliverable when
3044+ they cannot be delivered precisely as addressed. When they do so,
3045+ they MAY either provide address-updating information with a 551
3046+ code, or may reject the message as undeliverable with a 550 code
3047+ and no address-specific information. However, if a 551 code is
3048+ used, they MUST NOT assume that the client will actually update
3049+ address information or even return that information to the user.
3050+
3051+ SMTP server implementations that support the 251 and/or 551 reply
3052+ codes SHOULD provide configuration mechanisms so that sites that
3053+ conclude that they would undesirably disclose information can disable
3054+ or restrict their use.
3055+
3056+ 3.5. Commands for Debugging Addresses
3057+
3058+ 3.5.1. Overview
3059+
3060+ SMTP provides commands to verify a user name or obtain the content of
3061+ a mailing list. This is done with the VRFY and EXPN commands, which
3062+ have character string arguments. Implementations SHOULD support VRFY
3063+ and EXPN (however, see Section 3.5.2 and Section 7.3).
3064+
3065+ For the VRFY command, the string is a user name or a user name and
3066+ domain (see below). If a normal (i.e., 250) response is returned,
3067+ the response MAY include the full name of the user and MUST include
3068+ the mailbox of the user. It MUST be in either of the following
3069+ forms:
3070+
3071+ User Name <local-part@domain>
3072+ local-part@domain
3073+
3074+
3075+
3076+
3077+ Klensin Standards Track [Page 22]
3078+
3079+ RFC 5321 SMTP October 2008
3080+
3081+
3082+ When a name that is the argument to VRFY could identify more than one
3083+ mailbox, the server MAY either note the ambiguity or identify the
3084+ alternatives. In other words, any of the following are legitimate
3085+ responses to VRFY:
3086+
3087+ 553 User ambiguous
3088+
3089+ or
3090+
3091+ 553- Ambiguous; Possibilities are
3092+ 553-Joe Smith <jsmith@foo.com>
3093+ 553-Harry Smith <hsmith@foo.com>
3094+ 553 Melvin Smith <dweep@foo.com>
3095+
3096+ or
3097+
3098+ 553-Ambiguous; Possibilities
3099+ 553- <jsmith@foo.com>
3100+ 553- <hsmith@foo.com>
3101+ 553 <dweep@foo.com>
3102+
3103+ Under normal circumstances, a client receiving a 553 reply would be
3104+ expected to expose the result to the user. Use of exactly the forms
3105+ given, and the "user ambiguous" or "ambiguous" keywords, possibly
3106+ supplemented by extended reply codes, such as those described in RFC
3107+ 3463 [25], will facilitate automated translation into other languages
3108+ as needed. Of course, a client that was highly automated or that was
3109+ operating in another language than English might choose to try to
3110+ translate the response to return some other indication to the user
3111+ than the literal text of the reply, or to take some automated action
3112+ such as consulting a directory service for additional information
3113+ before reporting to the user.
3114+
3115+ For the EXPN command, the string identifies a mailing list, and the
3116+ successful (i.e., 250) multiline response MAY include the full name
3117+ of the users and MUST give the mailboxes on the mailing list.
3118+
3119+ In some hosts, the distinction between a mailing list and an alias
3120+ for a single mailbox is a bit fuzzy, since a common data structure
3121+ may hold both types of entries, and it is possible to have mailing
3122+ lists containing only one mailbox. If a request is made to apply
3123+ VRFY to a mailing list, a positive response MAY be given if a message
3124+ so addressed would be delivered to everyone on the list, otherwise an
3125+ error SHOULD be reported (e.g., "550 That is a mailing list, not a
3126+ user" or "252 Unable to verify members of mailing list"). If a
3127+ request is made to expand a user name, the server MAY return a
3128+
3129+
3130+
3131+
3132+
3133+ Klensin Standards Track [Page 23]
3134+
3135+ RFC 5321 SMTP October 2008
3136+
3137+
3138+ positive response consisting of a list containing one name, or an
3139+ error MAY be reported (e.g., "550 That is a user name, not a mailing
3140+ list").
3141+
3142+ In the case of a successful multiline reply (normal for EXPN),
3143+ exactly one mailbox is to be specified on each line of the reply.
3144+ The case of an ambiguous request is discussed above.
3145+
3146+ "User name" is a fuzzy term and has been used deliberately. An
3147+ implementation of the VRFY or EXPN commands MUST include at least
3148+ recognition of local mailboxes as "user names". However, since
3149+ current Internet practice often results in a single host handling
3150+ mail for multiple domains, hosts, especially hosts that provide this
3151+ functionality, SHOULD accept the "local-part@domain" form as a "user
3152+ name"; hosts MAY also choose to recognize other strings as "user
3153+ names".
3154+
3155+ The case of expanding a mailbox list requires a multiline reply, such
3156+ as:
3157+
3158+ C: EXPN Example-People
3159+ S: 250-Jon Postel <Postel@isi.edu>
3160+ S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
3161+ S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
3162+
3163+ or
3164+
3165+ C: EXPN Executive-Washroom-List
3166+ S: 550 Access Denied to You.
3167+
3168+ The character string arguments of the VRFY and EXPN commands cannot
3169+ be further restricted due to the variety of implementations of the
3170+ user name and mailbox list concepts. On some systems, it may be
3171+ appropriate for the argument of the EXPN command to be a file name
3172+ for a file containing a mailing list, but again there are a variety
3173+ of file naming conventions in the Internet. Similarly, historical
3174+ variations in what is returned by these commands are such that the
3175+ response SHOULD be interpreted very carefully, if at all, and SHOULD
3176+ generally only be used for diagnostic purposes.
3177+
3178+ 3.5.2. VRFY Normal Response
3179+
3180+ When normal (2yz or 551) responses are returned from a VRFY or EXPN
3181+ request, the reply MUST include the <Mailbox> name using a
3182+ "<local-part@domain>" construction, where "domain" is a fully-
3183+ qualified domain name. In circumstances exceptional enough to
3184+ justify violating the intent of this specification, free-form text
3185+ MAY be returned. In order to facilitate parsing by both computers
3186+
3187+
3188+
3189+ Klensin Standards Track [Page 24]
3190+
3191+ RFC 5321 SMTP October 2008
3192+
3193+
3194+ and people, addresses SHOULD appear in pointed brackets. When
3195+ addresses, rather than free-form debugging information, are returned,
3196+ EXPN and VRFY MUST return only valid domain addresses that are usable
3197+ in SMTP RCPT commands. Consequently, if an address implies delivery
3198+ to a program or other system, the mailbox name used to reach that
3199+ target MUST be given. Paths (explicit source routes) MUST NOT be
3200+ returned by VRFY or EXPN.
3201+
3202+ Server implementations SHOULD support both VRFY and EXPN. For
3203+ security reasons, implementations MAY provide local installations a
3204+ way to disable either or both of these commands through configuration
3205+ options or the equivalent (see Section 7.3). When these commands are
3206+ supported, they are not required to work across relays when relaying
3207+ is supported. Since they were both optional in RFC 821, but VRFY was
3208+ made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be
3209+ listed as a service extension in an EHLO response. VRFY MAY be
3210+ listed as a convenience but, since support for it is required, SMTP
3211+ clients are not required to check for its presence on the extension
3212+ list before using it.
3213+
3214+ 3.5.3. Meaning of VRFY or EXPN Success Response
3215+
3216+ A server MUST NOT return a 250 code in response to a VRFY or EXPN
3217+ command unless it has actually verified the address. In particular,
3218+ a server MUST NOT return 250 if all it has done is to verify that the
3219+ syntax given is valid. In that case, 502 (Command not implemented)
3220+ or 500 (Syntax error, command unrecognized) SHOULD be returned. As
3221+ stated elsewhere, implementation (in the sense of actually validating
3222+ addresses and returning information) of VRFY and EXPN are strongly
3223+ recommended. Hence, implementations that return 500 or 502 for VRFY
3224+ are not in full compliance with this specification.
3225+
3226+ There may be circumstances where an address appears to be valid but
3227+ cannot reasonably be verified in real time, particularly when a
3228+ server is acting as a mail exchanger for another server or domain.
3229+ "Apparent validity", in this case, would normally involve at least
3230+ syntax checking and might involve verification that any domains
3231+ specified were ones to which the host expected to be able to relay
3232+ mail. In these situations, reply code 252 SHOULD be returned. These
3233+ cases parallel the discussion of RCPT verification in Section 2.1.
3234+ Similarly, the discussion in Section 3.4 applies to the use of reply
3235+ codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are
3236+ recognized but that would be forwarded or rejected were mail received
3237+ for them. Implementations generally SHOULD be more aggressive about
3238+ address verification in the case of VRFY than in the case of RCPT,
3239+ even if it takes a little longer to do so.
3240+
3241+
3242+
3243+
3244+
3245+ Klensin Standards Track [Page 25]
3246+
3247+ RFC 5321 SMTP October 2008
3248+
3249+
3250+ 3.5.4. Semantics and Applications of EXPN
3251+
3252+ EXPN is often very useful in debugging and understanding problems
3253+ with mailing lists and multiple-target-address aliases. Some systems
3254+ have attempted to use source expansion of mailing lists as a means of
3255+ eliminating duplicates. The propagation of aliasing systems with
3256+ mail on the Internet for hosts (typically with MX and CNAME DNS
3257+ records), for mailboxes (various types of local host aliases), and in
3258+ various proxying arrangements has made it nearly impossible for these
3259+ strategies to work consistently, and mail systems SHOULD NOT attempt
3260+ them.
3261+
3262+ 3.6. Relaying and Mail Routing
3263+
3264+ 3.6.1. Source Routes and Relaying
3265+
3266+ In general, the availability of Mail eXchanger records in the domain
3267+ name system (RFC 1035 [2], RFC 974 [12]) makes the use of explicit
3268+ source routes in the Internet mail system unnecessary. Many
3269+ historical problems with the interpretation of explicit source routes
3270+ have made their use undesirable. SMTP clients SHOULD NOT generate
3271+ explicit source routes except under unusual circumstances. SMTP
3272+ servers MAY decline to act as mail relays or to accept addresses that
3273+ specify source routes. When route information is encountered, SMTP
3274+ servers MAY ignore the route information and simply send to the final
3275+ destination specified as the last element in the route and SHOULD do
3276+ so. There has been an invalid practice of using names that do not
3277+ appear in the DNS as destination names, with the senders counting on
3278+ the intermediate hosts specified in source routing to resolve any
3279+ problems. If source routes are stripped, this practice will cause
3280+ failures. This is one of several reasons why SMTP clients MUST NOT
3281+ generate invalid source routes or depend on serial resolution of
3282+ names.
3283+
3284+ When source routes are not used, the process described in RFC 821 for
3285+ constructing a reverse-path from the forward-path is not applicable
3286+ and the reverse-path at the time of delivery will simply be the
3287+ address that appeared in the MAIL command.
3288+
3289+ 3.6.2. Mail eXchange Records and Relaying
3290+
3291+ A relay SMTP server is usually the target of a DNS MX record that
3292+ designates it, rather than the final delivery system. The relay
3293+ server may accept or reject the task of relaying the mail in the same
3294+ way it accepts or rejects mail for a local user. If it accepts the
3295+ task, it then becomes an SMTP client, establishes a transmission
3296+ channel to the next SMTP server specified in the DNS (according to
3297+ the rules in Section 5), and sends it the mail. If it declines to
3298+
3299+
3300+
3301+ Klensin Standards Track [Page 26]
3302+
3303+ RFC 5321 SMTP October 2008
3304+
3305+
3306+ relay mail to a particular address for policy reasons, a 550 response
3307+ SHOULD be returned.
3308+
3309+ This specification does not deal with the verification of return
3310+ paths for use in delivery notifications. Recent work, such as that
3311+ on SPF [29] and DKIM [30] [31], has been done to provide ways to
3312+ ascertain that an address is valid or belongs to the person who
3313+ actually sent the message. A server MAY attempt to verify the return
3314+ path before using its address for delivery notifications, but methods
3315+ of doing so are not defined here nor is any particular method
3316+ recommended at this time.
3317+
3318+ 3.6.3. Message Submission Servers as Relays
3319+
3320+ Many mail-sending clients exist, especially in conjunction with
3321+ facilities that receive mail via POP3 or IMAP, that have limited
3322+ capability to support some of the requirements of this specification,
3323+ such as the ability to queue messages for subsequent delivery
3324+ attempts. For these clients, it is common practice to make private
3325+ arrangements to send all messages to a single server for processing
3326+ and subsequent distribution. SMTP, as specified here, is not ideally
3327+ suited for this role. A standardized mail submission protocol has
3328+ been developed that is gradually superseding practices based on SMTP
3329+ (see RFC 4409 [18]). In any event, because these arrangements are
3330+ private and fall outside the scope of this specification, they are
3331+ not described here.
3332+
3333+ It is important to note that MX records can point to SMTP servers
3334+ that act as gateways into other environments, not just SMTP relays
3335+ and final delivery systems; see Sections 3.7 and 5.
3336+
3337+ If an SMTP server has accepted the task of relaying the mail and
3338+ later finds that the destination is incorrect or that the mail cannot
3339+ be delivered for some other reason, then it MUST construct an
3340+ "undeliverable mail" notification message and send it to the
3341+ originator of the undeliverable mail (as indicated by the reverse-
3342+ path). Formats specified for non-delivery reports by other standards
3343+ (see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if
3344+ possible.
3345+
3346+ This notification message must be from the SMTP server at the relay
3347+ host or the host that first determines that delivery cannot be
3348+ accomplished. Of course, SMTP servers MUST NOT send notification
3349+ messages about problems transporting notification messages. One way
3350+ to prevent loops in error reporting is to specify a null reverse-path
3351+ in the MAIL command of a notification message. When such a message
3352+ is transmitted, the reverse-path MUST be set to null (see
3353+
3354+
3355+
3356+
3357+ Klensin Standards Track [Page 27]
3358+
3359+ RFC 5321 SMTP October 2008
3360+
3361+
3362+ Section 4.5.5 for additional discussion). A MAIL command with a null
3363+ reverse-path appears as follows:
3364+
3365+ MAIL FROM:<>
3366+
3367+ As discussed in Section 6.4, a relay SMTP has no need to inspect or
3368+ act upon the header section or body of the message data and MUST NOT
3369+ do so except to add its own "Received:" header field (Section 4.4)
3370+ and, optionally, to attempt to detect looping in the mail system (see
3371+ Section 6.3). Of course, this prohibition also applies to any
3372+ modifications of these header fields or text (see also Section 7.9).
3373+
3374+ 3.7. Mail Gatewaying
3375+
3376+ While the relay function discussed above operates within the Internet
3377+ SMTP transport service environment, MX records or various forms of
3378+ explicit routing may require that an intermediate SMTP server perform
3379+ a translation function between one transport service and another. As
3380+ discussed in Section 2.3.10, when such a system is at the boundary
3381+ between two transport service environments, we refer to it as a
3382+ "gateway" or "gateway SMTP".
3383+
3384+ Gatewaying mail between different mail environments, such as
3385+ different mail formats and protocols, is complex and does not easily
3386+ yield to standardization. However, some general requirements may be
3387+ given for a gateway between the Internet and another mail
3388+ environment.
3389+
3390+ 3.7.1. Header Fields in Gatewaying
3391+
3392+ Header fields MAY be rewritten when necessary as messages are
3393+ gatewayed across mail environment boundaries. This may involve
3394+ inspecting the message body or interpreting the local-part of the
3395+ destination address in spite of the prohibitions in Section 6.4.
3396+
3397+ Other mail systems gatewayed to the Internet often use a subset of
3398+ the RFC 822 header section or provide similar functionality with a
3399+ different syntax, but some of these mail systems do not have an
3400+ equivalent to the SMTP envelope. Therefore, when a message leaves
3401+ the Internet environment, it may be necessary to fold the SMTP
3402+ envelope information into the message header section. A possible
3403+ solution would be to create new header fields to carry the envelope
3404+ information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this
3405+ would require changes in mail programs in foreign environments and
3406+ might risk disclosure of private information (see Section 7.2).
3407+
3408+
3409+
3410+
3411+
3412+
3413+ Klensin Standards Track [Page 28]
3414+
3415+ RFC 5321 SMTP October 2008
3416+
3417+
3418+ 3.7.2. Received Lines in Gatewaying
3419+
3420+ When forwarding a message into or out of the Internet environment, a
3421+ gateway MUST prepend a Received: line, but it MUST NOT alter in any
3422+ way a Received: line that is already in the header section.
3423+
3424+ "Received:" header fields of messages originating from other
3425+ environments may not conform exactly to this specification. However,
3426+ the most important use of Received: lines is for debugging mail
3427+ faults, and this debugging can be severely hampered by well-meaning
3428+ gateways that try to "fix" a Received: line. As another consequence
3429+ of trace header fields arising in non-SMTP environments, receiving
3430+ systems MUST NOT reject mail based on the format of a trace header
3431+ field and SHOULD be extremely robust in the light of unexpected
3432+ information or formats in those header fields.
3433+
3434+ The gateway SHOULD indicate the environment and protocol in the "via"
3435+ clauses of Received header field(s) that it supplies.
3436+
3437+ 3.7.3. Addresses in Gatewaying
3438+
3439+ From the Internet side, the gateway SHOULD accept all valid address
3440+ formats in SMTP commands and in the RFC 822 header section, and all
3441+ valid RFC 822 messages. Addresses and header fields generated by
3442+ gateways MUST conform to applicable standards (including this one and
3443+ RFC 5322 [4]). Gateways are, of course, subject to the same rules
3444+ for handling source routes as those described for other SMTP systems
3445+ in Section 3.3.
3446+
3447+ 3.7.4. Other Header Fields in Gatewaying
3448+
3449+ The gateway MUST ensure that all header fields of a message that it
3450+ forwards into the Internet mail environment meet the requirements for
3451+ Internet mail. In particular, all addresses in "From:", "To:",
3452+ "Cc:", etc., header fields MUST be transformed (if necessary) to
3453+ satisfy the standard header syntax of RFC 5322 [4], MUST reference
3454+ only fully-qualified domain names, and MUST be effective and useful
3455+ for sending replies. The translation algorithm used to convert mail
3456+ from the Internet protocols to another environment's protocol SHOULD
3457+ ensure that error messages from the foreign mail environment are
3458+ delivered to the reverse-path from the SMTP envelope, not to an
3459+ address in the "From:", "Sender:", or similar header fields of the
3460+ message.
3461+
3462+
3463+
3464+
3465+
3466+
3467+
3468+
3469+ Klensin Standards Track [Page 29]
3470+
3471+ RFC 5321 SMTP October 2008
3472+
3473+
3474+ 3.7.5. Envelopes in Gatewaying
3475+
3476+ Similarly, when forwarding a message from another environment into
3477+ the Internet, the gateway SHOULD set the envelope return path in
3478+ accordance with an error message return address, if supplied by the
3479+ foreign environment. If the foreign environment has no equivalent
3480+ concept, the gateway must select and use a best approximation, with
3481+ the message originator's address as the default of last resort.
3482+
3483+ 3.8. Terminating Sessions and Connections
3484+
3485+ An SMTP connection is terminated when the client sends a QUIT
3486+ command. The server responds with a positive reply code, after which
3487+ it closes the connection.
3488+
3489+ An SMTP server MUST NOT intentionally close the connection under
3490+ normal operational circumstances (see Section 7.8) except:
3491+
3492+ o After receiving a QUIT command and responding with a 221 reply.
3493+
3494+ o After detecting the need to shut down the SMTP service and
3495+ returning a 421 response code. This response code can be issued
3496+ after the server receives any command or, if necessary,
3497+ asynchronously from command receipt (on the assumption that the
3498+ client will receive it after the next command is issued).
3499+
3500+ o After a timeout, as specified in Section 4.5.3.2, occurs waiting
3501+ for the client to send a command or data.
3502+
3503+ In particular, a server that closes connections in response to
3504+ commands that are not understood is in violation of this
3505+ specification. Servers are expected to be tolerant of unknown
3506+ commands, issuing a 500 reply and awaiting further instructions from
3507+ the client.
3508+
3509+ An SMTP server that is forcibly shut down via external means SHOULD
3510+ attempt to send a line containing a 421 response code to the SMTP
3511+ client before exiting. The SMTP client will normally read the 421
3512+ response code after sending its next command.
3513+
3514+ SMTP clients that experience a connection close, reset, or other
3515+ communications failure due to circumstances not under their control
3516+ (in violation of the intent of this specification but sometimes
3517+ unavoidable) SHOULD, to maintain the robustness of the mail system,
3518+ treat the mail transaction as if a 451 response had been received and
3519+ act accordingly.
3520+
3521+
3522+
3523+
3524+
3525+ Klensin Standards Track [Page 30]
3526+
3527+ RFC 5321 SMTP October 2008
3528+
3529+
3530+ 3.9. Mailing Lists and Aliases
3531+
3532+ An SMTP-capable host SHOULD support both the alias and the list
3533+ models of address expansion for multiple delivery. When a message is
3534+ delivered or forwarded to each address of an expanded list form, the
3535+ return address in the envelope ("MAIL FROM:") MUST be changed to be
3536+ the address of a person or other entity who administers the list.
3537+ However, in this case, the message header section (RFC 5322 [4]) MUST
3538+ be left unchanged; in particular, the "From" field of the header
3539+ section is unaffected.
3540+
3541+ An important mail facility is a mechanism for multi-destination
3542+ delivery of a single message, by transforming (or "expanding" or
3543+ "exploding") a pseudo-mailbox address into a list of destination
3544+ mailbox addresses. When a message is sent to such a pseudo-mailbox
3545+ (sometimes called an "exploder"), copies are forwarded or
3546+ redistributed to each mailbox in the expanded list. Servers SHOULD
3547+ simply utilize the addresses on the list; application of heuristics
3548+ or other matching rules to eliminate some addresses, such as that of
3549+ the originator, is strongly discouraged. We classify such a pseudo-
3550+ mailbox as an "alias" or a "list", depending upon the expansion
3551+ rules.
3552+
3553+ 3.9.1. Alias
3554+
3555+ To expand an alias, the recipient mailer simply replaces the pseudo-
3556+ mailbox address in the envelope with each of the expanded addresses
3557+ in turn; the rest of the envelope and the message body are left
3558+ unchanged. The message is then delivered or forwarded to each
3559+ expanded address.
3560+
3561+ 3.9.2. List
3562+
3563+ A mailing list may be said to operate by "redistribution" rather than
3564+ by "forwarding". To expand a list, the recipient mailer replaces the
3565+ pseudo-mailbox address in the envelope with each of the expanded
3566+ addresses in turn. The return (backward-pointing) address in the
3567+ envelope is changed so that all error messages generated by the final
3568+ deliveries will be returned to a list administrator, not to the
3569+ message originator, who generally has no control over the contents of
3570+ the list and will typically find error messages annoying. Note that
3571+ the key difference between handling aliases (Section 3.9.1) and
3572+ forwarding (this subsection) is the change to the backward-pointing
3573+ address in this case. When a list constrains its processing to the
3574+ very limited set of modifications and actions described here, it is
3575+ attempting to emulate an MTA; such lists can be treated as a
3576+ continuation in email transit.
3577+
3578+
3579+
3580+
3581+ Klensin Standards Track [Page 31]
3582+
3583+ RFC 5321 SMTP October 2008
3584+
3585+
3586+ There exist mailing lists that perform additional, sometimes
3587+ extensive, modifications to a message and its envelope. Such mailing
3588+ lists need to be viewed as full MUAs, which accept a delivery and
3589+ post a new message.
3590+
3591+ 4. The SMTP Specifications
3592+
3593+ 4.1. SMTP Commands
3594+
3595+ 4.1.1. Command Semantics and Syntax
3596+
3597+ The SMTP commands define the mail transfer or the mail system
3598+ function requested by the user. SMTP commands are character strings
3599+ terminated by <CRLF>. The commands themselves are alphabetic
3600+ characters terminated by <SP> if parameters follow and <CRLF>
3601+ otherwise. (In the interest of improved interoperability, SMTP
3602+ receivers SHOULD tolerate trailing white space before the terminating
3603+ <CRLF>.) The syntax of the local part of a mailbox MUST conform to
3604+ receiver site conventions and the syntax specified in Section 4.1.2.
3605+ The SMTP commands are discussed below. The SMTP replies are
3606+ discussed in Section 4.2.
3607+
3608+ A mail transaction involves several data objects that are
3609+ communicated as arguments to different commands. The reverse-path is
3610+ the argument of the MAIL command, the forward-path is the argument of
3611+ the RCPT command, and the mail data is the argument of the DATA
3612+ command. These arguments or data objects must be transmitted and
3613+ held, pending the confirmation communicated by the end of mail data
3614+ indication that finalizes the transaction. The model for this is
3615+ that distinct buffers are provided to hold the types of data objects;
3616+ that is, there is a reverse-path buffer, a forward-path buffer, and a
3617+ mail data buffer. Specific commands cause information to be appended
3618+ to a specific buffer, or cause one or more buffers to be cleared.
3619+
3620+ Several commands (RSET, DATA, QUIT) are specified as not permitting
3621+ parameters. In the absence of specific extensions offered by the
3622+ server and accepted by the client, clients MUST NOT send such
3623+ parameters and servers SHOULD reject commands containing them as
3624+ having invalid syntax.
3625+
3626+ 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
3627+
3628+ These commands are used to identify the SMTP client to the SMTP
3629+ server. The argument clause contains the fully-qualified domain name
3630+ of the SMTP client, if one is available. In situations in which the
3631+ SMTP client system does not have a meaningful domain name (e.g., when
3632+ its address is dynamically allocated and no reverse mapping record is
3633+
3634+
3635+
3636+
3637+ Klensin Standards Track [Page 32]
3638+
3639+ RFC 5321 SMTP October 2008
3640+
3641+
3642+ available), the client SHOULD send an address literal (see
3643+ Section 4.1.3).
3644+
3645+ RFC 2821, and some earlier informal practices, encouraged following
3646+ the literal by information that would help to identify the client
3647+ system. That convention was not widely supported, and many SMTP
3648+ servers considered it an error. In the interest of interoperability,
3649+ it is probably wise for servers to be prepared for this string to
3650+ occur, but SMTP clients SHOULD NOT send it.
3651+
3652+ The SMTP server identifies itself to the SMTP client in the
3653+ connection greeting reply and in the response to this command.
3654+
3655+ A client SMTP SHOULD start an SMTP session by issuing the EHLO
3656+ command. If the SMTP server supports the SMTP service extensions, it
3657+ will give a successful response, a failure response, or an error
3658+ response. If the SMTP server, in violation of this specification,
3659+ does not support any SMTP service extensions, it will generate an
3660+ error response. Older client SMTP systems MAY, as discussed above,
3661+ use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
3662+ support the HELO command and reply properly to it. In any event, a
3663+ client MUST issue HELO or EHLO before starting a mail transaction.
3664+
3665+ These commands, and a "250 OK" reply to one of them, confirm that
3666+ both the SMTP client and the SMTP server are in the initial state,
3667+ that is, there is no transaction in progress and all state tables and
3668+ buffers are cleared.
3669+
3670+ Syntax:
3671+
3672+ ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
3673+
3674+ helo = "HELO" SP Domain CRLF
3675+
3676+ Normally, the response to EHLO will be a multiline reply. Each line
3677+ of the response contains a keyword and, optionally, one or more
3678+ parameters. Following the normal syntax for multiline replies, these
3679+ keywords follow the code (250) and a hyphen for all but the last
3680+ line, and the code and a space for the last line. The syntax for a
3681+ positive response, using the ABNF notation and terminal symbols of
3682+ RFC 5234 [7], is:
3683+
3684+ ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
3685+ / ( "250-" Domain [ SP ehlo-greet ] CRLF
3686+ *( "250-" ehlo-line CRLF )
3687+ "250" SP ehlo-line CRLF )
3688+
3689+
3690+
3691+
3692+
3693+ Klensin Standards Track [Page 33]
3694+
3695+ RFC 5321 SMTP October 2008
3696+
3697+
3698+ ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
3699+ ; string of any characters other than CR or LF
3700+
3701+ ehlo-line = ehlo-keyword *( SP ehlo-param )
3702+
3703+ ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
3704+ ; additional syntax of ehlo-params depends on
3705+ ; ehlo-keyword
3706+
3707+ ehlo-param = 1*(%d33-126)
3708+ ; any CHAR excluding <SP> and all
3709+ ; control characters (US-ASCII 0-31 and 127
3710+ ; inclusive)
3711+
3712+ Although EHLO keywords may be specified in upper, lower, or mixed
3713+ case, they MUST always be recognized and processed in a case-
3714+ insensitive manner. This is simply an extension of practices
3715+ specified in RFC 821 and Section 2.4.
3716+
3717+ The EHLO response MUST contain keywords (and associated parameters if
3718+ required) for all commands not listed as "required" in Section 4.5.1
3719+ excepting only private-use commands as described in Section 4.1.5.
3720+ Private-use commands MAY be listed.
3721+
3722+ 4.1.1.2. MAIL (MAIL)
3723+
3724+ This command is used to initiate a mail transaction in which the mail
3725+ data is delivered to an SMTP server that may, in turn, deliver it to
3726+ one or more mailboxes or pass it on to another system (possibly using
3727+ SMTP). The argument clause contains a reverse-path and may contain
3728+ optional parameters. In general, the MAIL command may be sent only
3729+ when no mail transaction is in progress, see Section 4.1.4.
3730+
3731+ The reverse-path consists of the sender mailbox. Historically, that
3732+ mailbox might optionally have been preceded by a list of hosts, but
3733+ that behavior is now deprecated (see Appendix C). In some types of
3734+ reporting messages for which a reply is likely to cause a mail loop
3735+ (for example, mail delivery and non-delivery notifications), the
3736+ reverse-path may be null (see Section 3.6).
3737+
3738+ This command clears the reverse-path buffer, the forward-path buffer,
3739+ and the mail data buffer, and it inserts the reverse-path information
3740+ from its argument clause into the reverse-path buffer.
3741+
3742+ If service extensions were negotiated, the MAIL command may also
3743+ carry parameters associated with a particular service extension.
3744+
3745+
3746+
3747+
3748+
3749+ Klensin Standards Track [Page 34]
3750+
3751+ RFC 5321 SMTP October 2008
3752+
3753+
3754+ Syntax:
3755+
3756+ mail = "MAIL FROM:" Reverse-path
3757+ [SP Mail-parameters] CRLF
3758+
3759+ 4.1.1.3. RECIPIENT (RCPT)
3760+
3761+ This command is used to identify an individual recipient of the mail
3762+ data; multiple recipients are specified by multiple uses of this
3763+ command. The argument clause contains a forward-path and may contain
3764+ optional parameters.
3765+
3766+ The forward-path normally consists of the required destination
3767+ mailbox. Sending systems SHOULD NOT generate the optional list of
3768+ hosts known as a source route. Receiving systems MUST recognize
3769+ source route syntax but SHOULD strip off the source route
3770+ specification and utilize the domain name associated with the mailbox
3771+ as if the source route had not been provided.
3772+
3773+ Similarly, relay hosts SHOULD strip or ignore source routes, and
3774+ names MUST NOT be copied into the reverse-path. When mail reaches
3775+ its ultimate destination (the forward-path contains only a
3776+ destination mailbox), the SMTP server inserts it into the destination
3777+ mailbox in accordance with its host mail conventions.
3778+
3779+ This command appends its forward-path argument to the forward-path
3780+ buffer; it does not change the reverse-path buffer nor the mail data
3781+ buffer.
3782+
3783+ For example, mail received at relay host xyz.com with envelope
3784+ commands
3785+
3786+ MAIL FROM:<userx@y.foo.org>
3787+ RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
3788+
3789+ will normally be sent directly on to host d.bar.org with envelope
3790+ commands
3791+
3792+ MAIL FROM:<userx@y.foo.org>
3793+ RCPT TO:<userc@d.bar.org>
3794+
3795+ As provided in Appendix C, xyz.com MAY also choose to relay the
3796+ message to hosta.int, using the envelope commands
3797+
3798+ MAIL FROM:<userx@y.foo.org>
3799+ RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
3800+
3801+
3802+
3803+
3804+
3805+ Klensin Standards Track [Page 35]
3806+
3807+ RFC 5321 SMTP October 2008
3808+
3809+
3810+ or to jkl.org, using the envelope commands
3811+
3812+ MAIL FROM:<userx@y.foo.org>
3813+ RCPT TO:<@jkl.org:userc@d.bar.org>
3814+
3815+ Attempting to use relaying this way is now strongly discouraged.
3816+ Since hosts are not required to relay mail at all, xyz.com MAY also
3817+ reject the message entirely when the RCPT command is received, using
3818+ a 550 code (since this is a "policy reason").
3819+
3820+ If service extensions were negotiated, the RCPT command may also
3821+ carry parameters associated with a particular service extension
3822+ offered by the server. The client MUST NOT transmit parameters other
3823+ than those associated with a service extension offered by the server
3824+ in its EHLO response.
3825+
3826+ Syntax:
3827+
3828+ rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
3829+ Forward-path ) [SP Rcpt-parameters] CRLF
3830+
3831+ Note that, in a departure from the usual rules for
3832+ local-parts, the "Postmaster" string shown above is
3833+ treated as case-insensitive.
3834+
3835+ 4.1.1.4. DATA (DATA)
3836+
3837+ The receiver normally sends a 354 response to DATA, and then treats
3838+ the lines (strings ending in <CRLF> sequences, as described in
3839+ Section 2.3.7) following the command as mail data from the sender.
3840+ This command causes the mail data to be appended to the mail data
3841+ buffer. The mail data may contain any of the 128 ASCII character
3842+ codes, although experience has indicated that use of control
3843+ characters other than SP, HT, CR, and LF may cause problems and
3844+ SHOULD be avoided when possible.
3845+
3846+ The mail data are terminated by a line containing only a period, that
3847+ is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is
3848+ actually the terminator of the previous line (see Section 4.5.2).
3849+ This is the end of mail data indication. The first <CRLF> of this
3850+ terminating sequence is also the <CRLF> that ends the final line of
3851+ the data (message text) or, if there was no mail data, ends the DATA
3852+ command itself (the "no mail data" case does not conform to this
3853+ specification since it would require that neither the trace header
3854+ fields required by this specification nor the message header section
3855+ required by RFC 5322 [4] be transmitted). An extra <CRLF> MUST NOT
3856+ be added, as that would cause an empty line to be added to the
3857+ message. The only exception to this rule would arise if the message
3858+
3859+
3860+
3861+ Klensin Standards Track [Page 36]
3862+
3863+ RFC 5321 SMTP October 2008
3864+
3865+
3866+ body were passed to the originating SMTP-sender with a final "line"
3867+ that did not end in <CRLF>; in that case, the originating SMTP system
3868+ MUST either reject the message as invalid or add <CRLF> in order to
3869+ have the receiving SMTP server recognize the "end of data" condition.
3870+
3871+ The custom of accepting lines ending only in <LF>, as a concession to
3872+ non-conforming behavior on the part of some UNIX systems, has proven
3873+ to cause more interoperability problems than it solves, and SMTP
3874+ server systems MUST NOT do this, even in the name of improved
3875+ robustness. In particular, the sequence "<LF>.<LF>" (bare line
3876+ feeds, without carriage returns) MUST NOT be treated as equivalent to
3877+ <CRLF>.<CRLF> as the end of mail data indication.
3878+
3879+ Receipt of the end of mail data indication requires the server to
3880+ process the stored mail transaction information. This processing
3881+ consumes the information in the reverse-path buffer, the forward-path
3882+ buffer, and the mail data buffer, and on the completion of this
3883+ command these buffers are cleared. If the processing is successful,
3884+ the receiver MUST send an OK reply. If the processing fails, the
3885+ receiver MUST send a failure reply. The SMTP model does not allow
3886+ for partial failures at this point: either the message is accepted by
3887+ the server for delivery and a positive response is returned or it is
3888+ not accepted and a failure reply is returned. In sending a positive
3889+ "250 OK" completion reply to the end of data indication, the receiver
3890+ takes full responsibility for the message (see Section 6.1). Errors
3891+ that are diagnosed subsequently MUST be reported in a mail message,
3892+ as discussed in Section 4.4.
3893+
3894+ When the SMTP server accepts a message either for relaying or for
3895+ final delivery, it inserts a trace record (also referred to
3896+ interchangeably as a "time stamp line" or "Received" line) at the top
3897+ of the mail data. This trace record indicates the identity of the
3898+ host that sent the message, the identity of the host that received
3899+ the message (and is inserting this time stamp), and the date and time
3900+ the message was received. Relayed messages will have multiple time
3901+ stamp lines. Details for formation of these lines, including their
3902+ syntax, is specified in Section 4.4.
3903+
3904+ Additional discussion about the operation of the DATA command appears
3905+ in Section 3.3.
3906+
3907+ Syntax:
3908+
3909+ data = "DATA" CRLF
3910+
3911+
3912+
3913+
3914+
3915+
3916+
3917+ Klensin Standards Track [Page 37]
3918+
3919+ RFC 5321 SMTP October 2008
3920+
3921+
3922+ 4.1.1.5. RESET (RSET)
3923+
3924+ This command specifies that the current mail transaction will be
3925+ aborted. Any stored sender, recipients, and mail data MUST be
3926+ discarded, and all buffers and state tables cleared. The receiver
3927+ MUST send a "250 OK" reply to a RSET command with no arguments. A
3928+ reset command may be issued by the client at any time. It is
3929+ effectively equivalent to a NOOP (i.e., it has no effect) if issued
3930+ immediately after EHLO, before EHLO is issued in the session, after
3931+ an end of data indicator has been sent and acknowledged, or
3932+ immediately before a QUIT. An SMTP server MUST NOT close the
3933+ connection as the result of receiving a RSET; that action is reserved
3934+ for QUIT (see Section 4.1.1.10).
3935+
3936+ Since EHLO implies some additional processing and response by the
3937+ server, RSET will normally be more efficient than reissuing that
3938+ command, even though the formal semantics are the same.
3939+
3940+ There are circumstances, contrary to the intent of this
3941+ specification, in which an SMTP server may receive an indication that
3942+ the underlying TCP connection has been closed or reset. To preserve
3943+ the robustness of the mail system, SMTP servers SHOULD be prepared
3944+ for this condition and SHOULD treat it as if a QUIT had been received
3945+ before the connection disappeared.
3946+
3947+ Syntax:
3948+
3949+ rset = "RSET" CRLF
3950+
3951+ 4.1.1.6. VERIFY (VRFY)
3952+
3953+ This command asks the receiver to confirm that the argument
3954+ identifies a user or mailbox. If it is a user name, information is
3955+ returned as specified in Section 3.5.
3956+
3957+ This command has no effect on the reverse-path buffer, the forward-
3958+ path buffer, or the mail data buffer.
3959+
3960+ Syntax:
3961+
3962+ vrfy = "VRFY" SP String CRLF
3963+
3964+
3965+
3966+
3967+
3968+
3969+
3970+
3971+
3972+
3973+ Klensin Standards Track [Page 38]
3974+
3975+ RFC 5321 SMTP October 2008
3976+
3977+
3978+ 4.1.1.7. EXPAND (EXPN)
3979+
3980+ This command asks the receiver to confirm that the argument
3981+ identifies a mailing list, and if so, to return the membership of
3982+ that list. If the command is successful, a reply is returned
3983+ containing information as described in Section 3.5. This reply will
3984+ have multiple lines except in the trivial case of a one-member list.
3985+
3986+ This command has no effect on the reverse-path buffer, the forward-
3987+ path buffer, or the mail data buffer, and it may be issued at any
3988+ time.
3989+
3990+ Syntax:
3991+
3992+ expn = "EXPN" SP String CRLF
3993+
3994+ 4.1.1.8. HELP (HELP)
3995+
3996+ This command causes the server to send helpful information to the
3997+ client. The command MAY take an argument (e.g., any command name)
3998+ and return more specific information as a response.
3999+
4000+ This command has no effect on the reverse-path buffer, the forward-
4001+ path buffer, or the mail data buffer, and it may be issued at any
4002+ time.
4003+
4004+ SMTP servers SHOULD support HELP without arguments and MAY support it
4005+ with arguments.
4006+
4007+ Syntax:
4008+
4009+ help = "HELP" [ SP String ] CRLF
4010+
4011+
4012+
4013+
4014+
4015+
4016+
4017+
4018+
4019+
4020+
4021+
4022+
4023+
4024+
4025+
4026+
4027+
4028+
4029+ Klensin Standards Track [Page 39]
4030+
4031+ RFC 5321 SMTP October 2008
4032+
4033+
4034+ 4.1.1.9. NOOP (NOOP)
4035+
4036+ This command does not affect any parameters or previously entered
4037+ commands. It specifies no action other than that the receiver send a
4038+ "250 OK" reply.
4039+
4040+ This command has no effect on the reverse-path buffer, the forward-
4041+ path buffer, or the mail data buffer, and it may be issued at any
4042+ time. If a parameter string is specified, servers SHOULD ignore it.
4043+
4044+ Syntax:
4045+
4046+ noop = "NOOP" [ SP String ] CRLF
4047+
4048+ 4.1.1.10. QUIT (QUIT)
4049+
4050+ This command specifies that the receiver MUST send a "221 OK" reply,
4051+ and then close the transmission channel.
4052+
4053+ The receiver MUST NOT intentionally close the transmission channel
4054+ until it receives and replies to a QUIT command (even if there was an
4055+ error). The sender MUST NOT intentionally close the transmission
4056+ channel until it sends a QUIT command, and it SHOULD wait until it
4057+ receives the reply (even if there was an error response to a previous
4058+ command). If the connection is closed prematurely due to violations
4059+ of the above or system or network failure, the server MUST cancel any
4060+ pending transaction, but not undo any previously completed
4061+ transaction, and generally MUST act as if the command or transaction
4062+ in progress had received a temporary error (i.e., a 4yz response).
4063+
4064+ The QUIT command may be issued at any time. Any current uncompleted
4065+ mail transaction will be aborted.
4066+
4067+ Syntax:
4068+
4069+ quit = "QUIT" CRLF
4070+
4071+ 4.1.1.11. Mail-Parameter and Rcpt-Parameter Error Responses
4072+
4073+ If the server SMTP does not recognize or cannot implement one or more
4074+ of the parameters associated with a particular MAIL FROM or RCPT TO
4075+ command, it will return code 555.
4076+
4077+ If, for some reason, the server is temporarily unable to accommodate
4078+ one or more of the parameters associated with a MAIL FROM or RCPT TO
4079+ command, and if the definition of the specific parameter does not
4080+ mandate the use of another code, it should return code 455.
4081+
4082+
4083+
4084+
4085+ Klensin Standards Track [Page 40]
4086+
4087+ RFC 5321 SMTP October 2008
4088+
4089+
4090+ Errors specific to particular parameters and their values will be
4091+ specified in the parameter's defining RFC.
4092+
4093+ 4.1.2. Command Argument Syntax
4094+
4095+ The syntax of the argument clauses of the above commands (using the
4096+ syntax specified in RFC 5234 [7] where applicable) is given below.
4097+ Some of the productions given below are used only in conjunction with
4098+ source routes as described in Appendix C. Terminals not defined in
4099+ this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined
4100+ in the "core" syntax in Section 6 of RFC 5234 [7] or in the message
4101+ format syntax in RFC 5322 [4].
4102+
4103+ Reverse-path = Path / "<>"
4104+
4105+ Forward-path = Path
4106+
4107+ Path = "<" [ A-d-l ":" ] Mailbox ">"
4108+
4109+ A-d-l = At-domain *( "," At-domain )
4110+ ; Note that this form, the so-called "source
4111+ ; route", MUST BE accepted, SHOULD NOT be
4112+ ; generated, and SHOULD be ignored.
4113+
4114+ At-domain = "@" Domain
4115+
4116+ Mail-parameters = esmtp-param *(SP esmtp-param)
4117+
4118+ Rcpt-parameters = esmtp-param *(SP esmtp-param)
4119+
4120+ esmtp-param = esmtp-keyword ["=" esmtp-value]
4121+
4122+ esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
4123+
4124+ esmtp-value = 1*(%d33-60 / %d62-126)
4125+ ; any CHAR excluding "=", SP, and control
4126+ ; characters. If this string is an email address,
4127+ ; i.e., a Mailbox, then the "xtext" syntax [32]
4128+ ; SHOULD be used.
4129+
4130+ Keyword = Ldh-str
4131+
4132+ Argument = Atom
4133+
4134+ Domain = sub-domain *("." sub-domain)
4135+
4136+
4137+
4138+
4139+
4140+
4141+ Klensin Standards Track [Page 41]
4142+
4143+ RFC 5321 SMTP October 2008
4144+
4145+
4146+ sub-domain = Let-dig [Ldh-str]
4147+
4148+ Let-dig = ALPHA / DIGIT
4149+
4150+ Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
4151+
4152+ address-literal = "[" ( IPv4-address-literal /
4153+ IPv6-address-literal /
4154+ General-address-literal ) "]"
4155+ ; See Section 4.1.3
4156+
4157+ Mailbox = Local-part "@" ( Domain / address-literal )
4158+
4159+ Local-part = Dot-string / Quoted-string
4160+ ; MAY be case-sensitive
4161+
4162+
4163+ Dot-string = Atom *("." Atom)
4164+
4165+ Atom = 1*atext
4166+
4167+ Quoted-string = DQUOTE *QcontentSMTP DQUOTE
4168+
4169+ QcontentSMTP = qtextSMTP / quoted-pairSMTP
4170+
4171+ quoted-pairSMTP = %d92 %d32-126
4172+ ; i.e., backslash followed by any ASCII
4173+ ; graphic (including itself) or SPace
4174+
4175+ qtextSMTP = %d32-33 / %d35-91 / %d93-126
4176+ ; i.e., within a quoted string, any
4177+ ; ASCII graphic or space is permitted
4178+ ; without blackslash-quoting except
4179+ ; double-quote and the backslash itself.
4180+
4181+ String = Atom / Quoted-string
4182+
4183+ While the above definition for Local-part is relatively permissive,
4184+ for maximum interoperability, a host that expects to receive mail
4185+ SHOULD avoid defining mailboxes where the Local-part requires (or
4186+ uses) the Quoted-string form or where the Local-part is case-
4187+ sensitive. For any purposes that require generating or comparing
4188+ Local-parts (e.g., to specific mailbox names), all quoted forms MUST
4189+ be treated as equivalent, and the sending system SHOULD transmit the
4190+ form that uses the minimum quoting possible.
4191+
4192+ Systems MUST NOT define mailboxes in such a way as to require the use
4193+ in SMTP of non-ASCII characters (octets with the high order bit set
4194+
4195+
4196+
4197+ Klensin Standards Track [Page 42]
4198+
4199+ RFC 5321 SMTP October 2008
4200+
4201+
4202+ to one) or ASCII "control characters" (decimal value 0-31 and 127).
4203+ These characters MUST NOT be used in MAIL or RCPT commands or other
4204+ commands that require mailbox names.
4205+
4206+ Note that the backslash, "\", is a quote character, which is used to
4207+ indicate that the next character is to be used literally (instead of
4208+ its normal interpretation). For example, "Joe\,Smith" indicates a
4209+ single nine-character user name string with the comma being the
4210+ fourth character of that string.
4211+
4212+ To promote interoperability and consistent with long-standing
4213+ guidance about conservative use of the DNS in naming and applications
4214+ (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]),
4215+ characters outside the set of alphabetic characters, digits, and
4216+ hyphen MUST NOT appear in domain name labels for SMTP clients or
4217+ servers. In particular, the underscore character is not permitted.
4218+ SMTP servers that receive a command in which invalid character codes
4219+ have been employed, and for which there are no other reasons for
4220+ rejection, MUST reject that command with a 501 response (this rule,
4221+ like others, could be overridden by appropriate SMTP extensions).
4222+
4223+ 4.1.3. Address Literals
4224+
4225+ Sometimes a host is not known to the domain name system and
4226+ communication (and, in particular, communication to report and repair
4227+ the error) is blocked. To bypass this barrier, a special literal
4228+ form of the address is allowed as an alternative to a domain name.
4229+ For IPv4 addresses, this form uses four small decimal integers
4230+ separated by dots and enclosed by brackets such as [123.255.37.2],
4231+ which indicates an (IPv4) Internet Address in sequence-of-octets
4232+ form. For IPv6 and other forms of addressing that might eventually
4233+ be standardized, the form consists of a standardized "tag" that
4234+ identifies the address syntax, a colon, and the address itself, in a
4235+ format specified as part of the relevant standards (i.e., RFC 4291
4236+ [8] for IPv6).
4237+
4238+ Specifically:
4239+
4240+ IPv4-address-literal = Snum 3("." Snum)
4241+
4242+ IPv6-address-literal = "IPv6:" IPv6-addr
4243+
4244+ General-address-literal = Standardized-tag ":" 1*dcontent
4245+
4246+ Standardized-tag = Ldh-str
4247+ ; Standardized-tag MUST be specified in a
4248+ ; Standards-Track RFC and registered with IANA
4249+
4250+
4251+
4252+
4253+ Klensin Standards Track [Page 43]
4254+
4255+ RFC 5321 SMTP October 2008
4256+
4257+
4258+ dcontent = %d33-90 / ; Printable US-ASCII
4259+ %d94-126 ; excl. "[", "\", "]"
4260+
4261+ Snum = 1*3DIGIT
4262+ ; representing a decimal integer
4263+ ; value in the range 0 through 255
4264+
4265+ IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
4266+
4267+ IPv6-hex = 1*4HEXDIG
4268+
4269+ IPv6-full = IPv6-hex 7(":" IPv6-hex)
4270+
4271+ IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::"
4272+ [IPv6-hex *5(":" IPv6-hex)]
4273+ ; The "::" represents at least 2 16-bit groups of
4274+ ; zeros. No more than 6 groups in addition to the
4275+ ; "::" may be present.
4276+
4277+ IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
4278+
4279+ IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
4280+ [IPv6-hex *3(":" IPv6-hex) ":"]
4281+ IPv4-address-literal
4282+ ; The "::" represents at least 2 16-bit groups of
4283+ ; zeros. No more than 4 groups in addition to the
4284+ ; "::" and IPv4-address-literal may be present.
4285+
4286+ 4.1.4. Order of Commands
4287+
4288+ There are restrictions on the order in which these commands may be
4289+ used.
4290+
4291+ A session that will contain mail transactions MUST first be
4292+ initialized by the use of the EHLO command. An SMTP server SHOULD
4293+ accept commands for non-mail transactions (e.g., VRFY or EXPN)
4294+ without this initialization.
4295+
4296+ An EHLO command MAY be issued by a client later in the session. If
4297+ it is issued after the session begins and the EHLO command is
4298+ acceptable to the SMTP server, the SMTP server MUST clear all buffers
4299+ and reset the state exactly as if a RSET command had been issued. In
4300+ other words, the sequence of RSET followed immediately by EHLO is
4301+ redundant, but not harmful other than in the performance cost of
4302+ executing unnecessary commands.
4303+
4304+ If the EHLO command is not acceptable to the SMTP server, 501, 500,
4305+ 502, or 550 failure replies MUST be returned as appropriate. The
4306+
4307+
4308+
4309+ Klensin Standards Track [Page 44]
4310+
4311+ RFC 5321 SMTP October 2008
4312+
4313+
4314+ SMTP server MUST stay in the same state after transmitting these
4315+ replies that it was in before the EHLO was received.
4316+
4317+ The SMTP client MUST, if possible, ensure that the domain parameter
4318+ to the EHLO command is a primary host name as specified for this
4319+ command in Section 2.3.5. If this is not possible (e.g., when the
4320+ client's address is dynamically assigned and the client does not have
4321+ an obvious name), an address literal SHOULD be substituted for the
4322+ domain name.
4323+
4324+ An SMTP server MAY verify that the domain name argument in the EHLO
4325+ command actually corresponds to the IP address of the client.
4326+ However, if the verification fails, the server MUST NOT refuse to
4327+ accept a message on that basis. Information captured in the
4328+ verification attempt is for logging and tracing purposes. Note that
4329+ this prohibition applies to the matching of the parameter to its IP
4330+ address only; see Section 7.9 for a more extensive discussion of
4331+ rejecting incoming connections or mail messages.
4332+
4333+ The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
4334+ during a session, or without previously initializing a session. SMTP
4335+ servers SHOULD process these normally (that is, not return a 503
4336+ code) even if no EHLO command has yet been received; clients SHOULD
4337+ open a session with EHLO before sending these commands.
4338+
4339+ If these rules are followed, the example in RFC 821 that shows "550
4340+ access denied to you" in response to an EXPN command is incorrect
4341+ unless an EHLO command precedes the EXPN or the denial of access is
4342+ based on the client's IP address or other authentication or
4343+ authorization-determining mechanisms.
4344+
4345+ The MAIL command (or the obsolete SEND, SOML, or SAML commands)
4346+ begins a mail transaction. Once started, a mail transaction consists
4347+ of a transaction beginning command, one or more RCPT commands, and a
4348+ DATA command, in that order. A mail transaction may be aborted by
4349+ the RSET, a new EHLO, or the QUIT command. There may be zero or more
4350+ transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be
4351+ sent if a mail transaction is already open, i.e., it should be sent
4352+ only if no mail transaction had been started in the session, or if
4353+ the previous one successfully concluded with a successful DATA
4354+ command, or if the previous one was aborted, e.g., with a RSET or new
4355+ EHLO.
4356+
4357+ If the transaction beginning command argument is not acceptable, a
4358+ 501 failure reply MUST be returned and the SMTP server MUST stay in
4359+ the same state. If the commands in a transaction are out of order to
4360+ the degree that they cannot be processed by the server, a 503 failure
4361+
4362+
4363+
4364+
4365+ Klensin Standards Track [Page 45]
4366+
4367+ RFC 5321 SMTP October 2008
4368+
4369+
4370+ reply MUST be returned and the SMTP server MUST stay in the same
4371+ state.
4372+
4373+ The last command in a session MUST be the QUIT command. The QUIT
4374+ command SHOULD be used by the client SMTP to request connection
4375+ closure, even when no session opening command was sent and accepted.
4376+
4377+ 4.1.5. Private-Use Commands
4378+
4379+ As specified in Section 2.2.2, commands starting in "X" may be used
4380+ by bilateral agreement between the client (sending) and server
4381+ (receiving) SMTP agents. An SMTP server that does not recognize such
4382+ a command is expected to reply with "500 Command not recognized". An
4383+ extended SMTP server MAY list the feature names associated with these
4384+ private commands in the response to the EHLO command.
4385+
4386+ Commands sent or accepted by SMTP systems that do not start with "X"
4387+ MUST conform to the requirements of Section 2.2.2.
4388+
4389+ 4.2. SMTP Replies
4390+
4391+ Replies to SMTP commands serve to ensure the synchronization of
4392+ requests and actions in the process of mail transfer and to guarantee
4393+ that the SMTP client always knows the state of the SMTP server.
4394+ Every command MUST generate exactly one reply.
4395+
4396+ The details of the command-reply sequence are described in
4397+ Section 4.3.
4398+
4399+ An SMTP reply consists of a three digit number (transmitted as three
4400+ numeric characters) followed by some text unless specified otherwise
4401+ in this document. The number is for use by automata to determine
4402+ what state to enter next; the text is for the human user. The three
4403+ digits contain enough encoded information that the SMTP client need
4404+ not examine the text and may either discard it or pass it on to the
4405+ user, as appropriate. Exceptions are as noted elsewhere in this
4406+ document. In particular, the 220, 221, 251, 421, and 551 reply codes
4407+ are associated with message text that must be parsed and interpreted
4408+ by machines. In the general case, the text may be receiver dependent
4409+ and context dependent, so there are likely to be varying texts for
4410+ each reply code. A discussion of the theory of reply codes is given
4411+ in Section 4.2.1. Formally, a reply is defined to be the sequence: a
4412+ three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
4413+ reply (as defined in the same section). Since, in violation of this
4414+ specification, the text is sometimes not sent, clients that do not
4415+ receive it SHOULD be prepared to process the code alone (with or
4416+ without a trailing space character). Only the EHLO, EXPN, and HELP
4417+ commands are expected to result in multiline replies in normal
4418+
4419+
4420+
4421+ Klensin Standards Track [Page 46]
4422+
4423+ RFC 5321 SMTP October 2008
4424+
4425+
4426+ circumstances; however, multiline replies are allowed for any
4427+ command.
4428+
4429+ In ABNF, server responses are:
4430+
4431+ Greeting = ( "220 " (Domain / address-literal)
4432+ [ SP textstring ] CRLF ) /
4433+ ( "220-" (Domain / address-literal)
4434+ [ SP textstring ] CRLF
4435+ *( "220-" [ textstring ] CRLF )
4436+ "220" [ SP textstring ] CRLF )
4437+
4438+ textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
4439+
4440+ Reply-line = *( Reply-code "-" [ textstring ] CRLF )
4441+ Reply-code [ SP textstring ] CRLF
4442+
4443+ Reply-code = %x32-35 %x30-35 %x30-39
4444+
4445+ where "Greeting" appears only in the 220 response that announces that
4446+ the server is opening its part of the connection. (Other possible
4447+ server responses upon connection follow the syntax of Reply-line.)
4448+
4449+ An SMTP server SHOULD send only the reply codes listed in this
4450+ document. An SMTP server SHOULD use the text shown in the examples
4451+ whenever appropriate.
4452+
4453+ An SMTP client MUST determine its actions only by the reply code, not
4454+ by the text (except for the "change of address" 251 and 551 and, if
4455+ necessary, 220, 221, and 421 replies); in the general case, any text,
4456+ including no text at all (although senders SHOULD NOT send bare
4457+ codes), MUST be acceptable. The space (blank) following the reply
4458+ code is considered part of the text. Whenever possible, a receiver-
4459+ SMTP SHOULD test the first digit (severity indication) of the reply
4460+ code.
4461+
4462+ The list of codes that appears below MUST NOT be construed as
4463+ permanent. While the addition of new codes should be a rare and
4464+ significant activity, with supplemental information in the textual
4465+ part of the response being preferred, new codes may be added as the
4466+ result of new Standards or Standards-Track specifications.
4467+ Consequently, a sender-SMTP MUST be prepared to handle codes not
4468+ specified in this document and MUST do so by interpreting the first
4469+ digit only.
4470+
4471+ In the absence of extensions negotiated with the client, SMTP servers
4472+ MUST NOT send reply codes whose first digits are other than 2, 3, 4,
4473+
4474+
4475+
4476+
4477+ Klensin Standards Track [Page 47]
4478+
4479+ RFC 5321 SMTP October 2008
4480+
4481+
4482+ or 5. Clients that receive such out-of-range codes SHOULD normally
4483+ treat them as fatal errors and terminate the mail transaction.
4484+
4485+ 4.2.1. Reply Code Severities and Theory
4486+
4487+ The three digits of the reply each have a special significance. The
4488+ first digit denotes whether the response is good, bad, or incomplete.
4489+ An unsophisticated SMTP client, or one that receives an unexpected
4490+ code, will be able to determine its next action (proceed as planned,
4491+ redo, retrench, etc.) by examining this first digit. An SMTP client
4492+ that wants to know approximately what kind of error occurred (e.g.,
4493+ mail system error, command syntax error) may examine the second
4494+ digit. The third digit and any supplemental information that may be
4495+ present is reserved for the finest gradation of information.
4496+
4497+ There are four values for the first digit of the reply code:
4498+
4499+ 2yz Positive Completion reply
4500+ The requested action has been successfully completed. A new
4501+ request may be initiated.
4502+
4503+ 3yz Positive Intermediate reply
4504+ The command has been accepted, but the requested action is being
4505+ held in abeyance, pending receipt of further information. The
4506+ SMTP client should send another command specifying this
4507+ information. This reply is used in command sequence groups (i.e.,
4508+ in DATA).
4509+
4510+ 4yz Transient Negative Completion reply
4511+ The command was not accepted, and the requested action did not
4512+ occur. However, the error condition is temporary, and the action
4513+ may be requested again. The sender should return to the beginning
4514+ of the command sequence (if any). It is difficult to assign a
4515+ meaning to "transient" when two different sites (receiver- and
4516+ sender-SMTP agents) must agree on the interpretation. Each reply
4517+ in this category might have a different time value, but the SMTP
4518+ client SHOULD try again. A rule of thumb to determine whether a
4519+ reply fits into the 4yz or the 5yz category (see below) is that
4520+ replies are 4yz if they can be successful if repeated without any
4521+ change in command form or in properties of the sender or receiver
4522+ (that is, the command is repeated identically and the receiver
4523+ does not put up a new implementation).
4524+
4525+ 5yz Permanent Negative Completion reply
4526+ The command was not accepted and the requested action did not
4527+ occur. The SMTP client SHOULD NOT repeat the exact request (in
4528+ the same sequence). Even some "permanent" error conditions can be
4529+ corrected, so the human user may want to direct the SMTP client to
4530+
4531+
4532+
4533+ Klensin Standards Track [Page 48]
4534+
4535+ RFC 5321 SMTP October 2008
4536+
4537+
4538+ reinitiate the command sequence by direct action at some point in
4539+ the future (e.g., after the spelling has been changed, or the user
4540+ has altered the account status).
4541+
4542+ It is worth noting that the file transfer protocol (FTP) [34] uses a
4543+ very similar code architecture and that the SMTP codes are based on
4544+ the FTP model. However, SMTP uses a one-command, one-response model
4545+ (while FTP is asynchronous) and FTP's 1yz codes are not part of the
4546+ SMTP model.
4547+
4548+ The second digit encodes responses in specific categories:
4549+
4550+ x0z Syntax: These replies refer to syntax errors, syntactically
4551+ correct commands that do not fit any functional category, and
4552+ unimplemented or superfluous commands.
4553+
4554+ x1z Information: These are replies to requests for information, such
4555+ as status or help.
4556+
4557+ x2z Connections: These are replies referring to the transmission
4558+ channel.
4559+
4560+ x3z Unspecified.
4561+
4562+ x4z Unspecified.
4563+
4564+ x5z Mail system: These replies indicate the status of the receiver
4565+ mail system vis-a-vis the requested transfer or other mail system
4566+ action.
4567+
4568+ The third digit gives a finer gradation of meaning in each category
4569+ specified by the second digit. The list of replies illustrates this.
4570+ Each reply text is recommended rather than mandatory, and may even
4571+ change according to the command with which it is associated. On the
4572+ other hand, the reply codes must strictly follow the specifications
4573+ in this section. Receiver implementations should not invent new
4574+ codes for slightly different situations from the ones described here,
4575+ but rather adapt codes already defined.
4576+
4577+ For example, a command such as NOOP, whose successful execution does
4578+ not offer the SMTP client any new information, will return a 250
4579+ reply. The reply is 502 when the command requests an unimplemented
4580+ non-site-specific action. A refinement of that is the 504 reply for
4581+ a command that is implemented, but that requests an unimplemented
4582+ parameter.
4583+
4584+
4585+
4586+
4587+
4588+
4589+ Klensin Standards Track [Page 49]
4590+
4591+ RFC 5321 SMTP October 2008
4592+
4593+
4594+ The reply text may be longer than a single line; in these cases the
4595+ complete text must be marked so the SMTP client knows when it can
4596+ stop reading the reply. This requires a special format to indicate a
4597+ multiple line reply.
4598+
4599+ The format for multiline replies requires that every line, except the
4600+ last, begin with the reply code, followed immediately by a hyphen,
4601+ "-" (also known as minus), followed by text. The last line will
4602+ begin with the reply code, followed immediately by <SP>, optionally
4603+ some text, and <CRLF>. As noted above, servers SHOULD send the <SP>
4604+ if subsequent text is not sent, but clients MUST be prepared for it
4605+ to be omitted.
4606+
4607+ For example:
4608+
4609+ 250-First line
4610+ 250-Second line
4611+ 250-234 Text beginning with numbers
4612+ 250 The last line
4613+
4614+ In a multiline reply, the reply code on each of the lines MUST be the
4615+ same. It is reasonable for the client to rely on this, so it can
4616+ make processing decisions based on the code in any line, assuming
4617+ that all others will be the same. In a few cases, there is important
4618+ data for the client in the reply "text". The client will be able to
4619+ identify these cases from the current context.
4620+
4621+ 4.2.2. Reply Codes by Function Groups
4622+
4623+ 500 Syntax error, command unrecognized (This may include errors such
4624+ as command line too long)
4625+
4626+ 501 Syntax error in parameters or arguments
4627+
4628+ 502 Command not implemented (see Section 4.2.4)
4629+
4630+ 503 Bad sequence of commands
4631+
4632+ 504 Command parameter not implemented
4633+
4634+
4635+ 211 System status, or system help reply
4636+
4637+ 214 Help message (Information on how to use the receiver or the
4638+ meaning of a particular non-standard command; this reply is useful
4639+ only to the human user)
4640+
4641+
4642+
4643+
4644+
4645+ Klensin Standards Track [Page 50]
4646+
4647+ RFC 5321 SMTP October 2008
4648+
4649+
4650+ 220 <domain> Service ready
4651+
4652+ 221 <domain> Service closing transmission channel
4653+
4654+ 421 <domain> Service not available, closing transmission channel
4655+ (This may be a reply to any command if the service knows it must
4656+ shut down)
4657+
4658+
4659+ 250 Requested mail action okay, completed
4660+
4661+ 251 User not local; will forward to <forward-path> (See Section 3.4)
4662+
4663+ 252 Cannot VRFY user, but will accept message and attempt delivery
4664+ (See Section 3.5.3)
4665+
4666+ 455 Server unable to accommodate parameters
4667+
4668+ 555 MAIL FROM/RCPT TO parameters not recognized or not implemented
4669+
4670+ 450 Requested mail action not taken: mailbox unavailable (e.g.,
4671+ mailbox busy or temporarily blocked for policy reasons)
4672+
4673+ 550 Requested action not taken: mailbox unavailable (e.g., mailbox
4674+ not found, no access, or command rejected for policy reasons)
4675+
4676+ 451 Requested action aborted: error in processing
4677+
4678+ 551 User not local; please try <forward-path> (See Section 3.4)
4679+
4680+ 452 Requested action not taken: insufficient system storage
4681+
4682+ 552 Requested mail action aborted: exceeded storage allocation
4683+
4684+ 553 Requested action not taken: mailbox name not allowed (e.g.,
4685+ mailbox syntax incorrect)
4686+
4687+ 354 Start mail input; end with <CRLF>.<CRLF>
4688+
4689+ 554 Transaction failed (Or, in the case of a connection-opening
4690+ response, "No SMTP service here")
4691+
4692+
4693+
4694+
4695+
4696+
4697+
4698+
4699+
4700+
4701+ Klensin Standards Track [Page 51]
4702+
4703+ RFC 5321 SMTP October 2008
4704+
4705+
4706+ 4.2.3. Reply Codes in Numeric Order
4707+
4708+ 211 System status, or system help reply
4709+
4710+ 214 Help message (Information on how to use the receiver or the
4711+ meaning of a particular non-standard command; this reply is useful
4712+ only to the human user)
4713+
4714+ 220 <domain> Service ready
4715+
4716+ 221 <domain> Service closing transmission channel
4717+
4718+ 250 Requested mail action okay, completed
4719+
4720+ 251 User not local; will forward to <forward-path> (See Section 3.4)
4721+
4722+ 252 Cannot VRFY user, but will accept message and attempt delivery
4723+ (See Section 3.5.3)
4724+
4725+ 354 Start mail input; end with <CRLF>.<CRLF>
4726+
4727+ 421 <domain> Service not available, closing transmission channel
4728+ (This may be a reply to any command if the service knows it must
4729+ shut down)
4730+
4731+ 450 Requested mail action not taken: mailbox unavailable (e.g.,
4732+ mailbox busy or temporarily blocked for policy reasons)
4733+
4734+ 451 Requested action aborted: local error in processing
4735+
4736+ 452 Requested action not taken: insufficient system storage
4737+
4738+ 455 Server unable to accommodate parameters
4739+
4740+ 500 Syntax error, command unrecognized (This may include errors such
4741+ as command line too long)
4742+
4743+ 501 Syntax error in parameters or arguments
4744+
4745+ 502 Command not implemented (see Section 4.2.4)
4746+
4747+ 503 Bad sequence of commands
4748+
4749+ 504 Command parameter not implemented
4750+
4751+ 550 Requested action not taken: mailbox unavailable (e.g., mailbox
4752+ not found, no access, or command rejected for policy reasons)
4753+
4754+
4755+
4756+
4757+ Klensin Standards Track [Page 52]
4758+
4759+ RFC 5321 SMTP October 2008
4760+
4761+
4762+ 551 User not local; please try <forward-path> (See Section 3.4)
4763+
4764+ 552 Requested mail action aborted: exceeded storage allocation
4765+
4766+ 553 Requested action not taken: mailbox name not allowed (e.g.,
4767+ mailbox syntax incorrect)
4768+
4769+ 554 Transaction failed (Or, in the case of a connection-opening
4770+ response, "No SMTP service here")
4771+
4772+ 555 MAIL FROM/RCPT TO parameters not recognized or not implemented
4773+
4774+ 4.2.4. Reply Code 502
4775+
4776+ Questions have been raised as to when reply code 502 (Command not
4777+ implemented) SHOULD be returned in preference to other codes. 502
4778+ SHOULD be used when the command is actually recognized by the SMTP
4779+ server, but not implemented. If the command is not recognized, code
4780+ 500 SHOULD be returned. Extended SMTP systems MUST NOT list
4781+ capabilities in response to EHLO for which they will return 502 (or
4782+ 500) replies.
4783+
4784+ 4.2.5. Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>
4785+
4786+ When an SMTP server returns a positive completion status (2yz code)
4787+ after the DATA command is completed with <CRLF>.<CRLF>, it accepts
4788+ responsibility for:
4789+
4790+ o delivering the message (if the recipient mailbox exists), or
4791+
4792+ o if attempts to deliver the message fail due to transient
4793+ conditions, retrying delivery some reasonable number of times at
4794+ intervals as specified in Section 4.5.4.
4795+
4796+ o if attempts to deliver the message fail due to permanent
4797+ conditions, or if repeated attempts to deliver the message fail
4798+ due to transient conditions, returning appropriate notification to
4799+ the sender of the original message (using the address in the SMTP
4800+ MAIL command).
4801+
4802+ When an SMTP server returns a temporary error status (4yz) code after
4803+ the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a
4804+ subsequent attempt to deliver that message. The SMTP client retains
4805+ responsibility for the delivery of that message and may either return
4806+ it to the user or requeue it for a subsequent attempt (see
4807+ Section 4.5.4.1).
4808+
4809+
4810+
4811+
4812+
4813+ Klensin Standards Track [Page 53]
4814+
4815+ RFC 5321 SMTP October 2008
4816+
4817+
4818+ The user who originated the message SHOULD be able to interpret the
4819+ return of a transient failure status (by mail message or otherwise)
4820+ as a non-delivery indication, just as a permanent failure would be
4821+ interpreted. If the client SMTP successfully handles these
4822+ conditions, the user will not receive such a reply.
4823+
4824+ When an SMTP server returns a permanent error status (5yz) code after
4825+ the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
4826+ any subsequent attempt to deliver the message. As with temporary
4827+ error status codes, the SMTP client retains responsibility for the
4828+ message, but SHOULD not again attempt delivery to the same server
4829+ without user review of the message and response and appropriate
4830+ intervention.
4831+
4832+ 4.3. Sequencing of Commands and Replies
4833+
4834+ 4.3.1. Sequencing Overview
4835+
4836+ The communication between the sender and receiver is an alternating
4837+ dialogue, controlled by the sender. As such, the sender issues a
4838+ command and the receiver responds with a reply. Unless other
4839+ arrangements are negotiated through service extensions, the sender
4840+ MUST wait for this response before sending further commands. One
4841+ important reply is the connection greeting. Normally, a receiver
4842+ will send a 220 "Service ready" reply when the connection is
4843+ completed. The sender SHOULD wait for this greeting message before
4844+ sending any commands.
4845+
4846+ Note: all the greeting-type replies have the official name (the
4847+ fully-qualified primary domain name) of the server host as the first
4848+ word following the reply code. Sometimes the host will have no
4849+ meaningful name. See Section 4.1.3 for a discussion of alternatives
4850+ in these situations.
4851+
4852+ For example,
4853+
4854+ 220 ISIF.USC.EDU Service ready
4855+
4856+ or
4857+
4858+ 220 mail.example.com SuperSMTP v 6.1.2 Service ready
4859+
4860+ or
4861+
4862+ 220 [10.0.0.1] Clueless host service ready
4863+
4864+ The table below lists alternative success and failure replies for
4865+ each command. These SHOULD be strictly adhered to. A receiver MAY
4866+
4867+
4868+
4869+ Klensin Standards Track [Page 54]
4870+
4871+ RFC 5321 SMTP October 2008
4872+
4873+
4874+ substitute text in the replies, but the meanings and actions implied
4875+ by the code numbers and by the specific command reply sequence MUST
4876+ be preserved.
4877+
4878+ 4.3.2. Command-Reply Sequences
4879+
4880+ Each command is listed with its usual possible replies. The prefixes
4881+ used before the possible replies are "I" for intermediate, "S" for
4882+ success, and "E" for error. Since some servers may generate other
4883+ replies under special circumstances, and to allow for future
4884+ extension, SMTP clients SHOULD, when possible, interpret only the
4885+ first digit of the reply and MUST be prepared to deal with
4886+ unrecognized reply codes by interpreting the first digit only.
4887+ Unless extended using the mechanisms described in Section 2.2, SMTP
4888+ servers MUST NOT transmit reply codes to an SMTP client that are
4889+ other than three digits or that do not start in a digit between 2 and
4890+ 5 inclusive.
4891+
4892+ These sequencing rules and, in principle, the codes themselves, can
4893+ be extended or modified by SMTP extensions offered by the server and
4894+ accepted (requested) by the client. However, if the target is more
4895+ precise granularity in the codes, rather than codes for completely
4896+ new purposes, the system described in RFC 3463 [25] SHOULD be used in
4897+ preference to the invention of new codes.
4898+
4899+ In addition to the codes listed below, any SMTP command can return
4900+ any of the following codes if the corresponding unusual circumstances
4901+ are encountered:
4902+
4903+ 500 For the "command line too long" case or if the command name was
4904+ not recognized. Note that producing a "command not recognized"
4905+ error in response to the required subset of these commands is a
4906+ violation of this specification. Similarly, producing a "command
4907+ too long" message for a command line shorter than 512 characters
4908+ would violate the provisions of Section 4.5.3.1.4.
4909+
4910+ 501 Syntax error in command or arguments. In order to provide for
4911+ future extensions, commands that are specified in this document as
4912+ not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
4913+ message if arguments are supplied in the absence of EHLO-
4914+ advertised extensions.
4915+
4916+ 421 Service shutting down and closing transmission channel
4917+
4918+
4919+
4920+
4921+
4922+
4923+
4924+
4925+ Klensin Standards Track [Page 55]
4926+
4927+ RFC 5321 SMTP October 2008
4928+
4929+
4930+ Specific sequences are:
4931+
4932+ CONNECTION ESTABLISHMENT
4933+
4934+ S: 220
4935+ E: 554
4936+
4937+ EHLO or HELO
4938+
4939+ S: 250
4940+ E: 504 (a conforming implementation could return this code only
4941+ in fairly obscure cases), 550, 502 (permitted only with an old-
4942+ style server that does not support EHLO)
4943+
4944+ MAIL
4945+
4946+ S: 250
4947+ E: 552, 451, 452, 550, 553, 503, 455, 555
4948+
4949+ RCPT
4950+
4951+ S: 250, 251 (but see Section 3.4 for discussion of 251 and 551)
4952+ E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555
4953+
4954+ DATA
4955+
4956+ I: 354 -> data -> S: 250
4957+
4958+ E: 552, 554, 451, 452
4959+
4960+ E: 450, 550 (rejections for policy reasons)
4961+
4962+ E: 503, 554
4963+
4964+ RSET
4965+
4966+ S: 250
4967+
4968+ VRFY
4969+
4970+ S: 250, 251, 252
4971+ E: 550, 551, 553, 502, 504
4972+
4973+ EXPN
4974+
4975+ S: 250, 252
4976+ E: 550, 500, 502, 504
4977+
4978+
4979+
4980+
4981+ Klensin Standards Track [Page 56]
4982+
4983+ RFC 5321 SMTP October 2008
4984+
4985+
4986+ HELP
4987+
4988+ S: 211, 214
4989+ E: 502, 504
4990+
4991+ NOOP
4992+
4993+ S: 250
4994+
4995+ QUIT
4996+
4997+ S: 221
4998+
4999+ 4.4. Trace Information
5000+
5001+ When an SMTP server receives a message for delivery or further
5002+ processing, it MUST insert trace ("time stamp" or "Received")
5003+ information at the beginning of the message content, as discussed in
5004+ Section 4.1.1.4.
5005+
5006+ This line MUST be structured as follows:
5007+
5008+ o The FROM clause, which MUST be supplied in an SMTP environment,
5009+ SHOULD contain both (1) the name of the source host as presented
5010+ in the EHLO command and (2) an address literal containing the IP
5011+ address of the source, determined from the TCP connection.
5012+
5013+ o The ID clause MAY contain an "@" as suggested in RFC 822, but this
5014+ is not required.
5015+
5016+ o If the FOR clause appears, it MUST contain exactly one <path>
5017+ entry, even when multiple RCPT commands have been given. Multiple
5018+ <path>s raise some security issues and have been deprecated, see
5019+ Section 7.2.
5020+
5021+ An Internet mail program MUST NOT change or delete a Received: line
5022+ that was previously added to the message header section. SMTP
5023+ servers MUST prepend Received lines to messages; they MUST NOT change
5024+ the order of existing lines or insert Received lines in any other
5025+ location.
5026+
5027+ As the Internet grows, comparability of Received header fields is
5028+ important for detecting problems, especially slow relays. SMTP
5029+ servers that create Received header fields SHOULD use explicit
5030+ offsets in the dates (e.g., -0800), rather than time zone names of
5031+ any type. Local time (with an offset) SHOULD be used rather than UT
5032+ when feasible. This formulation allows slightly more information
5033+ about local circumstances to be specified. If UT is needed, the
5034+
5035+
5036+
5037+ Klensin Standards Track [Page 57]
5038+
5039+ RFC 5321 SMTP October 2008
5040+
5041+
5042+ receiver need merely do some simple arithmetic to convert the values.
5043+ Use of UT loses information about the time zone-location of the
5044+ server. If it is desired to supply a time zone name, it SHOULD be
5045+ included in a comment.
5046+
5047+ When the delivery SMTP server makes the "final delivery" of a
5048+ message, it inserts a return-path line at the beginning of the mail
5049+ data. This use of return-path is required; mail systems MUST support
5050+ it. The return-path line preserves the information in the <reverse-
5051+ path> from the MAIL command. Here, final delivery means the message
5052+ has left the SMTP environment. Normally, this would mean it had been
5053+ delivered to the destination user or an associated mail drop, but in
5054+ some cases it may be further processed and transmitted by another
5055+ mail system.
5056+
5057+ It is possible for the mailbox in the return path to be different
5058+ from the actual sender's mailbox, for example, if error responses are
5059+ to be delivered to a special error handling mailbox rather than to
5060+ the message sender. When mailing lists are involved, this
5061+ arrangement is common and useful as a means of directing errors to
5062+ the list maintainer rather than the message originator.
5063+
5064+ The text above implies that the final mail data will begin with a
5065+ return path line, followed by one or more time stamp lines. These
5066+ lines will be followed by the rest of the mail data: first the
5067+ balance of the mail header section and then the body (RFC 5322 [4]).
5068+
5069+ It is sometimes difficult for an SMTP server to determine whether or
5070+ not it is making final delivery since forwarding or other operations
5071+ may occur after the message is accepted for delivery. Consequently,
5072+ any further (forwarding, gateway, or relay) systems MAY remove the
5073+ return path and rebuild the MAIL command as needed to ensure that
5074+ exactly one such line appears in a delivered message.
5075+
5076+ A message-originating SMTP system SHOULD NOT send a message that
5077+ already contains a Return-path header field. SMTP servers performing
5078+ a relay function MUST NOT inspect the message data, and especially
5079+ not to the extent needed to determine if Return-path header fields
5080+ are present. SMTP servers making final delivery MAY remove Return-
5081+ path header fields before adding their own.
5082+
5083+ The primary purpose of the Return-path is to designate the address to
5084+ which messages indicating non-delivery or other mail system failures
5085+ are to be sent. For this to be unambiguous, exactly one return path
5086+ SHOULD be present when the message is delivered. Systems using RFC
5087+ 822 syntax with non-SMTP transports SHOULD designate an unambiguous
5088+ address, associated with the transport envelope, to which error
5089+ reports (e.g., non-delivery messages) should be sent.
5090+
5091+
5092+
5093+ Klensin Standards Track [Page 58]
5094+
5095+ RFC 5321 SMTP October 2008
5096+
5097+
5098+ Historical note: Text in RFC 822 that appears to contradict the use
5099+ of the Return-path header field (or the envelope reverse-path address
5100+ from the MAIL command) as the destination for error messages is not
5101+ applicable on the Internet. The reverse-path address (as copied into
5102+ the Return-path) MUST be used as the target of any mail containing
5103+ delivery error messages.
5104+
5105+ In particular:
5106+ o a gateway from SMTP -> elsewhere SHOULD insert a return-path
5107+ header field, unless it is known that the "elsewhere" transport
5108+ also uses Internet domain addresses and maintains the envelope
5109+ sender address separately.
5110+
5111+ o a gateway from elsewhere -> SMTP SHOULD delete any return-path
5112+ header field present in the message, and either copy that
5113+ information to the SMTP envelope or combine it with information
5114+ present in the envelope of the other transport system to construct
5115+ the reverse-path argument to the MAIL command in the SMTP
5116+ envelope.
5117+
5118+ The server must give special treatment to cases in which the
5119+ processing following the end of mail data indication is only
5120+ partially successful. This could happen if, after accepting several
5121+ recipients and the mail data, the SMTP server finds that the mail
5122+ data could be successfully delivered to some, but not all, of the
5123+ recipients. In such cases, the response to the DATA command MUST be
5124+ an OK reply. However, the SMTP server MUST compose and send an
5125+ "undeliverable mail" notification message to the originator of the
5126+ message.
5127+
5128+ A single notification listing all of the failed recipients or
5129+ separate notification messages MUST be sent for each failed
5130+ recipient. For economy of processing by the sender, the former
5131+ SHOULD be used when possible. Note that the key difference between
5132+ handling aliases (Section 3.9.1) and forwarding (this subsection) is
5133+ the change to the backward-pointing address in this case. All
5134+ notification messages about undeliverable mail MUST be sent using the
5135+ MAIL command (even if they result from processing the obsolete SEND,
5136+ SOML, or SAML commands) and MUST use a null return path as discussed
5137+ in Section 3.6.
5138+
5139+ The time stamp line and the return path line are formally defined as
5140+ follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
5141+ [4]):
5142+
5143+ Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
5144+
5145+ Time-stamp-line = "Received:" FWS Stamp <CRLF>
5146+
5147+
5148+
5149+ Klensin Standards Track [Page 59]
5150+
5151+ RFC 5321 SMTP October 2008
5152+
5153+
5154+ Stamp = From-domain By-domain Opt-info [CFWS] ";"
5155+ FWS date-time
5156+ ; where "date-time" is as defined in RFC 5322 [4]
5157+ ; but the "obs-" forms, especially two-digit
5158+ ; years, are prohibited in SMTP and MUST NOT be used.
5159+
5160+ From-domain = "FROM" FWS Extended-Domain
5161+
5162+ By-domain = CFWS "BY" FWS Extended-Domain
5163+
5164+ Extended-Domain = Domain /
5165+ ( Domain FWS "(" TCP-info ")" ) /
5166+ ( address-literal FWS "(" TCP-info ")" )
5167+
5168+ TCP-info = address-literal / ( Domain FWS address-literal )
5169+ ; Information derived by server from TCP connection
5170+ ; not client EHLO.
5171+
5172+ Opt-info = [Via] [With] [ID] [For]
5173+ [Additional-Registered-Clauses]
5174+
5175+ Via = CFWS "VIA" FWS Link
5176+
5177+ With = CFWS "WITH" FWS Protocol
5178+
5179+ ID = CFWS "ID" FWS ( Atom / msg-id )
5180+ ; msg-id is defined in RFC 5322 [4]
5181+
5182+ For = CFWS "FOR" FWS ( Path / Mailbox )
5183+
5184+ Additional-Registered-Clauses = CFWS Atom FWS String
5185+ ; Additional standard clauses may be
5186+ added in this
5187+ ; location by future standards and
5188+ registration with
5189+ ; IANA. SMTP servers SHOULD NOT use
5190+ unregistered
5191+ ; names. See Section 8.
5192+
5193+ Link = "TCP" / Addtl-Link
5194+
5195+ Addtl-Link = Atom
5196+ ; Additional standard names for links are
5197+ ; registered with the Internet Assigned Numbers
5198+ ; Authority (IANA). "Via" is primarily of value
5199+ ; with non-Internet transports. SMTP servers
5200+ ; SHOULD NOT use unregistered names.
5201+
5202+
5203+
5204+
5205+ Klensin Standards Track [Page 60]
5206+
5207+ RFC 5321 SMTP October 2008
5208+
5209+
5210+ Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
5211+
5212+ Attdl-Protocol = Atom
5213+ ; Additional standard names for protocols are
5214+ ; registered with the Internet Assigned Numbers
5215+ ; Authority (IANA) in the "mail parameters"
5216+ ; registry [9]. SMTP servers SHOULD NOT
5217+ ; use unregistered names.
5218+
5219+ 4.5. Additional Implementation Issues
5220+
5221+ 4.5.1. Minimum Implementation
5222+
5223+ In order to make SMTP workable, the following minimum implementation
5224+ MUST be provided by all receivers. The following commands MUST be
5225+ supported to conform to this specification:
5226+
5227+ EHLO
5228+ HELO
5229+ MAIL
5230+ RCPT
5231+ DATA
5232+ RSET
5233+ NOOP
5234+ QUIT
5235+ VRFY
5236+
5237+ Any system that includes an SMTP server supporting mail relaying or
5238+ delivery MUST support the reserved mailbox "postmaster" as a case-
5239+ insensitive local name. This postmaster address is not strictly
5240+ necessary if the server always returns 554 on connection opening (as
5241+ described in Section 3.1). The requirement to accept mail for
5242+ postmaster implies that RCPT commands that specify a mailbox for
5243+ postmaster at any of the domains for which the SMTP server provides
5244+ mail service, as well as the special case of "RCPT TO:<Postmaster>"
5245+ (with no domain specification), MUST be supported.
5246+
5247+ SMTP systems are expected to make every reasonable effort to accept
5248+ mail directed to Postmaster from any other system on the Internet.
5249+ In extreme cases -- such as to contain a denial of service attack or
5250+ other breach of security -- an SMTP server may block mail directed to
5251+ Postmaster. However, such arrangements SHOULD be narrowly tailored
5252+ so as to avoid blocking messages that are not part of such attacks.
5253+
5254+
5255+
5256+
5257+
5258+
5259+
5260+
5261+ Klensin Standards Track [Page 61]
5262+
5263+ RFC 5321 SMTP October 2008
5264+
5265+
5266+ 4.5.2. Transparency
5267+
5268+ Without some provision for data transparency, the character sequence
5269+ "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
5270+ In general, users are not aware of such "forbidden" sequences. To
5271+ allow all user composed text to be transmitted transparently, the
5272+ following procedures are used:
5273+
5274+ o Before sending a line of mail text, the SMTP client checks the
5275+ first character of the line. If it is a period, one additional
5276+ period is inserted at the beginning of the line.
5277+
5278+ o When a line of mail text is received by the SMTP server, it checks
5279+ the line. If the line is composed of a single period, it is
5280+ treated as the end of mail indicator. If the first character is a
5281+ period and there are other characters on the line, the first
5282+ character is deleted.
5283+
5284+ The mail data may contain any of the 128 ASCII characters. All
5285+ characters are to be delivered to the recipient's mailbox, including
5286+ spaces, vertical and horizontal tabs, and other control characters.
5287+ If the transmission channel provides an 8-bit byte (octet) data
5288+ stream, the 7-bit ASCII codes are transmitted, right justified, in
5289+ the octets, with the high-order bits cleared to zero. See
5290+ Section 3.6 for special treatment of these conditions in SMTP systems
5291+ serving a relay function.
5292+
5293+ In some systems, it may be necessary to transform the data as it is
5294+ received and stored. This may be necessary for hosts that use a
5295+ different character set than ASCII as their local character set, that
5296+ store data in records rather than strings, or which use special
5297+ character sequences as delimiters inside mailboxes. If such
5298+ transformations are necessary, they MUST be reversible, especially if
5299+ they are applied to mail being relayed.
5300+
5301+ 4.5.3. Sizes and Timeouts
5302+
5303+ 4.5.3.1. Size Limits and Minimums
5304+
5305+ There are several objects that have required minimum/maximum sizes.
5306+ Every implementation MUST be able to receive objects of at least
5307+ these sizes. Objects larger than these sizes SHOULD be avoided when
5308+ possible. However, some Internet mail constructs such as encoded
5309+ X.400 addresses (RFC 2156 [35]) will often require larger objects.
5310+ Clients MAY attempt to transmit these, but MUST be prepared for a
5311+ server to reject them if they cannot be handled by it. To the
5312+ maximum extent possible, implementation techniques that impose no
5313+ limits on the length of these objects should be used.
5314+
5315+
5316+
5317+ Klensin Standards Track [Page 62]
5318+
5319+ RFC 5321 SMTP October 2008
5320+
5321+
5322+ Extensions to SMTP may involve the use of characters that occupy more
5323+ than a single octet each. This section therefore specifies lengths
5324+ in octets where absolute lengths, rather than character counts, are
5325+ intended.
5326+
5327+ 4.5.3.1.1. Local-part
5328+
5329+ The maximum total length of a user name or other local-part is 64
5330+ octets.
5331+
5332+ 4.5.3.1.2. Domain
5333+
5334+ The maximum total length of a domain name or number is 255 octets.
5335+
5336+ 4.5.3.1.3. Path
5337+
5338+ The maximum total length of a reverse-path or forward-path is 256
5339+ octets (including the punctuation and element separators).
5340+
5341+ 4.5.3.1.4. Command Line
5342+
5343+ The maximum total length of a command line including the command word
5344+ and the <CRLF> is 512 octets. SMTP extensions may be used to
5345+ increase this limit.
5346+
5347+ 4.5.3.1.5. Reply Line
5348+
5349+ The maximum total length of a reply line including the reply code and
5350+ the <CRLF> is 512 octets. More information may be conveyed through
5351+ multiple-line replies.
5352+
5353+ 4.5.3.1.6. Text Line
5354+
5355+ The maximum total length of a text line including the <CRLF> is 1000
5356+ octets (not counting the leading dot duplicated for transparency).
5357+ This number may be increased by the use of SMTP Service Extensions.
5358+
5359+ 4.5.3.1.7. Message Content
5360+
5361+ The maximum total length of a message content (including any message
5362+ header section as well as the message body) MUST BE at least 64K
5363+ octets. Since the introduction of Internet Standards for multimedia
5364+ mail (RFC 2045 [21]), message lengths on the Internet have grown
5365+ dramatically, and message size restrictions should be avoided if at
5366+ all possible. SMTP server systems that must impose restrictions
5367+ SHOULD implement the "SIZE" service extension of RFC 1870 [10], and
5368+ SMTP client systems that will send large messages SHOULD utilize it
5369+ when possible.
5370+
5371+
5372+
5373+ Klensin Standards Track [Page 63]
5374+
5375+ RFC 5321 SMTP October 2008
5376+
5377+
5378+ 4.5.3.1.8. Recipients Buffer
5379+
5380+ The minimum total number of recipients that MUST be buffered is 100
5381+ recipients. Rejection of messages (for excessive recipients) with
5382+ fewer than 100 RCPT commands is a violation of this specification.
5383+ The general principle that relaying SMTP server MUST NOT, and
5384+ delivery SMTP servers SHOULD NOT, perform validation tests on message
5385+ header fields suggests that messages SHOULD NOT be rejected based on
5386+ the total number of recipients shown in header fields. A server that
5387+ imposes a limit on the number of recipients MUST behave in an orderly
5388+ fashion, such as rejecting additional addresses over its limit rather
5389+ than silently discarding addresses previously accepted. A client
5390+ that needs to deliver a message containing over 100 RCPT commands
5391+ SHOULD be prepared to transmit in 100-recipient "chunks" if the
5392+ server declines to accept more than 100 recipients in a single
5393+ message.
5394+
5395+ 4.5.3.1.9. Treatment When Limits Exceeded
5396+
5397+ Errors due to exceeding these limits may be reported by using the
5398+ reply codes. Some examples of reply codes are:
5399+
5400+ 500 Line too long.
5401+
5402+ or
5403+
5404+ 501 Path too long
5405+
5406+ or
5407+
5408+ 452 Too many recipients (see below)
5409+
5410+ or
5411+
5412+ 552 Too much mail data.
5413+
5414+ 4.5.3.1.10. Too Many Recipients Code
5415+
5416+ RFC 821 [1] incorrectly listed the error where an SMTP server
5417+ exhausts its implementation limit on the number of RCPT commands
5418+ ("too many recipients") as having reply code 552. The correct reply
5419+ code for this condition is 452. Clients SHOULD treat a 552 code in
5420+ this case as a temporary, rather than permanent, failure so the logic
5421+ below works.
5422+
5423+ When a conforming SMTP server encounters this condition, it has at
5424+ least 100 successful RCPT commands in its recipients buffer. If the
5425+ server is able to accept the message, then at least these 100
5426+
5427+
5428+
5429+ Klensin Standards Track [Page 64]
5430+
5431+ RFC 5321 SMTP October 2008
5432+
5433+
5434+ addresses will be removed from the SMTP client's queue. When the
5435+ client attempts retransmission of those addresses that received 452
5436+ responses, at least 100 of these will be able to fit in the SMTP
5437+ server's recipients buffer. Each retransmission attempt that is able
5438+ to deliver anything will be able to dispose of at least 100 of these
5439+ recipients.
5440+
5441+ If an SMTP server has an implementation limit on the number of RCPT
5442+ commands and this limit is exhausted, it MUST use a response code of
5443+ 452 (but the client SHOULD also be prepared for a 552, as noted
5444+ above). If the server has a configured site-policy limitation on the
5445+ number of RCPT commands, it MAY instead use a 5yz response code. In
5446+ particular, if the intent is to prohibit messages with more than a
5447+ site-specified number of recipients, rather than merely limit the
5448+ number of recipients in a given mail transaction, it would be
5449+ reasonable to return a 503 response to any DATA command received
5450+ subsequent to the 452 (or 552) code or to simply return the 503 after
5451+ DATA without returning any previous negative response.
5452+
5453+ 4.5.3.2. Timeouts
5454+
5455+ An SMTP client MUST provide a timeout mechanism. It MUST use per-
5456+ command timeouts rather than somehow trying to time the entire mail
5457+ transaction. Timeouts SHOULD be easily reconfigurable, preferably
5458+ without recompiling the SMTP code. To implement this, a timer is set
5459+ for each SMTP command and for each buffer of the data transfer. The
5460+ latter means that the overall timeout is inherently proportional to
5461+ the size of the message.
5462+
5463+ Based on extensive experience with busy mail-relay hosts, the minimum
5464+ per-command timeout values SHOULD be as follows:
5465+
5466+ 4.5.3.2.1. Initial 220 Message: 5 Minutes
5467+
5468+ An SMTP client process needs to distinguish between a failed TCP
5469+ connection and a delay in receiving the initial 220 greeting message.
5470+ Many SMTP servers accept a TCP connection but delay delivery of the
5471+ 220 message until their system load permits more mail to be
5472+ processed.
5473+
5474+ 4.5.3.2.2. MAIL Command: 5 Minutes
5475+
5476+ 4.5.3.2.3. RCPT Command: 5 Minutes
5477+
5478+ A longer timeout is required if processing of mailing lists and
5479+ aliases is not deferred until after the message was accepted.
5480+
5481+
5482+
5483+
5484+
5485+ Klensin Standards Track [Page 65]
5486+
5487+ RFC 5321 SMTP October 2008
5488+
5489+
5490+ 4.5.3.2.4. DATA Initiation: 2 Minutes
5491+
5492+ This is while awaiting the "354 Start Input" reply to a DATA command.
5493+
5494+ 4.5.3.2.5. Data Block: 3 Minutes
5495+
5496+ This is while awaiting the completion of each TCP SEND call
5497+ transmitting a chunk of data.
5498+
5499+ 4.5.3.2.6. DATA Termination: 10 Minutes.
5500+
5501+ This is while awaiting the "250 OK" reply. When the receiver gets
5502+ the final period terminating the message data, it typically performs
5503+ processing to deliver the message to a user mailbox. A spurious
5504+ timeout at this point would be very wasteful and would typically
5505+ result in delivery of multiple copies of the message, since it has
5506+ been successfully sent and the server has accepted responsibility for
5507+ delivery. See Section 6.1 for additional discussion.
5508+
5509+ 4.5.3.2.7. Server Timeout: 5 Minutes.
5510+
5511+ An SMTP server SHOULD have a timeout of at least 5 minutes while it
5512+ is awaiting the next command from the sender.
5513+
5514+ 4.5.4. Retry Strategies
5515+
5516+ The common structure of a host SMTP implementation includes user
5517+ mailboxes, one or more areas for queuing messages in transit, and one
5518+ or more daemon processes for sending and receiving mail. The exact
5519+ structure will vary depending on the needs of the users on the host
5520+ and the number and size of mailing lists supported by the host. We
5521+ describe several optimizations that have proved helpful, particularly
5522+ for mailers supporting high traffic levels.
5523+
5524+ Any queuing strategy MUST include timeouts on all activities on a
5525+ per-command basis. A queuing strategy MUST NOT send error messages
5526+ in response to error messages under any circumstances.
5527+
5528+ 4.5.4.1. Sending Strategy
5529+
5530+ The general model for an SMTP client is one or more processes that
5531+ periodically attempt to transmit outgoing mail. In a typical system,
5532+ the program that composes a message has some method for requesting
5533+ immediate attention for a new piece of outgoing mail, while mail that
5534+ cannot be transmitted immediately MUST be queued and periodically
5535+ retried by the sender. A mail queue entry will include not only the
5536+ message itself but also the envelope information.
5537+
5538+
5539+
5540+
5541+ Klensin Standards Track [Page 66]
5542+
5543+ RFC 5321 SMTP October 2008
5544+
5545+
5546+ The sender MUST delay retrying a particular destination after one
5547+ attempt has failed. In general, the retry interval SHOULD be at
5548+ least 30 minutes; however, more sophisticated and variable strategies
5549+ will be beneficial when the SMTP client can determine the reason for
5550+ non-delivery.
5551+
5552+ Retries continue until the message is transmitted or the sender gives
5553+ up; the give-up time generally needs to be at least 4-5 days. It MAY
5554+ be appropriate to set a shorter maximum number of retries for non-
5555+ delivery notifications and equivalent error messages than for
5556+ standard messages. The parameters to the retry algorithm MUST be
5557+ configurable.
5558+
5559+ A client SHOULD keep a list of hosts it cannot reach and
5560+ corresponding connection timeouts, rather than just retrying queued
5561+ mail items.
5562+
5563+ Experience suggests that failures are typically transient (the target
5564+ system or its connection has crashed), favoring a policy of two
5565+ connection attempts in the first hour the message is in the queue,
5566+ and then backing off to one every two or three hours.
5567+
5568+ The SMTP client can shorten the queuing delay in cooperation with the
5569+ SMTP server. For example, if mail is received from a particular
5570+ address, it is likely that mail queued for that host can now be sent.
5571+ Application of this principle may, in many cases, eliminate the
5572+ requirement for an explicit "send queues now" function such as ETRN,
5573+ RFC 1985 [36].
5574+
5575+ The strategy may be further modified as a result of multiple
5576+ addresses per host (see below) to optimize delivery time versus
5577+ resource usage.
5578+
5579+ An SMTP client may have a large queue of messages for each
5580+ unavailable destination host. If all of these messages were retried
5581+ in every retry cycle, there would be excessive Internet overhead and
5582+ the sending system would be blocked for a long period. Note that an
5583+ SMTP client can generally determine that a delivery attempt has
5584+ failed only after a timeout of several minutes, and even a one-minute
5585+ timeout per connection will result in a very large delay if retries
5586+ are repeated for dozens, or even hundreds, of queued messages to the
5587+ same host.
5588+
5589+ At the same time, SMTP clients SHOULD use great care in caching
5590+ negative responses from servers. In an extreme case, if EHLO is
5591+ issued multiple times during the same SMTP connection, different
5592+ answers may be returned by the server. More significantly, 5yz
5593+ responses to the MAIL command MUST NOT be cached.
5594+
5595+
5596+
5597+ Klensin Standards Track [Page 67]
5598+
5599+ RFC 5321 SMTP October 2008
5600+
5601+
5602+ When a mail message is to be delivered to multiple recipients, and
5603+ the SMTP server to which a copy of the message is to be sent is the
5604+ same for multiple recipients, then only one copy of the message
5605+ SHOULD be transmitted. That is, the SMTP client SHOULD use the
5606+ command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the
5607+ sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there
5608+ are very many addresses, a limit on the number of RCPT commands per
5609+ MAIL command MAY be imposed. This efficiency feature SHOULD be
5610+ implemented.
5611+
5612+ Similarly, to achieve timely delivery, the SMTP client MAY support
5613+ multiple concurrent outgoing mail transactions. However, some limit
5614+ may be appropriate to protect the host from devoting all its
5615+ resources to mail.
5616+
5617+ 4.5.4.2. Receiving Strategy
5618+
5619+ The SMTP server SHOULD attempt to keep a pending listen on the SMTP
5620+ port (specified by IANA as port 25) at all times. This requires the
5621+ support of multiple incoming TCP connections for SMTP. Some limit
5622+ MAY be imposed, but servers that cannot handle more than one SMTP
5623+ transaction at a time are not in conformance with the intent of this
5624+ specification.
5625+
5626+ As discussed above, when the SMTP server receives mail from a
5627+ particular host address, it could activate its own SMTP queuing
5628+ mechanisms to retry any mail pending for that host address.
5629+
5630+ 4.5.5. Messages with a Null Reverse-Path
5631+
5632+ There are several types of notification messages that are required by
5633+ existing and proposed Standards to be sent with a null reverse-path,
5634+ namely non-delivery notifications as discussed in Section 3.7, other
5635+ kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and
5636+ Message Disposition Notifications (MDNs, RFC 3798 [37]). All of
5637+ these kinds of messages are notifications about a previous message,
5638+ and they are sent to the reverse-path of the previous mail message.
5639+ (If the delivery of such a notification message fails, that usually
5640+ indicates a problem with the mail system of the host to which the
5641+ notification message is addressed. For this reason, at some hosts
5642+ the MTA is set up to forward such failed notification messages to
5643+ someone who is able to fix problems with the mail system, e.g., via
5644+ the postmaster alias.)
5645+
5646+ All other types of messages (i.e., any message which is not required
5647+ by a Standards-Track RFC to have a null reverse-path) SHOULD be sent
5648+ with a valid, non-null reverse-path.
5649+
5650+
5651+
5652+
5653+ Klensin Standards Track [Page 68]
5654+
5655+ RFC 5321 SMTP October 2008
5656+
5657+
5658+ Implementers of automated email processors should be careful to make
5659+ sure that the various kinds of messages with a null reverse-path are
5660+ handled correctly. In particular, such systems SHOULD NOT reply to
5661+ messages with a null reverse-path, and they SHOULD NOT add a non-null
5662+ reverse-path, or change a null reverse-path to a non-null one, to
5663+ such messages when forwarding.
5664+
5665+ 5. Address Resolution and Mail Handling
5666+
5667+ 5.1. Locating the Target Host
5668+
5669+ Once an SMTP client lexically identifies a domain to which mail will
5670+ be delivered for processing (as described in Sections 2.3.5 and 3.6),
5671+ a DNS lookup MUST be performed to resolve the domain name (RFC 1035
5672+ [2]). The names are expected to be fully-qualified domain names
5673+ (FQDNs): mechanisms for inferring FQDNs from partial names or local
5674+ aliases are outside of this specification. Due to a history of
5675+ problems, SMTP servers used for initial submission of messages SHOULD
5676+ NOT make such inferences (Message Submission Servers [18] have
5677+ somewhat more flexibility) and intermediate (relay) SMTP servers MUST
5678+ NOT make them.
5679+
5680+ The lookup first attempts to locate an MX record associated with the
5681+ name. If a CNAME record is found, the resulting name is processed as
5682+ if it were the initial name. If a non-existent domain error is
5683+ returned, this situation MUST be reported as an error. If a
5684+ temporary error is returned, the message MUST be queued and retried
5685+ later (see Section 4.5.4.1). If an empty list of MXs is returned,
5686+ the address is treated as if it was associated with an implicit MX
5687+ RR, with a preference of 0, pointing to that host. If MX records are
5688+ present, but none of them are usable, or the implicit MX is unusable,
5689+ this situation MUST be reported as an error.
5690+
5691+ If one or more MX RRs are found for a given name, SMTP systems MUST
5692+ NOT utilize any address RRs associated with that name unless they are
5693+ located using the MX RRs; the "implicit MX" rule above applies only
5694+ if there are no MX records present. If MX records are present, but
5695+ none of them are usable, this situation MUST be reported as an error.
5696+
5697+ When a domain name associated with an MX RR is looked up and the
5698+ associated data field obtained, the data field of that response MUST
5699+ contain a domain name. That domain name, when queried, MUST return
5700+ at least one address record (e.g., A or AAAA RR) that gives the IP
5701+ address of the SMTP server to which the message should be directed.
5702+ Any other response, specifically including a value that will return a
5703+ CNAME record when queried, lies outside the scope of this Standard.
5704+ The prohibition on labels in the data that resolve to CNAMEs is
5705+ discussed in more detail in RFC 2181, Section 10.3 [38].
5706+
5707+
5708+
5709+ Klensin Standards Track [Page 69]
5710+
5711+ RFC 5321 SMTP October 2008
5712+
5713+
5714+ When the lookup succeeds, the mapping can result in a list of
5715+ alternative delivery addresses rather than a single address, because
5716+ of multiple MX records, multihoming, or both. To provide reliable
5717+ mail transmission, the SMTP client MUST be able to try (and retry)
5718+ each of the relevant addresses in this list in order, until a
5719+ delivery attempt succeeds. However, there MAY also be a configurable
5720+ limit on the number of alternate addresses that can be tried. In any
5721+ case, the SMTP client SHOULD try at least two addresses.
5722+
5723+ Two types of information are used to rank the host addresses:
5724+ multiple MX records, and multihomed hosts.
5725+
5726+ MX records contain a preference indication that MUST be used in
5727+ sorting if more than one such record appears (see below). Lower
5728+ numbers are more preferred than higher ones. If there are multiple
5729+ destinations with the same preference and there is no clear reason to
5730+ favor one (e.g., by recognition of an easily reached address), then
5731+ the sender-SMTP MUST randomize them to spread the load across
5732+ multiple mail exchangers for a specific organization.
5733+
5734+ The destination host (perhaps taken from the preferred MX record) may
5735+ be multihomed, in which case the domain name resolver will return a
5736+ list of alternative IP addresses. It is the responsibility of the
5737+ domain name resolver interface to have ordered this list by
5738+ decreasing preference if necessary, and the SMTP sender MUST try them
5739+ in the order presented.
5740+
5741+ Although the capability to try multiple alternative addresses is
5742+ required, specific installations may want to limit or disable the use
5743+ of alternative addresses. The question of whether a sender should
5744+ attempt retries using the different addresses of a multihomed host
5745+ has been controversial. The main argument for using the multiple
5746+ addresses is that it maximizes the probability of timely delivery,
5747+ and indeed sometimes the probability of any delivery; the counter-
5748+ argument is that it may result in unnecessary resource use. Note
5749+ that resource use is also strongly determined by the sending strategy
5750+ discussed in Section 4.5.4.1.
5751+
5752+ If an SMTP server receives a message with a destination for which it
5753+ is a designated Mail eXchanger, it MAY relay the message (potentially
5754+ after having rewritten the MAIL FROM and/or RCPT TO addresses), make
5755+ final delivery of the message, or hand it off using some mechanism
5756+ outside the SMTP-provided transport environment. Of course, neither
5757+ of the latter require that the list of MX records be examined
5758+ further.
5759+
5760+ If it determines that it should relay the message without rewriting
5761+ the address, it MUST sort the MX records to determine candidates for
5762+
5763+
5764+
5765+ Klensin Standards Track [Page 70]
5766+
5767+ RFC 5321 SMTP October 2008
5768+
5769+
5770+ delivery. The records are first ordered by preference, with the
5771+ lowest-numbered records being most preferred. The relay host MUST
5772+ then inspect the list for any of the names or addresses by which it
5773+ might be known in mail transactions. If a matching record is found,
5774+ all records at that preference level and higher-numbered ones MUST be
5775+ discarded from consideration. If there are no records left at that
5776+ point, it is an error condition, and the message MUST be returned as
5777+ undeliverable. If records do remain, they SHOULD be tried, best
5778+ preference first, as described above.
5779+
5780+ 5.2. IPv6 and MX Records
5781+
5782+ In the contemporary Internet, SMTP clients and servers may be hosted
5783+ on IPv4 systems, IPv6 systems, or dual-stack systems that are
5784+ compatible with either version of the Internet Protocol. The host
5785+ domains to which MX records point may, consequently, contain "A RR"s
5786+ (IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC
5787+ 3974 [39] discusses some operational experience in mixed
5788+ environments, it was not comprehensive enough to justify
5789+ standardization, and some of its recommendations appear to be
5790+ inconsistent with this specification. The appropriate actions to be
5791+ taken either will depend on local circumstances, such as performance
5792+ of the relevant networks and any conversions that might be necessary,
5793+ or will be obvious (e.g., an IPv6-only client need not attempt to
5794+ look up A RRs or attempt to reach IPv4-only servers). Designers of
5795+ SMTP implementations that might run in IPv6 or dual-stack
5796+ environments should study the procedures above, especially the
5797+ comments about multihomed hosts, and, preferably, provide mechanisms
5798+ to facilitate operational tuning and mail interoperability between
5799+ IPv4 and IPv6 systems while considering local circumstances.
5800+
5801+ 6. Problem Detection and Handling
5802+
5803+ 6.1. Reliable Delivery and Replies by Email
5804+
5805+ When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
5806+ message in response to DATA), it is accepting responsibility for
5807+ delivering or relaying the message. It must take this responsibility
5808+ seriously. It MUST NOT lose the message for frivolous reasons, such
5809+ as because the host later crashes or because of a predictable
5810+ resource shortage. Some reasons that are not considered frivolous
5811+ are discussed in the next subsection and in Section 7.8.
5812+
5813+ If there is a delivery failure after acceptance of a message, the
5814+ receiver-SMTP MUST formulate and mail a notification message. This
5815+ notification MUST be sent using a null ("<>") reverse-path in the
5816+ envelope. The recipient of this notification MUST be the address
5817+ from the envelope return path (or the Return-Path: line). However,
5818+
5819+
5820+
5821+ Klensin Standards Track [Page 71]
5822+
5823+ RFC 5321 SMTP October 2008
5824+
5825+
5826+ if this address is null ("<>"), the receiver-SMTP MUST NOT send a
5827+ notification. Obviously, nothing in this section can or should
5828+ prohibit local decisions (i.e., as part of the same system
5829+ environment as the receiver-SMTP) to log or otherwise transmit
5830+ information about null address events locally if that is desired. If
5831+ the address is an explicit source route, it MUST be stripped down to
5832+ its final hop.
5833+
5834+ For example, suppose that an error notification must be sent for a
5835+ message that arrived with:
5836+
5837+ MAIL FROM:<@a,@b:user@d>
5838+
5839+ The notification message MUST be sent using:
5840+
5841+ RCPT TO:<user@d>
5842+
5843+ Some delivery failures after the message is accepted by SMTP will be
5844+ unavoidable. For example, it may be impossible for the receiving
5845+ SMTP server to validate all the delivery addresses in RCPT command(s)
5846+ due to a "soft" domain system error, because the target is a mailing
5847+ list (see earlier discussion of RCPT), or because the server is
5848+ acting as a relay and has no immediate access to the delivering
5849+ system.
5850+
5851+ To avoid receiving duplicate messages as the result of timeouts, a
5852+ receiver-SMTP MUST seek to minimize the time required to respond to
5853+ the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [40] for
5854+ a discussion of this problem.
5855+
5856+ 6.2. Unwanted, Unsolicited, and "Attack" Messages
5857+
5858+ Utility and predictability of the Internet mail system requires that
5859+ messages that can be delivered should be delivered, regardless of any
5860+ syntax or other faults associated with those messages and regardless
5861+ of their content. If they cannot be delivered, and cannot be
5862+ rejected by the SMTP server during the SMTP transaction, they should
5863+ be "bounced" (returned with non-delivery notification messages) as
5864+ described above. In today's world, in which many SMTP server
5865+ operators have discovered that the quantity of undesirable bulk email
5866+ vastly exceeds the quantity of desired mail and in which accepting a
5867+ message may trigger additional undesirable traffic by providing
5868+ verification of the address, those principles may not be practical.
5869+
5870+ As discussed in Section 7.8 and Section 7.9 below, dropping mail
5871+ without notification of the sender is permitted in practice.
5872+ However, it is extremely dangerous and violates a long tradition and
5873+ community expectations that mail is either delivered or returned. If
5874+
5875+
5876+
5877+ Klensin Standards Track [Page 72]
5878+
5879+ RFC 5321 SMTP October 2008
5880+
5881+
5882+ silent message-dropping is misused, it could easily undermine
5883+ confidence in the reliability of the Internet's mail systems. So
5884+ silent dropping of messages should be considered only in those cases
5885+ where there is very high confidence that the messages are seriously
5886+ fraudulent or otherwise inappropriate.
5887+
5888+ To stretch the principle of delivery if possible even further, it may
5889+ be a rational policy to not deliver mail that has an invalid return
5890+ address, although the history of the network is that users are
5891+ typically better served by delivering any message that can be
5892+ delivered. Reliably determining that a return address is invalid can
5893+ be a difficult and time-consuming process, especially if the putative
5894+ sending system is not directly accessible or does not fully and
5895+ accurately support VRFY and, even if a "drop messages with invalid
5896+ return addresses" policy is adopted, it SHOULD be applied only when
5897+ there is near-certainty that the return addresses are, in fact,
5898+ invalid.
5899+
5900+ Conversely, if a message is rejected because it is found to contain
5901+ hostile content (a decision that is outside the scope of an SMTP
5902+ server as defined in this document), rejection ("bounce") messages
5903+ SHOULD NOT be sent unless the receiving site is confident that those
5904+ messages will be usefully delivered. The preference and default in
5905+ these cases is to avoid sending non-delivery messages when the
5906+ incoming message is determined to contain hostile content.
5907+
5908+ 6.3. Loop Detection
5909+
5910+ Simple counting of the number of "Received:" header fields in a
5911+ message has proven to be an effective, although rarely optimal,
5912+ method of detecting loops in mail systems. SMTP servers using this
5913+ technique SHOULD use a large rejection threshold, normally at least
5914+ 100 Received entries. Whatever mechanisms are used, servers MUST
5915+ contain provisions for detecting and stopping trivial loops.
5916+
5917+ 6.4. Compensating for Irregularities
5918+
5919+ Unfortunately, variations, creative interpretations, and outright
5920+ violations of Internet mail protocols do occur; some would suggest
5921+ that they occur quite frequently. The debate as to whether a well-
5922+ behaved SMTP receiver or relay should reject a malformed message,
5923+ attempt to pass it on unchanged, or attempt to repair it to increase
5924+ the odds of successful delivery (or subsequent reply) began almost
5925+ with the dawn of structured network mail and shows no signs of
5926+ abating. Advocates of rejection claim that attempted repairs are
5927+ rarely completely adequate and that rejection of bad messages is the
5928+ only way to get the offending software repaired. Advocates of
5929+ "repair" or "deliver no matter what" argue that users prefer that
5930+
5931+
5932+
5933+ Klensin Standards Track [Page 73]
5934+
5935+ RFC 5321 SMTP October 2008
5936+
5937+
5938+ mail go through it if at all possible and that there are significant
5939+ market pressures in that direction. In practice, these market
5940+ pressures may be more important to particular vendors than strict
5941+ conformance to the standards, regardless of the preference of the
5942+ actual developers.
5943+
5944+ The problems associated with ill-formed messages were exacerbated by
5945+ the introduction of the split-UA mail reading protocols (Post Office
5946+ Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3
5947+ [16], IMAP version 2 [41], and PCMAIL [42]). These protocols
5948+ encouraged the use of SMTP as a posting (message submission)
5949+ protocol, and SMTP servers as relay systems for these client hosts
5950+ (which are often only intermittently connected to the Internet).
5951+ Historically, many of those client machines lacked some of the
5952+ mechanisms and information assumed by SMTP (and indeed, by the mail
5953+ format protocol, RFC 822 [28]). Some could not keep adequate track
5954+ of time; others had no concept of time zones; still others could not
5955+ identify their own names or addresses; and, of course, none could
5956+ satisfy the assumptions that underlay RFC 822's conception of
5957+ authenticated addresses.
5958+
5959+ In response to these weak SMTP clients, many SMTP systems now
5960+ complete messages that are delivered to them in incomplete or
5961+ incorrect form. This strategy is generally considered appropriate
5962+ when the server can identify or authenticate the client, and there
5963+ are prior agreements between them. By contrast, there is at best
5964+ great concern about fixes applied by a relay or delivery SMTP server
5965+ that has little or no knowledge of the user or client machine. Many
5966+ of these issues are addressed by using a separate protocol, such as
5967+ that defined in RFC 4409 [18], for message submission, rather than
5968+ using originating SMTP servers for that purpose.
5969+
5970+ The following changes to a message being processed MAY be applied
5971+ when necessary by an originating SMTP server, or one used as the
5972+ target of SMTP as an initial posting (message submission) protocol:
5973+
5974+ o Addition of a message-id field when none appears
5975+
5976+ o Addition of a date, time, or time zone when none appears
5977+
5978+ o Correction of addresses to proper FQDN format
5979+
5980+ The less information the server has about the client, the less likely
5981+ these changes are to be correct and the more caution and conservatism
5982+ should be applied when considering whether or not to perform fixes
5983+ and how. These changes MUST NOT be applied by an SMTP server that
5984+ provides an intermediate relay function.
5985+
5986+
5987+
5988+
5989+ Klensin Standards Track [Page 74]
5990+
5991+ RFC 5321 SMTP October 2008
5992+
5993+
5994+ In all cases, properly operating clients supplying correct
5995+ information are preferred to corrections by the SMTP server. In all
5996+ cases, documentation SHOULD be provided in trace header fields and/or
5997+ header field comments for actions performed by the servers.
5998+
5999+ 7. Security Considerations
6000+
6001+ 7.1. Mail Security and Spoofing
6002+
6003+ SMTP mail is inherently insecure in that it is feasible for even
6004+ fairly casual users to negotiate directly with receiving and relaying
6005+ SMTP servers and create messages that will trick a naive recipient
6006+ into believing that they came from somewhere else. Constructing such
6007+ a message so that the "spoofed" behavior cannot be detected by an
6008+ expert is somewhat more difficult, but not sufficiently so as to be a
6009+ deterrent to someone who is determined and knowledgeable.
6010+ Consequently, as knowledge of Internet mail increases, so does the
6011+ knowledge that SMTP mail inherently cannot be authenticated, or
6012+ integrity checks provided, at the transport level. Real mail
6013+ security lies only in end-to-end methods involving the message
6014+ bodies, such as those that use digital signatures (see RFC 1847 [43]
6015+ and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/
6016+ Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]).
6017+
6018+ Various protocol extensions and configuration options that provide
6019+ authentication at the transport level (e.g., from an SMTP client to
6020+ an SMTP server) improve somewhat on the traditional situation
6021+ described above. However, in general, they only authenticate one
6022+ server to another rather than a chain of relays and servers, much
6023+ less authenticating users or user machines. Consequently, unless
6024+ they are accompanied by careful handoffs of responsibility in a
6025+ carefully designed trust environment, they remain inherently weaker
6026+ than end-to-end mechanisms that use digitally signed messages rather
6027+ than depending on the integrity of the transport system.
6028+
6029+ Efforts to make it more difficult for users to set envelope return
6030+ path and header "From" fields to point to valid addresses other than
6031+ their own are largely misguided: they frustrate legitimate
6032+ applications in which mail is sent by one user on behalf of another,
6033+ in which error (or normal) replies should be directed to a special
6034+ address, or in which a single message is sent to multiple recipients
6035+ on different hosts. (Systems that provide convenient ways for users
6036+ to alter these header fields on a per-message basis should attempt to
6037+ establish a primary and permanent mailbox address for the user so
6038+ that Sender header fields within the message data can be generated
6039+ sensibly.)
6040+
6041+
6042+
6043+
6044+
6045+ Klensin Standards Track [Page 75]
6046+
6047+ RFC 5321 SMTP October 2008
6048+
6049+
6050+ This specification does not further address the authentication issues
6051+ associated with SMTP other than to advocate that useful functionality
6052+ not be disabled in the hope of providing some small margin of
6053+ protection against a user who is trying to fake mail.
6054+
6055+ 7.2. "Blind" Copies
6056+
6057+ Addresses that do not appear in the message header section may appear
6058+ in the RCPT commands to an SMTP server for a number of reasons. The
6059+ two most common involve the use of a mailing address as a "list
6060+ exploder" (a single address that resolves into multiple addresses)
6061+ and the appearance of "blind copies". Especially when more than one
6062+ RCPT command is present, and in order to avoid defeating some of the
6063+ purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
6064+ the full set of RCPT command arguments into the header section,
6065+ either as part of trace header fields or as informational or private-
6066+ extension header fields. Since this rule is often violated in
6067+ practice, and cannot be enforced, sending SMTP systems that are aware
6068+ of "bcc" use MAY find it helpful to send each blind copy as a
6069+ separate message transaction containing only a single RCPT command.
6070+
6071+ There is no inherent relationship between either "reverse" (from
6072+ MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
6073+ transaction ("envelope") and the addresses in the header section.
6074+ Receiving systems SHOULD NOT attempt to deduce such relationships and
6075+ use them to alter the header section of the message for delivery.
6076+ The popular "Apparently-to" header field is a violation of this
6077+ principle as well as a common source of unintended information
6078+ disclosure and SHOULD NOT be used.
6079+
6080+ 7.3. VRFY, EXPN, and Security
6081+
6082+ As discussed in Section 3.5, individual sites may want to disable
6083+ either or both of VRFY or EXPN for security reasons (see below). As
6084+ a corollary to the above, implementations that permit this MUST NOT
6085+ appear to have verified addresses that are not, in fact, verified.
6086+ If a site disables these commands for security reasons, the SMTP
6087+ server MUST return a 252 response, rather than a code that could be
6088+ confused with successful or unsuccessful verification.
6089+
6090+ Returning a 250 reply code with the address listed in the VRFY
6091+ command after having checked it only for syntax violates this rule.
6092+ Of course, an implementation that "supports" VRFY by always returning
6093+ 550 whether or not the address is valid is equally not in
6094+ conformance.
6095+
6096+ On the public Internet, the contents of mailing lists have become
6097+ popular as an address information source for so-called "spammers."
6098+
6099+
6100+
6101+ Klensin Standards Track [Page 76]
6102+
6103+ RFC 5321 SMTP October 2008
6104+
6105+
6106+ The use of EXPN to "harvest" addresses has increased as list
6107+ administrators have installed protections against inappropriate uses
6108+ of the lists themselves. However, VRFY and EXPN are still useful for
6109+ authenticated users and within an administrative domain. For
6110+ example, VRFY and EXPN are useful for performing internal audits of
6111+ how email gets routed to check and to make sure no one is
6112+ automatically forwarding sensitive mail outside the organization.
6113+ Sites implementing SMTP authentication may choose to make VRFY and
6114+ EXPN available only to authenticated requestors. Implementations
6115+ SHOULD still provide support for EXPN, but sites SHOULD carefully
6116+ evaluate the tradeoffs.
6117+
6118+ Whether disabling VRFY provides any real marginal security depends on
6119+ a series of other conditions. In many cases, RCPT commands can be
6120+ used to obtain the same information about address validity. On the
6121+ other hand, especially in situations where determination of address
6122+ validity for RCPT commands is deferred until after the DATA command
6123+ is received, RCPT may return no information at all, while VRFY is
6124+ expected to make a serious attempt to determine validity before
6125+ generating a response code (see discussion above).
6126+
6127+ 7.4. Mail Rerouting Based on the 251 and 551 Response Codes
6128+
6129+ Before a client uses the 251 or 551 reply codes from a RCPT command
6130+ to automatically update its future behavior (e.g., updating the
6131+ user's address book), it should be certain of the server's
6132+ authenticity. If it does not, it may be subject to a man in the
6133+ middle attack.
6134+
6135+ 7.5. Information Disclosure in Announcements
6136+
6137+ There has been an ongoing debate about the tradeoffs between the
6138+ debugging advantages of announcing server type and version (and,
6139+ sometimes, even server domain name) in the greeting response or in
6140+ response to the HELP command and the disadvantages of exposing
6141+ information that might be useful in a potential hostile attack. The
6142+ utility of the debugging information is beyond doubt. Those who
6143+ argue for making it available point out that it is far better to
6144+ actually secure an SMTP server rather than hope that trying to
6145+ conceal known vulnerabilities by hiding the server's precise identity
6146+ will provide more protection. Sites are encouraged to evaluate the
6147+ tradeoff with that issue in mind; implementations SHOULD minimally
6148+ provide for making type and version information available in some way
6149+ to other network hosts.
6150+
6151+
6152+
6153+
6154+
6155+
6156+
6157+ Klensin Standards Track [Page 77]
6158+
6159+ RFC 5321 SMTP October 2008
6160+
6161+
6162+ 7.6. Information Disclosure in Trace Fields
6163+
6164+ In some circumstances, such as when mail originates from within a LAN
6165+ whose hosts are not directly on the public Internet, trace
6166+ ("Received") header fields produced in conformance with this
6167+ specification may disclose host names and similar information that
6168+ would not normally be available. This ordinarily does not pose a
6169+ problem, but sites with special concerns about name disclosure should
6170+ be aware of it. Also, the optional FOR clause should be supplied
6171+ with caution or not at all when multiple recipients are involved lest
6172+ it inadvertently disclose the identities of "blind copy" recipients
6173+ to others.
6174+
6175+ 7.7. Information Disclosure in Message Forwarding
6176+
6177+ As discussed in Section 3.4, use of the 251 or 551 reply codes to
6178+ identify the replacement address associated with a mailbox may
6179+ inadvertently disclose sensitive information. Sites that are
6180+ concerned about those issues should ensure that they select and
6181+ configure servers appropriately.
6182+
6183+ 7.8. Resistance to Attacks
6184+
6185+ In recent years, there has been an increase of attacks on SMTP
6186+ servers, either in conjunction with attempts to discover addresses
6187+ for sending unsolicited messages or simply to make the servers
6188+ inaccessible to others (i.e., as an application-level denial of
6189+ service attack). While the means of doing so are beyond the scope of
6190+ this Standard, rational operational behavior requires that servers be
6191+ permitted to detect such attacks and take action to defend
6192+ themselves. For example, if a server determines that a large number
6193+ of RCPT TO commands are being sent, most or all with invalid
6194+ addresses, as part of such an attack, it would be reasonable for the
6195+ server to close the connection after generating an appropriate number
6196+ of 5yz (normally 550) replies.
6197+
6198+ 7.9. Scope of Operation of SMTP Servers
6199+
6200+ It is a well-established principle that an SMTP server may refuse to
6201+ accept mail for any operational or technical reason that makes sense
6202+ to the site providing the server. However, cooperation among sites
6203+ and installations makes the Internet possible. If sites take
6204+ excessive advantage of the right to reject traffic, the ubiquity of
6205+ email availability (one of the strengths of the Internet) will be
6206+ threatened; considerable care should be taken and balance maintained
6207+ if a site decides to be selective about the traffic it will accept
6208+ and process.
6209+
6210+
6211+
6212+
6213+ Klensin Standards Track [Page 78]
6214+
6215+ RFC 5321 SMTP October 2008
6216+
6217+
6218+ In recent years, use of the relay function through arbitrary sites
6219+ has been used as part of hostile efforts to hide the actual origins
6220+ of mail. Some sites have decided to limit the use of the relay
6221+ function to known or identifiable sources, and implementations SHOULD
6222+ provide the capability to perform this type of filtering. When mail
6223+ is rejected for these or other policy reasons, a 550 code SHOULD be
6224+ used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.
6225+
6226+ 8. IANA Considerations
6227+
6228+ IANA maintains three registries in support of this specification, all
6229+ of which were created for RFC 2821 or earlier. This document expands
6230+ the third one as specified below. The registry references listed are
6231+ as of the time of publication; IANA does not guarantee the locations
6232+ associated with the URLs. The registries are as follows:
6233+
6234+ o The first, "Simple Mail Transfer Protocol (SMTP) Service
6235+ Extensions" [46], consists of SMTP service extensions with the
6236+ associated keywords, and, as needed, parameters and verbs. As
6237+ specified in Section 2.2.2, no entry may be made in this registry
6238+ that starts in an "X". Entries may be made only for service
6239+ extensions (and associated keywords, parameters, or verbs) that
6240+ are defined in Standards-Track or Experimental RFCs specifically
6241+ approved by the IESG for this purpose.
6242+
6243+ o The second registry, "Address Literal Tags" [47], consists of
6244+ "tags" that identify forms of domain literals other than those for
6245+ IPv4 addresses (specified in RFC 821 and in this document). The
6246+ initial entry in that registry is for IPv6 addresses (specified in
6247+ this document). Additional literal types require standardization
6248+ before being used; none are anticipated at this time.
6249+
6250+ o The third, "Mail Transmission Types" [46], established by RFC 821
6251+ and renewed by this specification, is a registry of link and
6252+ protocol identifiers to be used with the "via" and "with"
6253+ subclauses of the time stamp ("Received:" header field) described
6254+ in Section 4.4. Link and protocol identifiers in addition to
6255+ those specified in this document may be registered only by
6256+ standardization or by way of an RFC-documented, IESG-approved,
6257+ Experimental protocol extension. This name space is for
6258+ identification and not limited in size: the IESG is encouraged to
6259+ approve on the basis of clear documentation and a distinct method
6260+ rather than preferences about the properties of the method itself.
6261+
6262+ An additional subsection has been added to the "VIA link types"
6263+ and "WITH protocol types" subsections of this registry to contain
6264+ registrations of "Additional-registered-clauses" as described
6265+ above. The registry will contain clause names, a description, a
6266+
6267+
6268+
6269+ Klensin Standards Track [Page 79]
6270+
6271+ RFC 5321 SMTP October 2008
6272+
6273+
6274+ summary of the syntax of the associated String, and a reference.
6275+ As new clauses are defined, they may, in principle, specify
6276+ creation of their own registries if the Strings consist of
6277+ reserved terms or keywords rather than less restricted strings.
6278+ As with link and protocol identifiers, additional clauses may be
6279+ registered only by standardization or by way of an RFC-documented,
6280+ IESG-approved, Experimental protocol extension. The additional
6281+ clause name space is for identification and is not limited in
6282+ size: the IESG is encouraged to approve on the basis of clear
6283+ documentation, actual use or strong signs that the clause will be
6284+ used, and a distinct requirement rather than preferences about the
6285+ properties of the clause itself.
6286+
6287+ In addition, if additional trace header fields (i.e., in addition to
6288+ Return-path and Received) are ever created, those trace fields MUST
6289+ be added to the IANA registry established by BCP 90 (RFC 3864) [11]
6290+ for use with RFC 5322 [4].
6291+
6292+ 9. Acknowledgments
6293+
6294+ Many people contributed to the development of RFC 2821. That
6295+ document should be consulted for those acknowledgments. For the
6296+ present document, the editor and the community owe thanks to Dawn
6297+ Mann and Tony Hansen who assisted in the very painful process of
6298+ editing and converting the internal format of the document from one
6299+ system to another.
6300+
6301+ Neither this document nor RFC 2821 would have been possible without
6302+ the many contribution and insights of the late Jon Postel. Those
6303+ contributions of course include the original specification of SMTP in
6304+ RFC 821. A considerable quantity of text from RFC 821 still appears
6305+ in this document as do several of Jon's original examples that have
6306+ been updated only as needed to reflect other changes in the
6307+ specification.
6308+
6309+ Many people made comments or suggestions on the mailing list or in
6310+ notes to the author. Important corrections or clarifications were
6311+ suggested by several people, including Matti Aarnio, Glenn Anderson,
6312+ Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint
6313+ Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman,
6314+ Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt
6315+ Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J.
6316+ Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias
6317+ Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett,
6318+ Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas
6319+ Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos,
6320+ David F. Skoll, Paul Smith, and Brett Watson.
6321+
6322+
6323+
6324+
6325+ Klensin Standards Track [Page 80]
6326+
6327+ RFC 5321 SMTP October 2008
6328+
6329+
6330+ The efforts of the Area Directors -- Lisa Dusseault, Ted Hardie, and
6331+ Chris Newman -- to get this effort restarted and keep it moving, and
6332+ of an ad hoc committee with the same purpose, are gratefully
6333+ acknowledged. The members of that committee were (in alphabetical
6334+ order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall
6335+ Gellens, Tony Hansen, the author, and Alexey Melnikov. Tony Hansen
6336+ also acted as ad hoc chair on the mailing list reviewing this
6337+ document; without his efforts, sense of balance and fairness, and
6338+ patience, it clearly would not have been possible.
6339+
6340+ 10. References
6341+
6342+ 10.1. Normative References
6343+
6344+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
6345+ August 1982.
6346+
6347+ [2] Mockapetris, P., "Domain names - implementation and
6348+ specification", STD 13, RFC 1035, November 1987.
6349+
6350+ [3] Braden, R., "Requirements for Internet Hosts - Application and
6351+ Support", STD 3, RFC 1123, October 1989.
6352+
6353+ [4] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
6354+
6355+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
6356+ Levels", BCP 14, RFC 2119, March 1997.
6357+
6358+ [6] American National Standards Institute (formerly United States
6359+ of America Standards Institute), "USA Code for Information
6360+ Interchange", ANSI X3.4-1968, 1968.
6361+
6362+ ANSI X3.4-1968 has been replaced by newer versions with slight
6363+ modifications, but the 1968 version remains definitive for the
6364+ Internet.
6365+
6366+ [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
6367+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
6368+
6369+ [8] Hinden, R. and S. Deering, "IP Version 6 Addressing
6370+ Architecture", RFC 4291, February 2006.
6371+
6372+ [9] Newman, C., "ESMTP and LMTP Transmission Types Registration",
6373+ RFC 3848, July 2004.
6374+
6375+ [10] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension
6376+ for Message Size Declaration", STD 10, RFC 1870, November 1995.
6377+
6378+
6379+
6380+
6381+ Klensin Standards Track [Page 81]
6382+
6383+ RFC 5321 SMTP October 2008
6384+
6385+
6386+ [11] Klyne, G., Nottingham, M., and J. Mogul, "Registration
6387+ Procedures for Message Header Fields", BCP 90, RFC 3864,
6388+ September 2004.
6389+
6390+ 10.2. Informative References
6391+
6392+ [12] Partridge, C., "Mail routing and the domain system", RFC 974,
6393+ January 1986.
6394+
6395+ [13] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
6396+ Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
6397+ November 1995.
6398+
6399+ [14] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
6400+ April 2001.
6401+
6402+ [15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J.
6403+ Reynolds, "Post Office Protocol: Version 2", RFC 937,
6404+ February 1985.
6405+
6406+ [16] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
6407+ STD 53, RFC 1939, May 1996.
6408+
6409+ [17] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
6410+ 4rev1", RFC 3501, March 2003.
6411+
6412+ [18] Gellens, R. and J. Klensin, "Message Submission for Mail",
6413+ RFC 4409, April 2006.
6414+
6415+ [19] Freed, N., "SMTP Service Extension for Command Pipelining",
6416+ STD 60, RFC 2920, September 2000.
6417+
6418+ [20] Vaudreuil, G., "SMTP Service Extensions for Transmission of
6419+ Large and Binary MIME Messages", RFC 3030, December 2000.
6420+
6421+ [21] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
6422+ Extensions (MIME) Part One: Format of Internet Message Bodies",
6423+ RFC 2045, November 1996.
6424+
6425+ [22] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
6426+ Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
6427+ RFC 1652, July 1994.
6428+
6429+ [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
6430+ Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
6431+ November 1996.
6432+
6433+
6434+
6435+
6436+
6437+ Klensin Standards Track [Page 82]
6438+
6439+ RFC 5321 SMTP October 2008
6440+
6441+
6442+ [24] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
6443+ Extensions: Character Sets, Languages, and Continuations",
6444+ RFC 2231, November 1997.
6445+
6446+ [25] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
6447+ January 2003.
6448+
6449+ [26] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail
6450+ System Status Codes", BCP 138, RFC 5248, June 2008.
6451+
6452+ [27] Freed, N., "Behavior of and Requirements for Internet
6453+ Firewalls", RFC 2979, October 2000.
6454+
6455+ [28] Crocker, D., "Standard for the format of ARPA Internet text
6456+ messages", STD 11, RFC 822, August 1982.
6457+
6458+ [29] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for
6459+ Authorizing Use of Domains in E-Mail, Version 1", RFC 4408,
6460+ April 2006.
6461+
6462+ [30] Fenton, J., "Analysis of Threats Motivating DomainKeys
6463+ Identified Mail (DKIM)", RFC 4686, September 2006.
6464+
6465+ [31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
6466+ M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
6467+ RFC 4871, May 2007.
6468+
6469+ [32] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
6470+ Extension for Delivery Status Notifications (DSNs)", RFC 3461,
6471+ January 2003.
6472+
6473+ [33] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
6474+ Delivery Status Notifications", RFC 3464, January 2003.
6475+
6476+ [34] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
6477+ RFC 959, October 1985.
6478+
6479+ [35] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
6480+ between X.400 and RFC 822/MIME", RFC 2156, January 1998.
6481+
6482+ [36] De Winter, J., "SMTP Service Extension for Remote Message Queue
6483+ Starting", RFC 1985, August 1996.
6484+
6485+ [37] Hansen, T. and G. Vaudreuil, "Message Disposition
6486+ Notification", RFC 3798, May 2004.
6487+
6488+ [38] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
6489+ RFC 2181, July 1997.
6490+
6491+
6492+
6493+ Klensin Standards Track [Page 83]
6494+
6495+ RFC 5321 SMTP October 2008
6496+
6497+
6498+ [39] Nakamura, M. and J. Hagino, "SMTP Operational Experience in
6499+ Mixed IPv4/v6 Environments", RFC 3974, January 2005.
6500+
6501+ [40] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
6502+ February 1988.
6503+
6504+ [41] Crispin, M., "Interactive Mail Access Protocol: Version 2",
6505+ RFC 1176, August 1990.
6506+
6507+ [42] Lambert, M., "PCMAIL: A distributed mail system for personal
6508+ computers", RFC 1056, June 1988.
6509+
6510+ [43] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
6511+ Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
6512+ RFC 1847, October 1995.
6513+
6514+ [44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
6515+ Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
6516+
6517+ [45] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
6518+ (S/MIME) Version 3.1 Message Specification", RFC 3851,
6519+ July 2004.
6520+
6521+ [46] Internet Assigned Number Authority (IANA), "IANA Mail
6522+ Parameters", 2007,
6523+ <http://www.iana.org/assignments/mail-parameters>.
6524+
6525+ [47] Internet Assigned Number Authority (IANA), "Address Literal
6526+ Tags", 2007,
6527+ <http://www.iana.org/assignments/address-literal-tags>.
6528+
6529+
6530+
6531+
6532+
6533+
6534+
6535+
6536+
6537+
6538+
6539+
6540+
6541+
6542+
6543+
6544+
6545+
6546+
6547+
6548+
6549+ Klensin Standards Track [Page 84]
6550+
6551+ RFC 5321 SMTP October 2008
6552+
6553+
6554+ Appendix A. TCP Transport Service
6555+
6556+ The TCP connection supports the transmission of 8-bit bytes. The
6557+ SMTP data is 7-bit ASCII characters. Each character is transmitted
6558+ as an 8-bit byte with the high-order bit cleared to zero. Service
6559+ extensions may modify this rule to permit transmission of full 8-bit
6560+ data bytes as part of the message body, or, if specifically designed
6561+ to do so, in SMTP commands or responses.
6562+
6563+ Appendix B. Generating SMTP Commands from RFC 822 Header Fields
6564+
6565+ Some systems use an RFC 822 header section (only) in a mail
6566+ submission protocol, or otherwise generate SMTP commands from RFC 822
6567+ header fields when such a message is handed to an MTA from a UA.
6568+ While the MTA-UA protocol is a private matter, not covered by any
6569+ Internet Standard, there are problems with this approach. For
6570+ example, there have been repeated problems with proper handling of
6571+ "bcc" copies and redistribution lists when information that
6572+ conceptually belongs to the mail envelope is not separated early in
6573+ processing from header field information (and kept separate).
6574+
6575+ It is recommended that the UA provide its initial ("submission
6576+ client") MTA with an envelope separate from the message itself.
6577+ However, if the envelope is not supplied, SMTP commands SHOULD be
6578+ generated as follows:
6579+
6580+ 1. Each recipient address from a TO, CC, or BCC header field SHOULD
6581+ be copied to a RCPT command (generating multiple message copies
6582+ if that is required for queuing or delivery). This includes any
6583+ addresses listed in a RFC 822 "group". Any BCC header fields
6584+ SHOULD then be removed from the header section. Once this
6585+ process is completed, the remaining header fields SHOULD be
6586+ checked to verify that at least one TO, CC, or BCC header field
6587+ remains. If none do, then a BCC header field with no additional
6588+ information SHOULD be inserted as specified in [4].
6589+
6590+ 2. The return address in the MAIL command SHOULD, if possible, be
6591+ derived from the system's identity for the submitting (local)
6592+ user, and the "From:" header field otherwise. If there is a
6593+ system identity available, it SHOULD also be copied to the Sender
6594+ header field if it is different from the address in the From
6595+ header field. (Any Sender header field that was already there
6596+ SHOULD be removed.) Systems may provide a way for submitters to
6597+ override the envelope return address, but may want to restrict
6598+ its use to privileged users. This will not prevent mail forgery,
6599+ but may lessen its incidence; see Section 7.1.
6600+
6601+
6602+
6603+
6604+
6605+ Klensin Standards Track [Page 85]
6606+
6607+ RFC 5321 SMTP October 2008
6608+
6609+
6610+ When an MTA is being used in this way, it bears responsibility for
6611+ ensuring that the message being transmitted is valid. The mechanisms
6612+ for checking that validity, and for handling (or returning) messages
6613+ that are not valid at the time of arrival, are part of the MUA-MTA
6614+ interface and not covered by this specification.
6615+
6616+ A submission protocol based on Standard RFC 822 information alone
6617+ MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
6618+ system into an SMTP environment. Additional information to construct
6619+ an envelope must come from some source in the other environment,
6620+ whether supplemental header fields or the foreign system's envelope.
6621+
6622+ Attempts to gateway messages using only their header "To" and "Cc"
6623+ fields have repeatedly caused mail loops and other behavior adverse
6624+ to the proper functioning of the Internet mail environment. These
6625+ problems have been especially common when the message originates from
6626+ an Internet mailing list and is distributed into the foreign
6627+ environment using envelope information. When these messages are then
6628+ processed by a header-section-only remailer, loops back to the
6629+ Internet environment (and the mailing list) are almost inevitable.
6630+
6631+ Appendix C. Source Routes
6632+
6633+ Historically, the <reverse-path> was a reverse source routing list of
6634+ hosts and a source mailbox. The first host in the <reverse-path> was
6635+ historically the host sending the MAIL command; today, source routes
6636+ SHOULD NOT appear in the reverse-path. Similarly, the <forward-path>
6637+ may be a source routing lists of hosts and a destination mailbox.
6638+ However, in general, the <forward-path> SHOULD contain only a mailbox
6639+ and domain name, relying on the domain name system to supply routing
6640+ information if required. The use of source routes is deprecated (see
6641+ Appendix F.2); while servers MUST be prepared to receive and handle
6642+ them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT
6643+ transmit them and this section is included in the current
6644+ specification only to provide context. It has been modified somewhat
6645+ from the material in RFC 821 to prevent server actions that might
6646+ confuse clients or subsequent servers that do not expect a full
6647+ source route implementation.
6648+
6649+ For relay purposes, the forward-path may be a source route of the
6650+ form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully-
6651+ qualified domain names. This form is used to emphasize the
6652+ distinction between an address and a route. The mailbox (here, JOE@
6653+ THREE) is an absolute address, and the route is information about how
6654+ to get there. The two concepts should not be confused.
6655+
6656+ If source routes are used, RFC 821 and the text below should be
6657+ consulted for the mechanisms for constructing and updating the
6658+
6659+
6660+
6661+ Klensin Standards Track [Page 86]
6662+
6663+ RFC 5321 SMTP October 2008
6664+
6665+
6666+ forward-path. A server that is reached by means of a source route
6667+ (e.g., its domain name appears first in the list in the forward-path)
6668+ MUST remove its domain name from any forward-paths in which that
6669+ domain name appears before forwarding the message and MAY remove all
6670+ other source routing information. The reverse-path SHOULD NOT be
6671+ updated by servers conforming to this specification.
6672+
6673+ Notice that the forward-path and reverse-path appear in the SMTP
6674+ commands and replies, but not necessarily in the message. That is,
6675+ there is no need for these paths and especially this syntax to appear
6676+ in the "To:" , "From:", "CC:", etc. fields of the message header
6677+ section. Conversely, SMTP servers MUST NOT derive final message
6678+ routing information from message header fields.
6679+
6680+ When the list of hosts is present despite the recommendations above,
6681+ it is a "reverse" source route and indicates that the mail was
6682+ relayed through each host on the list (the first host in the list was
6683+ the most recent relay). This list is used as a source route to
6684+ return non-delivery notices to the sender. If, contrary to the
6685+ recommendations here, a relay host adds itself to the beginning of
6686+ the list, it MUST use its name as known in the transport environment
6687+ to which it is relaying the mail rather than that of the transport
6688+ environment from which the mail came (if they are different). Note
6689+ that a situation could easily arise in which some relay hosts add
6690+ their names to the reverse source route and others do not, generating
6691+ discontinuities in the routing list. This is another reason why
6692+ servers needing to return a message SHOULD ignore the source route
6693+ entirely and simply use the domain as specified in the Mailbox.
6694+
6695+ Appendix D. Scenarios
6696+
6697+ This section presents complete scenarios of several types of SMTP
6698+ sessions. In the examples, "C:" indicates what is said by the SMTP
6699+ client, and "S:" indicates what is said by the SMTP server.
6700+
6701+
6702+
6703+
6704+
6705+
6706+
6707+
6708+
6709+
6710+
6711+
6712+
6713+
6714+
6715+
6716+
6717+ Klensin Standards Track [Page 87]
6718+
6719+ RFC 5321 SMTP October 2008
6720+
6721+
6722+ D.1. A Typical SMTP Transaction Scenario
6723+
6724+ This SMTP example shows mail sent by Smith at host bar.com, and to
6725+ Jones, Green, and Brown at host foo.com. Here we assume that host
6726+ bar.com contacts host foo.com directly. The mail is accepted for
6727+ Jones and Brown. Green does not have a mailbox at host foo.com.
6728+
6729+ S: 220 foo.com Simple Mail Transfer Service Ready
6730+ C: EHLO bar.com
6731+ S: 250-foo.com greets bar.com
6732+ S: 250-8BITMIME
6733+ S: 250-SIZE
6734+ S: 250-DSN
6735+ S: 250 HELP
6736+ C: MAIL FROM:<Smith@bar.com>
6737+ S: 250 OK
6738+ C: RCPT TO:<Jones@foo.com>
6739+ S: 250 OK
6740+ C: RCPT TO:<Green@foo.com>
6741+ S: 550 No such user here
6742+ C: RCPT TO:<Brown@foo.com>
6743+ S: 250 OK
6744+ C: DATA
6745+ S: 354 Start mail input; end with <CRLF>.<CRLF>
6746+ C: Blah blah blah...
6747+ C: ...etc. etc. etc.
6748+ C: .
6749+ S: 250 OK
6750+ C: QUIT
6751+ S: 221 foo.com Service closing transmission channel
6752+
6753+
6754+
6755+
6756+
6757+
6758+
6759+
6760+
6761+
6762+
6763+
6764+
6765+
6766+
6767+
6768+
6769+
6770+
6771+
6772+
6773+ Klensin Standards Track [Page 88]
6774+
6775+ RFC 5321 SMTP October 2008
6776+
6777+
6778+ D.2. Aborted SMTP Transaction Scenario
6779+
6780+ S: 220 foo.com Simple Mail Transfer Service Ready
6781+ C: EHLO bar.com
6782+ S: 250-foo.com greets bar.com
6783+ S: 250-8BITMIME
6784+ S: 250-SIZE
6785+ S: 250-DSN
6786+ S: 250 HELP
6787+ C: MAIL FROM:<Smith@bar.com>
6788+ S: 250 OK
6789+ C: RCPT TO:<Jones@foo.com>
6790+ S: 250 OK
6791+ C: RCPT TO:<Green@foo.com>
6792+ S: 550 No such user here
6793+ C: RSET
6794+ S: 250 OK
6795+ C: QUIT
6796+ S: 221 foo.com Service closing transmission channel
6797+
6798+
6799+
6800+
6801+
6802+
6803+
6804+
6805+
6806+
6807+
6808+
6809+
6810+
6811+
6812+
6813+
6814+
6815+
6816+
6817+
6818+
6819+
6820+
6821+
6822+
6823+
6824+
6825+
6826+
6827+
6828+
6829+ Klensin Standards Track [Page 89]
6830+
6831+ RFC 5321 SMTP October 2008
6832+
6833+
6834+ D.3. Relayed Mail Scenario
6835+
6836+ Step 1 -- Source Host to Relay Host
6837+
6838+ The source host performs a DNS lookup on XYZ.COM (the destination
6839+ address) and finds DNS MX records specifying xyz.com as the best
6840+ preference and foo.com as a lower preference. It attempts to open a
6841+ connection to xyz.com and fails. It then opens a connection to
6842+ foo.com, with the following dialogue:
6843+
6844+ S: 220 foo.com Simple Mail Transfer Service Ready
6845+ C: EHLO bar.com
6846+ S: 250-foo.com greets bar.com
6847+ S: 250-8BITMIME
6848+ S: 250-SIZE
6849+ S: 250-DSN
6850+ S: 250 HELP
6851+ C: MAIL FROM:<JQP@bar.com>
6852+ S: 250 OK
6853+ C: RCPT TO:<Jones@XYZ.COM>
6854+ S: 250 OK
6855+ C: DATA
6856+ S: 354 Start mail input; end with <CRLF>.<CRLF>
6857+ C: Date: Thu, 21 May 1998 05:33:29 -0700
6858+ C: From: John Q. Public <JQP@bar.com>
6859+ C: Subject: The Next Meeting of the Board
6860+ C: To: Jones@xyz.com
6861+ C:
6862+ C: Bill:
6863+ C: The next meeting of the board of directors will be
6864+ C: on Tuesday.
6865+ C: John.
6866+ C: .
6867+ S: 250 OK
6868+ C: QUIT
6869+ S: 221 foo.com Service closing transmission channel
6870+
6871+
6872+
6873+
6874+
6875+
6876+
6877+
6878+
6879+
6880+
6881+
6882+
6883+
6884+
6885+ Klensin Standards Track [Page 90]
6886+
6887+ RFC 5321 SMTP October 2008
6888+
6889+
6890+ Step 2 -- Relay Host to Destination Host
6891+
6892+ foo.com, having received the message, now does a DNS lookup on
6893+ xyz.com. It finds the same set of MX records, but cannot use the one
6894+ that points to itself (or to any other host as a worse preference).
6895+ It tries to open a connection to xyz.com itself and succeeds. Then
6896+ we have:
6897+
6898+ S: 220 xyz.com Simple Mail Transfer Service Ready
6899+ C: EHLO foo.com
6900+ S: 250 xyz.com is on the air
6901+ C: MAIL FROM:<JQP@bar.com>
6902+ S: 250 OK
6903+ C: RCPT TO:<Jones@XYZ.COM>
6904+ S: 250 OK
6905+ C: DATA
6906+ S: 354 Start mail input; end with <CRLF>.<CRLF>
6907+ C: Received: from bar.com by foo.com ; Thu, 21 May 1998
6908+ C: 05:33:29 -0700
6909+ C: Date: Thu, 21 May 1998 05:33:22 -0700
6910+ C: From: John Q. Public <JQP@bar.com>
6911+ C: Subject: The Next Meeting of the Board
6912+ C: To: Jones@xyz.com
6913+ C:
6914+ C: Bill:
6915+ C: The next meeting of the board of directors will be
6916+ C: on Tuesday.
6917+ C: John.
6918+ C: .
6919+ S: 250 OK
6920+ C: QUIT
6921+ S: 221 foo.com Service closing transmission channel
6922+
6923+
6924+
6925+
6926+
6927+
6928+
6929+
6930+
6931+
6932+
6933+
6934+
6935+
6936+
6937+
6938+
6939+
6940+
6941+ Klensin Standards Track [Page 91]
6942+
6943+ RFC 5321 SMTP October 2008
6944+
6945+
6946+ D.4. Verifying and Sending Scenario
6947+
6948+ S: 220 foo.com Simple Mail Transfer Service Ready
6949+ C: EHLO bar.com
6950+ S: 250-foo.com greets bar.com
6951+ S: 250-8BITMIME
6952+ S: 250-SIZE
6953+ S: 250-DSN
6954+ S: 250-VRFY
6955+ S: 250 HELP
6956+ C: VRFY Crispin
6957+ S: 250 Mark Crispin <Admin.MRC@foo.com>
6958+ C: MAIL FROM:<EAK@bar.com>
6959+ S: 250 OK
6960+ C: RCPT TO:<Admin.MRC@foo.com>
6961+ S: 250 OK
6962+ C: DATA
6963+ S: 354 Start mail input; end with <CRLF>.<CRLF>
6964+ C: Blah blah blah...
6965+ C: ...etc. etc. etc.
6966+ C: .
6967+ S: 250 OK
6968+ C: QUIT
6969+ S: 221 foo.com Service closing transmission channel
6970+
6971+ Appendix E. Other Gateway Issues
6972+
6973+ In general, gateways between the Internet and other mail systems
6974+ SHOULD attempt to preserve any layering semantics across the
6975+ boundaries between the two mail systems involved. Gateway-
6976+ translation approaches that attempt to take shortcuts by mapping
6977+ (such as mapping envelope information from one system to the message
6978+ header section or body of another) have generally proven to be
6979+ inadequate in important ways. Systems translating between
6980+ environments that do not support both envelopes and a header section
6981+ and Internet mail must be written with the understanding that some
6982+ information loss is almost inevitable.
6983+
6984+
6985+
6986+
6987+
6988+
6989+
6990+
6991+
6992+
6993+
6994+
6995+
6996+
6997+ Klensin Standards Track [Page 92]
6998+
6999+ RFC 5321 SMTP October 2008
7000+
7001+
7002+ Appendix F. Deprecated Features of RFC 821
7003+
7004+ A few features of RFC 821 have proven to be problematic and SHOULD
7005+ NOT be used in Internet mail.
7006+
7007+ F.1. TURN
7008+
7009+ This command, described in RFC 821, raises important security issues
7010+ since, in the absence of strong authentication of the host requesting
7011+ that the client and server switch roles, it can easily be used to
7012+ divert mail from its correct destination. Its use is deprecated;
7013+ SMTP systems SHOULD NOT use it unless the server can authenticate the
7014+ client.
7015+
7016+ F.2. Source Routing
7017+
7018+ RFC 821 utilized the concept of explicit source routing to get mail
7019+ from one host to another via a series of relays. The requirement to
7020+ utilize source routes in regular mail traffic was eliminated by the
7021+ introduction of the domain name system "MX" record and the last
7022+ significant justification for them was eliminated by the
7023+ introduction, in RFC 1123, of a clear requirement that addresses
7024+ following an "@" must all be fully-qualified domain names.
7025+ Consequently, the only remaining justifications for the use of source
7026+ routes are support for very old SMTP clients or MUAs and in mail
7027+ system debugging. They can, however, still be useful in the latter
7028+ circumstance and for routing mail around serious, but temporary,
7029+ problems such as problems with the relevant DNS records.
7030+
7031+ SMTP servers MUST continue to accept source route syntax as specified
7032+ in the main body of this document and in RFC 1123. They MAY, if
7033+ necessary, ignore the routes and utilize only the target domain in
7034+ the address. If they do utilize the source route, the message MUST
7035+ be sent to the first domain shown in the address. In particular, a
7036+ server MUST NOT guess at shortcuts within the source route.
7037+
7038+ Clients SHOULD NOT utilize explicit source routing except under
7039+ unusual circumstances, such as debugging or potentially relaying
7040+ around firewall or mail system configuration errors.
7041+
7042+ F.3. HELO
7043+
7044+ As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather
7045+ than HELO when the server will accept the former. Servers MUST
7046+ continue to accept and process HELO in order to support older
7047+ clients.
7048+
7049+
7050+
7051+
7052+
7053+ Klensin Standards Track [Page 93]
7054+
7055+ RFC 5321 SMTP October 2008
7056+
7057+
7058+ F.4. #-literals
7059+
7060+ RFC 821 provided for specifying an Internet address as a decimal
7061+ integer host number prefixed by a pound sign, "#". In practice, that
7062+ form has been obsolete since the introduction of TCP/IP. It is
7063+ deprecated and MUST NOT be used.
7064+
7065+ F.5. Dates and Years
7066+
7067+ When dates are inserted into messages by SMTP clients or servers
7068+ (e.g., in trace header fields), four-digit years MUST BE used. Two-
7069+ digit years are deprecated; three-digit years were never permitted in
7070+ the Internet mail system.
7071+
7072+ F.6. Sending versus Mailing
7073+
7074+ In addition to specifying a mechanism for delivering messages to
7075+ user's mailboxes, RFC 821 provided additional, optional, commands to
7076+ deliver messages directly to the user's terminal screen. These
7077+ commands (SEND, SAML, SOML) were rarely implemented, and changes in
7078+ workstation technology and the introduction of other protocols may
7079+ have rendered them obsolete even where they are implemented.
7080+
7081+ Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
7082+ MAY implement them. If they are implemented by servers, the
7083+ implementation model specified in RFC 821 MUST be used and the
7084+ command names MUST be published in the response to the EHLO command.
7085+
7086+ Author's Address
7087+
7088+ John C. Klensin
7089+ 1770 Massachusetts Ave, Suite 322
7090+ Cambridge, MA 02140
7091+ USA
7092+
7093+ EMail: john+smtp@jck.com
7094+
7095+
7096+
7097+
7098+
7099+
7100+
7101+
7102+
7103+
7104+
7105+
7106+
7107+
7108+
7109+ Klensin Standards Track [Page 94]
7110+
7111+ RFC 5321 SMTP October 2008
7112+
7113+
7114+ Full Copyright Statement
7115+
7116+ Copyright (C) The IETF Trust (2008).
7117+
7118+ This document is subject to the rights, licenses and restrictions
7119+ contained in BCP 78, and except as set forth therein, the authors
7120+ retain all their rights.
7121+
7122+ This document and the information contained herein are provided on an
7123+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
7124+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
7125+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
7126+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
7127+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
7128+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7129+
7130+ Intellectual Property
7131+
7132+ The IETF takes no position regarding the validity or scope of any
7133+ Intellectual Property Rights or other rights that might be claimed to
7134+ pertain to the implementation or use of the technology described in
7135+ this document or the extent to which any license under such rights
7136+ might or might not be available; nor does it represent that it has
7137+ made any independent effort to identify any such rights. Information
7138+ on the procedures with respect to rights in RFC documents can be
7139+ found in BCP 78 and BCP 79.
7140+
7141+ Copies of IPR disclosures made to the IETF Secretariat and any
7142+ assurances of licenses to be made available, or the result of an
7143+ attempt made to obtain a general license or permission for the use of
7144+ such proprietary rights by implementers or users of this
7145+ specification can be obtained from the IETF on-line IPR repository at
7146+ http://www.ietf.org/ipr.
7147+
7148+ The IETF invites any interested party to bring to its attention any
7149+ copyrights, patents or patent applications, or other proprietary
7150+ rights that may cover technology that may be required to implement
7151+ this standard. Please address the information to the IETF at
7152+ ietf-ipr@ietf.org.
7153+
7154+
7155+
7156+
7157+
7158+
7159+
7160+
7161+
7162+
7163+
7164+
7165+ Klensin Standards Track [Page 95]
7166+
7167 diff --git a/rfcs/rfc5322.txt b/rfcs/rfc5322.txt
7168new file mode 100644
7169index 0000000..f330686
7170--- /dev/null
7171+++ b/rfcs/rfc5322.txt
7172 @@ -0,0 +1,3195 @@
7173+
7174+
7175+
7176+
7177+
7178+
7179+ Network Working Group P. Resnick, Ed.
7180+ Request for Comments: 5322 Qualcomm Incorporated
7181+ Obsoletes: 2822 October 2008
7182+ Updates: 4021
7183+ Category: Standards Track
7184+
7185+
7186+ Internet Message Format
7187+
7188+ Status of This Memo
7189+
7190+ This document specifies an Internet standards track protocol for the
7191+ Internet community, and requests discussion and suggestions for
7192+ improvements. Please refer to the current edition of the "Internet
7193+ Official Protocol Standards" (STD 1) for the standardization state
7194+ and status of this protocol. Distribution of this memo is unlimited.
7195+
7196+ Abstract
7197+
7198+ This document specifies the Internet Message Format (IMF), a syntax
7199+ for text messages that are sent between computer users, within the
7200+ framework of "electronic mail" messages. This specification is a
7201+ revision of Request For Comments (RFC) 2822, which itself superseded
7202+ Request For Comments (RFC) 822, "Standard for the Format of ARPA
7203+ Internet Text Messages", updating it to reflect current practice and
7204+ incorporating incremental changes that were specified in other RFCs.
7205+
7206+
7207+
7208+
7209+
7210+
7211+
7212+
7213+
7214+
7215+
7216+
7217+
7218+
7219+
7220+
7221+
7222+
7223+
7224+
7225+
7226+
7227+
7228+
7229+
7230+ Resnick Standards Track [Page 1]
7231+
7232+ RFC 5322 Internet Message Format October 2008
7233+
7234+
7235+ Table of Contents
7236+
7237+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
7238+ 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7239+ 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 5
7240+ 1.2.1. Requirements Notation . . . . . . . . . . . . . . . . 5
7241+ 1.2.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 5
7242+ 1.2.3. Structure of This Document . . . . . . . . . . . . . . 5
7243+ 2. Lexical Analysis of Messages . . . . . . . . . . . . . . . . . 6
7244+ 2.1. General Description . . . . . . . . . . . . . . . . . . . 6
7245+ 2.1.1. Line Length Limits . . . . . . . . . . . . . . . . . . 7
7246+ 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8
7247+ 2.2.1. Unstructured Header Field Bodies . . . . . . . . . . . 8
7248+ 2.2.2. Structured Header Field Bodies . . . . . . . . . . . . 8
7249+ 2.2.3. Long Header Fields . . . . . . . . . . . . . . . . . . 8
7250+ 2.3. Body . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7251+ 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7252+ 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
7253+ 3.2. Lexical Tokens . . . . . . . . . . . . . . . . . . . . . . 10
7254+ 3.2.1. Quoted characters . . . . . . . . . . . . . . . . . . 10
7255+ 3.2.2. Folding White Space and Comments . . . . . . . . . . . 11
7256+ 3.2.3. Atom . . . . . . . . . . . . . . . . . . . . . . . . . 12
7257+ 3.2.4. Quoted Strings . . . . . . . . . . . . . . . . . . . . 13
7258+ 3.2.5. Miscellaneous Tokens . . . . . . . . . . . . . . . . . 14
7259+ 3.3. Date and Time Specification . . . . . . . . . . . . . . . 14
7260+ 3.4. Address Specification . . . . . . . . . . . . . . . . . . 16
7261+ 3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 17
7262+ 3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . . 18
7263+ 3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 19
7264+ 3.6.1. The Origination Date Field . . . . . . . . . . . . . . 22
7265+ 3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 22
7266+ 3.6.3. Destination Address Fields . . . . . . . . . . . . . . 23
7267+ 3.6.4. Identification Fields . . . . . . . . . . . . . . . . 25
7268+ 3.6.5. Informational Fields . . . . . . . . . . . . . . . . . 27
7269+ 3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 28
7270+ 3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . . 30
7271+ 3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 30
7272+ 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 31
7273+ 4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 32
7274+ 4.2. Obsolete Folding White Space . . . . . . . . . . . . . . . 33
7275+ 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33
7276+ 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 35
7277+ 4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 35
7278+ 4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 36
7279+ 4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . . 36
7280+ 4.5.3. Obsolete Destination Address Fields . . . . . . . . . 37
7281+ 4.5.4. Obsolete Identification Fields . . . . . . . . . . . . 37
7282+ 4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 37
7283+
7284+
7285+
7286+ Resnick Standards Track [Page 2]
7287+
7288+ RFC 5322 Internet Message Format October 2008
7289+
7290+
7291+ 4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . . 38
7292+ 4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 38
7293+ 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38
7294+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7295+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
7296+ Appendix A. Example Messages . . . . . . . . . . . . . . . . . 43
7297+ Appendix A.1. Addressing Examples . . . . . . . . . . . . . . . 44
7298+ Appendix A.1.1. A Message from One Person to Another with
7299+ Simple Addressing . . . . . . . . . . . . . . . . 44
7300+ Appendix A.1.2. Different Types of Mailboxes . . . . . . . . . . . 45
7301+ Appendix A.1.3. Group Addresses . . . . . . . . . . . . . . . . . 45
7302+ Appendix A.2. Reply Messages . . . . . . . . . . . . . . . . . . 46
7303+ Appendix A.3. Resent Messages . . . . . . . . . . . . . . . . . 47
7304+ Appendix A.4. Messages with Trace Fields . . . . . . . . . . . . 48
7305+ Appendix A.5. White Space, Comments, and Other Oddities . . . . 49
7306+ Appendix A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . 50
7307+ Appendix A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . 50
7308+ Appendix A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . 50
7309+ Appendix A.6.3. Obsolete White Space and Comments . . . . . . . . 51
7310+ Appendix B. Differences from Earlier Specifications . . . . . 52
7311+ Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 53
7312+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7313+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 55
7314+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 55
7315+
7316+
7317+
7318+
7319+
7320+
7321+
7322+
7323+
7324+
7325+
7326+
7327+
7328+
7329+
7330+
7331+
7332+
7333+
7334+
7335+
7336+
7337+
7338+
7339+
7340+
7341+
7342+ Resnick Standards Track [Page 3]
7343+
7344+ RFC 5322 Internet Message Format October 2008
7345+
7346+
7347+ 1. Introduction
7348+
7349+ 1.1. Scope
7350+
7351+ This document specifies the Internet Message Format (IMF), a syntax
7352+ for text messages that are sent between computer users, within the
7353+ framework of "electronic mail" messages. This specification is an
7354+ update to [RFC2822], which itself superseded [RFC0822], updating it
7355+ to reflect current practice and incorporating incremental changes
7356+ that were specified in other RFCs such as [RFC1123].
7357+
7358+ This document specifies a syntax only for text messages. In
7359+ particular, it makes no provision for the transmission of images,
7360+ audio, or other sorts of structured data in electronic mail messages.
7361+ There are several extensions published, such as the MIME document
7362+ series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
7363+ for the transmission of such data through electronic mail, either by
7364+ extending the syntax provided here or by structuring such messages to
7365+ conform to this syntax. Those mechanisms are outside of the scope of
7366+ this specification.
7367+
7368+ In the context of electronic mail, messages are viewed as having an
7369+ envelope and contents. The envelope contains whatever information is
7370+ needed to accomplish transmission and delivery. (See [RFC5321] for a
7371+ discussion of the envelope.) The contents comprise the object to be
7372+ delivered to the recipient. This specification applies only to the
7373+ format and some of the semantics of message contents. It contains no
7374+ specification of the information in the envelope.
7375+
7376+ However, some message systems may use information from the contents
7377+ to create the envelope. It is intended that this specification
7378+ facilitate the acquisition of such information by programs.
7379+
7380+ This specification is intended as a definition of what message
7381+ content format is to be passed between systems. Though some message
7382+ systems locally store messages in this format (which eliminates the
7383+ need for translation between formats) and others use formats that
7384+ differ from the one specified in this specification, local storage is
7385+ outside of the scope of this specification.
7386+
7387+ Note: This specification is not intended to dictate the internal
7388+ formats used by sites, the specific message system features that
7389+ they are expected to support, or any of the characteristics of
7390+ user interface programs that create or read messages. In
7391+ addition, this document does not specify an encoding of the
7392+ characters for either transport or storage; that is, it does not
7393+ specify the number of bits used or how those bits are specifically
7394+ transferred over the wire or stored on disk.
7395+
7396+
7397+
7398+ Resnick Standards Track [Page 4]
7399+
7400+ RFC 5322 Internet Message Format October 2008
7401+
7402+
7403+ 1.2. Notational Conventions
7404+
7405+ 1.2.1. Requirements Notation
7406+
7407+ This document occasionally uses terms that appear in capital letters.
7408+ When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
7409+ NOT", and "MAY" appear capitalized, they are being used to indicate
7410+ particular requirements of this specification. A discussion of the
7411+ meanings of these terms appears in [RFC2119].
7412+
7413+ 1.2.2. Syntactic Notation
7414+
7415+ This specification uses the Augmented Backus-Naur Form (ABNF)
7416+ [RFC5234] notation for the formal definitions of the syntax of
7417+ messages. Characters will be specified either by a decimal value
7418+ (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
7419+ a case-insensitive literal value enclosed in quotation marks (e.g.,
7420+ "A" for either uppercase or lowercase A).
7421+
7422+ 1.2.3. Structure of This Document
7423+
7424+ This document is divided into several sections.
7425+
7426+ This section, section 1, is a short introduction to the document.
7427+
7428+ Section 2 lays out the general description of a message and its
7429+ constituent parts. This is an overview to help the reader understand
7430+ some of the general principles used in the later portions of this
7431+ document. Any examples in this section MUST NOT be taken as
7432+ specification of the formal syntax of any part of a message.
7433+
7434+ Section 3 specifies formal ABNF rules for the structure of each part
7435+ of a message (the syntax) and describes the relationship between
7436+ those parts and their meaning in the context of a message (the
7437+ semantics). That is, it lays out the actual rules for the structure
7438+ of each part of a message (the syntax) as well as a description of
7439+ the parts and instructions for their interpretation (the semantics).
7440+ This includes analysis of the syntax and semantics of subparts of
7441+ messages that have specific structure. The syntax included in
7442+ section 3 represents messages as they MUST be created. There are
7443+ also notes in section 3 to indicate if any of the options specified
7444+ in the syntax SHOULD be used over any of the others.
7445+
7446+ Both sections 2 and 3 describe messages that are legal to generate
7447+ for purposes of this specification.
7448+
7449+
7450+
7451+
7452+
7453+
7454+ Resnick Standards Track [Page 5]
7455+
7456+ RFC 5322 Internet Message Format October 2008
7457+
7458+
7459+ Section 4 of this document specifies an "obsolete" syntax. There are
7460+ references in section 3 to these obsolete syntactic elements. The
7461+ rules of the obsolete syntax are elements that have appeared in
7462+ earlier versions of this specification or have previously been widely
7463+ used in Internet messages. As such, these elements MUST be
7464+ interpreted by parsers of messages in order to be conformant to this
7465+ specification. However, since items in this syntax have been
7466+ determined to be non-interoperable or to cause significant problems
7467+ for recipients of messages, they MUST NOT be generated by creators of
7468+ conformant messages.
7469+
7470+ Section 5 details security considerations to take into account when
7471+ implementing this specification.
7472+
7473+ Appendix A lists examples of different sorts of messages. These
7474+ examples are not exhaustive of the types of messages that appear on
7475+ the Internet, but give a broad overview of certain syntactic forms.
7476+
7477+ Appendix B lists the differences between this specification and
7478+ earlier specifications for Internet messages.
7479+
7480+ Appendix C contains acknowledgements.
7481+
7482+ 2. Lexical Analysis of Messages
7483+
7484+ 2.1. General Description
7485+
7486+ At the most basic level, a message is a series of characters. A
7487+ message that is conformant with this specification is composed of
7488+ characters with values in the range of 1 through 127 and interpreted
7489+ as US-ASCII [ANSI.X3-4.1986] characters. For brevity, this document
7490+ sometimes refers to this range of characters as simply "US-ASCII
7491+ characters".
7492+
7493+ Note: This document specifies that messages are made up of
7494+ characters in the US-ASCII range of 1 through 127. There are
7495+ other documents, specifically the MIME document series ([RFC2045],
7496+ [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
7497+ extend this specification to allow for values outside of that
7498+ range. Discussion of those mechanisms is not within the scope of
7499+ this specification.
7500+
7501+ Messages are divided into lines of characters. A line is a series of
7502+ characters that is delimited with the two characters carriage-return
7503+ and line-feed; that is, the carriage return (CR) character (ASCII
7504+ value 13) followed immediately by the line feed (LF) character (ASCII
7505+ value 10). (The carriage return/line feed pair is usually written in
7506+ this document as "CRLF".)
7507+
7508+
7509+
7510+ Resnick Standards Track [Page 6]
7511+
7512+ RFC 5322 Internet Message Format October 2008
7513+
7514+
7515+ A message consists of header fields (collectively called "the header
7516+ section of the message") followed, optionally, by a body. The header
7517+ section is a sequence of lines of characters with special syntax as
7518+ defined in this specification. The body is simply a sequence of
7519+ characters that follows the header section and is separated from the
7520+ header section by an empty line (i.e., a line with nothing preceding
7521+ the CRLF).
7522+
7523+ Note: Common parlance and earlier versions of this specification
7524+ use the term "header" to either refer to the entire header section
7525+ or to refer to an individual header field. To avoid ambiguity,
7526+ this document does not use the terms "header" or "headers" in
7527+ isolation, but instead always uses "header field" to refer to the
7528+ individual field and "header section" to refer to the entire
7529+ collection.
7530+
7531+ 2.1.1. Line Length Limits
7532+
7533+ There are two limits that this specification places on the number of
7534+ characters in a line. Each line of characters MUST be no more than
7535+ 998 characters, and SHOULD be no more than 78 characters, excluding
7536+ the CRLF.
7537+
7538+ The 998 character limit is due to limitations in many implementations
7539+ that send, receive, or store IMF messages which simply cannot handle
7540+ more than 998 characters on a line. Receiving implementations would
7541+ do well to handle an arbitrarily large number of characters in a line
7542+ for robustness sake. However, there are so many implementations that
7543+ (in compliance with the transport requirements of [RFC5321]) do not
7544+ accept messages containing more than 1000 characters including the CR
7545+ and LF per line, it is important for implementations not to create
7546+ such messages.
7547+
7548+ The more conservative 78 character recommendation is to accommodate
7549+ the many implementations of user interfaces that display these
7550+ messages which may truncate, or disastrously wrap, the display of
7551+ more than 78 characters per line, in spite of the fact that such
7552+ implementations are non-conformant to the intent of this
7553+ specification (and that of [RFC5321] if they actually cause
7554+ information to be lost). Again, even though this limitation is put
7555+ on messages, it is incumbent upon implementations that display
7556+ messages to handle an arbitrarily large number of characters in a
7557+ line (certainly at least up to the 998 character limit) for the sake
7558+ of robustness.
7559+
7560+
7561+
7562+
7563+
7564+
7565+
7566+ Resnick Standards Track [Page 7]
7567+
7568+ RFC 5322 Internet Message Format October 2008
7569+
7570+
7571+ 2.2. Header Fields
7572+
7573+ Header fields are lines beginning with a field name, followed by a
7574+ colon (":"), followed by a field body, and terminated by CRLF. A
7575+ field name MUST be composed of printable US-ASCII characters (i.e.,
7576+ characters that have values between 33 and 126, inclusive), except
7577+ colon. A field body may be composed of printable US-ASCII characters
7578+ as well as the space (SP, ASCII value 32) and horizontal tab (HTAB,
7579+ ASCII value 9) characters (together known as the white space
7580+ characters, WSP). A field body MUST NOT include CR and LF except
7581+ when used in "folding" and "unfolding", as described in section
7582+ 2.2.3. All field bodies MUST conform to the syntax described in
7583+ sections 3 and 4 of this specification.
7584+
7585+ 2.2.1. Unstructured Header Field Bodies
7586+
7587+ Some field bodies in this specification are defined simply as
7588+ "unstructured" (which is specified in section 3.2.5 as any printable
7589+ US-ASCII characters plus white space characters) with no further
7590+ restrictions. These are referred to as unstructured field bodies.
7591+ Semantically, unstructured field bodies are simply to be treated as a
7592+ single line of characters with no further processing (except for
7593+ "folding" and "unfolding" as described in section 2.2.3).
7594+
7595+ 2.2.2. Structured Header Field Bodies
7596+
7597+ Some field bodies in this specification have a syntax that is more
7598+ restrictive than the unstructured field bodies described above.
7599+ These are referred to as "structured" field bodies. Structured field
7600+ bodies are sequences of specific lexical tokens as described in
7601+ sections 3 and 4 of this specification. Many of these tokens are
7602+ allowed (according to their syntax) to be introduced or end with
7603+ comments (as described in section 3.2.2) as well as the white space
7604+ characters, and those white space characters are subject to "folding"
7605+ and "unfolding" as described in section 2.2.3. Semantic analysis of
7606+ structured field bodies is given along with their syntax.
7607+
7608+ 2.2.3. Long Header Fields
7609+
7610+ Each header field is logically a single line of characters comprising
7611+ the field name, the colon, and the field body. For convenience
7612+ however, and to deal with the 998/78 character limitations per line,
7613+ the field body portion of a header field can be split into a
7614+ multiple-line representation; this is called "folding". The general
7615+ rule is that wherever this specification allows for folding white
7616+ space (not simply WSP characters), a CRLF may be inserted before any
7617+ WSP.
7618+
7619+
7620+
7621+
7622+ Resnick Standards Track [Page 8]
7623+
7624+ RFC 5322 Internet Message Format October 2008
7625+
7626+
7627+ For example, the header field:
7628+
7629+ Subject: This is a test
7630+
7631+ can be represented as:
7632+
7633+ Subject: This
7634+ is a test
7635+
7636+ Note: Though structured field bodies are defined in such a way
7637+ that folding can take place between many of the lexical tokens
7638+ (and even within some of the lexical tokens), folding SHOULD be
7639+ limited to placing the CRLF at higher-level syntactic breaks. For
7640+ instance, if a field body is defined as comma-separated values, it
7641+ is recommended that folding occur after the comma separating the
7642+ structured items in preference to other places where the field
7643+ could be folded, even if it is allowed elsewhere.
7644+
7645+ The process of moving from this folded multiple-line representation
7646+ of a header field to its single line representation is called
7647+ "unfolding". Unfolding is accomplished by simply removing any CRLF
7648+ that is immediately followed by WSP. Each header field should be
7649+ treated in its unfolded form for further syntactic and semantic
7650+ evaluation. An unfolded header field has no length restriction and
7651+ therefore may be indeterminately long.
7652+
7653+ 2.3. Body
7654+
7655+ The body of a message is simply lines of US-ASCII characters. The
7656+ only two limitations on the body are as follows:
7657+
7658+ o CR and LF MUST only occur together as CRLF; they MUST NOT appear
7659+ independently in the body.
7660+ o Lines of characters in the body MUST be limited to 998 characters,
7661+ and SHOULD be limited to 78 characters, excluding the CRLF.
7662+
7663+ Note: As was stated earlier, there are other documents,
7664+ specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049],
7665+ [RFC4288], [RFC4289]), that extend (and limit) this specification
7666+ to allow for different sorts of message bodies. Again, these
7667+ mechanisms are beyond the scope of this document.
7668+
7669+
7670+
7671+
7672+
7673+
7674+
7675+
7676+
7677+
7678+ Resnick Standards Track [Page 9]
7679+
7680+ RFC 5322 Internet Message Format October 2008
7681+
7682+
7683+ 3. Syntax
7684+
7685+ 3.1. Introduction
7686+
7687+ The syntax as given in this section defines the legal syntax of
7688+ Internet messages. Messages that are conformant to this
7689+ specification MUST conform to the syntax in this section. If there
7690+ are options in this section where one option SHOULD be generated,
7691+ that is indicated either in the prose or in a comment next to the
7692+ syntax.
7693+
7694+ For the defined expressions, a short description of the syntax and
7695+ use is given, followed by the syntax in ABNF, followed by a semantic
7696+ analysis. The following primitive tokens that are used but otherwise
7697+ unspecified are taken from the "Core Rules" of [RFC5234], Appendix
7698+ B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR.
7699+
7700+ In some of the definitions, there will be non-terminals whose names
7701+ start with "obs-". These "obs-" elements refer to tokens defined in
7702+ the obsolete syntax in section 4. In all cases, these productions
7703+ are to be ignored for the purposes of generating legal Internet
7704+ messages and MUST NOT be used as part of such a message. However,
7705+ when interpreting messages, these tokens MUST be honored as part of
7706+ the legal syntax. In this sense, section 3 defines a grammar for the
7707+ generation of messages, with "obs-" elements that are to be ignored,
7708+ while section 4 adds grammar for the interpretation of messages.
7709+
7710+ 3.2. Lexical Tokens
7711+
7712+ The following rules are used to define an underlying lexical
7713+ analyzer, which feeds tokens to the higher-level parsers. This
7714+ section defines the tokens used in structured header field bodies.
7715+
7716+ Note: Readers of this specification need to pay special attention
7717+ to how these lexical tokens are used in both the lower-level and
7718+ higher-level syntax later in the document. Particularly, the
7719+ white space tokens and the comment tokens defined in section 3.2.2
7720+ get used in the lower-level tokens defined here, and those lower-
7721+ level tokens are in turn used as parts of the higher-level tokens
7722+ defined later. Therefore, white space and comments may be allowed
7723+ in the higher-level tokens even though they may not explicitly
7724+ appear in a particular definition.
7725+
7726+ 3.2.1. Quoted characters
7727+
7728+ Some characters are reserved for special interpretation, such as
7729+ delimiting lexical tokens. To permit use of these characters as
7730+ uninterpreted data, a quoting mechanism is provided.
7731+
7732+
7733+
7734+ Resnick Standards Track [Page 10]
7735+
7736+ RFC 5322 Internet Message Format October 2008
7737+
7738+
7739+ quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
7740+
7741+ Where any quoted-pair appears, it is to be interpreted as the
7742+ character alone. That is to say, the "\" character that appears as
7743+ part of a quoted-pair is semantically "invisible".
7744+
7745+ Note: The "\" character may appear in a message where it is not
7746+ part of a quoted-pair. A "\" character that does not appear in a
7747+ quoted-pair is not semantically invisible. The only places in
7748+ this specification where quoted-pair currently appears are
7749+ ccontent, qcontent, and in obs-dtext in section 4.
7750+
7751+ 3.2.2. Folding White Space and Comments
7752+
7753+ White space characters, including white space used in folding
7754+ (described in section 2.2.3), may appear between many elements in
7755+ header field bodies. Also, strings of characters that are treated as
7756+ comments may be included in structured field bodies as characters
7757+ enclosed in parentheses. The following defines the folding white
7758+ space (FWS) and comment constructs.
7759+
7760+ Strings of characters enclosed in parentheses are considered comments
7761+ so long as they do not appear within a "quoted-string", as defined in
7762+ section 3.2.4. Comments may nest.
7763+
7764+ There are several places in this specification where comments and FWS
7765+ may be freely inserted. To accommodate that syntax, an additional
7766+ token for "CFWS" is defined for places where comments and/or FWS can
7767+ occur. However, where CFWS occurs in this specification, it MUST NOT
7768+ be inserted in such a way that any line of a folded header field is
7769+ made up entirely of WSP characters and nothing else.
7770+
7771+ FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
7772+ ; Folding white space
7773+
7774+ ctext = %d33-39 / ; Printable US-ASCII
7775+ %d42-91 / ; characters not including
7776+ %d93-126 / ; "(", ")", or "\"
7777+ obs-ctext
7778+
7779+ ccontent = ctext / quoted-pair / comment
7780+
7781+ comment = "(" *([FWS] ccontent) [FWS] ")"
7782+
7783+ CFWS = (1*([FWS] comment) [FWS]) / FWS
7784+
7785+
7786+
7787+
7788+
7789+
7790+ Resnick Standards Track [Page 11]
7791+
7792+ RFC 5322 Internet Message Format October 2008
7793+
7794+
7795+ Throughout this specification, where FWS (the folding white space
7796+ token) appears, it indicates a place where folding, as discussed in
7797+ section 2.2.3, may take place. Wherever folding appears in a message
7798+ (that is, a header field body containing a CRLF followed by any WSP),
7799+ unfolding (removal of the CRLF) is performed before any further
7800+ semantic analysis is performed on that header field according to this
7801+ specification. That is to say, any CRLF that appears in FWS is
7802+ semantically "invisible".
7803+
7804+ A comment is normally used in a structured field body to provide some
7805+ human-readable informational text. Since a comment is allowed to
7806+ contain FWS, folding is permitted within the comment. Also note that
7807+ since quoted-pair is allowed in a comment, the parentheses and
7808+ backslash characters may appear in a comment, so long as they appear
7809+ as a quoted-pair. Semantically, the enclosing parentheses are not
7810+ part of the comment; the comment is what is contained between the two
7811+ parentheses. As stated earlier, the "\" in any quoted-pair and the
7812+ CRLF in any FWS that appears within the comment are semantically
7813+ "invisible" and therefore not part of the comment either.
7814+
7815+ Runs of FWS, comment, or CFWS that occur between lexical tokens in a
7816+ structured header field are semantically interpreted as a single
7817+ space character.
7818+
7819+ 3.2.3. Atom
7820+
7821+ Several productions in structured header field bodies are simply
7822+ strings of certain basic characters. Such productions are called
7823+ atoms.
7824+
7825+ Some of the structured header field bodies also allow the period
7826+ character (".", ASCII value 46) within runs of atext. An additional
7827+ "dot-atom" token is defined for those purposes.
7828+
7829+ Note: The "specials" token does not appear anywhere else in this
7830+ specification. It is simply the visible (i.e., non-control, non-
7831+ white space) characters that do not appear in atext. It is
7832+ provided only because it is useful for implementers who use tools
7833+ that lexically analyze messages. Each of the characters in
7834+ specials can be used to indicate a tokenization point in lexical
7835+ analysis.
7836+
7837+
7838+
7839+
7840+
7841+
7842+
7843+
7844+
7845+
7846+ Resnick Standards Track [Page 12]
7847+
7848+ RFC 5322 Internet Message Format October 2008
7849+
7850+
7851+ atext = ALPHA / DIGIT / ; Printable US-ASCII
7852+ "!" / "#" / ; characters not including
7853+ "$" / "%" / ; specials. Used for atoms.
7854+ "&" / "'" /
7855+ "*" / "+" /
7856+ "-" / "/" /
7857+ "=" / "?" /
7858+ "^" / "_" /
7859+ "`" / "{" /
7860+ "|" / "}" /
7861+ "~"
7862+
7863+ atom = [CFWS] 1*atext [CFWS]
7864+
7865+ dot-atom-text = 1*atext *("." 1*atext)
7866+
7867+ dot-atom = [CFWS] dot-atom-text [CFWS]
7868+
7869+ specials = "(" / ")" / ; Special characters that do
7870+ "<" / ">" / ; not appear in atext
7871+ "[" / "]" /
7872+ ":" / ";" /
7873+ "@" / "\" /
7874+ "," / "." /
7875+ DQUOTE
7876+
7877+ Both atom and dot-atom are interpreted as a single unit, comprising
7878+ the string of characters that make it up. Semantically, the optional
7879+ comments and FWS surrounding the rest of the characters are not part
7880+ of the atom; the atom is only the run of atext characters in an atom,
7881+ or the atext and "." characters in a dot-atom.
7882+
7883+ 3.2.4. Quoted Strings
7884+
7885+ Strings of characters that include characters other than those
7886+ allowed in atoms can be represented in a quoted string format, where
7887+ the characters are surrounded by quote (DQUOTE, ASCII value 34)
7888+ characters.
7889+
7890+
7891+
7892+
7893+
7894+
7895+
7896+
7897+
7898+
7899+
7900+
7901+
7902+ Resnick Standards Track [Page 13]
7903+
7904+ RFC 5322 Internet Message Format October 2008
7905+
7906+
7907+ qtext = %d33 / ; Printable US-ASCII
7908+ %d35-91 / ; characters not including
7909+ %d93-126 / ; "\" or the quote character
7910+ obs-qtext
7911+
7912+ qcontent = qtext / quoted-pair
7913+
7914+ quoted-string = [CFWS]
7915+ DQUOTE *([FWS] qcontent) [FWS] DQUOTE
7916+ [CFWS]
7917+
7918+ A quoted-string is treated as a unit. That is, quoted-string is
7919+ identical to atom, semantically. Since a quoted-string is allowed to
7920+ contain FWS, folding is permitted. Also note that since quoted-pair
7921+ is allowed in a quoted-string, the quote and backslash characters may
7922+ appear in a quoted-string so long as they appear as a quoted-pair.
7923+
7924+ Semantically, neither the optional CFWS outside of the quote
7925+ characters nor the quote characters themselves are part of the
7926+ quoted-string; the quoted-string is what is contained between the two
7927+ quote characters. As stated earlier, the "\" in any quoted-pair and
7928+ the CRLF in any FWS/CFWS that appears within the quoted-string are
7929+ semantically "invisible" and therefore not part of the quoted-string
7930+ either.
7931+
7932+ 3.2.5. Miscellaneous Tokens
7933+
7934+ Three additional tokens are defined: word and phrase for combinations
7935+ of atoms and/or quoted-strings, and unstructured for use in
7936+ unstructured header fields and in some places within structured
7937+ header fields.
7938+
7939+ word = atom / quoted-string
7940+
7941+ phrase = 1*word / obs-phrase
7942+
7943+ unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
7944+
7945+ 3.3. Date and Time Specification
7946+
7947+ Date and time values occur in several header fields. This section
7948+ specifies the syntax for a full date and time specification. Though
7949+ folding white space is permitted throughout the date-time
7950+ specification, it is RECOMMENDED that a single space be used in each
7951+ place that FWS appears (whether it is required or optional); some
7952+ older implementations will not interpret longer sequences of folding
7953+ white space correctly.
7954+
7955+
7956+
7957+
7958+ Resnick Standards Track [Page 14]
7959+
7960+ RFC 5322 Internet Message Format October 2008
7961+
7962+
7963+ date-time = [ day-of-week "," ] date time [CFWS]
7964+
7965+ day-of-week = ([FWS] day-name) / obs-day-of-week
7966+
7967+ day-name = "Mon" / "Tue" / "Wed" / "Thu" /
7968+ "Fri" / "Sat" / "Sun"
7969+
7970+ date = day month year
7971+
7972+ day = ([FWS] 1*2DIGIT FWS) / obs-day
7973+
7974+ month = "Jan" / "Feb" / "Mar" / "Apr" /
7975+ "May" / "Jun" / "Jul" / "Aug" /
7976+ "Sep" / "Oct" / "Nov" / "Dec"
7977+
7978+ year = (FWS 4*DIGIT FWS) / obs-year
7979+
7980+ time = time-of-day zone
7981+
7982+ time-of-day = hour ":" minute [ ":" second ]
7983+
7984+ hour = 2DIGIT / obs-hour
7985+
7986+ minute = 2DIGIT / obs-minute
7987+
7988+ second = 2DIGIT / obs-second
7989+
7990+ zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
7991+
7992+ The day is the numeric day of the month. The year is any numeric
7993+ year 1900 or later.
7994+
7995+ The time-of-day specifies the number of hours, minutes, and
7996+ optionally seconds since midnight of the date indicated.
7997+
7998+ The date and time-of-day SHOULD express local time.
7999+
8000+ The zone specifies the offset from Coordinated Universal Time (UTC,
8001+ formerly referred to as "Greenwich Mean Time") that the date and
8002+ time-of-day represent. The "+" or "-" indicates whether the time-of-
8003+ day is ahead of (i.e., east of) or behind (i.e., west of) Universal
8004+ Time. The first two digits indicate the number of hours difference
8005+ from Universal Time, and the last two digits indicate the number of
8006+ additional minutes difference from Universal Time. (Hence, +hhmm
8007+ means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
8008+ minutes). The form "+0000" SHOULD be used to indicate a time zone at
8009+ Universal Time. Though "-0000" also indicates Universal Time, it is
8010+
8011+
8012+
8013+
8014+ Resnick Standards Track [Page 15]
8015+
8016+ RFC 5322 Internet Message Format October 2008
8017+
8018+
8019+ used to indicate that the time was generated on a system that may be
8020+ in a local time zone other than Universal Time and that the date-time
8021+ contains no information about the local time zone.
8022+
8023+ A date-time specification MUST be semantically valid. That is, the
8024+ day-of-week (if included) MUST be the day implied by the date, the
8025+ numeric day-of-month MUST be between 1 and the number of days allowed
8026+ for the specified month (in the specified year), the time-of-day MUST
8027+ be in the range 00:00:00 through 23:59:60 (the number of seconds
8028+ allowing for a leap second; see [RFC1305]), and the last two digits
8029+ of the zone MUST be within the range 00 through 59.
8030+
8031+ 3.4. Address Specification
8032+
8033+ Addresses occur in several message header fields to indicate senders
8034+ and recipients of messages. An address may either be an individual
8035+ mailbox, or a group of mailboxes.
8036+
8037+ address = mailbox / group
8038+
8039+ mailbox = name-addr / addr-spec
8040+
8041+ name-addr = [display-name] angle-addr
8042+
8043+ angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
8044+ obs-angle-addr
8045+
8046+ group = display-name ":" [group-list] ";" [CFWS]
8047+
8048+ display-name = phrase
8049+
8050+ mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
8051+
8052+ address-list = (address *("," address)) / obs-addr-list
8053+
8054+ group-list = mailbox-list / CFWS / obs-group-list
8055+
8056+ A mailbox receives mail. It is a conceptual entity that does not
8057+ necessarily pertain to file storage. For example, some sites may
8058+ choose to print mail on a printer and deliver the output to the
8059+ addressee's desk.
8060+
8061+ Normally, a mailbox is composed of two parts: (1) an optional display
8062+ name that indicates the name of the recipient (which can be a person
8063+ or a system) that could be displayed to the user of a mail
8064+ application, and (2) an addr-spec address enclosed in angle brackets
8065+
8066+
8067+
8068+
8069+
8070+ Resnick Standards Track [Page 16]
8071+
8072+ RFC 5322 Internet Message Format October 2008
8073+
8074+
8075+ ("<" and ">"). There is an alternate simple form of a mailbox where
8076+ the addr-spec address appears alone, without the recipient's name or
8077+ the angle brackets. The Internet addr-spec address is described in
8078+ section 3.4.1.
8079+
8080+ Note: Some legacy implementations used the simple form where the
8081+ addr-spec appears without the angle brackets, but included the
8082+ name of the recipient in parentheses as a comment following the
8083+ addr-spec. Since the meaning of the information in a comment is
8084+ unspecified, implementations SHOULD use the full name-addr form of
8085+ the mailbox, instead of the legacy form, to specify the display
8086+ name associated with a mailbox. Also, because some legacy
8087+ implementations interpret the comment, comments generally SHOULD
8088+ NOT be used in address fields to avoid confusing such
8089+ implementations.
8090+
8091+ When it is desirable to treat several mailboxes as a single unit
8092+ (i.e., in a distribution list), the group construct can be used. The
8093+ group construct allows the sender to indicate a named group of
8094+ recipients. This is done by giving a display name for the group,
8095+ followed by a colon, followed by a comma-separated list of any number
8096+ of mailboxes (including zero and one), and ending with a semicolon.
8097+ Because the list of mailboxes can be empty, using the group construct
8098+ is also a simple way to communicate to recipients that the message
8099+ was sent to one or more named sets of recipients, without actually
8100+ providing the individual mailbox address for any of those recipients.
8101+
8102+ 3.4.1. Addr-Spec Specification
8103+
8104+ An addr-spec is a specific Internet identifier that contains a
8105+ locally interpreted string followed by the at-sign character ("@",
8106+ ASCII value 64) followed by an Internet domain. The locally
8107+ interpreted string is either a quoted-string or a dot-atom. If the
8108+ string can be represented as a dot-atom (that is, it contains no
8109+ characters other than atext characters or "." surrounded by atext
8110+ characters), then the dot-atom form SHOULD be used and the quoted-
8111+ string form SHOULD NOT be used. Comments and folding white space
8112+ SHOULD NOT be used around the "@" in the addr-spec.
8113+
8114+ Note: A liberal syntax for the domain portion of addr-spec is
8115+ given here. However, the domain portion contains addressing
8116+ information specified by and used in other protocols (e.g.,
8117+ [RFC1034], [RFC1035], [RFC1123], [RFC5321]). It is therefore
8118+ incumbent upon implementations to conform to the syntax of
8119+ addresses for the context in which they are used.
8120+
8121+
8122+
8123+
8124+
8125+
8126+ Resnick Standards Track [Page 17]
8127+
8128+ RFC 5322 Internet Message Format October 2008
8129+
8130+
8131+ addr-spec = local-part "@" domain
8132+
8133+ local-part = dot-atom / quoted-string / obs-local-part
8134+
8135+ domain = dot-atom / domain-literal / obs-domain
8136+
8137+ domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
8138+
8139+ dtext = %d33-90 / ; Printable US-ASCII
8140+ %d94-126 / ; characters not including
8141+ obs-dtext ; "[", "]", or "\"
8142+
8143+ The domain portion identifies the point to which the mail is
8144+ delivered. In the dot-atom form, this is interpreted as an Internet
8145+ domain name (either a host name or a mail exchanger name) as
8146+ described in [RFC1034], [RFC1035], and [RFC1123]. In the domain-
8147+ literal form, the domain is interpreted as the literal Internet
8148+ address of the particular host. In both cases, how addressing is
8149+ used and how messages are transported to a particular host is covered
8150+ in separate documents, such as [RFC5321]. These mechanisms are
8151+ outside of the scope of this document.
8152+
8153+ The local-part portion is a domain-dependent string. In addresses,
8154+ it is simply interpreted on the particular host as a name of a
8155+ particular mailbox.
8156+
8157+ 3.5. Overall Message Syntax
8158+
8159+ A message consists of header fields, optionally followed by a message
8160+ body. Lines in a message MUST be a maximum of 998 characters
8161+ excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
8162+ characters excluding the CRLF. (See section 2.1.1 for explanation.)
8163+ In a message body, though all of the characters listed in the text
8164+ rule MAY be used, the use of US-ASCII control characters (values 1
8165+ through 8, 11, 12, and 14 through 31) is discouraged since their
8166+ interpretation by receivers for display is not guaranteed.
8167+
8168+ message = (fields / obs-fields)
8169+ [CRLF body]
8170+
8171+ body = (*(*998text CRLF) *998text) / obs-body
8172+
8173+ text = %d1-9 / ; Characters excluding CR
8174+ %d11 / ; and LF
8175+ %d12 /
8176+ %d14-127
8177+
8178+
8179+
8180+
8181+
8182+ Resnick Standards Track [Page 18]
8183+
8184+ RFC 5322 Internet Message Format October 2008
8185+
8186+
8187+ The header fields carry most of the semantic information and are
8188+ defined in section 3.6. The body is simply a series of lines of text
8189+ that are uninterpreted for the purposes of this specification.
8190+
8191+ 3.6. Field Definitions
8192+
8193+ The header fields of a message are defined here. All header fields
8194+ have the same general syntactic structure: a field name, followed by
8195+ a colon, followed by the field body. The specific syntax for each
8196+ header field is defined in the subsequent sections.
8197+
8198+ Note: In the ABNF syntax for each field in subsequent sections,
8199+ each field name is followed by the required colon. However, for
8200+ brevity, sometimes the colon is not referred to in the textual
8201+ description of the syntax. It is, nonetheless, required.
8202+
8203+ It is important to note that the header fields are not guaranteed to
8204+ be in a particular order. They may appear in any order, and they
8205+ have been known to be reordered occasionally when transported over
8206+ the Internet. However, for the purposes of this specification,
8207+ header fields SHOULD NOT be reordered when a message is transported
8208+ or transformed. More importantly, the trace header fields and resent
8209+ header fields MUST NOT be reordered, and SHOULD be kept in blocks
8210+ prepended to the message. See sections 3.6.6 and 3.6.7 for more
8211+ information.
8212+
8213+ The only required header fields are the origination date field and
8214+ the originator address field(s). All other header fields are
8215+ syntactically optional. More information is contained in the table
8216+ following this definition.
8217+
8218+
8219+
8220+
8221+
8222+
8223+
8224+
8225+
8226+
8227+
8228+
8229+
8230+
8231+
8232+
8233+
8234+
8235+
8236+
8237+
8238+ Resnick Standards Track [Page 19]
8239+
8240+ RFC 5322 Internet Message Format October 2008
8241+
8242+
8243+ fields = *(trace
8244+ *optional-field /
8245+ *(resent-date /
8246+ resent-from /
8247+ resent-sender /
8248+ resent-to /
8249+ resent-cc /
8250+ resent-bcc /
8251+ resent-msg-id))
8252+ *(orig-date /
8253+ from /
8254+ sender /
8255+ reply-to /
8256+ to /
8257+ cc /
8258+ bcc /
8259+ message-id /
8260+ in-reply-to /
8261+ references /
8262+ subject /
8263+ comments /
8264+ keywords /
8265+ optional-field)
8266+
8267+ The following table indicates limits on the number of times each
8268+ field may occur in the header section of a message as well as any
8269+ special limitations on the use of those fields. An asterisk ("*")
8270+ next to a value in the minimum or maximum column indicates that a
8271+ special restriction appears in the Notes column.
8272+
8273+
8274+
8275+
8276+
8277+
8278+
8279+
8280+
8281+
8282+
8283+
8284+
8285+
8286+
8287+
8288+
8289+
8290+
8291+
8292+
8293+
8294+ Resnick Standards Track [Page 20]
8295+
8296+ RFC 5322 Internet Message Format October 2008
8297+
8298+
8299+ +----------------+--------+------------+----------------------------+
8300+ | Field | Min | Max number | Notes |
8301+ | | number | | |
8302+ +----------------+--------+------------+----------------------------+
8303+ | trace | 0 | unlimited | Block prepended - see |
8304+ | | | | 3.6.7 |
8305+ | resent-date | 0* | unlimited* | One per block, required if |
8306+ | | | | other resent fields are |
8307+ | | | | present - see 3.6.6 |
8308+ | resent-from | 0 | unlimited* | One per block - see 3.6.6 |
8309+ | resent-sender | 0* | unlimited* | One per block, MUST occur |
8310+ | | | | with multi-address |
8311+ | | | | resent-from - see 3.6.6 |
8312+ | resent-to | 0 | unlimited* | One per block - see 3.6.6 |
8313+ | resent-cc | 0 | unlimited* | One per block - see 3.6.6 |
8314+ | resent-bcc | 0 | unlimited* | One per block - see 3.6.6 |
8315+ | resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 |
8316+ | orig-date | 1 | 1 | |
8317+ | from | 1 | 1 | See sender and 3.6.2 |
8318+ | sender | 0* | 1 | MUST occur with |
8319+ | | | | multi-address from - see |
8320+ | | | | 3.6.2 |
8321+ | reply-to | 0 | 1 | |
8322+ | to | 0 | 1 | |
8323+ | cc | 0 | 1 | |
8324+ | bcc | 0 | 1 | |
8325+ | message-id | 0* | 1 | SHOULD be present - see |
8326+ | | | | 3.6.4 |
8327+ | in-reply-to | 0* | 1 | SHOULD occur in some |
8328+ | | | | replies - see 3.6.4 |
8329+ | references | 0* | 1 | SHOULD occur in some |
8330+ | | | | replies - see 3.6.4 |
8331+ | subject | 0 | 1 | |
8332+ | comments | 0 | unlimited | |
8333+ | keywords | 0 | unlimited | |
8334+ | optional-field | 0 | unlimited | |
8335+ +----------------+--------+------------+----------------------------+
8336+
8337+ The exact interpretation of each field is described in subsequent
8338+ sections.
8339+
8340+
8341+
8342+
8343+
8344+
8345+
8346+
8347+
8348+
8349+
8350+ Resnick Standards Track [Page 21]
8351+
8352+ RFC 5322 Internet Message Format October 2008
8353+
8354+
8355+ 3.6.1. The Origination Date Field
8356+
8357+ The origination date field consists of the field name "Date" followed
8358+ by a date-time specification.
8359+
8360+ orig-date = "Date:" date-time CRLF
8361+
8362+ The origination date specifies the date and time at which the creator
8363+ of the message indicated that the message was complete and ready to
8364+ enter the mail delivery system. For instance, this might be the time
8365+ that a user pushes the "send" or "submit" button in an application
8366+ program. In any case, it is specifically not intended to convey the
8367+ time that the message is actually transported, but rather the time at
8368+ which the human or other creator of the message has put the message
8369+ into its final form, ready for transport. (For example, a portable
8370+ computer user who is not connected to a network might queue a message
8371+ for delivery. The origination date is intended to contain the date
8372+ and time that the user queued the message, not the time when the user
8373+ connected to the network to send the message.)
8374+
8375+ 3.6.2. Originator Fields
8376+
8377+ The originator fields of a message consist of the from field, the
8378+ sender field (when applicable), and optionally the reply-to field.
8379+ The from field consists of the field name "From" and a comma-
8380+ separated list of one or more mailbox specifications. If the from
8381+ field contains more than one mailbox specification in the mailbox-
8382+ list, then the sender field, containing the field name "Sender" and a
8383+ single mailbox specification, MUST appear in the message. In either
8384+ case, an optional reply-to field MAY also be included, which contains
8385+ the field name "Reply-To" and a comma-separated list of one or more
8386+ addresses.
8387+
8388+ from = "From:" mailbox-list CRLF
8389+
8390+ sender = "Sender:" mailbox CRLF
8391+
8392+ reply-to = "Reply-To:" address-list CRLF
8393+
8394+ The originator fields indicate the mailbox(es) of the source of the
8395+ message. The "From:" field specifies the author(s) of the message,
8396+ that is, the mailbox(es) of the person(s) or system(s) responsible
8397+ for the writing of the message. The "Sender:" field specifies the
8398+ mailbox of the agent responsible for the actual transmission of the
8399+ message. For example, if a secretary were to send a message for
8400+ another person, the mailbox of the secretary would appear in the
8401+ "Sender:" field and the mailbox of the actual author would appear in
8402+ the "From:" field. If the originator of the message can be indicated
8403+
8404+
8405+
8406+ Resnick Standards Track [Page 22]
8407+
8408+ RFC 5322 Internet Message Format October 2008
8409+
8410+
8411+ by a single mailbox and the author and transmitter are identical, the
8412+ "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
8413+ appear.
8414+
8415+ Note: The transmitter information is always present. The absence
8416+ of the "Sender:" field is sometimes mistakenly taken to mean that
8417+ the agent responsible for transmission of the message has not been
8418+ specified. This absence merely means that the transmitter is
8419+ identical to the author and is therefore not redundantly placed
8420+ into the "Sender:" field.
8421+
8422+ The originator fields also provide the information required when
8423+ replying to a message. When the "Reply-To:" field is present, it
8424+ indicates the address(es) to which the author of the message suggests
8425+ that replies be sent. In the absence of the "Reply-To:" field,
8426+ replies SHOULD by default be sent to the mailbox(es) specified in the
8427+ "From:" field unless otherwise specified by the person composing the
8428+ reply.
8429+
8430+ In all cases, the "From:" field SHOULD NOT contain any mailbox that
8431+ does not belong to the author(s) of the message. See also section
8432+ 3.6.3 for more information on forming the destination addresses for a
8433+ reply.
8434+
8435+ 3.6.3. Destination Address Fields
8436+
8437+ The destination fields of a message consist of three possible fields,
8438+ each of the same form: the field name, which is either "To", "Cc", or
8439+ "Bcc", followed by a comma-separated list of one or more addresses
8440+ (either mailbox or group syntax).
8441+
8442+ to = "To:" address-list CRLF
8443+
8444+ cc = "Cc:" address-list CRLF
8445+
8446+ bcc = "Bcc:" [address-list / CFWS] CRLF
8447+
8448+ The destination fields specify the recipients of the message. Each
8449+ destination field may have one or more addresses, and the addresses
8450+ indicate the intended recipients of the message. The only difference
8451+ between the three fields is how each is used.
8452+
8453+ The "To:" field contains the address(es) of the primary recipient(s)
8454+ of the message.
8455+
8456+
8457+
8458+
8459+
8460+
8461+
8462+ Resnick Standards Track [Page 23]
8463+
8464+ RFC 5322 Internet Message Format October 2008
8465+
8466+
8467+ The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
8468+ making a copy on a typewriter using carbon paper) contains the
8469+ addresses of others who are to receive the message, though the
8470+ content of the message may not be directed at them.
8471+
8472+ The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
8473+ addresses of recipients of the message whose addresses are not to be
8474+ revealed to other recipients of the message. There are three ways in
8475+ which the "Bcc:" field is used. In the first case, when a message
8476+ containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
8477+ removed even though all of the recipients (including those specified
8478+ in the "Bcc:" field) are sent a copy of the message. In the second
8479+ case, recipients specified in the "To:" and "Cc:" lines each are sent
8480+ a copy of the message with the "Bcc:" line removed as above, but the
8481+ recipients on the "Bcc:" line get a separate copy of the message
8482+ containing a "Bcc:" line. (When there are multiple recipient
8483+ addresses in the "Bcc:" field, some implementations actually send a
8484+ separate copy of the message to each recipient with a "Bcc:"
8485+ containing only the address of that particular recipient.) Finally,
8486+ since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
8487+ sent without any addresses indicating to the recipients that blind
8488+ copies were sent to someone. Which method to use with "Bcc:" fields
8489+ is implementation dependent, but refer to the "Security
8490+ Considerations" section of this document for a discussion of each.
8491+
8492+ When a message is a reply to another message, the mailboxes of the
8493+ authors of the original message (the mailboxes in the "From:" field)
8494+ or mailboxes specified in the "Reply-To:" field (if it exists) MAY
8495+ appear in the "To:" field of the reply since these would normally be
8496+ the primary recipients of the reply. If a reply is sent to a message
8497+ that has destination fields, it is often desirable to send a copy of
8498+ the reply to all of the recipients of the message, in addition to the
8499+ author. When such a reply is formed, addresses in the "To:" and
8500+ "Cc:" fields of the original message MAY appear in the "Cc:" field of
8501+ the reply, since these are normally secondary recipients of the
8502+ reply. If a "Bcc:" field is present in the original message,
8503+ addresses in that field MAY appear in the "Bcc:" field of the reply,
8504+ but they SHOULD NOT appear in the "To:" or "Cc:" fields.
8505+
8506+ Note: Some mail applications have automatic reply commands that
8507+ include the destination addresses of the original message in the
8508+ destination addresses of the reply. How those reply commands
8509+ behave is implementation dependent and is beyond the scope of this
8510+ document. In particular, whether or not to include the original
8511+ destination addresses when the original message had a "Reply-To:"
8512+ field is not addressed here.
8513+
8514+
8515+
8516+
8517+
8518+ Resnick Standards Track [Page 24]
8519+
8520+ RFC 5322 Internet Message Format October 2008
8521+
8522+
8523+ 3.6.4. Identification Fields
8524+
8525+ Though listed as optional in the table in section 3.6, every message
8526+ SHOULD have a "Message-ID:" field. Furthermore, reply messages
8527+ SHOULD have "In-Reply-To:" and "References:" fields as appropriate
8528+ and as described below.
8529+
8530+ The "Message-ID:" field contains a single unique message identifier.
8531+ The "References:" and "In-Reply-To:" fields each contain one or more
8532+ unique message identifiers, optionally separated by CFWS.
8533+
8534+ The message identifier (msg-id) syntax is a limited version of the
8535+ addr-spec construct enclosed in the angle bracket characters, "<" and
8536+ ">". Unlike addr-spec, this syntax only permits the dot-atom-text
8537+ form on the left-hand side of the "@" and does not have internal CFWS
8538+ anywhere in the message identifier.
8539+
8540+ Note: As with addr-spec, a liberal syntax is given for the right-
8541+ hand side of the "@" in a msg-id. However, later in this section,
8542+ the use of a domain for the right-hand side of the "@" is
8543+ RECOMMENDED. Again, the syntax of domain constructs is specified
8544+ by and used in other protocols (e.g., [RFC1034], [RFC1035],
8545+ [RFC1123], [RFC5321]). It is therefore incumbent upon
8546+ implementations to conform to the syntax of addresses for the
8547+ context in which they are used.
8548+
8549+ message-id = "Message-ID:" msg-id CRLF
8550+
8551+ in-reply-to = "In-Reply-To:" 1*msg-id CRLF
8552+
8553+ references = "References:" 1*msg-id CRLF
8554+
8555+ msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
8556+
8557+ id-left = dot-atom-text / obs-id-left
8558+
8559+ id-right = dot-atom-text / no-fold-literal / obs-id-right
8560+
8561+ no-fold-literal = "[" *dtext "]"
8562+
8563+ The "Message-ID:" field provides a unique message identifier that
8564+ refers to a particular version of a particular message. The
8565+ uniqueness of the message identifier is guaranteed by the host that
8566+ generates it (see below). This message identifier is intended to be
8567+ machine readable and not necessarily meaningful to humans. A message
8568+ identifier pertains to exactly one version of a particular message;
8569+ subsequent revisions to the message each receive new message
8570+ identifiers.
8571+
8572+
8573+
8574+ Resnick Standards Track [Page 25]
8575+
8576+ RFC 5322 Internet Message Format October 2008
8577+
8578+
8579+ Note: There are many instances when messages are "changed", but
8580+ those changes do not constitute a new instantiation of that
8581+ message, and therefore the message would not get a new message
8582+ identifier. For example, when messages are introduced into the
8583+ transport system, they are often prepended with additional header
8584+ fields such as trace fields (described in section 3.6.7) and
8585+ resent fields (described in section 3.6.6). The addition of such
8586+ header fields does not change the identity of the message and
8587+ therefore the original "Message-ID:" field is retained. In all
8588+ cases, it is the meaning that the sender of the message wishes to
8589+ convey (i.e., whether this is the same message or a different
8590+ message) that determines whether or not the "Message-ID:" field
8591+ changes, not any particular syntactic difference that appears (or
8592+ does not appear) in the message.
8593+
8594+ The "In-Reply-To:" and "References:" fields are used when creating a
8595+ reply to a message. They hold the message identifier of the original
8596+ message and the message identifiers of other messages (for example,
8597+ in the case of a reply to a message that was itself a reply). The
8598+ "In-Reply-To:" field may be used to identify the message (or
8599+ messages) to which the new message is a reply, while the
8600+ "References:" field may be used to identify a "thread" of
8601+ conversation.
8602+
8603+ When creating a reply to a message, the "In-Reply-To:" and
8604+ "References:" fields of the resultant message are constructed as
8605+ follows:
8606+
8607+ The "In-Reply-To:" field will contain the contents of the
8608+ "Message-ID:" field of the message to which this one is a reply (the
8609+ "parent message"). If there is more than one parent message, then
8610+ the "In-Reply-To:" field will contain the contents of all of the
8611+ parents' "Message-ID:" fields. If there is no "Message-ID:" field in
8612+ any of the parent messages, then the new message will have no "In-
8613+ Reply-To:" field.
8614+
8615+ The "References:" field will contain the contents of the parent's
8616+ "References:" field (if any) followed by the contents of the parent's
8617+ "Message-ID:" field (if any). If the parent message does not contain
8618+ a "References:" field but does have an "In-Reply-To:" field
8619+ containing a single message identifier, then the "References:" field
8620+ will contain the contents of the parent's "In-Reply-To:" field
8621+ followed by the contents of the parent's "Message-ID:" field (if
8622+ any). If the parent has none of the "References:", "In-Reply-To:",
8623+ or "Message-ID:" fields, then the new message will have no
8624+ "References:" field.
8625+
8626+
8627+
8628+
8629+
8630+ Resnick Standards Track [Page 26]
8631+
8632+ RFC 5322 Internet Message Format October 2008
8633+
8634+
8635+ Note: Some implementations parse the "References:" field to
8636+ display the "thread of the discussion". These implementations
8637+ assume that each new message is a reply to a single parent and
8638+ hence that they can walk backwards through the "References:" field
8639+ to find the parent of each message listed there. Therefore,
8640+ trying to form a "References:" field for a reply that has multiple
8641+ parents is discouraged; how to do so is not defined in this
8642+ document.
8643+
8644+ The message identifier (msg-id) itself MUST be a globally unique
8645+ identifier for a message. The generator of the message identifier
8646+ MUST guarantee that the msg-id is unique. There are several
8647+ algorithms that can be used to accomplish this. Since the msg-id has
8648+ a similar syntax to addr-spec (identical except that quoted strings,
8649+ comments, and folding white space are not allowed), a good method is
8650+ to put the domain name (or a domain literal IP address) of the host
8651+ on which the message identifier was created on the right-hand side of
8652+ the "@" (since domain names and IP addresses are normally unique),
8653+ and put a combination of the current absolute date and time along
8654+ with some other currently unique (perhaps sequential) identifier
8655+ available on the system (for example, a process id number) on the
8656+ left-hand side. Though other algorithms will work, it is RECOMMENDED
8657+ that the right-hand side contain some domain identifier (either of
8658+ the host itself or otherwise) such that the generator of the message
8659+ identifier can guarantee the uniqueness of the left-hand side within
8660+ the scope of that domain.
8661+
8662+ Semantically, the angle bracket characters are not part of the
8663+ msg-id; the msg-id is what is contained between the two angle bracket
8664+ characters.
8665+
8666+ 3.6.5. Informational Fields
8667+
8668+ The informational fields are all optional. The "Subject:" and
8669+ "Comments:" fields are unstructured fields as defined in section
8670+ 2.2.1, and therefore may contain text or folding white space. The
8671+ "Keywords:" field contains a comma-separated list of one or more
8672+ words or quoted-strings.
8673+
8674+ subject = "Subject:" unstructured CRLF
8675+
8676+ comments = "Comments:" unstructured CRLF
8677+
8678+ keywords = "Keywords:" phrase *("," phrase) CRLF
8679+
8680+ These three fields are intended to have only human-readable content
8681+ with information about the message. The "Subject:" field is the most
8682+ common and contains a short string identifying the topic of the
8683+
8684+
8685+
8686+ Resnick Standards Track [Page 27]
8687+
8688+ RFC 5322 Internet Message Format October 2008
8689+
8690+
8691+ message. When used in a reply, the field body MAY start with the
8692+ string "Re: " (an abbreviation of the Latin "in re", meaning "in the
8693+ matter of") followed by the contents of the "Subject:" field body of
8694+ the original message. If this is done, only one instance of the
8695+ literal string "Re: " ought to be used since use of other strings or
8696+ more than one instance can lead to undesirable consequences. The
8697+ "Comments:" field contains any additional comments on the text of the
8698+ body of the message. The "Keywords:" field contains a comma-
8699+ separated list of important words and phrases that might be useful
8700+ for the recipient.
8701+
8702+ 3.6.6. Resent Fields
8703+
8704+ Resent fields SHOULD be added to any message that is reintroduced by
8705+ a user into the transport system. A separate set of resent fields
8706+ SHOULD be added each time this is done. All of the resent fields
8707+ corresponding to a particular resending of the message SHOULD be
8708+ grouped together. Each new set of resent fields is prepended to the
8709+ message; that is, the most recent set of resent fields appears
8710+ earlier in the message. No other fields in the message are changed
8711+ when resent fields are added.
8712+
8713+ Each of the resent fields corresponds to a particular field elsewhere
8714+ in the syntax. For instance, the "Resent-Date:" field corresponds to
8715+ the "Date:" field and the "Resent-To:" field corresponds to the "To:"
8716+ field. In each case, the syntax for the field body is identical to
8717+ the syntax given previously for the corresponding field.
8718+
8719+ When resent fields are used, the "Resent-From:" and "Resent-Date:"
8720+ fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
8721+ "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
8722+ identical to "Resent-From:".
8723+
8724+ resent-date = "Resent-Date:" date-time CRLF
8725+
8726+ resent-from = "Resent-From:" mailbox-list CRLF
8727+
8728+ resent-sender = "Resent-Sender:" mailbox CRLF
8729+
8730+ resent-to = "Resent-To:" address-list CRLF
8731+
8732+ resent-cc = "Resent-Cc:" address-list CRLF
8733+
8734+ resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF
8735+
8736+ resent-msg-id = "Resent-Message-ID:" msg-id CRLF
8737+
8738+
8739+
8740+
8741+
8742+ Resnick Standards Track [Page 28]
8743+
8744+ RFC 5322 Internet Message Format October 2008
8745+
8746+
8747+ Resent fields are used to identify a message as having been
8748+ reintroduced into the transport system by a user. The purpose of
8749+ using resent fields is to have the message appear to the final
8750+ recipient as if it were sent directly by the original sender, with
8751+ all of the original fields remaining the same. Each set of resent
8752+ fields correspond to a particular resending event. That is, if a
8753+ message is resent multiple times, each set of resent fields gives
8754+ identifying information for each individual time. Resent fields are
8755+ strictly informational. They MUST NOT be used in the normal
8756+ processing of replies or other such automatic actions on messages.
8757+
8758+ Note: Reintroducing a message into the transport system and using
8759+ resent fields is a different operation from "forwarding".
8760+ "Forwarding" has two meanings: One sense of forwarding is that a
8761+ mail reading program can be told by a user to forward a copy of a
8762+ message to another person, making the forwarded message the body
8763+ of the new message. A forwarded message in this sense does not
8764+ appear to have come from the original sender, but is an entirely
8765+ new message from the forwarder of the message. Forwarding may
8766+ also mean that a mail transport program gets a message and
8767+ forwards it on to a different destination for final delivery.
8768+ Resent header fields are not intended for use with either type of
8769+ forwarding.
8770+
8771+ The resent originator fields indicate the mailbox of the person(s) or
8772+ system(s) that resent the message. As with the regular originator
8773+ fields, there are two forms: a simple "Resent-From:" form, which
8774+ contains the mailbox of the individual doing the resending, and the
8775+ more complex form, when one individual (identified in the "Resent-
8776+ Sender:" field) resends a message on behalf of one or more others
8777+ (identified in the "Resent-From:" field).
8778+
8779+ Note: When replying to a resent message, replies behave just as
8780+ they would with any other message, using the original "From:",
8781+ "Reply-To:", "Message-ID:", and other fields. The resent fields
8782+ are only informational and MUST NOT be used in the normal
8783+ processing of replies.
8784+
8785+ The "Resent-Date:" indicates the date and time at which the resent
8786+ message is dispatched by the resender of the message. Like the
8787+ "Date:" field, it is not the date and time that the message was
8788+ actually transported.
8789+
8790+ The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
8791+ identically to the "To:", "Cc:", and "Bcc:" fields, respectively,
8792+ except that they indicate the recipients of the resent message, not
8793+ the recipients of the original message.
8794+
8795+
8796+
8797+
8798+ Resnick Standards Track [Page 29]
8799+
8800+ RFC 5322 Internet Message Format October 2008
8801+
8802+
8803+ The "Resent-Message-ID:" field provides a unique identifier for the
8804+ resent message.
8805+
8806+ 3.6.7. Trace Fields
8807+
8808+ The trace fields are a group of header fields consisting of an
8809+ optional "Return-Path:" field, and one or more "Received:" fields.
8810+ The "Return-Path:" header field contains a pair of angle brackets
8811+ that enclose an optional addr-spec. The "Received:" field contains a
8812+ (possibly empty) list of tokens followed by a semicolon and a date-
8813+ time specification. Each token must be a word, angle-addr, addr-
8814+ spec, or a domain. Further restrictions are applied to the syntax of
8815+ the trace fields by specifications that provide for their use, such
8816+ as [RFC5321].
8817+
8818+ trace = [return]
8819+ 1*received
8820+
8821+ return = "Return-Path:" path CRLF
8822+
8823+ path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
8824+
8825+ received = "Received:" *received-token ";" date-time CRLF
8826+
8827+ received-token = word / angle-addr / addr-spec / domain
8828+
8829+ A full discussion of the Internet mail use of trace fields is
8830+ contained in [RFC5321]. For the purposes of this specification, the
8831+ trace fields are strictly informational, and any formal
8832+ interpretation of them is outside of the scope of this document.
8833+
8834+ 3.6.8. Optional Fields
8835+
8836+ Fields may appear in messages that are otherwise unspecified in this
8837+ document. They MUST conform to the syntax of an optional-field.
8838+ This is a field name, made up of the printable US-ASCII characters
8839+ except SP and colon, followed by a colon, followed by any text that
8840+ conforms to the unstructured syntax.
8841+
8842+ The field names of any optional field MUST NOT be identical to any
8843+ field name specified elsewhere in this document.
8844+
8845+
8846+
8847+
8848+
8849+
8850+
8851+
8852+
8853+
8854+ Resnick Standards Track [Page 30]
8855+
8856+ RFC 5322 Internet Message Format October 2008
8857+
8858+
8859+ optional-field = field-name ":" unstructured CRLF
8860+
8861+ field-name = 1*ftext
8862+
8863+ ftext = %d33-57 / ; Printable US-ASCII
8864+ %d59-126 ; characters not including
8865+ ; ":".
8866+
8867+ For the purposes of this specification, any optional field is
8868+ uninterpreted.
8869+
8870+ 4. Obsolete Syntax
8871+
8872+ Earlier versions of this specification allowed for different (usually
8873+ more liberal) syntax than is allowed in this version. Also, there
8874+ have been syntactic elements used in messages on the Internet whose
8875+ interpretations have never been documented. Though these syntactic
8876+ forms MUST NOT be generated according to the grammar in section 3,
8877+ they MUST be accepted and parsed by a conformant receiver. This
8878+ section documents many of these syntactic elements. Taking the
8879+ grammar in section 3 and adding the definitions presented in this
8880+ section will result in the grammar to use for the interpretation of
8881+ messages.
8882+
8883+ Note: This section identifies syntactic forms that any
8884+ implementation MUST reasonably interpret. However, there are
8885+ certainly Internet messages that do not conform to even the
8886+ additional syntax given in this section. The fact that a
8887+ particular form does not appear in any section of this document is
8888+ not justification for computer programs to crash or for malformed
8889+ data to be irretrievably lost by any implementation. It is up to
8890+ the implementation to deal with messages robustly.
8891+
8892+ One important difference between the obsolete (interpreting) and the
8893+ current (generating) syntax is that in structured header field bodies
8894+ (i.e., between the colon and the CRLF of any structured header
8895+ field), white space characters, including folding white space, and
8896+ comments could be freely inserted between any syntactic tokens. This
8897+ allowed many complex forms that have proven difficult for some
8898+ implementations to parse.
8899+
8900+ Another key difference between the obsolete and the current syntax is
8901+ that the rule in section 3.2.2 regarding lines composed entirely of
8902+ white space in comments and folding white space does not apply. See
8903+ the discussion of folding white space in section 4.2 below.
8904+
8905+ Finally, certain characters that were formerly allowed in messages
8906+ appear in this section. The NUL character (ASCII value 0) was once
8907+
8908+
8909+
8910+ Resnick Standards Track [Page 31]
8911+
8912+ RFC 5322 Internet Message Format October 2008
8913+
8914+
8915+ allowed, but is no longer for compatibility reasons. Similarly, US-
8916+ ASCII control characters other than CR, LF, SP, and HTAB (ASCII
8917+ values 1 through 8, 11, 12, 14 through 31, and 127) were allowed to
8918+ appear in header field bodies. CR and LF were allowed to appear in
8919+ messages other than as CRLF; this use is also shown here.
8920+
8921+ Other differences in syntax and semantics are noted in the following
8922+ sections.
8923+
8924+ 4.1. Miscellaneous Obsolete Tokens
8925+
8926+ These syntactic elements are used elsewhere in the obsolete syntax or
8927+ in the main syntax. Bare CR, bare LF, and NUL are added to obs-qp,
8928+ obs-body, and obs-unstruct. US-ASCII control characters are added to
8929+ obs-qp, obs-unstruct, obs-ctext, and obs-qtext. The period character
8930+ is added to obs-phrase. The obs-phrase-list provides for a
8931+ (potentially empty) comma-separated list of phrases that may include
8932+ "null" elements. That is, there could be two or more commas in such
8933+ a list with nothing in between them, or commas at the beginning or
8934+ end of the list.
8935+
8936+ Note: The "period" (or "full stop") character (".") in obs-phrase
8937+ is not a form that was allowed in earlier versions of this or any
8938+ other specification. Period (nor any other character from
8939+ specials) was not allowed in phrase because it introduced a
8940+ parsing difficulty distinguishing between phrases and portions of
8941+ an addr-spec (see section 4.4). It appears here because the
8942+ period character is currently used in many messages in the
8943+ display-name portion of addresses, especially for initials in
8944+ names, and therefore must be interpreted properly.
8945+
8946+ obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
8947+ %d11 / ; characters that do not
8948+ %d12 / ; include the carriage
8949+ %d14-31 / ; return, line feed, and
8950+ %d127 ; white space characters
8951+
8952+ obs-ctext = obs-NO-WS-CTL
8953+
8954+ obs-qtext = obs-NO-WS-CTL
8955+
8956+ obs-utext = %d0 / obs-NO-WS-CTL / VCHAR
8957+
8958+ obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR)
8959+
8960+ obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
8961+
8962+ obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
8963+
8964+
8965+
8966+ Resnick Standards Track [Page 32]
8967+
8968+ RFC 5322 Internet Message Format October 2008
8969+
8970+
8971+ obs-phrase = word *(word / "." / CFWS)
8972+
8973+ obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS])
8974+
8975+ Bare CR and bare LF appear in messages with two different meanings.
8976+ In many cases, bare CR or bare LF are used improperly instead of CRLF
8977+ to indicate line separators. In other cases, bare CR and bare LF are
8978+ used simply as US-ASCII control characters with their traditional
8979+ ASCII meanings.
8980+
8981+ 4.2. Obsolete Folding White Space
8982+
8983+ In the obsolete syntax, any amount of folding white space MAY be
8984+ inserted where the obs-FWS rule is allowed. This creates the
8985+ possibility of having two consecutive "folds" in a line, and
8986+ therefore the possibility that a line which makes up a folded header
8987+ field could be composed entirely of white space.
8988+
8989+ obs-FWS = 1*WSP *(CRLF 1*WSP)
8990+
8991+ 4.3. Obsolete Date and Time
8992+
8993+ The syntax for the obsolete date format allows a 2 digit year in the
8994+ date field and allows for a list of alphabetic time zone specifiers
8995+ that were used in earlier versions of this specification. It also
8996+ permits comments and folding white space between many of the tokens.
8997+
8998+ obs-day-of-week = [CFWS] day-name [CFWS]
8999+
9000+ obs-day = [CFWS] 1*2DIGIT [CFWS]
9001+
9002+ obs-year = [CFWS] 2*DIGIT [CFWS]
9003+
9004+ obs-hour = [CFWS] 2DIGIT [CFWS]
9005+
9006+ obs-minute = [CFWS] 2DIGIT [CFWS]
9007+
9008+ obs-second = [CFWS] 2DIGIT [CFWS]
9009+
9010+ obs-zone = "UT" / "GMT" / ; Universal Time
9011+ ; North American UT
9012+ ; offsets
9013+ "EST" / "EDT" / ; Eastern: - 5/ - 4
9014+ "CST" / "CDT" / ; Central: - 6/ - 5
9015+ "MST" / "MDT" / ; Mountain: - 7/ - 6
9016+ "PST" / "PDT" / ; Pacific: - 8/ - 7
9017+ ;
9018+
9019+
9020+
9021+
9022+ Resnick Standards Track [Page 33]
9023+
9024+ RFC 5322 Internet Message Format October 2008
9025+
9026+
9027+ %d65-73 / ; Military zones - "A"
9028+ %d75-90 / ; through "I" and "K"
9029+ %d97-105 / ; through "Z", both
9030+ %d107-122 ; upper and lower case
9031+
9032+ Where a two or three digit year occurs in a date, the year is to be
9033+ interpreted as follows: If a two digit year is encountered whose
9034+ value is between 00 and 49, the year is interpreted by adding 2000,
9035+ ending up with a value between 2000 and 2049. If a two digit year is
9036+ encountered with a value between 50 and 99, or any three digit year
9037+ is encountered, the year is interpreted by adding 1900.
9038+
9039+ In the obsolete time zone, "UT" and "GMT" are indications of
9040+ "Universal Time" and "Greenwich Mean Time", respectively, and are
9041+ both semantically identical to "+0000".
9042+
9043+ The remaining three character zones are the US time zones. The first
9044+ letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
9045+ "Mountain", and "Pacific". The second letter is either "S" for
9046+ "Standard" time, or "D" for "Daylight Savings" (or summer) time.
9047+ Their interpretations are as follows:
9048+
9049+ EDT is semantically equivalent to -0400
9050+ EST is semantically equivalent to -0500
9051+ CDT is semantically equivalent to -0500
9052+ CST is semantically equivalent to -0600
9053+ MDT is semantically equivalent to -0600
9054+ MST is semantically equivalent to -0700
9055+ PDT is semantically equivalent to -0700
9056+ PST is semantically equivalent to -0800
9057+
9058+ The 1 character military time zones were defined in a non-standard
9059+ way in [RFC0822] and are therefore unpredictable in their meaning.
9060+ The original definitions of the military zones "A" through "I" are
9061+ equivalent to "+0100" through "+0900", respectively; "K", "L", and
9062+ "M" are equivalent to "+1000", "+1100", and "+1200", respectively;
9063+ "N" through "Y" are equivalent to "-0100" through "-1200".
9064+ respectively; and "Z" is equivalent to "+0000". However, because of
9065+ the error in [RFC0822], they SHOULD all be considered equivalent to
9066+ "-0000" unless there is out-of-band information confirming their
9067+ meaning.
9068+
9069+ Other multi-character (usually between 3 and 5) alphabetic time zones
9070+ have been used in Internet messages. Any such time zone whose
9071+ meaning is not known SHOULD be considered equivalent to "-0000"
9072+ unless there is out-of-band information confirming their meaning.
9073+
9074+
9075+
9076+
9077+
9078+ Resnick Standards Track [Page 34]
9079+
9080+ RFC 5322 Internet Message Format October 2008
9081+
9082+
9083+ 4.4. Obsolete Addressing
9084+
9085+ There are four primary differences in addressing. First, mailbox
9086+ addresses were allowed to have a route portion before the addr-spec
9087+ when enclosed in "<" and ">". The route is simply a comma-separated
9088+ list of domain names, each preceded by "@", and the list terminated
9089+ by a colon. Second, CFWS were allowed between the period-separated
9090+ elements of local-part and domain (i.e., dot-atom was not used). In
9091+ addition, local-part is allowed to contain quoted-string in addition
9092+ to just atom. Third, mailbox-list and address-list were allowed to
9093+ have "null" members. That is, there could be two or more commas in
9094+ such a list with nothing in between them, or commas at the beginning
9095+ or end of the list. Finally, US-ASCII control characters and quoted-
9096+ pairs were allowed in domain literals and are added here.
9097+
9098+ obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS]
9099+
9100+ obs-route = obs-domain-list ":"
9101+
9102+ obs-domain-list = *(CFWS / ",") "@" domain
9103+ *("," [CFWS] ["@" domain])
9104+
9105+ obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS])
9106+
9107+ obs-addr-list = *([CFWS] ",") address *("," [address / CFWS])
9108+
9109+ obs-group-list = 1*([CFWS] ",") [CFWS]
9110+
9111+ obs-local-part = word *("." word)
9112+
9113+ obs-domain = atom *("." atom)
9114+
9115+ obs-dtext = obs-NO-WS-CTL / quoted-pair
9116+
9117+ When interpreting addresses, the route portion SHOULD be ignored.
9118+
9119+ 4.5. Obsolete Header Fields
9120+
9121+ Syntactically, the primary difference in the obsolete field syntax is
9122+ that it allows multiple occurrences of any of the fields and they may
9123+ occur in any order. Also, any amount of white space is allowed
9124+ before the ":" at the end of the field name.
9125+
9126+
9127+
9128+
9129+
9130+
9131+
9132+
9133+
9134+ Resnick Standards Track [Page 35]
9135+
9136+ RFC 5322 Internet Message Format October 2008
9137+
9138+
9139+ obs-fields = *(obs-return /
9140+ obs-received /
9141+ obs-orig-date /
9142+ obs-from /
9143+ obs-sender /
9144+ obs-reply-to /
9145+ obs-to /
9146+ obs-cc /
9147+ obs-bcc /
9148+ obs-message-id /
9149+ obs-in-reply-to /
9150+ obs-references /
9151+ obs-subject /
9152+ obs-comments /
9153+ obs-keywords /
9154+ obs-resent-date /
9155+ obs-resent-from /
9156+ obs-resent-send /
9157+ obs-resent-rply /
9158+ obs-resent-to /
9159+ obs-resent-cc /
9160+ obs-resent-bcc /
9161+ obs-resent-mid /
9162+ obs-optional)
9163+
9164+ Except for destination address fields (described in section 4.5.3),
9165+ the interpretation of multiple occurrences of fields is unspecified.
9166+ Also, the interpretation of trace fields and resent fields that do
9167+ not occur in blocks prepended to the message is unspecified as well.
9168+ Unless otherwise noted in the following sections, interpretation of
9169+ other fields is identical to the interpretation of their non-obsolete
9170+ counterparts in section 3.
9171+
9172+ 4.5.1. Obsolete Origination Date Field
9173+
9174+ obs-orig-date = "Date" *WSP ":" date-time CRLF
9175+
9176+ 4.5.2. Obsolete Originator Fields
9177+
9178+ obs-from = "From" *WSP ":" mailbox-list CRLF
9179+
9180+ obs-sender = "Sender" *WSP ":" mailbox CRLF
9181+
9182+ obs-reply-to = "Reply-To" *WSP ":" address-list CRLF
9183+
9184+
9185+
9186+
9187+
9188+
9189+
9190+ Resnick Standards Track [Page 36]
9191+
9192+ RFC 5322 Internet Message Format October 2008
9193+
9194+
9195+ 4.5.3. Obsolete Destination Address Fields
9196+
9197+ obs-to = "To" *WSP ":" address-list CRLF
9198+
9199+ obs-cc = "Cc" *WSP ":" address-list CRLF
9200+
9201+ obs-bcc = "Bcc" *WSP ":"
9202+ (address-list / (*([CFWS] ",") [CFWS])) CRLF
9203+
9204+ When multiple occurrences of destination address fields occur in a
9205+ message, they SHOULD be treated as if the address list in the first
9206+ occurrence of the field is combined with the address lists of the
9207+ subsequent occurrences by adding a comma and concatenating.
9208+
9209+ 4.5.4. Obsolete Identification Fields
9210+
9211+ The obsolete "In-Reply-To:" and "References:" fields differ from the
9212+ current syntax in that they allow phrase (words or quoted strings) to
9213+ appear. The obsolete forms of the left and right sides of msg-id
9214+ allow interspersed CFWS, making them syntactically identical to
9215+ local-part and domain, respectively.
9216+
9217+ obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
9218+
9219+ obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
9220+
9221+ obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
9222+
9223+ obs-id-left = local-part
9224+
9225+ obs-id-right = domain
9226+
9227+ For purposes of interpretation, the phrases in the "In-Reply-To:" and
9228+ "References:" fields are ignored.
9229+
9230+ Semantically, none of the optional CFWS in the local-part and the
9231+ domain is part of the obs-id-left and obs-id-right, respectively.
9232+
9233+ 4.5.5. Obsolete Informational Fields
9234+
9235+ obs-subject = "Subject" *WSP ":" unstructured CRLF
9236+
9237+ obs-comments = "Comments" *WSP ":" unstructured CRLF
9238+
9239+ obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
9240+
9241+
9242+
9243+
9244+
9245+
9246+ Resnick Standards Track [Page 37]
9247+
9248+ RFC 5322 Internet Message Format October 2008
9249+
9250+
9251+ 4.5.6. Obsolete Resent Fields
9252+
9253+ The obsolete syntax adds a "Resent-Reply-To:" field, which consists
9254+ of the field name, the optional comments and folding white space, the
9255+ colon, and a comma separated list of addresses.
9256+
9257+ obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
9258+
9259+ obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
9260+
9261+ obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
9262+
9263+ obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
9264+
9265+ obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
9266+
9267+ obs-resent-bcc = "Resent-Bcc" *WSP ":"
9268+ (address-list / (*([CFWS] ",") [CFWS])) CRLF
9269+
9270+ obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
9271+
9272+ obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
9273+
9274+ As with other resent fields, the "Resent-Reply-To:" field is to be
9275+ treated as trace information only.
9276+
9277+ 4.5.7. Obsolete Trace Fields
9278+
9279+ The obs-return and obs-received are again given here as template
9280+ definitions, just as return and received are in section 3. Their
9281+ full syntax is given in [RFC5321].
9282+
9283+ obs-return = "Return-Path" *WSP ":" path CRLF
9284+
9285+ obs-received = "Received" *WSP ":" *received-token CRLF
9286+
9287+ 4.5.8. Obsolete optional fields
9288+
9289+ obs-optional = field-name *WSP ":" unstructured CRLF
9290+
9291+ 5. Security Considerations
9292+
9293+ Care needs to be taken when displaying messages on a terminal or
9294+ terminal emulator. Powerful terminals may act on escape sequences
9295+ and other combinations of US-ASCII control characters with a variety
9296+ of consequences. They can remap the keyboard or permit other
9297+ modifications to the terminal that could lead to denial of service or
9298+ even damaged data. They can trigger (sometimes programmable)
9299+
9300+
9301+
9302+ Resnick Standards Track [Page 38]
9303+
9304+ RFC 5322 Internet Message Format October 2008
9305+
9306+
9307+ answerback messages that can allow a message to cause commands to be
9308+ issued on the recipient's behalf. They can also affect the operation
9309+ of terminal attached devices such as printers. Message viewers may
9310+ wish to strip potentially dangerous terminal escape sequences from
9311+ the message prior to display. However, other escape sequences appear
9312+ in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045],
9313+ [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore
9314+ should not be stripped indiscriminately.
9315+
9316+ Transmission of non-text objects in messages raises additional
9317+ security issues. These issues are discussed in [RFC2045], [RFC2046],
9318+ [RFC2047], [RFC2049], [RFC4288], and [RFC4289].
9319+
9320+ Many implementations use the "Bcc:" (blind carbon copy) field,
9321+ described in section 3.6.3, to facilitate sending messages to
9322+ recipients without revealing the addresses of one or more of the
9323+ addressees to the other recipients. Mishandling this use of "Bcc:"
9324+ may disclose confidential information that could eventually lead to
9325+ security problems through knowledge of even the existence of a
9326+ particular mail address. For example, if using the first method
9327+ described in section 3.6.3, where the "Bcc:" line is removed from the
9328+ message, blind recipients have no explicit indication that they have
9329+ been sent a blind copy, except insofar as their address does not
9330+ appear in the header section of a message. Because of this, one of
9331+ the blind addressees could potentially send a reply to all of the
9332+ shown recipients and accidentally reveal that the message went to the
9333+ blind recipient. When the second method from section 3.6.3 is used,
9334+ the blind recipient's address appears in the "Bcc:" field of a
9335+ separate copy of the message. If the "Bcc:" field sent contains all
9336+ of the blind addressees, all of the "Bcc:" recipients will be seen by
9337+ each "Bcc:" recipient. Even if a separate message is sent to each
9338+ "Bcc:" recipient with only the individual's address, implementations
9339+ still need to be careful to process replies to the message as per
9340+ section 3.6.3 so as not to accidentally reveal the blind recipient to
9341+ other recipients.
9342+
9343+ 6. IANA Considerations
9344+
9345+ This document updates the registrations that appeared in [RFC4021]
9346+ that referred to the definitions in [RFC2822]. IANA has updated the
9347+ Permanent Message Header Field Repository with the following header
9348+ fields, in accordance with the procedures set out in [RFC3864].
9349+
9350+ Header field name: Date
9351+ Applicable protocol: Mail
9352+ Status: standard
9353+ Author/Change controller: IETF
9354+ Specification document(s): This document (section 3.6.1)
9355+
9356+
9357+
9358+ Resnick Standards Track [Page 39]
9359+
9360+ RFC 5322 Internet Message Format October 2008
9361+
9362+
9363+ Header field name: From
9364+ Applicable protocol: Mail
9365+ Status: standard
9366+ Author/Change controller: IETF
9367+ Specification document(s): This document (section 3.6.2)
9368+
9369+ Header field name: Sender
9370+ Applicable protocol: Mail
9371+ Status: standard
9372+ Author/Change controller: IETF
9373+ Specification document(s): This document (section 3.6.2)
9374+
9375+ Header field name: Reply-To
9376+ Applicable protocol: Mail
9377+ Status: standard
9378+ Author/Change controller: IETF
9379+ Specification document(s): This document (section 3.6.2)
9380+
9381+ Header field name: To
9382+ Applicable protocol: Mail
9383+ Status: standard
9384+ Author/Change controller: IETF
9385+ Specification document(s): This document (section 3.6.3)
9386+
9387+ Header field name: Cc
9388+ Applicable protocol: Mail
9389+ Status: standard
9390+ Author/Change controller: IETF
9391+ Specification document(s): This document (section 3.6.3)
9392+
9393+ Header field name: Bcc
9394+ Applicable protocol: Mail
9395+ Status: standard
9396+ Author/Change controller: IETF
9397+ Specification document(s): This document (section 3.6.3)
9398+
9399+ Header field name: Message-ID
9400+ Applicable protocol: Mail
9401+ Status: standard
9402+ Author/Change controller: IETF
9403+ Specification document(s): This document (section 3.6.4)
9404+
9405+ Header field name: In-Reply-To
9406+ Applicable protocol: Mail
9407+ Status: standard
9408+ Author/Change controller: IETF
9409+ Specification document(s): This document (section 3.6.4)
9410+
9411+
9412+
9413+
9414+ Resnick Standards Track [Page 40]
9415+
9416+ RFC 5322 Internet Message Format October 2008
9417+
9418+
9419+ Header field name: References
9420+ Applicable protocol: Mail
9421+ Status: standard
9422+ Author/Change controller: IETF
9423+ Specification document(s): This document (section 3.6.4)
9424+
9425+ Header field name: Subject
9426+ Applicable protocol: Mail
9427+ Status: standard
9428+ Author/Change controller: IETF
9429+ Specification document(s): This document (section 3.6.5)
9430+
9431+ Header field name: Comments
9432+ Applicable protocol: Mail
9433+ Status: standard
9434+ Author/Change controller: IETF
9435+ Specification document(s): This document (section 3.6.5)
9436+
9437+ Header field name: Keywords
9438+ Applicable protocol: Mail
9439+ Status: standard
9440+ Author/Change controller: IETF
9441+ Specification document(s): This document (section 3.6.5)
9442+
9443+ Header field name: Resent-Date
9444+ Applicable protocol: Mail
9445+ Status: standard
9446+ Author/Change controller: IETF
9447+ Specification document(s): This document (section 3.6.6)
9448+
9449+ Header field name: Resent-From
9450+ Applicable protocol: Mail
9451+ Status: standard
9452+ Author/Change controller: IETF
9453+ Specification document(s): This document (section 3.6.6)
9454+
9455+ Header field name: Resent-Sender
9456+ Applicable protocol: Mail
9457+ Status: standard
9458+ Author/Change controller: IETF
9459+ Specification document(s): This document (section 3.6.6)
9460+
9461+ Header field name: Resent-To
9462+ Applicable protocol: Mail
9463+ Status: standard
9464+ Author/Change controller: IETF
9465+ Specification document(s): This document (section 3.6.6)
9466+
9467+
9468+
9469+
9470+ Resnick Standards Track [Page 41]
9471+
9472+ RFC 5322 Internet Message Format October 2008
9473+
9474+
9475+ Header field name: Resent-Cc
9476+ Applicable protocol: Mail
9477+ Status: standard
9478+ Author/Change controller: IETF
9479+ Specification document(s): This document (section 3.6.6)
9480+
9481+ Header field name: Resent-Bcc
9482+ Applicable protocol: Mail
9483+ Status: standard
9484+ Author/Change controller: IETF
9485+ Specification document(s): This document (section 3.6.6)
9486+
9487+ Header field name: Resent-Reply-To
9488+ Applicable protocol: Mail
9489+ Status: obsolete
9490+ Author/Change controller: IETF
9491+ Specification document(s): This document (section 4.5.6)
9492+
9493+ Header field name: Resent-Message-ID
9494+ Applicable protocol: Mail
9495+ Status: standard
9496+ Author/Change controller: IETF
9497+ Specification document(s): This document (section 3.6.6)
9498+
9499+ Header field name: Return-Path
9500+ Applicable protocol: Mail
9501+ Status: standard
9502+ Author/Change controller: IETF
9503+ Specification document(s): This document (section 3.6.7)
9504+
9505+ Header field name: Received
9506+ Applicable protocol: Mail
9507+ Status: standard
9508+ Author/Change controller: IETF
9509+ Specification document(s): This document (section 3.6.7)
9510+ Related information: [RFC5321]
9511+
9512+
9513+
9514+
9515+
9516+
9517+
9518+
9519+
9520+
9521+
9522+
9523+
9524+
9525+
9526+ Resnick Standards Track [Page 42]
9527+
9528+ RFC 5322 Internet Message Format October 2008
9529+
9530+
9531+ Appendix A. Example Messages
9532+
9533+ This section presents a selection of messages. These are intended to
9534+ assist in the implementation of this specification, but should not be
9535+ taken as normative; that is to say, although the examples in this
9536+ section were carefully reviewed, if there happens to be a conflict
9537+ between these examples and the syntax described in sections 3 and 4
9538+ of this document, the syntax in those sections is to be taken as
9539+ correct.
9540+
9541+ In the text version of this document, messages in this section are
9542+ delimited between lines of "----". The "----" lines are not part of
9543+ the message itself.
9544+
9545+
9546+
9547+
9548+
9549+
9550+
9551+
9552+
9553+
9554+
9555+
9556+
9557+
9558+
9559+
9560+
9561+
9562+
9563+
9564+
9565+
9566+
9567+
9568+
9569+
9570+
9571+
9572+
9573+
9574+
9575+
9576+
9577+
9578+
9579+
9580+
9581+
9582+ Resnick Standards Track [Page 43]
9583+
9584+ RFC 5322 Internet Message Format October 2008
9585+
9586+
9587+ Appendix A.1. Addressing Examples
9588+
9589+ The following are examples of messages that might be sent between two
9590+ individuals.
9591+
9592+ Appendix A.1.1. A Message from One Person to Another with Simple
9593+ Addressing
9594+
9595+ This could be called a canonical message. It has a single author,
9596+ John Doe, a single recipient, Mary Smith, a subject, the date, a
9597+ message identifier, and a textual message in the body.
9598+
9599+ ----
9600+ From: John Doe <jdoe@machine.example>
9601+ To: Mary Smith <mary@example.net>
9602+ Subject: Saying Hello
9603+ Date: Fri, 21 Nov 1997 09:55:06 -0600
9604+ Message-ID: <1234@local.machine.example>
9605+
9606+ This is a message just to say hello.
9607+ So, "Hello".
9608+ ----
9609+
9610+ If John's secretary Michael actually sent the message, even though
9611+ John was the author and replies to this message should go back to
9612+ him, the sender field would be used:
9613+
9614+ ----
9615+ From: John Doe <jdoe@machine.example>
9616+ Sender: Michael Jones <mjones@machine.example>
9617+ To: Mary Smith <mary@example.net>
9618+ Subject: Saying Hello
9619+ Date: Fri, 21 Nov 1997 09:55:06 -0600
9620+ Message-ID: <1234@local.machine.example>
9621+
9622+ This is a message just to say hello.
9623+ So, "Hello".
9624+ ----
9625+
9626+
9627+
9628+
9629+
9630+
9631+
9632+
9633+
9634+
9635+
9636+
9637+
9638+ Resnick Standards Track [Page 44]
9639+
9640+ RFC 5322 Internet Message Format October 2008
9641+
9642+
9643+ Appendix A.1.2. Different Types of Mailboxes
9644+
9645+ This message includes multiple addresses in the destination fields
9646+ and also uses several different forms of addresses.
9647+
9648+ ----
9649+ From: "Joe Q. Public" <john.q.public@example.com>
9650+ To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
9651+ Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
9652+ Date: Tue, 1 Jul 2003 10:52:37 +0200
9653+ Message-ID: <5678.21-Nov-1997@example.com>
9654+
9655+ Hi everyone.
9656+ ----
9657+
9658+ Note that the display names for Joe Q. Public and Giant; "Big" Box
9659+ needed to be enclosed in double-quotes because the former contains
9660+ the period and the latter contains both semicolon and double-quote
9661+ characters (the double-quote characters appearing as quoted-pair
9662+ constructs). Conversely, the display name for Who? could appear
9663+ without them because the question mark is legal in an atom. Notice
9664+ also that jdoe@example.org and boss@nil.test have no display names
9665+ associated with them at all, and jdoe@example.org uses the simpler
9666+ address form without the angle brackets.
9667+
9668+ Appendix A.1.3. Group Addresses
9669+
9670+ ----
9671+ From: Pete <pete@silly.example>
9672+ To: A Group:Ed Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
9673+ Cc: Undisclosed recipients:;
9674+ Date: Thu, 13 Feb 1969 23:32:54 -0330
9675+ Message-ID: <testabcd.1234@silly.example>
9676+
9677+ Testing.
9678+ ----
9679+
9680+ In this message, the "To:" field has a single group recipient named
9681+ "A Group", which contains 3 addresses, and a "Cc:" field with an
9682+ empty group recipient named Undisclosed recipients.
9683+
9684+
9685+
9686+
9687+
9688+
9689+
9690+
9691+
9692+
9693+
9694+ Resnick Standards Track [Page 45]
9695+
9696+ RFC 5322 Internet Message Format October 2008
9697+
9698+
9699+ Appendix A.2. Reply Messages
9700+
9701+ The following is a series of three messages that make up a
9702+ conversation thread between John and Mary. John first sends a
9703+ message to Mary, Mary then replies to John's message, and then John
9704+ replies to Mary's reply message.
9705+
9706+ Note especially the "Message-ID:", "References:", and "In-Reply-To:"
9707+ fields in each message.
9708+
9709+ ----
9710+ From: John Doe <jdoe@machine.example>
9711+ To: Mary Smith <mary@example.net>
9712+ Subject: Saying Hello
9713+ Date: Fri, 21 Nov 1997 09:55:06 -0600
9714+ Message-ID: <1234@local.machine.example>
9715+
9716+ This is a message just to say hello.
9717+ So, "Hello".
9718+ ----
9719+
9720+ When sending replies, the Subject field is often retained, though
9721+ prepended with "Re: " as described in section 3.6.5.
9722+
9723+ ----
9724+ From: Mary Smith <mary@example.net>
9725+ To: John Doe <jdoe@machine.example>
9726+ Reply-To: "Mary Smith: Personal Account" <smith@home.example>
9727+ Subject: Re: Saying Hello
9728+ Date: Fri, 21 Nov 1997 10:01:10 -0600
9729+ Message-ID: <3456@example.net>
9730+ In-Reply-To: <1234@local.machine.example>
9731+ References: <1234@local.machine.example>
9732+
9733+ This is a reply to your hello.
9734+ ----
9735+
9736+ Note the "Reply-To:" field in the above message. When John replies
9737+ to Mary's message above, the reply should go to the address in the
9738+ "Reply-To:" field instead of the address in the "From:" field.
9739+
9740+
9741+
9742+
9743+
9744+
9745+
9746+
9747+
9748+
9749+
9750+ Resnick Standards Track [Page 46]
9751+
9752+ RFC 5322 Internet Message Format October 2008
9753+
9754+
9755+ ----
9756+ To: "Mary Smith: Personal Account" <smith@home.example>
9757+ From: John Doe <jdoe@machine.example>
9758+ Subject: Re: Saying Hello
9759+ Date: Fri, 21 Nov 1997 11:00:00 -0600
9760+ Message-ID: <abcd.1234@local.machine.test>
9761+ In-Reply-To: <3456@example.net>
9762+ References: <1234@local.machine.example> <3456@example.net>
9763+
9764+ This is a reply to your reply.
9765+ ----
9766+
9767+ Appendix A.3. Resent Messages
9768+
9769+ Start with the message that has been used as an example several
9770+ times:
9771+
9772+ ----
9773+ From: John Doe <jdoe@machine.example>
9774+ To: Mary Smith <mary@example.net>
9775+ Subject: Saying Hello
9776+ Date: Fri, 21 Nov 1997 09:55:06 -0600
9777+ Message-ID: <1234@local.machine.example>
9778+
9779+ This is a message just to say hello.
9780+ So, "Hello".
9781+ ----
9782+
9783+ Say that Mary, upon receiving this message, wishes to send a copy of
9784+ the message to Jane such that (a) the message would appear to have
9785+ come straight from John; (b) if Jane replies to the message, the
9786+ reply should go back to John; and (c) all of the original
9787+ information, like the date the message was originally sent to Mary,
9788+ the message identifier, and the original addressee, is preserved. In
9789+ this case, resent fields are prepended to the message:
9790+
9791+
9792+
9793+
9794+
9795+
9796+
9797+
9798+
9799+
9800+
9801+
9802+
9803+
9804+
9805+
9806+ Resnick Standards Track [Page 47]
9807+
9808+ RFC 5322 Internet Message Format October 2008
9809+
9810+
9811+ ----
9812+ Resent-From: Mary Smith <mary@example.net>
9813+ Resent-To: Jane Brown <j-brown@other.example>
9814+ Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
9815+ Resent-Message-ID: <78910@example.net>
9816+ From: John Doe <jdoe@machine.example>
9817+ To: Mary Smith <mary@example.net>
9818+ Subject: Saying Hello
9819+ Date: Fri, 21 Nov 1997 09:55:06 -0600
9820+ Message-ID: <1234@local.machine.example>
9821+
9822+ This is a message just to say hello.
9823+ So, "Hello".
9824+ ----
9825+
9826+ If Jane, in turn, wished to resend this message to another person,
9827+ she would prepend her own set of resent header fields to the above
9828+ and send that. (Note that for brevity, trace fields are not shown.)
9829+
9830+ Appendix A.4. Messages with Trace Fields
9831+
9832+ As messages are sent through the transport system as described in
9833+ [RFC5321], trace fields are prepended to the message. The following
9834+ is an example of what those trace fields might look like. Note that
9835+ there is some folding white space in the first one since these lines
9836+ can be long.
9837+
9838+ ----
9839+ Received: from x.y.test
9840+ by example.net
9841+ via TCP
9842+ with ESMTP
9843+ id ABC12345
9844+ for <mary@example.net>; 21 Nov 1997 10:05:43 -0600
9845+ Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600
9846+ From: John Doe <jdoe@node.example>
9847+ To: Mary Smith <mary@example.net>
9848+ Subject: Saying Hello
9849+ Date: Fri, 21 Nov 1997 09:55:06 -0600
9850+ Message-ID: <1234@local.node.example>
9851+
9852+ This is a message just to say hello.
9853+ So, "Hello".
9854+ ----
9855+
9856+
9857+
9858+
9859+
9860+
9861+
9862+ Resnick Standards Track [Page 48]
9863+
9864+ RFC 5322 Internet Message Format October 2008
9865+
9866+
9867+ Appendix A.5. White Space, Comments, and Other Oddities
9868+
9869+ White space, including folding white space, and comments can be
9870+ inserted between many of the tokens of fields. Taking the example
9871+ from A.1.3, white space and comments can be inserted into all of the
9872+ fields.
9873+
9874+ ----
9875+ From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
9876+ To:A Group(Some people)
9877+ :Chris Jones <c@(Chris's host.)public.example>,
9878+ joe@example.org,
9879+ John <jdoe@one.test> (my dear friend); (the end of the group)
9880+ Cc:(Empty list)(start)Hidden recipients :(nobody(that I know)) ;
9881+ Date: Thu,
9882+ 13
9883+ Feb
9884+ 1969
9885+ 23:32
9886+ -0330 (Newfoundland Time)
9887+ Message-ID: <testabcd.1234@silly.test>
9888+
9889+ Testing.
9890+ ----
9891+
9892+ The above example is aesthetically displeasing, but perfectly legal.
9893+ Note particularly (1) the comments in the "From:" field (including
9894+ one that has a ")" character appearing as part of a quoted-pair); (2)
9895+ the white space absent after the ":" in the "To:" field as well as
9896+ the comment and folding white space after the group name, the special
9897+ character (".") in the comment in Chris Jones's address, and the
9898+ folding white space before and after "joe@example.org,"; (3) the
9899+ multiple and nested comments in the "Cc:" field as well as the
9900+ comment immediately following the ":" after "Cc"; (4) the folding
9901+ white space (but no comments except at the end) and the missing
9902+ seconds in the time of the date field; and (5) the white space before
9903+ (but not within) the identifier in the "Message-ID:" field.
9904+
9905+
9906+
9907+
9908+
9909+
9910+
9911+
9912+
9913+
9914+
9915+
9916+
9917+
9918+ Resnick Standards Track [Page 49]
9919+
9920+ RFC 5322 Internet Message Format October 2008
9921+
9922+
9923+ Appendix A.6. Obsoleted Forms
9924+
9925+ The following are examples of obsolete (that is, the "MUST NOT
9926+ generate") syntactic elements described in section 4 of this
9927+ document.
9928+
9929+ Appendix A.6.1. Obsolete Addressing
9930+
9931+ Note in the example below the lack of quotes around Joe Q. Public,
9932+ the route that appears in the address for Mary Smith, the two commas
9933+ that appear in the "To:" field, and the spaces that appear around the
9934+ "." in the jdoe address.
9935+
9936+ ----
9937+ From: Joe Q. Public <john.q.public@example.com>
9938+ To: Mary Smith <@node.test:mary@example.net>, , jdoe@test . example
9939+ Date: Tue, 1 Jul 2003 10:52:37 +0200
9940+ Message-ID: <5678.21-Nov-1997@example.com>
9941+
9942+ Hi everyone.
9943+ ----
9944+
9945+ Appendix A.6.2. Obsolete Dates
9946+
9947+ The following message uses an obsolete date format, including a non-
9948+ numeric time zone and a two digit year. Note that although the day-
9949+ of-week is missing, that is not specific to the obsolete syntax; it
9950+ is optional in the current syntax as well.
9951+
9952+ ----
9953+ From: John Doe <jdoe@machine.example>
9954+ To: Mary Smith <mary@example.net>
9955+ Subject: Saying Hello
9956+ Date: 21 Nov 97 09:55:06 GMT
9957+ Message-ID: <1234@local.machine.example>
9958+
9959+ This is a message just to say hello.
9960+ So, "Hello".
9961+ ----
9962+
9963+
9964+
9965+
9966+
9967+
9968+
9969+
9970+
9971+
9972+
9973+
9974+ Resnick Standards Track [Page 50]
9975+
9976+ RFC 5322 Internet Message Format October 2008
9977+
9978+
9979+ Appendix A.6.3. Obsolete White Space and Comments
9980+
9981+ White space and comments can appear between many more elements than
9982+ in the current syntax. Also, folding lines that are made up entirely
9983+ of white space are legal.
9984+
9985+ ----
9986+ From : John Doe <jdoe@machine(comment). example>
9987+ To : Mary Smith
9988+ __
9989+ <mary@example.net>
9990+ Subject : Saying Hello
9991+ Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
9992+ Message-ID : <1234 @ local(blah) .machine .example>
9993+
9994+ This is a message just to say hello.
9995+ So, "Hello".
9996+ ----
9997+
9998+ Note especially the second line of the "To:" field. It starts with
9999+ two space characters. (Note that "__" represent blank spaces.)
10000+ Therefore, it is considered part of the folding, as described in
10001+ section 4.2. Also, the comments and white space throughout
10002+ addresses, dates, and message identifiers are all part of the
10003+ obsolete syntax.
10004+
10005+
10006+
10007+
10008+
10009+
10010+
10011+
10012+
10013+
10014+
10015+
10016+
10017+
10018+
10019+
10020+
10021+
10022+
10023+
10024+
10025+
10026+
10027+
10028+
10029+
10030+ Resnick Standards Track [Page 51]
10031+
10032+ RFC 5322 Internet Message Format October 2008
10033+
10034+
10035+ Appendix B. Differences from Earlier Specifications
10036+
10037+ This appendix contains a list of changes that have been made in the
10038+ Internet Message Format from earlier specifications, specifically
10039+ [RFC0822], [RFC1123], and [RFC2822]. Items marked with an asterisk
10040+ (*) below are items which appear in section 4 of this document and
10041+ therefore can no longer be generated.
10042+
10043+ The following are the changes made from [RFC0822] and [RFC1123] to
10044+ [RFC2822] that remain in this document:
10045+
10046+ 1. Period allowed in obsolete form of phrase.
10047+ 2. ABNF moved out of document, now in [RFC5234].
10048+ 3. Four or more digits allowed for year.
10049+ 4. Header field ordering (and lack thereof) made explicit.
10050+ 5. Encrypted header field removed.
10051+ 6. Specifically allow and give meaning to "-0000" time zone.
10052+ 7. Folding white space is not allowed between every token.
10053+ 8. Requirement for destinations removed.
10054+ 9. Forwarding and resending redefined.
10055+ 10. Extension header fields no longer specifically called out.
10056+ 11. ASCII 0 (null) removed.*
10057+ 12. Folding continuation lines cannot contain only white space.*
10058+ 13. Free insertion of comments not allowed in date.*
10059+ 14. Non-numeric time zones not allowed.*
10060+ 15. Two digit years not allowed.*
10061+ 16. Three digit years interpreted, but not allowed for generation.*
10062+ 17. Routes in addresses not allowed.*
10063+ 18. CFWS within local-parts and domains not allowed.*
10064+ 19. Empty members of address lists not allowed.*
10065+ 20. Folding white space between field name and colon not allowed.*
10066+ 21. Comments between field name and colon not allowed.
10067+ 22. Tightened syntax of in-reply-to and references.*
10068+ 23. CFWS within msg-id not allowed.*
10069+ 24. Tightened semantics of resent fields as informational only.
10070+ 25. Resent-Reply-To not allowed.*
10071+ 26. No multiple occurrences of fields (except resent and received).*
10072+ 27. Free CR and LF not allowed.*
10073+ 28. Line length limits specified.
10074+ 29. Bcc more clearly specified.
10075+
10076+
10077+
10078+
10079+
10080+
10081+
10082+
10083+
10084+
10085+
10086+ Resnick Standards Track [Page 52]
10087+
10088+ RFC 5322 Internet Message Format October 2008
10089+
10090+
10091+ The following are changes from [RFC2822].
10092+ 1. Assorted typographical/grammatical errors fixed and
10093+ clarifications made.
10094+ 2. Changed "standard" to "document" or "specification" throughout.
10095+ 3. Made distinction between "header field" and "header section".
10096+ 4. Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.*
10097+ 5. Moved discussion of specials to the "Atom" section. Moved text
10098+ to "Overall message syntax" section.
10099+ 6. Simplified CFWS syntax.
10100+ 7. Fixed unstructured syntax.
10101+ 8. Changed date and time syntax to deal with white space in
10102+ obsolete date syntax.
10103+ 9. Removed quoted-pair from domain literals and message
10104+ identifiers.*
10105+ 10. Clarified that other specifications limit domain syntax.
10106+ 11. Simplified "Bcc:" and "Resent-Bcc:" syntax.
10107+ 12. Allowed optional-field to appear within trace information.
10108+ 13. Removed no-fold-quote from msg-id. Clarified syntax
10109+ limitations.
10110+ 14. Generalized "Received:" syntax to fix bugs and move definition
10111+ out of this document.
10112+ 15. Simplified obs-qp. Fixed and simplified obs-utext (which now
10113+ only appears in the obsolete syntax). Removed obs-text and obs-
10114+ char, adding obs-body.
10115+ 16. Fixed obsolete date syntax to allow for more (or less) comments
10116+ and white space.
10117+ 17. Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list,
10118+ obs-addr-list, obs-phrase-list, and the newly added obs-group-
10119+ list).
10120+ 18. Fixed obs-reply-to syntax.
10121+ 19. Fixed obs-bcc and obs-resent-bcc to allow empty lists.
10122+ 20. Removed obs-path.
10123+
10124+ Appendix C. Acknowledgements
10125+
10126+ Many people contributed to this document. They included folks who
10127+ participated in the Detailed Revision and Update of Messaging
10128+ Standards (DRUMS) Working Group of the Internet Engineering Task
10129+ Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
10130+ people who simply sent their comments in via email. The editor is
10131+ deeply indebted to them all and thanks them sincerely. The below
10132+ list includes everyone who sent email concerning both this document
10133+ and [RFC2822]. Hopefully, everyone who contributed is named here:
10134+
10135+ +--------------------+----------------------+---------------------+
10136+ | Matti Aarnio | Tanaka Akira | Russ Allbery |
10137+ | Eric Allman | Harald Alvestrand | Ran Atkinson |
10138+ | Jos Backus | Bruce Balden | Dave Barr |
10139+
10140+
10141+
10142+ Resnick Standards Track [Page 53]
10143+
10144+ RFC 5322 Internet Message Format October 2008
10145+
10146+
10147+ | Alan Barrett | John Beck | J Robert von Behren |
10148+ | Jos den Bekker | D J Bernstein | James Berriman |
10149+ | Oliver Block | Norbert Bollow | Raj Bose |
10150+ | Antony Bowesman | Scott Bradner | Randy Bush |
10151+ | Tom Byrer | Bruce Campbell | Larry Campbell |
10152+ | W J Carpenter | Michael Chapman | Richard Clayton |
10153+ | Maurizio Codogno | Jim Conklin | R Kelley Cook |
10154+ | Nathan Coulter | Steve Coya | Mark Crispin |
10155+ | Dave Crocker | Matt Curtin | Michael D'Errico |
10156+ | Cyrus Daboo | Michael D Dean | Jutta Degener |
10157+ | Mark Delany | Steve Dorner | Harold A Driscoll |
10158+ | Michael Elkins | Frank Ellerman | Robert Elz |
10159+ | Johnny Eriksson | Erik E Fair | Roger Fajman |
10160+ | Patrik Faltstrom | Claus Andre Faerber | Barry Finkel |
10161+ | Erik Forsberg | Chuck Foster | Paul Fox |
10162+ | Klaus M Frank | Ned Freed | Jochen Friedrich |
10163+ | Randall C Gellens | Sukvinder Singh Gill | Tim Goodwin |
10164+ | Philip Guenther | Arnt Gulbrandsen | Eric A Hall |
10165+ | Tony Hansen | John Hawkinson | Philip Hazel |
10166+ | Kai Henningsen | Robert Herriot | Paul Hethmon |
10167+ | Jim Hill | Alfred Hoenes | Paul E Hoffman |
10168+ | Steve Hole | Kari Hurtta | Marco S Hyman |
10169+ | Ofer Inbar | Olle Jarnefors | Kevin Johnson |
10170+ | Sudish Joseph | Maynard Kang | Prabhat Keni |
10171+ | John C Klensin | Graham Klyne | Brad Knowles |
10172+ | Shuhei Kobayashi | Peter Koch | Dan Kohn |
10173+ | Christian Kuhtz | Anand Kumria | Steen Larsen |
10174+ | Eliot Lear | Barry Leiba | Jay Levitt |
10175+ | Bruce Lilly | Lars-Johan Liman | Charles Lindsey |
10176+ | Pete Loshin | Simon Lyall | Bill Manning |
10177+ | John Martin | Mark Martinec | Larry Masinter |
10178+ | Denis McKeon | William P McQuillan | Alexey Melnikov |
10179+ | Perry E Metzger | Steven Miller | S Moonesamy |
10180+ | Keith Moore | John Gardiner Myers | Chris Newman |
10181+ | John W Noerenberg | Eric Norman | Mike O'Dell |
10182+ | Larry Osterman | Paul Overell | Jacob Palme |
10183+ | Michael A Patton | Uzi Paz | Michael A Quinlan |
10184+ | Robert Rapplean | Eric S Raymond | Sam Roberts |
10185+ | Hugh Sasse | Bart Schaefer | Tom Scola |
10186+ | Wolfgang Segmuller | Nick Shelness | John Stanley |
10187+ | Einar Stefferud | Jeff Stephenson | Bernard Stern |
10188+ | Peter Sylvester | Mark Symons | Eric Thomas |
10189+ | Lee Thompson | Karel De Vriendt | Matthew Wall |
10190+ | Rolf Weber | Brent B Welch | Dan Wing |
10191+ | Jack De Winter | Gregory J Woodhouse | Greg A Woods |
10192+ | Kazu Yamamoto | Alain Zahm | Jamie Zawinski |
10193+ | Timothy S Zurcher | | |
10194+ +--------------------+----------------------+---------------------+
10195+
10196+
10197+
10198+ Resnick Standards Track [Page 54]
10199+
10200+ RFC 5322 Internet Message Format October 2008
10201+
10202+
10203+ 7. References
10204+
10205+ 7.1. Normative References
10206+
10207+ [ANSI.X3-4.1986] American National Standards Institute, "Coded
10208+ Character Set - 7-bit American Standard Code for
10209+ Information Interchange", ANSI X3.4, 1986.
10210+
10211+ [RFC1034] Mockapetris, P., "Domain names - concepts and
10212+ facilities", STD 13, RFC 1034, November 1987.
10213+
10214+ [RFC1035] Mockapetris, P., "Domain names - implementation and
10215+ specification", STD 13, RFC 1035, November 1987.
10216+
10217+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
10218+ Application and Support", STD 3, RFC 1123,
10219+ October 1989.
10220+
10221+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
10222+ Requirement Levels", BCP 14, RFC 2119, March 1997.
10223+
10224+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
10225+ Syntax Specifications: ABNF", STD 68, RFC 5234,
10226+ January 2008.
10227+
10228+ 7.2. Informative References
10229+
10230+ [RFC0822] Crocker, D., "Standard for the format of ARPA
10231+ Internet text messages", STD 11, RFC 822,
10232+ August 1982.
10233+
10234+ [RFC1305] Mills, D., "Network Time Protocol (Version 3)
10235+ Specification, Implementation", RFC 1305,
10236+ March 1992.
10237+
10238+ [ISO.2022.1994] International Organization for Standardization,
10239+ "Information technology - Character code structure
10240+ and extension techniques", ISO Standard 2022, 1994.
10241+
10242+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
10243+ Mail Extensions (MIME) Part One: Format of Internet
10244+ Message Bodies", RFC 2045, November 1996.
10245+
10246+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
10247+ Mail Extensions (MIME) Part Two: Media Types",
10248+ RFC 2046, November 1996.
10249+
10250+
10251+
10252+
10253+
10254+ Resnick Standards Track [Page 55]
10255+
10256+ RFC 5322 Internet Message Format October 2008
10257+
10258+
10259+ [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
10260+ Extensions) Part Three: Message Header Extensions
10261+ for Non-ASCII Text", RFC 2047, November 1996.
10262+
10263+ [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
10264+ Mail Extensions (MIME) Part Five: Conformance
10265+ Criteria and Examples", RFC 2049, November 1996.
10266+
10267+ [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
10268+ April 2001.
10269+
10270+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
10271+ "Registration Procedures for Message Header
10272+ Fields", BCP 90, RFC 3864, September 2004.
10273+
10274+ [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and
10275+ MIME Header Fields", RFC 4021, March 2005.
10276+
10277+ [RFC4288] Freed, N. and J. Klensin, "Media Type
10278+ Specifications and Registration Procedures",
10279+ BCP 13, RFC 4288, December 2005.
10280+
10281+ [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet
10282+ Mail Extensions (MIME) Part Four: Registration
10283+ Procedures", BCP 13, RFC 4289, December 2005.
10284+
10285+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol",
10286+ RFC 5321, October 2008.
10287+
10288+ Author's Address
10289+
10290+ Peter W. Resnick (editor)
10291+ Qualcomm Incorporated
10292+ 5775 Morehouse Drive
10293+ San Diego, CA 92121-1714
10294+ US
10295+
10296+ Phone: +1 858 651 4478
10297+ EMail: presnick@qualcomm.com
10298+ URI: http://www.qualcomm.com/~presnick/
10299+
10300+
10301+
10302+
10303+
10304+
10305+
10306+
10307+
10308+
10309+
10310+ Resnick Standards Track [Page 56]
10311+
10312+ RFC 5322 Internet Message Format October 2008
10313+
10314+
10315+ Full Copyright Statement
10316+
10317+ Copyright (C) The IETF Trust (2008).
10318+
10319+ This document is subject to the rights, licenses and restrictions
10320+ contained in BCP 78, and except as set forth therein, the authors
10321+ retain all their rights.
10322+
10323+ This document and the information contained herein are provided on an
10324+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
10325+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
10326+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
10327+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
10328+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
10329+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10330+
10331+ Intellectual Property
10332+
10333+ The IETF takes no position regarding the validity or scope of any
10334+ Intellectual Property Rights or other rights that might be claimed to
10335+ pertain to the implementation or use of the technology described in
10336+ this document or the extent to which any license under such rights
10337+ might or might not be available; nor does it represent that it has
10338+ made any independent effort to identify any such rights. Information
10339+ on the procedures with respect to rights in RFC documents can be
10340+ found in BCP 78 and BCP 79.
10341+
10342+ Copies of IPR disclosures made to the IETF Secretariat and any
10343+ assurances of licenses to be made available, or the result of an
10344+ attempt made to obtain a general license or permission for the use of
10345+ such proprietary rights by implementers or users of this
10346+ specification can be obtained from the IETF on-line IPR repository at
10347+ http://www.ietf.org/ipr.
10348+
10349+ The IETF invites any interested party to bring to its attention any
10350+ copyrights, patents or patent applications, or other proprietary
10351+ rights that may cover technology that may be required to implement
10352+ this standard. Please address the information to the IETF at
10353+ ietf-ipr@ietf.org.
10354+
10355+
10356+
10357+
10358+
10359+
10360+
10361+
10362+
10363+
10364+
10365+
10366+ Resnick Standards Track [Page 57]
10367+