rack-mail_exception 0.0.1

Sign up to get free protection for your applications and to get access to all the features.
Files changed (321) hide show
  1. data/.document +5 -0
  2. data/.gitignore +22 -0
  3. data/LICENSE +20 -0
  4. data/README.rdoc +38 -0
  5. data/Rakefile +56 -0
  6. data/VERSION +1 -0
  7. data/lib/rack/mail_exception.rb +103 -0
  8. data/test/helper.rb +13 -0
  9. data/test/test_rack_mail_exception.rb +93 -0
  10. data/vendor/mail/.bundle/config +2 -0
  11. data/vendor/mail/CHANGELOG.rdoc +370 -0
  12. data/vendor/mail/Dependencies.txt +3 -0
  13. data/vendor/mail/Gemfile +17 -0
  14. data/vendor/mail/README.rdoc +572 -0
  15. data/vendor/mail/ROADMAP +92 -0
  16. data/vendor/mail/Rakefile +41 -0
  17. data/vendor/mail/TODO.rdoc +9 -0
  18. data/vendor/mail/lib/mail.rb +76 -0
  19. data/vendor/mail/lib/mail/attachments_list.rb +99 -0
  20. data/vendor/mail/lib/mail/body.rb +287 -0
  21. data/vendor/mail/lib/mail/configuration.rb +67 -0
  22. data/vendor/mail/lib/mail/core_extensions/blank.rb +26 -0
  23. data/vendor/mail/lib/mail/core_extensions/nil.rb +11 -0
  24. data/vendor/mail/lib/mail/core_extensions/string.rb +27 -0
  25. data/vendor/mail/lib/mail/elements.rb +14 -0
  26. data/vendor/mail/lib/mail/elements/address.rb +306 -0
  27. data/vendor/mail/lib/mail/elements/address_list.rb +74 -0
  28. data/vendor/mail/lib/mail/elements/content_disposition_element.rb +30 -0
  29. data/vendor/mail/lib/mail/elements/content_location_element.rb +25 -0
  30. data/vendor/mail/lib/mail/elements/content_transfer_encoding_element.rb +24 -0
  31. data/vendor/mail/lib/mail/elements/content_type_element.rb +35 -0
  32. data/vendor/mail/lib/mail/elements/date_time_element.rb +26 -0
  33. data/vendor/mail/lib/mail/elements/envelope_from_element.rb +34 -0
  34. data/vendor/mail/lib/mail/elements/message_ids_element.rb +29 -0
  35. data/vendor/mail/lib/mail/elements/mime_version_element.rb +26 -0
  36. data/vendor/mail/lib/mail/elements/phrase_list.rb +21 -0
  37. data/vendor/mail/lib/mail/elements/received_element.rb +30 -0
  38. data/vendor/mail/lib/mail/encodings.rb +258 -0
  39. data/vendor/mail/lib/mail/encodings/7bit.rb +31 -0
  40. data/vendor/mail/lib/mail/encodings/8bit.rb +31 -0
  41. data/vendor/mail/lib/mail/encodings/base64.rb +33 -0
  42. data/vendor/mail/lib/mail/encodings/binary.rb +31 -0
  43. data/vendor/mail/lib/mail/encodings/quoted_printable.rb +38 -0
  44. data/vendor/mail/lib/mail/encodings/transfer_encoding.rb +58 -0
  45. data/vendor/mail/lib/mail/envelope.rb +35 -0
  46. data/vendor/mail/lib/mail/field.rb +223 -0
  47. data/vendor/mail/lib/mail/field_list.rb +33 -0
  48. data/vendor/mail/lib/mail/fields.rb +35 -0
  49. data/vendor/mail/lib/mail/fields/bcc_field.rb +56 -0
  50. data/vendor/mail/lib/mail/fields/cc_field.rb +55 -0
  51. data/vendor/mail/lib/mail/fields/comments_field.rb +41 -0
  52. data/vendor/mail/lib/mail/fields/common/address_container.rb +16 -0
  53. data/vendor/mail/lib/mail/fields/common/common_address.rb +125 -0
  54. data/vendor/mail/lib/mail/fields/common/common_date.rb +42 -0
  55. data/vendor/mail/lib/mail/fields/common/common_field.rb +50 -0
  56. data/vendor/mail/lib/mail/fields/common/common_message_id.rb +43 -0
  57. data/vendor/mail/lib/mail/fields/common/parameter_hash.rb +52 -0
  58. data/vendor/mail/lib/mail/fields/content_description_field.rb +19 -0
  59. data/vendor/mail/lib/mail/fields/content_disposition_field.rb +69 -0
  60. data/vendor/mail/lib/mail/fields/content_id_field.rb +63 -0
  61. data/vendor/mail/lib/mail/fields/content_location_field.rb +42 -0
  62. data/vendor/mail/lib/mail/fields/content_transfer_encoding_field.rb +50 -0
  63. data/vendor/mail/lib/mail/fields/content_type_field.rb +185 -0
  64. data/vendor/mail/lib/mail/fields/date_field.rb +55 -0
  65. data/vendor/mail/lib/mail/fields/from_field.rb +55 -0
  66. data/vendor/mail/lib/mail/fields/in_reply_to_field.rb +55 -0
  67. data/vendor/mail/lib/mail/fields/keywords_field.rb +44 -0
  68. data/vendor/mail/lib/mail/fields/message_id_field.rb +83 -0
  69. data/vendor/mail/lib/mail/fields/mime_version_field.rb +53 -0
  70. data/vendor/mail/lib/mail/fields/optional_field.rb +13 -0
  71. data/vendor/mail/lib/mail/fields/received_field.rb +67 -0
  72. data/vendor/mail/lib/mail/fields/references_field.rb +55 -0
  73. data/vendor/mail/lib/mail/fields/reply_to_field.rb +55 -0
  74. data/vendor/mail/lib/mail/fields/resent_bcc_field.rb +55 -0
  75. data/vendor/mail/lib/mail/fields/resent_cc_field.rb +55 -0
  76. data/vendor/mail/lib/mail/fields/resent_date_field.rb +35 -0
  77. data/vendor/mail/lib/mail/fields/resent_from_field.rb +55 -0
  78. data/vendor/mail/lib/mail/fields/resent_message_id_field.rb +34 -0
  79. data/vendor/mail/lib/mail/fields/resent_sender_field.rb +62 -0
  80. data/vendor/mail/lib/mail/fields/resent_to_field.rb +55 -0
  81. data/vendor/mail/lib/mail/fields/return_path_field.rb +64 -0
  82. data/vendor/mail/lib/mail/fields/sender_field.rb +67 -0
  83. data/vendor/mail/lib/mail/fields/structured_field.rb +51 -0
  84. data/vendor/mail/lib/mail/fields/subject_field.rb +16 -0
  85. data/vendor/mail/lib/mail/fields/to_field.rb +55 -0
  86. data/vendor/mail/lib/mail/fields/unstructured_field.rb +166 -0
  87. data/vendor/mail/lib/mail/header.rb +262 -0
  88. data/vendor/mail/lib/mail/mail.rb +234 -0
  89. data/vendor/mail/lib/mail/message.rb +1867 -0
  90. data/vendor/mail/lib/mail/network.rb +9 -0
  91. data/vendor/mail/lib/mail/network/delivery_methods/file_delivery.rb +40 -0
  92. data/vendor/mail/lib/mail/network/delivery_methods/sendmail.rb +62 -0
  93. data/vendor/mail/lib/mail/network/delivery_methods/smtp.rb +110 -0
  94. data/vendor/mail/lib/mail/network/delivery_methods/test_mailer.rb +40 -0
  95. data/vendor/mail/lib/mail/network/retriever_methods/imap.rb +18 -0
  96. data/vendor/mail/lib/mail/network/retriever_methods/pop3.rb +149 -0
  97. data/vendor/mail/lib/mail/parsers/address_lists.rb +64 -0
  98. data/vendor/mail/lib/mail/parsers/address_lists.treetop +19 -0
  99. data/vendor/mail/lib/mail/parsers/content_disposition.rb +387 -0
  100. data/vendor/mail/lib/mail/parsers/content_disposition.treetop +46 -0
  101. data/vendor/mail/lib/mail/parsers/content_location.rb +139 -0
  102. data/vendor/mail/lib/mail/parsers/content_location.treetop +20 -0
  103. data/vendor/mail/lib/mail/parsers/content_transfer_encoding.rb +162 -0
  104. data/vendor/mail/lib/mail/parsers/content_transfer_encoding.treetop +20 -0
  105. data/vendor/mail/lib/mail/parsers/content_type.rb +539 -0
  106. data/vendor/mail/lib/mail/parsers/content_type.treetop +58 -0
  107. data/vendor/mail/lib/mail/parsers/date_time.rb +114 -0
  108. data/vendor/mail/lib/mail/parsers/date_time.treetop +11 -0
  109. data/vendor/mail/lib/mail/parsers/envelope_from.rb +194 -0
  110. data/vendor/mail/lib/mail/parsers/envelope_from.treetop +32 -0
  111. data/vendor/mail/lib/mail/parsers/message_ids.rb +45 -0
  112. data/vendor/mail/lib/mail/parsers/message_ids.treetop +15 -0
  113. data/vendor/mail/lib/mail/parsers/mime_version.rb +144 -0
  114. data/vendor/mail/lib/mail/parsers/mime_version.treetop +19 -0
  115. data/vendor/mail/lib/mail/parsers/phrase_lists.rb +45 -0
  116. data/vendor/mail/lib/mail/parsers/phrase_lists.treetop +15 -0
  117. data/vendor/mail/lib/mail/parsers/received.rb +71 -0
  118. data/vendor/mail/lib/mail/parsers/received.treetop +11 -0
  119. data/vendor/mail/lib/mail/parsers/rfc2045.rb +464 -0
  120. data/vendor/mail/lib/mail/parsers/rfc2045.treetop +36 -0
  121. data/vendor/mail/lib/mail/parsers/rfc2822.rb +5318 -0
  122. data/vendor/mail/lib/mail/parsers/rfc2822.treetop +410 -0
  123. data/vendor/mail/lib/mail/parsers/rfc2822_obsolete.rb +3757 -0
  124. data/vendor/mail/lib/mail/parsers/rfc2822_obsolete.treetop +241 -0
  125. data/vendor/mail/lib/mail/part.rb +102 -0
  126. data/vendor/mail/lib/mail/parts_list.rb +34 -0
  127. data/vendor/mail/lib/mail/patterns.rb +30 -0
  128. data/vendor/mail/lib/mail/utilities.rb +181 -0
  129. data/vendor/mail/lib/mail/version.rb +10 -0
  130. data/vendor/mail/lib/mail/version_specific/ruby_1_8.rb +97 -0
  131. data/vendor/mail/lib/mail/version_specific/ruby_1_9.rb +87 -0
  132. data/vendor/mail/lib/tasks/corpus.rake +125 -0
  133. data/vendor/mail/lib/tasks/treetop.rake +10 -0
  134. data/vendor/mail/mail.gemspec +20 -0
  135. data/vendor/mail/reference/US ASCII Table.txt +130 -0
  136. data/vendor/mail/reference/rfc1035 Domain Implementation and Specification.txt +3083 -0
  137. data/vendor/mail/reference/rfc1049 Content-Type Header Field for Internet Messages.txt +451 -0
  138. data/vendor/mail/reference/rfc1344 Implications of MIME for Internet Mail Gateways.txt +586 -0
  139. data/vendor/mail/reference/rfc1345 Character Mnemonics & Character Sets.txt +5761 -0
  140. data/vendor/mail/reference/rfc1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information.txt +675 -0
  141. data/vendor/mail/reference/rfc1652 SMTP Service Extension for 8bit-MIMEtransport.txt +339 -0
  142. data/vendor/mail/reference/rfc1892 Multipart Report .txt +227 -0
  143. data/vendor/mail/reference/rfc1893 Mail System Status Codes.txt +843 -0
  144. data/vendor/mail/reference/rfc2045 Multipurpose Internet Mail Extensions (1).txt +1739 -0
  145. data/vendor/mail/reference/rfc2046 Multipurpose Internet Mail Extensions (2).txt +2467 -0
  146. data/vendor/mail/reference/rfc2047 Multipurpose Internet Mail Extensions (3).txt +843 -0
  147. data/vendor/mail/reference/rfc2048 Multipurpose Internet Mail Extensions (4).txt +1180 -0
  148. data/vendor/mail/reference/rfc2049 Multipurpose Internet Mail Extensions (5).txt +1347 -0
  149. data/vendor/mail/reference/rfc2111 Content-ID and Message-ID URLs.txt +283 -0
  150. data/vendor/mail/reference/rfc2183 Content-Disposition Header Field.txt +675 -0
  151. data/vendor/mail/reference/rfc2231 MIME Parameter Value and Encoded Word Extensions.txt +563 -0
  152. data/vendor/mail/reference/rfc2387 MIME Multipart-Related Content-type.txt +563 -0
  153. data/vendor/mail/reference/rfc2821 Simple Mail Transfer Protocol.txt +3711 -0
  154. data/vendor/mail/reference/rfc2822 Internet Message Format.txt +2859 -0
  155. data/vendor/mail/reference/rfc3462 Reporting of Mail System Administrative Messages.txt +396 -0
  156. data/vendor/mail/reference/rfc3696 Checking and Transformation of Names.txt +898 -0
  157. data/vendor/mail/reference/rfc4155 The application-mbox Media Type.txt +502 -0
  158. data/vendor/mail/reference/rfc4234 Augmented BNF for Syntax Specifications: ABNF.txt +899 -0
  159. data/vendor/mail/reference/rfc822 Standard for the Format of ARPA Internet Text Messages.txt +2900 -0
  160. data/vendor/mail/spec/environment.rb +15 -0
  161. data/vendor/mail/spec/features/making_a_new_message.feature +14 -0
  162. data/vendor/mail/spec/features/steps/env.rb +6 -0
  163. data/vendor/mail/spec/features/steps/making_a_new_message_steps.rb +11 -0
  164. data/vendor/mail/spec/fixtures/attachments/basic_email.eml +31 -0
  165. data/vendor/mail/spec/fixtures/attachments/test.gif +0 -0
  166. data/vendor/mail/spec/fixtures/attachments/test.jpg +0 -0
  167. data/vendor/mail/spec/fixtures/attachments/test.pdf +0 -0
  168. data/vendor/mail/spec/fixtures/attachments/test.png +0 -0
  169. data/vendor/mail/spec/fixtures/attachments/test.tiff +0 -0
  170. data/vendor/mail/spec/fixtures/attachments/test.zip +0 -0
  171. data/vendor/mail/spec/fixtures/attachments//343/201/246/343/201/231/343/201/250.txt +2 -0
  172. data/vendor/mail/spec/fixtures/emails/attachment_emails/attachment_content_disposition.eml +29 -0
  173. data/vendor/mail/spec/fixtures/emails/attachment_emails/attachment_content_location.eml +32 -0
  174. data/vendor/mail/spec/fixtures/emails/attachment_emails/attachment_message_rfc822.eml +92 -0
  175. data/vendor/mail/spec/fixtures/emails/attachment_emails/attachment_only_email.eml +17 -0
  176. data/vendor/mail/spec/fixtures/emails/attachment_emails/attachment_pdf.eml +70 -0
  177. data/vendor/mail/spec/fixtures/emails/attachment_emails/attachment_with_encoded_name.eml +47 -0
  178. data/vendor/mail/spec/fixtures/emails/attachment_emails/attachment_with_quoted_filename.eml +60 -0
  179. data/vendor/mail/spec/fixtures/emails/error_emails/cant_parse_from.eml +33 -0
  180. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_7-bit.eml +231 -0
  181. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_empty.eml +33 -0
  182. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_plain.eml +148 -0
  183. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_qp_with_space.eml +53 -0
  184. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_spam.eml +44 -0
  185. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_text-html.eml +50 -0
  186. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_with_8bits.eml +770 -0
  187. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_with_semi_colon.eml +269 -0
  188. data/vendor/mail/spec/fixtures/emails/error_emails/content_transfer_encoding_x_uuencode.eml +79 -0
  189. data/vendor/mail/spec/fixtures/emails/error_emails/empty_group_lists.eml +162 -0
  190. data/vendor/mail/spec/fixtures/emails/error_emails/header_fields_with_empty_values.eml +33 -0
  191. data/vendor/mail/spec/fixtures/emails/error_emails/missing_body.eml +16 -0
  192. data/vendor/mail/spec/fixtures/emails/error_emails/missing_content_disposition.eml +43 -0
  193. data/vendor/mail/spec/fixtures/emails/error_emails/multiple_content_types.eml +25 -0
  194. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email11.eml +34 -0
  195. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email12.eml +32 -0
  196. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email2.eml +114 -0
  197. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email4.eml +59 -0
  198. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email7.eml +66 -0
  199. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email_encoded_stack_level_too_deep.eml +53 -0
  200. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email_with_illegal_boundary.eml +58 -0
  201. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email_with_mimepart_without_content_type.eml +94 -0
  202. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email_with_multipart_mixed_quoted_boundary.eml +50 -0
  203. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email_with_nested_attachment.eml +100 -0
  204. data/vendor/mail/spec/fixtures/emails/mime_emails/raw_email_with_quoted_illegal_boundary.eml +58 -0
  205. data/vendor/mail/spec/fixtures/emails/mime_emails/sig_only_email.eml +29 -0
  206. data/vendor/mail/spec/fixtures/emails/mime_emails/two_from_in_message.eml +42 -0
  207. data/vendor/mail/spec/fixtures/emails/multi_charset/japanese.eml +9 -0
  208. data/vendor/mail/spec/fixtures/emails/multi_charset/japanese_attachment.eml +27 -0
  209. data/vendor/mail/spec/fixtures/emails/multi_charset/japanese_attachment_long_name.eml +44 -0
  210. data/vendor/mail/spec/fixtures/emails/multipart_report_emails/multi_address_bounce1.eml +179 -0
  211. data/vendor/mail/spec/fixtures/emails/multipart_report_emails/multi_address_bounce2.eml +179 -0
  212. data/vendor/mail/spec/fixtures/emails/multipart_report_emails/report_422.eml +98 -0
  213. data/vendor/mail/spec/fixtures/emails/multipart_report_emails/report_530.eml +97 -0
  214. data/vendor/mail/spec/fixtures/emails/plain_emails/basic_email.eml +31 -0
  215. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email.eml +14 -0
  216. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email10.eml +20 -0
  217. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email5.eml +19 -0
  218. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email6.eml +20 -0
  219. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email8.eml +47 -0
  220. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_bad_time.eml +62 -0
  221. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_double_at_in_header.eml +14 -0
  222. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_incorrect_header.eml +28 -0
  223. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_multiple_from.eml +30 -0
  224. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_quoted_with_0d0a.eml +14 -0
  225. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_reply.eml +32 -0
  226. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_simple.eml +11 -0
  227. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_string_in_date_field.eml +17 -0
  228. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_trailing_dot.eml +21 -0
  229. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_with_bad_date.eml +48 -0
  230. data/vendor/mail/spec/fixtures/emails/plain_emails/raw_email_with_partially_quoted_subject.eml +14 -0
  231. data/vendor/mail/spec/fixtures/emails/rfc2822/example01.eml +8 -0
  232. data/vendor/mail/spec/fixtures/emails/rfc2822/example02.eml +9 -0
  233. data/vendor/mail/spec/fixtures/emails/rfc2822/example03.eml +7 -0
  234. data/vendor/mail/spec/fixtures/emails/rfc2822/example04.eml +7 -0
  235. data/vendor/mail/spec/fixtures/emails/rfc2822/example05.eml +8 -0
  236. data/vendor/mail/spec/fixtures/emails/rfc2822/example06.eml +10 -0
  237. data/vendor/mail/spec/fixtures/emails/rfc2822/example07.eml +9 -0
  238. data/vendor/mail/spec/fixtures/emails/rfc2822/example08.eml +12 -0
  239. data/vendor/mail/spec/fixtures/emails/rfc2822/example09.eml +15 -0
  240. data/vendor/mail/spec/fixtures/emails/rfc2822/example10.eml +15 -0
  241. data/vendor/mail/spec/fixtures/emails/rfc2822/example11.eml +6 -0
  242. data/vendor/mail/spec/fixtures/emails/rfc2822/example12.eml +8 -0
  243. data/vendor/mail/spec/fixtures/emails/rfc2822/example13.eml +10 -0
  244. data/vendor/mail/spec/fixtures/emails/sample_output_multipart +0 -0
  245. data/vendor/mail/spec/mail/attachments_list_spec.rb +214 -0
  246. data/vendor/mail/spec/mail/body_spec.rb +385 -0
  247. data/vendor/mail/spec/mail/configuration_spec.rb +19 -0
  248. data/vendor/mail/spec/mail/core_extensions/string_spec.rb +62 -0
  249. data/vendor/mail/spec/mail/core_extensions_spec.rb +99 -0
  250. data/vendor/mail/spec/mail/elements/address_list_spec.rb +109 -0
  251. data/vendor/mail/spec/mail/elements/address_spec.rb +609 -0
  252. data/vendor/mail/spec/mail/elements/date_time_element_spec.rb +20 -0
  253. data/vendor/mail/spec/mail/elements/envelope_from_element_spec.rb +31 -0
  254. data/vendor/mail/spec/mail/elements/message_ids_element_spec.rb +43 -0
  255. data/vendor/mail/spec/mail/elements/phrase_list_spec.rb +22 -0
  256. data/vendor/mail/spec/mail/elements/received_element_spec.rb +34 -0
  257. data/vendor/mail/spec/mail/encoding_spec.rb +189 -0
  258. data/vendor/mail/spec/mail/encodings/base64_spec.rb +25 -0
  259. data/vendor/mail/spec/mail/encodings/quoted_printable_spec.rb +25 -0
  260. data/vendor/mail/spec/mail/encodings_spec.rb +664 -0
  261. data/vendor/mail/spec/mail/example_emails_spec.rb +303 -0
  262. data/vendor/mail/spec/mail/field_list_spec.rb +33 -0
  263. data/vendor/mail/spec/mail/field_spec.rb +198 -0
  264. data/vendor/mail/spec/mail/fields/bcc_field_spec.rb +89 -0
  265. data/vendor/mail/spec/mail/fields/cc_field_spec.rb +79 -0
  266. data/vendor/mail/spec/mail/fields/comments_field_spec.rb +25 -0
  267. data/vendor/mail/spec/mail/fields/common/address_container_spec.rb +18 -0
  268. data/vendor/mail/spec/mail/fields/common/common_address_spec.rb +132 -0
  269. data/vendor/mail/spec/mail/fields/common/common_date_spec.rb +25 -0
  270. data/vendor/mail/spec/mail/fields/common/common_field_spec.rb +69 -0
  271. data/vendor/mail/spec/mail/fields/common/common_message_id_spec.rb +30 -0
  272. data/vendor/mail/spec/mail/fields/common/parameter_hash_spec.rb +56 -0
  273. data/vendor/mail/spec/mail/fields/content_description_field_spec.rb +39 -0
  274. data/vendor/mail/spec/mail/fields/content_disposition_field_spec.rb +55 -0
  275. data/vendor/mail/spec/mail/fields/content_id_field_spec.rb +117 -0
  276. data/vendor/mail/spec/mail/fields/content_location_field_spec.rb +46 -0
  277. data/vendor/mail/spec/mail/fields/content_transfer_encoding_field_spec.rb +113 -0
  278. data/vendor/mail/spec/mail/fields/content_type_field_spec.rb +678 -0
  279. data/vendor/mail/spec/mail/fields/date_field_spec.rb +73 -0
  280. data/vendor/mail/spec/mail/fields/envelope_spec.rb +48 -0
  281. data/vendor/mail/spec/mail/fields/from_field_spec.rb +89 -0
  282. data/vendor/mail/spec/mail/fields/in_reply_to_field_spec.rb +62 -0
  283. data/vendor/mail/spec/mail/fields/keywords_field_spec.rb +66 -0
  284. data/vendor/mail/spec/mail/fields/message_id_field_spec.rb +147 -0
  285. data/vendor/mail/spec/mail/fields/mime_version_field_spec.rb +166 -0
  286. data/vendor/mail/spec/mail/fields/received_field_spec.rb +44 -0
  287. data/vendor/mail/spec/mail/fields/references_field_spec.rb +35 -0
  288. data/vendor/mail/spec/mail/fields/reply_to_field_spec.rb +67 -0
  289. data/vendor/mail/spec/mail/fields/resent_bcc_field_spec.rb +66 -0
  290. data/vendor/mail/spec/mail/fields/resent_cc_field_spec.rb +66 -0
  291. data/vendor/mail/spec/mail/fields/resent_date_field_spec.rb +39 -0
  292. data/vendor/mail/spec/mail/fields/resent_from_field_spec.rb +66 -0
  293. data/vendor/mail/spec/mail/fields/resent_message_id_field_spec.rb +24 -0
  294. data/vendor/mail/spec/mail/fields/resent_sender_field_spec.rb +58 -0
  295. data/vendor/mail/spec/mail/fields/resent_to_field_spec.rb +66 -0
  296. data/vendor/mail/spec/mail/fields/return_path_field_spec.rb +52 -0
  297. data/vendor/mail/spec/mail/fields/sender_field_spec.rb +58 -0
  298. data/vendor/mail/spec/mail/fields/structured_field_spec.rb +72 -0
  299. data/vendor/mail/spec/mail/fields/to_field_spec.rb +92 -0
  300. data/vendor/mail/spec/mail/fields/unstructured_field_spec.rb +134 -0
  301. data/vendor/mail/spec/mail/header_spec.rb +578 -0
  302. data/vendor/mail/spec/mail/mail_spec.rb +34 -0
  303. data/vendor/mail/spec/mail/message_spec.rb +1409 -0
  304. data/vendor/mail/spec/mail/mime_messages_spec.rb +435 -0
  305. data/vendor/mail/spec/mail/multipart_report_spec.rb +112 -0
  306. data/vendor/mail/spec/mail/network/delivery_methods/file_delivery_spec.rb +79 -0
  307. data/vendor/mail/spec/mail/network/delivery_methods/sendmail_spec.rb +125 -0
  308. data/vendor/mail/spec/mail/network/delivery_methods/smtp_spec.rb +133 -0
  309. data/vendor/mail/spec/mail/network/delivery_methods/test_mailer_spec.rb +57 -0
  310. data/vendor/mail/spec/mail/network/retriever_methods/pop3_spec.rb +180 -0
  311. data/vendor/mail/spec/mail/network_spec.rb +359 -0
  312. data/vendor/mail/spec/mail/parsers/address_lists_parser_spec.rb +15 -0
  313. data/vendor/mail/spec/mail/parsers/content_transfer_encoding_parser_spec.rb +72 -0
  314. data/vendor/mail/spec/mail/part_spec.rb +129 -0
  315. data/vendor/mail/spec/mail/parts_list_spec.rb +12 -0
  316. data/vendor/mail/spec/mail/round_tripping_spec.rb +44 -0
  317. data/vendor/mail/spec/mail/utilities_spec.rb +327 -0
  318. data/vendor/mail/spec/mail/version_specific/escape_paren_1_8_spec.rb +32 -0
  319. data/vendor/mail/spec/matchers/break_down_to.rb +35 -0
  320. data/vendor/mail/spec/spec_helper.rb +163 -0
  321. metadata +442 -0
@@ -0,0 +1,2859 @@
1
+
2
+
3
+
4
+
5
+
6
+
7
+ Network Working Group P. Resnick, Editor
8
+ Request for Comments: 2822 QUALCOMM Incorporated
9
+ Obsoletes: 822 April 2001
10
+ Category: Standards Track
11
+
12
+
13
+ Internet Message Format
14
+
15
+ Status of this Memo
16
+
17
+ This document specifies an Internet standards track protocol for the
18
+ Internet community, and requests discussion and suggestions for
19
+ improvements. Please refer to the current edition of the "Internet
20
+ Official Protocol Standards" (STD 1) for the standardization state
21
+ and status of this protocol. Distribution of this memo is unlimited.
22
+
23
+ Copyright Notice
24
+
25
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
26
+
27
+ Abstract
28
+
29
+ This standard specifies a syntax for text messages that are sent
30
+ between computer users, within the framework of "electronic mail"
31
+ messages. This standard supersedes the one specified in Request For
32
+ Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
33
+ Messages", updating it to reflect current practice and incorporating
34
+ incremental changes that were specified in other RFCs.
35
+
36
+ Table of Contents
37
+
38
+ 1. Introduction ............................................... 3
39
+ 1.1. Scope .................................................... 3
40
+ 1.2. Notational conventions ................................... 4
41
+ 1.2.1. Requirements notation .................................. 4
42
+ 1.2.2. Syntactic notation ..................................... 4
43
+ 1.3. Structure of this document ............................... 4
44
+ 2. Lexical Analysis of Messages ............................... 5
45
+ 2.1. General Description ...................................... 5
46
+ 2.1.1. Line Length Limits ..................................... 6
47
+ 2.2. Header Fields ............................................ 7
48
+ 2.2.1. Unstructured Header Field Bodies ....................... 7
49
+ 2.2.2. Structured Header Field Bodies ......................... 7
50
+ 2.2.3. Long Header Fields ..................................... 7
51
+ 2.3. Body ..................................................... 8
52
+ 3. Syntax ..................................................... 9
53
+ 3.1. Introduction ............................................. 9
54
+ 3.2. Lexical Tokens ........................................... 9
55
+
56
+
57
+
58
+ Resnick Standards Track [Page 1]
59
+
60
+ RFC 2822 Internet Message Format April 2001
61
+
62
+
63
+ 3.2.1. Primitive Tokens ....................................... 9
64
+ 3.2.2. Quoted characters ......................................10
65
+ 3.2.3. Folding white space and comments .......................11
66
+ 3.2.4. Atom ...................................................12
67
+ 3.2.5. Quoted strings .........................................13
68
+ 3.2.6. Miscellaneous tokens ...................................13
69
+ 3.3. Date and Time Specification ..............................14
70
+ 3.4. Address Specification ....................................15
71
+ 3.4.1. Addr-spec specification ................................16
72
+ 3.5 Overall message syntax ....................................17
73
+ 3.6. Field definitions ........................................18
74
+ 3.6.1. The origination date field .............................20
75
+ 3.6.2. Originator fields ......................................21
76
+ 3.6.3. Destination address fields .............................22
77
+ 3.6.4. Identification fields ..................................23
78
+ 3.6.5. Informational fields ...................................26
79
+ 3.6.6. Resent fields ..........................................26
80
+ 3.6.7. Trace fields ...........................................28
81
+ 3.6.8. Optional fields ........................................29
82
+ 4. Obsolete Syntax ............................................29
83
+ 4.1. Miscellaneous obsolete tokens ............................30
84
+ 4.2. Obsolete folding white space .............................31
85
+ 4.3. Obsolete Date and Time ...................................31
86
+ 4.4. Obsolete Addressing ......................................33
87
+ 4.5. Obsolete header fields ...................................33
88
+ 4.5.1. Obsolete origination date field ........................34
89
+ 4.5.2. Obsolete originator fields .............................34
90
+ 4.5.3. Obsolete destination address fields ....................34
91
+ 4.5.4. Obsolete identification fields .........................35
92
+ 4.5.5. Obsolete informational fields ..........................35
93
+ 4.5.6. Obsolete resent fields .................................35
94
+ 4.5.7. Obsolete trace fields ..................................36
95
+ 4.5.8. Obsolete optional fields ...............................36
96
+ 5. Security Considerations ....................................36
97
+ 6. Bibliography ...............................................37
98
+ 7. Editor's Address ...........................................38
99
+ 8. Acknowledgements ...........................................39
100
+ Appendix A. Example messages ..................................41
101
+ A.1. Addressing examples ......................................41
102
+ A.1.1. A message from one person to another with simple
103
+ addressing .............................................41
104
+ A.1.2. Different types of mailboxes ...........................42
105
+ A.1.3. Group addresses ........................................43
106
+ A.2. Reply messages ...........................................43
107
+ A.3. Resent messages ..........................................44
108
+ A.4. Messages with trace fields ...............................46
109
+ A.5. White space, comments, and other oddities ................47
110
+ A.6. Obsoleted forms ..........................................47
111
+
112
+
113
+
114
+ Resnick Standards Track [Page 2]
115
+
116
+ RFC 2822 Internet Message Format April 2001
117
+
118
+
119
+ A.6.1. Obsolete addressing ....................................48
120
+ A.6.2. Obsolete dates .........................................48
121
+ A.6.3. Obsolete white space and comments ......................48
122
+ Appendix B. Differences from earlier standards ................49
123
+ Appendix C. Notices ...........................................50
124
+ Full Copyright Statement ......................................51
125
+
126
+ 1. Introduction
127
+
128
+ 1.1. Scope
129
+
130
+ This standard specifies a syntax for text messages that are sent
131
+ between computer users, within the framework of "electronic mail"
132
+ messages. This standard supersedes the one specified in Request For
133
+ Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
134
+ Messages" [RFC822], updating it to reflect current practice and
135
+ incorporating incremental changes that were specified in other RFCs
136
+ [STD3].
137
+
138
+ This standard specifies a syntax only for text messages. In
139
+ particular, it makes no provision for the transmission of images,
140
+ audio, or other sorts of structured data in electronic mail messages.
141
+ There are several extensions published, such as the MIME document
142
+ series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the
143
+ transmission of such data through electronic mail, either by
144
+ extending the syntax provided here or by structuring such messages to
145
+ conform to this syntax. Those mechanisms are outside of the scope of
146
+ this standard.
147
+
148
+ In the context of electronic mail, messages are viewed as having an
149
+ envelope and contents. The envelope contains whatever information is
150
+ needed to accomplish transmission and delivery. (See [RFC2821] for a
151
+ discussion of the envelope.) The contents comprise the object to be
152
+ delivered to the recipient. This standard applies only to the format
153
+ and some of the semantics of message contents. It contains no
154
+ specification of the information in the envelope.
155
+
156
+ However, some message systems may use information from the contents
157
+ to create the envelope. It is intended that this standard facilitate
158
+ the acquisition of such information by programs.
159
+
160
+ This specification is intended as a definition of what message
161
+ content format is to be passed between systems. Though some message
162
+ systems locally store messages in this format (which eliminates the
163
+ need for translation between formats) and others use formats that
164
+ differ from the one specified in this standard, local storage is
165
+ outside of the scope of this standard.
166
+
167
+
168
+
169
+
170
+ Resnick Standards Track [Page 3]
171
+
172
+ RFC 2822 Internet Message Format April 2001
173
+
174
+
175
+ Note: This standard is not intended to dictate the internal formats
176
+ used by sites, the specific message system features that they are
177
+ expected to support, or any of the characteristics of user interface
178
+ programs that create or read messages. In addition, this standard
179
+ does not specify an encoding of the characters for either transport
180
+ or storage; that is, it does not specify the number of bits used or
181
+ how those bits are specifically transferred over the wire or stored
182
+ on disk.
183
+
184
+ 1.2. Notational conventions
185
+
186
+ 1.2.1. Requirements notation
187
+
188
+ This document occasionally uses terms that appear in capital letters.
189
+ When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
190
+ NOT", and "MAY" appear capitalized, they are being used to indicate
191
+ particular requirements of this specification. A discussion of the
192
+ meanings of these terms appears in [RFC2119].
193
+
194
+ 1.2.2. Syntactic notation
195
+
196
+ This standard uses the Augmented Backus-Naur Form (ABNF) notation
197
+ specified in [RFC2234] for the formal definitions of the syntax of
198
+ messages. Characters will be specified either by a decimal value
199
+ (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
200
+ a case-insensitive literal value enclosed in quotation marks (e.g.,
201
+ "A" for either uppercase or lowercase A). See [RFC2234] for the full
202
+ description of the notation.
203
+
204
+ 1.3. Structure of this document
205
+
206
+ This document is divided into several sections.
207
+
208
+ This section, section 1, is a short introduction to the document.
209
+
210
+ Section 2 lays out the general description of a message and its
211
+ constituent parts. This is an overview to help the reader understand
212
+ some of the general principles used in the later portions of this
213
+ document. Any examples in this section MUST NOT be taken as
214
+ specification of the formal syntax of any part of a message.
215
+
216
+ Section 3 specifies formal ABNF rules for the structure of each part
217
+ of a message (the syntax) and describes the relationship between
218
+ those parts and their meaning in the context of a message (the
219
+ semantics). That is, it describes the actual rules for the structure
220
+ of each part of a message (the syntax) as well as a description of
221
+ the parts and instructions on how they ought to be interpreted (the
222
+ semantics). This includes analysis of the syntax and semantics of
223
+
224
+
225
+
226
+ Resnick Standards Track [Page 4]
227
+
228
+ RFC 2822 Internet Message Format April 2001
229
+
230
+
231
+ subparts of messages that have specific structure. The syntax
232
+ included in section 3 represents messages as they MUST be created.
233
+ There are also notes in section 3 to indicate if any of the options
234
+ specified in the syntax SHOULD be used over any of the others.
235
+
236
+ Both sections 2 and 3 describe messages that are legal to generate
237
+ for purposes of this standard.
238
+
239
+ Section 4 of this document specifies an "obsolete" syntax. There are
240
+ references in section 3 to these obsolete syntactic elements. The
241
+ rules of the obsolete syntax are elements that have appeared in
242
+ earlier revisions of this standard or have previously been widely
243
+ used in Internet messages. As such, these elements MUST be
244
+ interpreted by parsers of messages in order to be conformant to this
245
+ standard. However, since items in this syntax have been determined
246
+ to be non-interoperable or to cause significant problems for
247
+ recipients of messages, they MUST NOT be generated by creators of
248
+ conformant messages.
249
+
250
+ Section 5 details security considerations to take into account when
251
+ implementing this standard.
252
+
253
+ Section 6 is a bibliography of references in this document.
254
+
255
+ Section 7 contains the editor's address.
256
+
257
+ Section 8 contains acknowledgements.
258
+
259
+ Appendix A lists examples of different sorts of messages. These
260
+ examples are not exhaustive of the types of messages that appear on
261
+ the Internet, but give a broad overview of certain syntactic forms.
262
+
263
+ Appendix B lists the differences between this standard and earlier
264
+ standards for Internet messages.
265
+
266
+ Appendix C has copyright and intellectual property notices.
267
+
268
+ 2. Lexical Analysis of Messages
269
+
270
+ 2.1. General Description
271
+
272
+ At the most basic level, a message is a series of characters. A
273
+ message that is conformant with this standard is comprised of
274
+ characters with values in the range 1 through 127 and interpreted as
275
+ US-ASCII characters [ASCII]. For brevity, this document sometimes
276
+ refers to this range of characters as simply "US-ASCII characters".
277
+
278
+
279
+
280
+
281
+
282
+ Resnick Standards Track [Page 5]
283
+
284
+ RFC 2822 Internet Message Format April 2001
285
+
286
+
287
+ Note: This standard specifies that messages are made up of characters
288
+ in the US-ASCII range of 1 through 127. There are other documents,
289
+ specifically the MIME document series [RFC2045, RFC2046, RFC2047,
290
+ RFC2048, RFC2049], that extend this standard to allow for values
291
+ outside of that range. Discussion of those mechanisms is not within
292
+ the scope of this standard.
293
+
294
+ Messages are divided into lines of characters. A line is a series of
295
+ characters that is delimited with the two characters carriage-return
296
+ and line-feed; that is, the carriage return (CR) character (ASCII
297
+ value 13) followed immediately by the line feed (LF) character (ASCII
298
+ value 10). (The carriage-return/line-feed pair is usually written in
299
+ this document as "CRLF".)
300
+
301
+ A message consists of header fields (collectively called "the header
302
+ of the message") followed, optionally, by a body. The header is a
303
+ sequence of lines of characters with special syntax as defined in
304
+ this standard. The body is simply a sequence of characters that
305
+ follows the header and is separated from the header by an empty line
306
+ (i.e., a line with nothing preceding the CRLF).
307
+
308
+ 2.1.1. Line Length Limits
309
+
310
+ There are two limits that this standard places on the number of
311
+ characters in a line. Each line of characters MUST be no more than
312
+ 998 characters, and SHOULD be no more than 78 characters, excluding
313
+ the CRLF.
314
+
315
+ The 998 character limit is due to limitations in many implementations
316
+ which send, receive, or store Internet Message Format messages that
317
+ simply cannot handle more than 998 characters on a line. Receiving
318
+ implementations would do well to handle an arbitrarily large number
319
+ of characters in a line for robustness sake. However, there are so
320
+ many implementations which (in compliance with the transport
321
+ requirements of [RFC2821]) do not accept messages containing more
322
+ than 1000 character including the CR and LF per line, it is important
323
+ for implementations not to create such messages.
324
+
325
+ The more conservative 78 character recommendation is to accommodate
326
+ the many implementations of user interfaces that display these
327
+ messages which may truncate, or disastrously wrap, the display of
328
+ more than 78 characters per line, in spite of the fact that such
329
+ implementations are non-conformant to the intent of this
330
+ specification (and that of [RFC2821] if they actually cause
331
+ information to be lost). Again, even though this limitation is put on
332
+ messages, it is encumbant upon implementations which display messages
333
+
334
+
335
+
336
+
337
+
338
+ Resnick Standards Track [Page 6]
339
+
340
+ RFC 2822 Internet Message Format April 2001
341
+
342
+
343
+ to handle an arbitrarily large number of characters in a line
344
+ (certainly at least up to the 998 character limit) for the sake of
345
+ robustness.
346
+
347
+ 2.2. Header Fields
348
+
349
+ Header fields are lines composed of a field name, followed by a colon
350
+ (":"), followed by a field body, and terminated by CRLF. A field
351
+ name MUST be composed of printable US-ASCII characters (i.e.,
352
+ characters that have values between 33 and 126, inclusive), except
353
+ colon. A field body may be composed of any US-ASCII characters,
354
+ except for CR and LF. However, a field body may contain CRLF when
355
+ used in header "folding" and "unfolding" as described in section
356
+ 2.2.3. All field bodies MUST conform to the syntax described in
357
+ sections 3 and 4 of this standard.
358
+
359
+ 2.2.1. Unstructured Header Field Bodies
360
+
361
+ Some field bodies in this standard are defined simply as
362
+ "unstructured" (which is specified below as any US-ASCII characters,
363
+ except for CR and LF) with no further restrictions. These are
364
+ referred to as unstructured field bodies. Semantically, unstructured
365
+ field bodies are simply to be treated as a single line of characters
366
+ with no further processing (except for header "folding" and
367
+ "unfolding" as described in section 2.2.3).
368
+
369
+ 2.2.2. Structured Header Field Bodies
370
+
371
+ Some field bodies in this standard have specific syntactical
372
+ structure more restrictive than the unstructured field bodies
373
+ described above. These are referred to as "structured" field bodies.
374
+ Structured field bodies are sequences of specific lexical tokens as
375
+ described in sections 3 and 4 of this standard. Many of these tokens
376
+ are allowed (according to their syntax) to be introduced or end with
377
+ comments (as described in section 3.2.3) as well as the space (SP,
378
+ ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters
379
+ (together known as the white space characters, WSP), and those WSP
380
+ characters are subject to header "folding" and "unfolding" as
381
+ described in section 2.2.3. Semantic analysis of structured field
382
+ bodies is given along with their syntax.
383
+
384
+ 2.2.3. Long Header Fields
385
+
386
+ Each header field is logically a single line of characters comprising
387
+ the field name, the colon, and the field body. For convenience
388
+ however, and to deal with the 998/78 character limitations per line,
389
+ the field body portion of a header field can be split into a multiple
390
+ line representation; this is called "folding". The general rule is
391
+
392
+
393
+
394
+ Resnick Standards Track [Page 7]
395
+
396
+ RFC 2822 Internet Message Format April 2001
397
+
398
+
399
+ that wherever this standard allows for folding white space (not
400
+ simply WSP characters), a CRLF may be inserted before any WSP. For
401
+ example, the header field:
402
+
403
+ Subject: This is a test
404
+
405
+ can be represented as:
406
+
407
+ Subject: This
408
+ is a test
409
+
410
+ Note: Though structured field bodies are defined in such a way that
411
+ folding can take place between many of the lexical tokens (and even
412
+ within some of the lexical tokens), folding SHOULD be limited to
413
+ placing the CRLF at higher-level syntactic breaks. For instance, if
414
+ a field body is defined as comma-separated values, it is recommended
415
+ that folding occur after the comma separating the structured items in
416
+ preference to other places where the field could be folded, even if
417
+ it is allowed elsewhere.
418
+
419
+ The process of moving from this folded multiple-line representation
420
+ of a header field to its single line representation is called
421
+ "unfolding". Unfolding is accomplished by simply removing any CRLF
422
+ that is immediately followed by WSP. Each header field should be
423
+ treated in its unfolded form for further syntactic and semantic
424
+ evaluation.
425
+
426
+ 2.3. Body
427
+
428
+ The body of a message is simply lines of US-ASCII characters. The
429
+ only two limitations on the body are as follows:
430
+
431
+ - CR and LF MUST only occur together as CRLF; they MUST NOT appear
432
+ independently in the body.
433
+
434
+ - Lines of characters in the body MUST be limited to 998 characters,
435
+ and SHOULD be limited to 78 characters, excluding the CRLF.
436
+
437
+ Note: As was stated earlier, there are other standards documents,
438
+ specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049]
439
+ that extend this standard to allow for different sorts of message
440
+ bodies. Again, these mechanisms are beyond the scope of this
441
+ document.
442
+
443
+
444
+
445
+
446
+
447
+
448
+
449
+
450
+ Resnick Standards Track [Page 8]
451
+
452
+ RFC 2822 Internet Message Format April 2001
453
+
454
+
455
+ 3. Syntax
456
+
457
+ 3.1. Introduction
458
+
459
+ The syntax as given in this section defines the legal syntax of
460
+ Internet messages. Messages that are conformant to this standard
461
+ MUST conform to the syntax in this section. If there are options in
462
+ this section where one option SHOULD be generated, that is indicated
463
+ either in the prose or in a comment next to the syntax.
464
+
465
+ For the defined expressions, a short description of the syntax and
466
+ use is given, followed by the syntax in ABNF, followed by a semantic
467
+ analysis. Primitive tokens that are used but otherwise unspecified
468
+ come from [RFC2234].
469
+
470
+ In some of the definitions, there will be nonterminals whose names
471
+ start with "obs-". These "obs-" elements refer to tokens defined in
472
+ the obsolete syntax in section 4. In all cases, these productions
473
+ are to be ignored for the purposes of generating legal Internet
474
+ messages and MUST NOT be used as part of such a message. However,
475
+ when interpreting messages, these tokens MUST be honored as part of
476
+ the legal syntax. In this sense, section 3 defines a grammar for
477
+ generation of messages, with "obs-" elements that are to be ignored,
478
+ while section 4 adds grammar for interpretation of messages.
479
+
480
+ 3.2. Lexical Tokens
481
+
482
+ The following rules are used to define an underlying lexical
483
+ analyzer, which feeds tokens to the higher-level parsers. This
484
+ section defines the tokens used in structured header field bodies.
485
+
486
+ Note: Readers of this standard need to pay special attention to how
487
+ these lexical tokens are used in both the lower-level and
488
+ higher-level syntax later in the document. Particularly, the white
489
+ space tokens and the comment tokens defined in section 3.2.3 get used
490
+ in the lower-level tokens defined here, and those lower-level tokens
491
+ are in turn used as parts of the higher-level tokens defined later.
492
+ Therefore, the white space and comments may be allowed in the
493
+ higher-level tokens even though they may not explicitly appear in a
494
+ particular definition.
495
+
496
+ 3.2.1. Primitive Tokens
497
+
498
+ The following are primitive tokens referred to elsewhere in this
499
+ standard, but not otherwise defined in [RFC2234]. Some of them will
500
+ not appear anywhere else in the syntax, but they are convenient to
501
+ refer to in other parts of this document.
502
+
503
+
504
+
505
+
506
+ Resnick Standards Track [Page 9]
507
+
508
+ RFC 2822 Internet Message Format April 2001
509
+
510
+
511
+ Note: The "specials" below are just such an example. Though the
512
+ specials token does not appear anywhere else in this standard, it is
513
+ useful for implementers who use tools that lexically analyze
514
+ messages. Each of the characters in specials can be used to indicate
515
+ a tokenization point in lexical analysis.
516
+
517
+ NO-WS-CTL = %d1-8 / ; US-ASCII control characters
518
+ %d11 / ; that do not include the
519
+ %d12 / ; carriage return, line feed,
520
+ %d14-31 / ; and white space characters
521
+ %d127
522
+
523
+ text = %d1-9 / ; Characters excluding CR and LF
524
+ %d11 /
525
+ %d12 /
526
+ %d14-127 /
527
+ obs-text
528
+
529
+ specials = "(" / ")" / ; Special characters used in
530
+ "<" / ">" / ; other parts of the syntax
531
+ "[" / "]" /
532
+ ":" / ";" /
533
+ "@" / "\" /
534
+ "," / "." /
535
+ DQUOTE
536
+
537
+ No special semantics are attached to these tokens. They are simply
538
+ single characters.
539
+
540
+ 3.2.2. Quoted characters
541
+
542
+ Some characters are reserved for special interpretation, such as
543
+ delimiting lexical tokens. To permit use of these characters as
544
+ uninterpreted data, a quoting mechanism is provided.
545
+
546
+ quoted-pair = ("\" text) / obs-qp
547
+
548
+ Where any quoted-pair appears, it is to be interpreted as the text
549
+ character alone. That is to say, the "\" character that appears as
550
+ part of a quoted-pair is semantically "invisible".
551
+
552
+ Note: The "\" character may appear in a message where it is not part
553
+ of a quoted-pair. A "\" character that does not appear in a
554
+ quoted-pair is not semantically invisible. The only places in this
555
+ standard where quoted-pair currently appears are ccontent, qcontent,
556
+ dcontent, no-fold-quote, and no-fold-literal.
557
+
558
+
559
+
560
+
561
+
562
+ Resnick Standards Track [Page 10]
563
+
564
+ RFC 2822 Internet Message Format April 2001
565
+
566
+
567
+ 3.2.3. Folding white space and comments
568
+
569
+ White space characters, including white space used in folding
570
+ (described in section 2.2.3), may appear between many elements in
571
+ header field bodies. Also, strings of characters that are treated as
572
+ comments may be included in structured field bodies as characters
573
+ enclosed in parentheses. The following defines the folding white
574
+ space (FWS) and comment constructs.
575
+
576
+ Strings of characters enclosed in parentheses are considered comments
577
+ so long as they do not appear within a "quoted-string", as defined in
578
+ section 3.2.5. Comments may nest.
579
+
580
+ There are several places in this standard where comments and FWS may
581
+ be freely inserted. To accommodate that syntax, an additional token
582
+ for "CFWS" is defined for places where comments and/or FWS can occur.
583
+ However, where CFWS occurs in this standard, it MUST NOT be inserted
584
+ in such a way that any line of a folded header field is made up
585
+ entirely of WSP characters and nothing else.
586
+
587
+ FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
588
+ obs-FWS
589
+
590
+ ctext = NO-WS-CTL / ; Non white space controls
591
+
592
+ %d33-39 / ; The rest of the US-ASCII
593
+ %d42-91 / ; characters not including "(",
594
+ %d93-126 ; ")", or "\"
595
+
596
+ ccontent = ctext / quoted-pair / comment
597
+
598
+ comment = "(" *([FWS] ccontent) [FWS] ")"
599
+
600
+ CFWS = *([FWS] comment) (([FWS] comment) / FWS)
601
+
602
+ Throughout this standard, where FWS (the folding white space token)
603
+ appears, it indicates a place where header folding, as discussed in
604
+ section 2.2.3, may take place. Wherever header folding appears in a
605
+ message (that is, a header field body containing a CRLF followed by
606
+ any WSP), header unfolding (removal of the CRLF) is performed before
607
+ any further lexical analysis is performed on that header field
608
+ according to this standard. That is to say, any CRLF that appears in
609
+ FWS is semantically "invisible."
610
+
611
+ A comment is normally used in a structured field body to provide some
612
+ human readable informational text. Since a comment is allowed to
613
+ contain FWS, folding is permitted within the comment. Also note that
614
+ since quoted-pair is allowed in a comment, the parentheses and
615
+
616
+
617
+
618
+ Resnick Standards Track [Page 11]
619
+
620
+ RFC 2822 Internet Message Format April 2001
621
+
622
+
623
+ backslash characters may appear in a comment so long as they appear
624
+ as a quoted-pair. Semantically, the enclosing parentheses are not
625
+ part of the comment; the comment is what is contained between the two
626
+ parentheses. As stated earlier, the "\" in any quoted-pair and the
627
+ CRLF in any FWS that appears within the comment are semantically
628
+ "invisible" and therefore not part of the comment either.
629
+
630
+ Runs of FWS, comment or CFWS that occur between lexical tokens in a
631
+ structured field header are semantically interpreted as a single
632
+ space character.
633
+
634
+ 3.2.4. Atom
635
+
636
+ Several productions in structured header field bodies are simply
637
+ strings of certain basic characters. Such productions are called
638
+ atoms.
639
+
640
+ Some of the structured header field bodies also allow the period
641
+ character (".", ASCII value 46) within runs of atext. An additional
642
+ "dot-atom" token is defined for those purposes.
643
+
644
+ atext = ALPHA / DIGIT / ; Any character except controls,
645
+ "!" / "#" / ; SP, and specials.
646
+ "$" / "%" / ; Used for atoms
647
+ "&" / "'" /
648
+ "*" / "+" /
649
+ "-" / "/" /
650
+ "=" / "?" /
651
+ "^" / "_" /
652
+ "`" / "{" /
653
+ "|" / "}" /
654
+ "~"
655
+
656
+ atom = [CFWS] 1*atext [CFWS]
657
+
658
+ dot-atom = [CFWS] dot-atom-text [CFWS]
659
+
660
+ dot-atom-text = 1*atext *("." 1*atext)
661
+
662
+ Both atom and dot-atom are interpreted as a single unit, comprised of
663
+ the string of characters that make it up. Semantically, the optional
664
+ comments and FWS surrounding the rest of the characters are not part
665
+ of the atom; the atom is only the run of atext characters in an atom,
666
+ or the atext and "." characters in a dot-atom.
667
+
668
+
669
+
670
+
671
+
672
+
673
+
674
+ Resnick Standards Track [Page 12]
675
+
676
+ RFC 2822 Internet Message Format April 2001
677
+
678
+
679
+ 3.2.5. Quoted strings
680
+
681
+ Strings of characters that include characters other than those
682
+ allowed in atoms may be represented in a quoted string format, where
683
+ the characters are surrounded by quote (DQUOTE, ASCII value 34)
684
+ characters.
685
+
686
+ qtext = NO-WS-CTL / ; Non white space controls
687
+
688
+ %d33 / ; The rest of the US-ASCII
689
+ %d35-91 / ; characters not including "\"
690
+ %d93-126 ; or the quote character
691
+
692
+ qcontent = qtext / quoted-pair
693
+
694
+ quoted-string = [CFWS]
695
+ DQUOTE *([FWS] qcontent) [FWS] DQUOTE
696
+ [CFWS]
697
+
698
+ A quoted-string is treated as a unit. That is, quoted-string is
699
+ identical to atom, semantically. Since a quoted-string is allowed to
700
+ contain FWS, folding is permitted. Also note that since quoted-pair
701
+ is allowed in a quoted-string, the quote and backslash characters may
702
+ appear in a quoted-string so long as they appear as a quoted-pair.
703
+
704
+ Semantically, neither the optional CFWS outside of the quote
705
+ characters nor the quote characters themselves are part of the
706
+ quoted-string; the quoted-string is what is contained between the two
707
+ quote characters. As stated earlier, the "\" in any quoted-pair and
708
+ the CRLF in any FWS/CFWS that appears within the quoted-string are
709
+ semantically "invisible" and therefore not part of the quoted-string
710
+ either.
711
+
712
+ 3.2.6. Miscellaneous tokens
713
+
714
+ Three additional tokens are defined, word and phrase for combinations
715
+ of atoms and/or quoted-strings, and unstructured for use in
716
+ unstructured header fields and in some places within structured
717
+ header fields.
718
+
719
+ word = atom / quoted-string
720
+
721
+ phrase = 1*word / obs-phrase
722
+
723
+
724
+
725
+
726
+
727
+
728
+
729
+
730
+ Resnick Standards Track [Page 13]
731
+
732
+ RFC 2822 Internet Message Format April 2001
733
+
734
+
735
+ utext = NO-WS-CTL / ; Non white space controls
736
+ %d33-126 / ; The rest of US-ASCII
737
+ obs-utext
738
+
739
+ unstructured = *([FWS] utext) [FWS]
740
+
741
+ 3.3. Date and Time Specification
742
+
743
+ Date and time occur in several header fields. This section specifies
744
+ the syntax for a full date and time specification. Though folding
745
+ white space is permitted throughout the date-time specification, it
746
+ is RECOMMENDED that a single space be used in each place that FWS
747
+ appears (whether it is required or optional); some older
748
+ implementations may not interpret other occurrences of folding white
749
+ space correctly.
750
+
751
+ date-time = [ day-of-week "," ] date FWS time [CFWS]
752
+
753
+ day-of-week = ([FWS] day-name) / obs-day-of-week
754
+
755
+ day-name = "Mon" / "Tue" / "Wed" / "Thu" /
756
+ "Fri" / "Sat" / "Sun"
757
+
758
+ date = day month year
759
+
760
+ year = 4*DIGIT / obs-year
761
+
762
+ month = (FWS month-name FWS) / obs-month
763
+
764
+ month-name = "Jan" / "Feb" / "Mar" / "Apr" /
765
+ "May" / "Jun" / "Jul" / "Aug" /
766
+ "Sep" / "Oct" / "Nov" / "Dec"
767
+
768
+ day = ([FWS] 1*2DIGIT) / obs-day
769
+
770
+ time = time-of-day FWS zone
771
+
772
+ time-of-day = hour ":" minute [ ":" second ]
773
+
774
+ hour = 2DIGIT / obs-hour
775
+
776
+ minute = 2DIGIT / obs-minute
777
+
778
+ second = 2DIGIT / obs-second
779
+
780
+ zone = (( "+" / "-" ) 4DIGIT) / obs-zone
781
+
782
+
783
+
784
+
785
+
786
+ Resnick Standards Track [Page 14]
787
+
788
+ RFC 2822 Internet Message Format April 2001
789
+
790
+
791
+ The day is the numeric day of the month. The year is any numeric
792
+ year 1900 or later.
793
+
794
+ The time-of-day specifies the number of hours, minutes, and
795
+ optionally seconds since midnight of the date indicated.
796
+
797
+ The date and time-of-day SHOULD express local time.
798
+
799
+ The zone specifies the offset from Coordinated Universal Time (UTC,
800
+ formerly referred to as "Greenwich Mean Time") that the date and
801
+ time-of-day represent. The "+" or "-" indicates whether the
802
+ time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
803
+ Universal Time. The first two digits indicate the number of hours
804
+ difference from Universal Time, and the last two digits indicate the
805
+ number of minutes difference from Universal Time. (Hence, +hhmm
806
+ means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
807
+ minutes). The form "+0000" SHOULD be used to indicate a time zone at
808
+ Universal Time. Though "-0000" also indicates Universal Time, it is
809
+ used to indicate that the time was generated on a system that may be
810
+ in a local time zone other than Universal Time and therefore
811
+ indicates that the date-time contains no information about the local
812
+ time zone.
813
+
814
+ A date-time specification MUST be semantically valid. That is, the
815
+ day-of-the-week (if included) MUST be the day implied by the date,
816
+ the numeric day-of-month MUST be between 1 and the number of days
817
+ allowed for the specified month (in the specified year), the
818
+ time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
819
+ number of seconds allowing for a leap second; see [STD12]), and the
820
+ zone MUST be within the range -9959 through +9959.
821
+
822
+ 3.4. Address Specification
823
+
824
+ Addresses occur in several message header fields to indicate senders
825
+ and recipients of messages. An address may either be an individual
826
+ mailbox, or a group of mailboxes.
827
+
828
+ address = mailbox / group
829
+
830
+ mailbox = name-addr / addr-spec
831
+
832
+ name-addr = [display-name] angle-addr
833
+
834
+ angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
835
+
836
+ group = display-name ":" [mailbox-list / CFWS] ";"
837
+ [CFWS]
838
+
839
+
840
+
841
+
842
+ Resnick Standards Track [Page 15]
843
+
844
+ RFC 2822 Internet Message Format April 2001
845
+
846
+
847
+ display-name = phrase
848
+
849
+ mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
850
+
851
+ address-list = (address *("," address)) / obs-addr-list
852
+
853
+ A mailbox receives mail. It is a conceptual entity which does not
854
+ necessarily pertain to file storage. For example, some sites may
855
+ choose to print mail on a printer and deliver the output to the
856
+ addressee's desk. Normally, a mailbox is comprised of two parts: (1)
857
+ an optional display name that indicates the name of the recipient
858
+ (which could be a person or a system) that could be displayed to the
859
+ user of a mail application, and (2) an addr-spec address enclosed in
860
+ angle brackets ("<" and ">"). There is also an alternate simple form
861
+ of a mailbox where the addr-spec address appears alone, without the
862
+ recipient's name or the angle brackets. The Internet addr-spec
863
+ address is described in section 3.4.1.
864
+
865
+ Note: Some legacy implementations used the simple form where the
866
+ addr-spec appears without the angle brackets, but included the name
867
+ of the recipient in parentheses as a comment following the addr-spec.
868
+ Since the meaning of the information in a comment is unspecified,
869
+ implementations SHOULD use the full name-addr form of the mailbox,
870
+ instead of the legacy form, to specify the display name associated
871
+ with a mailbox. Also, because some legacy implementations interpret
872
+ the comment, comments generally SHOULD NOT be used in address fields
873
+ to avoid confusing such implementations.
874
+
875
+ When it is desirable to treat several mailboxes as a single unit
876
+ (i.e., in a distribution list), the group construct can be used. The
877
+ group construct allows the sender to indicate a named group of
878
+ recipients. This is done by giving a display name for the group,
879
+ followed by a colon, followed by a comma separated list of any number
880
+ of mailboxes (including zero and one), and ending with a semicolon.
881
+ Because the list of mailboxes can be empty, using the group construct
882
+ is also a simple way to communicate to recipients that the message
883
+ was sent to one or more named sets of recipients, without actually
884
+ providing the individual mailbox address for each of those
885
+ recipients.
886
+
887
+ 3.4.1. Addr-spec specification
888
+
889
+ An addr-spec is a specific Internet identifier that contains a
890
+ locally interpreted string followed by the at-sign character ("@",
891
+ ASCII value 64) followed by an Internet domain. The locally
892
+ interpreted string is either a quoted-string or a dot-atom. If the
893
+ string can be represented as a dot-atom (that is, it contains no
894
+ characters other than atext characters or "." surrounded by atext
895
+
896
+
897
+
898
+ Resnick Standards Track [Page 16]
899
+
900
+ RFC 2822 Internet Message Format April 2001
901
+
902
+
903
+ characters), then the dot-atom form SHOULD be used and the
904
+ quoted-string form SHOULD NOT be used. Comments and folding white
905
+ space SHOULD NOT be used around the "@" in the addr-spec.
906
+
907
+ addr-spec = local-part "@" domain
908
+
909
+ local-part = dot-atom / quoted-string / obs-local-part
910
+
911
+ domain = dot-atom / domain-literal / obs-domain
912
+
913
+ domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]
914
+
915
+ dcontent = dtext / quoted-pair
916
+
917
+ dtext = NO-WS-CTL / ; Non white space controls
918
+
919
+ %d33-90 / ; The rest of the US-ASCII
920
+ %d94-126 ; characters not including "[",
921
+ ; "]", or "\"
922
+
923
+ The domain portion identifies the point to which the mail is
924
+ delivered. In the dot-atom form, this is interpreted as an Internet
925
+ domain name (either a host name or a mail exchanger name) as
926
+ described in [STD3, STD13, STD14]. In the domain-literal form, the
927
+ domain is interpreted as the literal Internet address of the
928
+ particular host. In both cases, how addressing is used and how
929
+ messages are transported to a particular host is covered in the mail
930
+ transport document [RFC2821]. These mechanisms are outside of the
931
+ scope of this document.
932
+
933
+ The local-part portion is a domain dependent string. In addresses,
934
+ it is simply interpreted on the particular host as a name of a
935
+ particular mailbox.
936
+
937
+ 3.5 Overall message syntax
938
+
939
+ A message consists of header fields, optionally followed by a message
940
+ body. Lines in a message MUST be a maximum of 998 characters
941
+ excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
942
+ characters excluding the CRLF. (See section 2.1.1 for explanation.)
943
+ In a message body, though all of the characters listed in the text
944
+ rule MAY be used, the use of US-ASCII control characters (values 1
945
+ through 8, 11, 12, and 14 through 31) is discouraged since their
946
+ interpretation by receivers for display is not guaranteed.
947
+
948
+
949
+
950
+
951
+
952
+
953
+
954
+ Resnick Standards Track [Page 17]
955
+
956
+ RFC 2822 Internet Message Format April 2001
957
+
958
+
959
+ message = (fields / obs-fields)
960
+ [CRLF body]
961
+
962
+ body = *(*998text CRLF) *998text
963
+
964
+ The header fields carry most of the semantic information and are
965
+ defined in section 3.6. The body is simply a series of lines of text
966
+ which are uninterpreted for the purposes of this standard.
967
+
968
+ 3.6. Field definitions
969
+
970
+ The header fields of a message are defined here. All header fields
971
+ have the same general syntactic structure: A field name, followed by
972
+ a colon, followed by the field body. The specific syntax for each
973
+ header field is defined in the subsequent sections.
974
+
975
+ Note: In the ABNF syntax for each field in subsequent sections, each
976
+ field name is followed by the required colon. However, for brevity
977
+ sometimes the colon is not referred to in the textual description of
978
+ the syntax. It is, nonetheless, required.
979
+
980
+ It is important to note that the header fields are not guaranteed to
981
+ be in a particular order. They may appear in any order, and they
982
+ have been known to be reordered occasionally when transported over
983
+ the Internet. However, for the purposes of this standard, header
984
+ fields SHOULD NOT be reordered when a message is transported or
985
+ transformed. More importantly, the trace header fields and resent
986
+ header fields MUST NOT be reordered, and SHOULD be kept in blocks
987
+ prepended to the message. See sections 3.6.6 and 3.6.7 for more
988
+ information.
989
+
990
+ The only required header fields are the origination date field and
991
+ the originator address field(s). All other header fields are
992
+ syntactically optional. More information is contained in the table
993
+ following this definition.
994
+
995
+ fields = *(trace
996
+ *(resent-date /
997
+ resent-from /
998
+ resent-sender /
999
+ resent-to /
1000
+ resent-cc /
1001
+ resent-bcc /
1002
+ resent-msg-id))
1003
+ *(orig-date /
1004
+ from /
1005
+ sender /
1006
+ reply-to /
1007
+
1008
+
1009
+
1010
+ Resnick Standards Track [Page 18]
1011
+
1012
+ RFC 2822 Internet Message Format April 2001
1013
+
1014
+
1015
+ to /
1016
+ cc /
1017
+ bcc /
1018
+ message-id /
1019
+ in-reply-to /
1020
+ references /
1021
+ subject /
1022
+ comments /
1023
+ keywords /
1024
+ optional-field)
1025
+
1026
+ The following table indicates limits on the number of times each
1027
+ field may occur in a message header as well as any special
1028
+ limitations on the use of those fields. An asterisk next to a value
1029
+ in the minimum or maximum column indicates that a special restriction
1030
+ appears in the Notes column.
1031
+
1032
+ Field Min number Max number Notes
1033
+
1034
+ trace 0 unlimited Block prepended - see
1035
+ 3.6.7
1036
+
1037
+ resent-date 0* unlimited* One per block, required
1038
+ if other resent fields
1039
+ present - see 3.6.6
1040
+
1041
+ resent-from 0 unlimited* One per block - see
1042
+ 3.6.6
1043
+
1044
+ resent-sender 0* unlimited* One per block, MUST
1045
+ occur with multi-address
1046
+ resent-from - see 3.6.6
1047
+
1048
+ resent-to 0 unlimited* One per block - see
1049
+ 3.6.6
1050
+
1051
+ resent-cc 0 unlimited* One per block - see
1052
+ 3.6.6
1053
+
1054
+ resent-bcc 0 unlimited* One per block - see
1055
+ 3.6.6
1056
+
1057
+ resent-msg-id 0 unlimited* One per block - see
1058
+ 3.6.6
1059
+
1060
+ orig-date 1 1
1061
+
1062
+ from 1 1 See sender and 3.6.2
1063
+
1064
+
1065
+
1066
+ Resnick Standards Track [Page 19]
1067
+
1068
+ RFC 2822 Internet Message Format April 2001
1069
+
1070
+
1071
+ sender 0* 1 MUST occur with multi-
1072
+ address from - see 3.6.2
1073
+
1074
+ reply-to 0 1
1075
+
1076
+ to 0 1
1077
+
1078
+ cc 0 1
1079
+
1080
+ bcc 0 1
1081
+
1082
+ message-id 0* 1 SHOULD be present - see
1083
+ 3.6.4
1084
+
1085
+ in-reply-to 0* 1 SHOULD occur in some
1086
+ replies - see 3.6.4
1087
+
1088
+ references 0* 1 SHOULD occur in some
1089
+ replies - see 3.6.4
1090
+
1091
+ subject 0 1
1092
+
1093
+ comments 0 unlimited
1094
+
1095
+ keywords 0 unlimited
1096
+
1097
+ optional-field 0 unlimited
1098
+
1099
+ The exact interpretation of each field is described in subsequent
1100
+ sections.
1101
+
1102
+ 3.6.1. The origination date field
1103
+
1104
+ The origination date field consists of the field name "Date" followed
1105
+ by a date-time specification.
1106
+
1107
+ orig-date = "Date:" date-time CRLF
1108
+
1109
+ The origination date specifies the date and time at which the creator
1110
+ of the message indicated that the message was complete and ready to
1111
+ enter the mail delivery system. For instance, this might be the time
1112
+ that a user pushes the "send" or "submit" button in an application
1113
+ program. In any case, it is specifically not intended to convey the
1114
+ time that the message is actually transported, but rather the time at
1115
+ which the human or other creator of the message has put the message
1116
+ into its final form, ready for transport. (For example, a portable
1117
+ computer user who is not connected to a network might queue a message
1118
+
1119
+
1120
+
1121
+
1122
+ Resnick Standards Track [Page 20]
1123
+
1124
+ RFC 2822 Internet Message Format April 2001
1125
+
1126
+
1127
+ for delivery. The origination date is intended to contain the date
1128
+ and time that the user queued the message, not the time when the user
1129
+ connected to the network to send the message.)
1130
+
1131
+ 3.6.2. Originator fields
1132
+
1133
+ The originator fields of a message consist of the from field, the
1134
+ sender field (when applicable), and optionally the reply-to field.
1135
+ The from field consists of the field name "From" and a
1136
+ comma-separated list of one or more mailbox specifications. If the
1137
+ from field contains more than one mailbox specification in the
1138
+ mailbox-list, then the sender field, containing the field name
1139
+ "Sender" and a single mailbox specification, MUST appear in the
1140
+ message. In either case, an optional reply-to field MAY also be
1141
+ included, which contains the field name "Reply-To" and a
1142
+ comma-separated list of one or more addresses.
1143
+
1144
+ from = "From:" mailbox-list CRLF
1145
+
1146
+ sender = "Sender:" mailbox CRLF
1147
+
1148
+ reply-to = "Reply-To:" address-list CRLF
1149
+
1150
+ The originator fields indicate the mailbox(es) of the source of the
1151
+ message. The "From:" field specifies the author(s) of the message,
1152
+ that is, the mailbox(es) of the person(s) or system(s) responsible
1153
+ for the writing of the message. The "Sender:" field specifies the
1154
+ mailbox of the agent responsible for the actual transmission of the
1155
+ message. For example, if a secretary were to send a message for
1156
+ another person, the mailbox of the secretary would appear in the
1157
+ "Sender:" field and the mailbox of the actual author would appear in
1158
+ the "From:" field. If the originator of the message can be indicated
1159
+ by a single mailbox and the author and transmitter are identical, the
1160
+ "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
1161
+ appear.
1162
+
1163
+ The originator fields also provide the information required when
1164
+ replying to a message. When the "Reply-To:" field is present, it
1165
+ indicates the mailbox(es) to which the author of the message suggests
1166
+ that replies be sent. In the absence of the "Reply-To:" field,
1167
+ replies SHOULD by default be sent to the mailbox(es) specified in the
1168
+ "From:" field unless otherwise specified by the person composing the
1169
+ reply.
1170
+
1171
+ In all cases, the "From:" field SHOULD NOT contain any mailbox that
1172
+ does not belong to the author(s) of the message. See also section
1173
+ 3.6.3 for more information on forming the destination addresses for a
1174
+ reply.
1175
+
1176
+
1177
+
1178
+ Resnick Standards Track [Page 21]
1179
+
1180
+ RFC 2822 Internet Message Format April 2001
1181
+
1182
+
1183
+ 3.6.3. Destination address fields
1184
+
1185
+ The destination fields of a message consist of three possible fields,
1186
+ each of the same form: The field name, which is either "To", "Cc", or
1187
+ "Bcc", followed by a comma-separated list of one or more addresses
1188
+ (either mailbox or group syntax).
1189
+
1190
+ to = "To:" address-list CRLF
1191
+
1192
+ cc = "Cc:" address-list CRLF
1193
+
1194
+ bcc = "Bcc:" (address-list / [CFWS]) CRLF
1195
+
1196
+ The destination fields specify the recipients of the message. Each
1197
+ destination field may have one or more addresses, and each of the
1198
+ addresses indicate the intended recipients of the message. The only
1199
+ difference between the three fields is how each is used.
1200
+
1201
+ The "To:" field contains the address(es) of the primary recipient(s)
1202
+ of the message.
1203
+
1204
+ The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of
1205
+ making a copy on a typewriter using carbon paper) contains the
1206
+ addresses of others who are to receive the message, though the
1207
+ content of the message may not be directed at them.
1208
+
1209
+ The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
1210
+ addresses of recipients of the message whose addresses are not to be
1211
+ revealed to other recipients of the message. There are three ways in
1212
+ which the "Bcc:" field is used. In the first case, when a message
1213
+ containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
1214
+ removed even though all of the recipients (including those specified
1215
+ in the "Bcc:" field) are sent a copy of the message. In the second
1216
+ case, recipients specified in the "To:" and "Cc:" lines each are sent
1217
+ a copy of the message with the "Bcc:" line removed as above, but the
1218
+ recipients on the "Bcc:" line get a separate copy of the message
1219
+ containing a "Bcc:" line. (When there are multiple recipient
1220
+ addresses in the "Bcc:" field, some implementations actually send a
1221
+ separate copy of the message to each recipient with a "Bcc:"
1222
+ containing only the address of that particular recipient.) Finally,
1223
+ since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
1224
+ sent without any addresses indicating to the recipients that blind
1225
+ copies were sent to someone. Which method to use with "Bcc:" fields
1226
+ is implementation dependent, but refer to the "Security
1227
+ Considerations" section of this document for a discussion of each.
1228
+
1229
+
1230
+
1231
+
1232
+
1233
+
1234
+ Resnick Standards Track [Page 22]
1235
+
1236
+ RFC 2822 Internet Message Format April 2001
1237
+
1238
+
1239
+ When a message is a reply to another message, the mailboxes of the
1240
+ authors of the original message (the mailboxes in the "From:" field)
1241
+ or mailboxes specified in the "Reply-To:" field (if it exists) MAY
1242
+ appear in the "To:" field of the reply since these would normally be
1243
+ the primary recipients of the reply. If a reply is sent to a message
1244
+ that has destination fields, it is often desirable to send a copy of
1245
+ the reply to all of the recipients of the message, in addition to the
1246
+ author. When such a reply is formed, addresses in the "To:" and
1247
+ "Cc:" fields of the original message MAY appear in the "Cc:" field of
1248
+ the reply, since these are normally secondary recipients of the
1249
+ reply. If a "Bcc:" field is present in the original message,
1250
+ addresses in that field MAY appear in the "Bcc:" field of the reply,
1251
+ but SHOULD NOT appear in the "To:" or "Cc:" fields.
1252
+
1253
+ Note: Some mail applications have automatic reply commands that
1254
+ include the destination addresses of the original message in the
1255
+ destination addresses of the reply. How those reply commands behave
1256
+ is implementation dependent and is beyond the scope of this document.
1257
+ In particular, whether or not to include the original destination
1258
+ addresses when the original message had a "Reply-To:" field is not
1259
+ addressed here.
1260
+
1261
+ 3.6.4. Identification fields
1262
+
1263
+ Though optional, every message SHOULD have a "Message-ID:" field.
1264
+ Furthermore, reply messages SHOULD have "In-Reply-To:" and
1265
+ "References:" fields as appropriate, as described below.
1266
+
1267
+ The "Message-ID:" field contains a single unique message identifier.
1268
+ The "References:" and "In-Reply-To:" field each contain one or more
1269
+ unique message identifiers, optionally separated by CFWS.
1270
+
1271
+ The message identifier (msg-id) is similar in syntax to an angle-addr
1272
+ construct without the internal CFWS.
1273
+
1274
+ message-id = "Message-ID:" msg-id CRLF
1275
+
1276
+ in-reply-to = "In-Reply-To:" 1*msg-id CRLF
1277
+
1278
+ references = "References:" 1*msg-id CRLF
1279
+
1280
+ msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
1281
+
1282
+ id-left = dot-atom-text / no-fold-quote / obs-id-left
1283
+
1284
+ id-right = dot-atom-text / no-fold-literal / obs-id-right
1285
+
1286
+ no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE
1287
+
1288
+
1289
+
1290
+ Resnick Standards Track [Page 23]
1291
+
1292
+ RFC 2822 Internet Message Format April 2001
1293
+
1294
+
1295
+ no-fold-literal = "[" *(dtext / quoted-pair) "]"
1296
+
1297
+ The "Message-ID:" field provides a unique message identifier that
1298
+ refers to a particular version of a particular message. The
1299
+ uniqueness of the message identifier is guaranteed by the host that
1300
+ generates it (see below). This message identifier is intended to be
1301
+ machine readable and not necessarily meaningful to humans. A message
1302
+ identifier pertains to exactly one instantiation of a particular
1303
+ message; subsequent revisions to the message each receive new message
1304
+ identifiers.
1305
+
1306
+ Note: There are many instances when messages are "changed", but those
1307
+ changes do not constitute a new instantiation of that message, and
1308
+ therefore the message would not get a new message identifier. For
1309
+ example, when messages are introduced into the transport system, they
1310
+ are often prepended with additional header fields such as trace
1311
+ fields (described in section 3.6.7) and resent fields (described in
1312
+ section 3.6.6). The addition of such header fields does not change
1313
+ the identity of the message and therefore the original "Message-ID:"
1314
+ field is retained. In all cases, it is the meaning that the sender
1315
+ of the message wishes to convey (i.e., whether this is the same
1316
+ message or a different message) that determines whether or not the
1317
+ "Message-ID:" field changes, not any particular syntactic difference
1318
+ that appears (or does not appear) in the message.
1319
+
1320
+ The "In-Reply-To:" and "References:" fields are used when creating a
1321
+ reply to a message. They hold the message identifier of the original
1322
+ message and the message identifiers of other messages (for example,
1323
+ in the case of a reply to a message which was itself a reply). The
1324
+ "In-Reply-To:" field may be used to identify the message (or
1325
+ messages) to which the new message is a reply, while the
1326
+ "References:" field may be used to identify a "thread" of
1327
+ conversation.
1328
+
1329
+ When creating a reply to a message, the "In-Reply-To:" and
1330
+ "References:" fields of the resultant message are constructed as
1331
+ follows:
1332
+
1333
+ The "In-Reply-To:" field will contain the contents of the "Message-
1334
+ ID:" field of the message to which this one is a reply (the "parent
1335
+ message"). If there is more than one parent message, then the "In-
1336
+ Reply-To:" field will contain the contents of all of the parents'
1337
+ "Message-ID:" fields. If there is no "Message-ID:" field in any of
1338
+ the parent messages, then the new message will have no "In-Reply-To:"
1339
+ field.
1340
+
1341
+
1342
+
1343
+
1344
+
1345
+
1346
+ Resnick Standards Track [Page 24]
1347
+
1348
+ RFC 2822 Internet Message Format April 2001
1349
+
1350
+
1351
+ The "References:" field will contain the contents of the parent's
1352
+ "References:" field (if any) followed by the contents of the parent's
1353
+ "Message-ID:" field (if any). If the parent message does not contain
1354
+ a "References:" field but does have an "In-Reply-To:" field
1355
+ containing a single message identifier, then the "References:" field
1356
+ will contain the contents of the parent's "In-Reply-To:" field
1357
+ followed by the contents of the parent's "Message-ID:" field (if
1358
+ any). If the parent has none of the "References:", "In-Reply-To:",
1359
+ or "Message-ID:" fields, then the new message will have no
1360
+ "References:" field.
1361
+
1362
+ Note: Some implementations parse the "References:" field to display
1363
+ the "thread of the discussion". These implementations assume that
1364
+ each new message is a reply to a single parent and hence that they
1365
+ can walk backwards through the "References:" field to find the parent
1366
+ of each message listed there. Therefore, trying to form a
1367
+ "References:" field for a reply that has multiple parents is
1368
+ discouraged and how to do so is not defined in this document.
1369
+
1370
+ The message identifier (msg-id) itself MUST be a globally unique
1371
+ identifier for a message. The generator of the message identifier
1372
+ MUST guarantee that the msg-id is unique. There are several
1373
+ algorithms that can be used to accomplish this. Since the msg-id has
1374
+ a similar syntax to angle-addr (identical except that comments and
1375
+ folding white space are not allowed), a good method is to put the
1376
+ domain name (or a domain literal IP address) of the host on which the
1377
+ message identifier was created on the right hand side of the "@", and
1378
+ put a combination of the current absolute date and time along with
1379
+ some other currently unique (perhaps sequential) identifier available
1380
+ on the system (for example, a process id number) on the left hand
1381
+ side. Using a date on the left hand side and a domain name or domain
1382
+ literal on the right hand side makes it possible to guarantee
1383
+ uniqueness since no two hosts use the same domain name or IP address
1384
+ at the same time. Though other algorithms will work, it is
1385
+ RECOMMENDED that the right hand side contain some domain identifier
1386
+ (either of the host itself or otherwise) such that the generator of
1387
+ the message identifier can guarantee the uniqueness of the left hand
1388
+ side within the scope of that domain.
1389
+
1390
+ Semantically, the angle bracket characters are not part of the
1391
+ msg-id; the msg-id is what is contained between the two angle bracket
1392
+ characters.
1393
+
1394
+
1395
+
1396
+
1397
+
1398
+
1399
+
1400
+
1401
+
1402
+ Resnick Standards Track [Page 25]
1403
+
1404
+ RFC 2822 Internet Message Format April 2001
1405
+
1406
+
1407
+ 3.6.5. Informational fields
1408
+
1409
+ The informational fields are all optional. The "Keywords:" field
1410
+ contains a comma-separated list of one or more words or
1411
+ quoted-strings. The "Subject:" and "Comments:" fields are
1412
+ unstructured fields as defined in section 2.2.1, and therefore may
1413
+ contain text or folding white space.
1414
+
1415
+ subject = "Subject:" unstructured CRLF
1416
+
1417
+ comments = "Comments:" unstructured CRLF
1418
+
1419
+ keywords = "Keywords:" phrase *("," phrase) CRLF
1420
+
1421
+ These three fields are intended to have only human-readable content
1422
+ with information about the message. The "Subject:" field is the most
1423
+ common and contains a short string identifying the topic of the
1424
+ message. When used in a reply, the field body MAY start with the
1425
+ string "Re: " (from the Latin "res", in the matter of) followed by
1426
+ the contents of the "Subject:" field body of the original message.
1427
+ If this is done, only one instance of the literal string "Re: " ought
1428
+ to be used since use of other strings or more than one instance can
1429
+ lead to undesirable consequences. The "Comments:" field contains any
1430
+ additional comments on the text of the body of the message. The
1431
+ "Keywords:" field contains a comma-separated list of important words
1432
+ and phrases that might be useful for the recipient.
1433
+
1434
+ 3.6.6. Resent fields
1435
+
1436
+ Resent fields SHOULD be added to any message that is reintroduced by
1437
+ a user into the transport system. A separate set of resent fields
1438
+ SHOULD be added each time this is done. All of the resent fields
1439
+ corresponding to a particular resending of the message SHOULD be
1440
+ together. Each new set of resent fields is prepended to the message;
1441
+ that is, the most recent set of resent fields appear earlier in the
1442
+ message. No other fields in the message are changed when resent
1443
+ fields are added.
1444
+
1445
+ Each of the resent fields corresponds to a particular field elsewhere
1446
+ in the syntax. For instance, the "Resent-Date:" field corresponds to
1447
+ the "Date:" field and the "Resent-To:" field corresponds to the "To:"
1448
+ field. In each case, the syntax for the field body is identical to
1449
+ the syntax given previously for the corresponding field.
1450
+
1451
+ When resent fields are used, the "Resent-From:" and "Resent-Date:"
1452
+ fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
1453
+ "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
1454
+ identical to "Resent-From:".
1455
+
1456
+
1457
+
1458
+ Resnick Standards Track [Page 26]
1459
+
1460
+ RFC 2822 Internet Message Format April 2001
1461
+
1462
+
1463
+ resent-date = "Resent-Date:" date-time CRLF
1464
+
1465
+ resent-from = "Resent-From:" mailbox-list CRLF
1466
+
1467
+ resent-sender = "Resent-Sender:" mailbox CRLF
1468
+
1469
+ resent-to = "Resent-To:" address-list CRLF
1470
+
1471
+ resent-cc = "Resent-Cc:" address-list CRLF
1472
+
1473
+ resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF
1474
+
1475
+ resent-msg-id = "Resent-Message-ID:" msg-id CRLF
1476
+
1477
+ Resent fields are used to identify a message as having been
1478
+ reintroduced into the transport system by a user. The purpose of
1479
+ using resent fields is to have the message appear to the final
1480
+ recipient as if it were sent directly by the original sender, with
1481
+ all of the original fields remaining the same. Each set of resent
1482
+ fields correspond to a particular resending event. That is, if a
1483
+ message is resent multiple times, each set of resent fields gives
1484
+ identifying information for each individual time. Resent fields are
1485
+ strictly informational. They MUST NOT be used in the normal
1486
+ processing of replies or other such automatic actions on messages.
1487
+
1488
+ Note: Reintroducing a message into the transport system and using
1489
+ resent fields is a different operation from "forwarding".
1490
+ "Forwarding" has two meanings: One sense of forwarding is that a mail
1491
+ reading program can be told by a user to forward a copy of a message
1492
+ to another person, making the forwarded message the body of the new
1493
+ message. A forwarded message in this sense does not appear to have
1494
+ come from the original sender, but is an entirely new message from
1495
+ the forwarder of the message. On the other hand, forwarding is also
1496
+ used to mean when a mail transport program gets a message and
1497
+ forwards it on to a different destination for final delivery. Resent
1498
+ header fields are not intended for use with either type of
1499
+ forwarding.
1500
+
1501
+ The resent originator fields indicate the mailbox of the person(s) or
1502
+ system(s) that resent the message. As with the regular originator
1503
+ fields, there are two forms: a simple "Resent-From:" form which
1504
+ contains the mailbox of the individual doing the resending, and the
1505
+ more complex form, when one individual (identified in the
1506
+ "Resent-Sender:" field) resends a message on behalf of one or more
1507
+ others (identified in the "Resent-From:" field).
1508
+
1509
+ Note: When replying to a resent message, replies behave just as they
1510
+ would with any other message, using the original "From:",
1511
+
1512
+
1513
+
1514
+ Resnick Standards Track [Page 27]
1515
+
1516
+ RFC 2822 Internet Message Format April 2001
1517
+
1518
+
1519
+ "Reply-To:", "Message-ID:", and other fields. The resent fields are
1520
+ only informational and MUST NOT be used in the normal processing of
1521
+ replies.
1522
+
1523
+ The "Resent-Date:" indicates the date and time at which the resent
1524
+ message is dispatched by the resender of the message. Like the
1525
+ "Date:" field, it is not the date and time that the message was
1526
+ actually transported.
1527
+
1528
+ The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function
1529
+ identically to the "To:", "Cc:", and "Bcc:" fields respectively,
1530
+ except that they indicate the recipients of the resent message, not
1531
+ the recipients of the original message.
1532
+
1533
+ The "Resent-Message-ID:" field provides a unique identifier for the
1534
+ resent message.
1535
+
1536
+ 3.6.7. Trace fields
1537
+
1538
+ The trace fields are a group of header fields consisting of an
1539
+ optional "Return-Path:" field, and one or more "Received:" fields.
1540
+ The "Return-Path:" header field contains a pair of angle brackets
1541
+ that enclose an optional addr-spec. The "Received:" field contains a
1542
+ (possibly empty) list of name/value pairs followed by a semicolon and
1543
+ a date-time specification. The first item of the name/value pair is
1544
+ defined by item-name, and the second item is either an addr-spec, an
1545
+ atom, a domain, or a msg-id. Further restrictions may be applied to
1546
+ the syntax of the trace fields by standards that provide for their
1547
+ use, such as [RFC2821].
1548
+
1549
+ trace = [return]
1550
+ 1*received
1551
+
1552
+ return = "Return-Path:" path CRLF
1553
+
1554
+ path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) /
1555
+ obs-path
1556
+
1557
+ received = "Received:" name-val-list ";" date-time CRLF
1558
+
1559
+ name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)]
1560
+
1561
+ name-val-pair = item-name CFWS item-value
1562
+
1563
+ item-name = ALPHA *(["-"] (ALPHA / DIGIT))
1564
+
1565
+ item-value = 1*angle-addr / addr-spec /
1566
+ atom / domain / msg-id
1567
+
1568
+
1569
+
1570
+ Resnick Standards Track [Page 28]
1571
+
1572
+ RFC 2822 Internet Message Format April 2001
1573
+
1574
+
1575
+ A full discussion of the Internet mail use of trace fields is
1576
+ contained in [RFC2821]. For the purposes of this standard, the trace
1577
+ fields are strictly informational, and any formal interpretation of
1578
+ them is outside of the scope of this document.
1579
+
1580
+ 3.6.8. Optional fields
1581
+
1582
+ Fields may appear in messages that are otherwise unspecified in this
1583
+ standard. They MUST conform to the syntax of an optional-field.
1584
+ This is a field name, made up of the printable US-ASCII characters
1585
+ except SP and colon, followed by a colon, followed by any text which
1586
+ conforms to unstructured.
1587
+
1588
+ The field names of any optional-field MUST NOT be identical to any
1589
+ field name specified elsewhere in this standard.
1590
+
1591
+ optional-field = field-name ":" unstructured CRLF
1592
+
1593
+ field-name = 1*ftext
1594
+
1595
+ ftext = %d33-57 / ; Any character except
1596
+ %d59-126 ; controls, SP, and
1597
+ ; ":".
1598
+
1599
+ For the purposes of this standard, any optional field is
1600
+ uninterpreted.
1601
+
1602
+ 4. Obsolete Syntax
1603
+
1604
+ Earlier versions of this standard allowed for different (usually more
1605
+ liberal) syntax than is allowed in this version. Also, there have
1606
+ been syntactic elements used in messages on the Internet whose
1607
+ interpretation have never been documented. Though some of these
1608
+ syntactic forms MUST NOT be generated according to the grammar in
1609
+ section 3, they MUST be accepted and parsed by a conformant receiver.
1610
+ This section documents many of these syntactic elements. Taking the
1611
+ grammar in section 3 and adding the definitions presented in this
1612
+ section will result in the grammar to use for interpretation of
1613
+ messages.
1614
+
1615
+ Note: This section identifies syntactic forms that any implementation
1616
+ MUST reasonably interpret. However, there are certainly Internet
1617
+ messages which do not conform to even the additional syntax given in
1618
+ this section. The fact that a particular form does not appear in any
1619
+ section of this document is not justification for computer programs
1620
+ to crash or for malformed data to be irretrievably lost by any
1621
+ implementation. To repeat an example, though this document requires
1622
+ lines in messages to be no longer than 998 characters, silently
1623
+
1624
+
1625
+
1626
+ Resnick Standards Track [Page 29]
1627
+
1628
+ RFC 2822 Internet Message Format April 2001
1629
+
1630
+
1631
+ discarding the 999th and subsequent characters in a line without
1632
+ warning would still be bad behavior for an implementation. It is up
1633
+ to the implementation to deal with messages robustly.
1634
+
1635
+ One important difference between the obsolete (interpreting) and the
1636
+ current (generating) syntax is that in structured header field bodies
1637
+ (i.e., between the colon and the CRLF of any structured header
1638
+ field), white space characters, including folding white space, and
1639
+ comments can be freely inserted between any syntactic tokens. This
1640
+ allows many complex forms that have proven difficult for some
1641
+ implementations to parse.
1642
+
1643
+ Another key difference between the obsolete and the current syntax is
1644
+ that the rule in section 3.2.3 regarding lines composed entirely of
1645
+ white space in comments and folding white space does not apply. See
1646
+ the discussion of folding white space in section 4.2 below.
1647
+
1648
+ Finally, certain characters that were formerly allowed in messages
1649
+ appear in this section. The NUL character (ASCII value 0) was once
1650
+ allowed, but is no longer for compatibility reasons. CR and LF were
1651
+ allowed to appear in messages other than as CRLF; this use is also
1652
+ shown here.
1653
+
1654
+ Other differences in syntax and semantics are noted in the following
1655
+ sections.
1656
+
1657
+ 4.1. Miscellaneous obsolete tokens
1658
+
1659
+ These syntactic elements are used elsewhere in the obsolete syntax or
1660
+ in the main syntax. The obs-char and obs-qp elements each add ASCII
1661
+ value 0. Bare CR and bare LF are added to obs-text and obs-utext.
1662
+ The period character is added to obs-phrase. The obs-phrase-list
1663
+ provides for "empty" elements in a comma-separated list of phrases.
1664
+
1665
+ Note: The "period" (or "full stop") character (".") in obs-phrase is
1666
+ not a form that was allowed in earlier versions of this or any other
1667
+ standard. Period (nor any other character from specials) was not
1668
+ allowed in phrase because it introduced a parsing difficulty
1669
+ distinguishing between phrases and portions of an addr-spec (see
1670
+ section 4.4). It appears here because the period character is
1671
+ currently used in many messages in the display-name portion of
1672
+ addresses, especially for initials in names, and therefore must be
1673
+ interpreted properly. In the future, period may appear in the
1674
+ regular syntax of phrase.
1675
+
1676
+ obs-qp = "\" (%d0-127)
1677
+
1678
+ obs-text = *LF *CR *(obs-char *LF *CR)
1679
+
1680
+
1681
+
1682
+ Resnick Standards Track [Page 30]
1683
+
1684
+ RFC 2822 Internet Message Format April 2001
1685
+
1686
+
1687
+ obs-char = %d0-9 / %d11 / ; %d0-127 except CR and
1688
+ %d12 / %d14-127 ; LF
1689
+
1690
+ obs-utext = obs-text
1691
+
1692
+ obs-phrase = word *(word / "." / CFWS)
1693
+
1694
+ obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase]
1695
+
1696
+ Bare CR and bare LF appear in messages with two different meanings.
1697
+ In many cases, bare CR or bare LF are used improperly instead of CRLF
1698
+ to indicate line separators. In other cases, bare CR and bare LF are
1699
+ used simply as ASCII control characters with their traditional ASCII
1700
+ meanings.
1701
+
1702
+ 4.2. Obsolete folding white space
1703
+
1704
+ In the obsolete syntax, any amount of folding white space MAY be
1705
+ inserted where the obs-FWS rule is allowed. This creates the
1706
+ possibility of having two consecutive "folds" in a line, and
1707
+ therefore the possibility that a line which makes up a folded header
1708
+ field could be composed entirely of white space.
1709
+
1710
+ obs-FWS = 1*WSP *(CRLF 1*WSP)
1711
+
1712
+ 4.3. Obsolete Date and Time
1713
+
1714
+ The syntax for the obsolete date format allows a 2 digit year in the
1715
+ date field and allows for a list of alphabetic time zone
1716
+ specifications that were used in earlier versions of this standard.
1717
+ It also permits comments and folding white space between many of the
1718
+ tokens.
1719
+
1720
+ obs-day-of-week = [CFWS] day-name [CFWS]
1721
+
1722
+ obs-year = [CFWS] 2*DIGIT [CFWS]
1723
+
1724
+ obs-month = CFWS month-name CFWS
1725
+
1726
+ obs-day = [CFWS] 1*2DIGIT [CFWS]
1727
+
1728
+ obs-hour = [CFWS] 2DIGIT [CFWS]
1729
+
1730
+ obs-minute = [CFWS] 2DIGIT [CFWS]
1731
+
1732
+ obs-second = [CFWS] 2DIGIT [CFWS]
1733
+
1734
+ obs-zone = "UT" / "GMT" / ; Universal Time
1735
+
1736
+
1737
+
1738
+ Resnick Standards Track [Page 31]
1739
+
1740
+ RFC 2822 Internet Message Format April 2001
1741
+
1742
+
1743
+ ; North American UT
1744
+ ; offsets
1745
+ "EST" / "EDT" / ; Eastern: - 5/ - 4
1746
+ "CST" / "CDT" / ; Central: - 6/ - 5
1747
+ "MST" / "MDT" / ; Mountain: - 7/ - 6
1748
+ "PST" / "PDT" / ; Pacific: - 8/ - 7
1749
+
1750
+ %d65-73 / ; Military zones - "A"
1751
+ %d75-90 / ; through "I" and "K"
1752
+ %d97-105 / ; through "Z", both
1753
+ %d107-122 ; upper and lower case
1754
+
1755
+ Where a two or three digit year occurs in a date, the year is to be
1756
+ interpreted as follows: If a two digit year is encountered whose
1757
+ value is between 00 and 49, the year is interpreted by adding 2000,
1758
+ ending up with a value between 2000 and 2049. If a two digit year is
1759
+ encountered with a value between 50 and 99, or any three digit year
1760
+ is encountered, the year is interpreted by adding 1900.
1761
+
1762
+ In the obsolete time zone, "UT" and "GMT" are indications of
1763
+ "Universal Time" and "Greenwich Mean Time" respectively and are both
1764
+ semantically identical to "+0000".
1765
+
1766
+ The remaining three character zones are the US time zones. The first
1767
+ letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
1768
+ "Mountain" and "Pacific". The second letter is either "S" for
1769
+ "Standard" time, or "D" for "Daylight" (or summer) time. Their
1770
+ interpretations are as follows:
1771
+
1772
+ EDT is semantically equivalent to -0400
1773
+ EST is semantically equivalent to -0500
1774
+ CDT is semantically equivalent to -0500
1775
+ CST is semantically equivalent to -0600
1776
+ MDT is semantically equivalent to -0600
1777
+ MST is semantically equivalent to -0700
1778
+ PDT is semantically equivalent to -0700
1779
+ PST is semantically equivalent to -0800
1780
+
1781
+ The 1 character military time zones were defined in a non-standard
1782
+ way in [RFC822] and are therefore unpredictable in their meaning.
1783
+ The original definitions of the military zones "A" through "I" are
1784
+ equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
1785
+ are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
1786
+ through "Y" are equivalent to "-0100" through "-1200" respectively;
1787
+ and "Z" is equivalent to "+0000". However, because of the error in
1788
+ [RFC822], they SHOULD all be considered equivalent to "-0000" unless
1789
+ there is out-of-band information confirming their meaning.
1790
+
1791
+
1792
+
1793
+
1794
+ Resnick Standards Track [Page 32]
1795
+
1796
+ RFC 2822 Internet Message Format April 2001
1797
+
1798
+
1799
+ Other multi-character (usually between 3 and 5) alphabetic time zones
1800
+ have been used in Internet messages. Any such time zone whose
1801
+ meaning is not known SHOULD be considered equivalent to "-0000"
1802
+ unless there is out-of-band information confirming their meaning.
1803
+
1804
+ 4.4. Obsolete Addressing
1805
+
1806
+ There are three primary differences in addressing. First, mailbox
1807
+ addresses were allowed to have a route portion before the addr-spec
1808
+ when enclosed in "<" and ">". The route is simply a comma-separated
1809
+ list of domain names, each preceded by "@", and the list terminated
1810
+ by a colon. Second, CFWS were allowed between the period-separated
1811
+ elements of local-part and domain (i.e., dot-atom was not used). In
1812
+ addition, local-part is allowed to contain quoted-string in addition
1813
+ to just atom. Finally, mailbox-list and address-list were allowed to
1814
+ have "null" members. That is, there could be two or more commas in
1815
+ such a list with nothing in between them.
1816
+
1817
+ obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS]
1818
+
1819
+ obs-route = [CFWS] obs-domain-list ":" [CFWS]
1820
+
1821
+ obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain)
1822
+
1823
+ obs-local-part = word *("." word)
1824
+
1825
+ obs-domain = atom *("." atom)
1826
+
1827
+ obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox]
1828
+
1829
+ obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address]
1830
+
1831
+ When interpreting addresses, the route portion SHOULD be ignored.
1832
+
1833
+ 4.5. Obsolete header fields
1834
+
1835
+ Syntactically, the primary difference in the obsolete field syntax is
1836
+ that it allows multiple occurrences of any of the fields and they may
1837
+ occur in any order. Also, any amount of white space is allowed
1838
+ before the ":" at the end of the field name.
1839
+
1840
+ obs-fields = *(obs-return /
1841
+ obs-received /
1842
+ obs-orig-date /
1843
+ obs-from /
1844
+ obs-sender /
1845
+ obs-reply-to /
1846
+ obs-to /
1847
+
1848
+
1849
+
1850
+ Resnick Standards Track [Page 33]
1851
+
1852
+ RFC 2822 Internet Message Format April 2001
1853
+
1854
+
1855
+ obs-cc /
1856
+ obs-bcc /
1857
+ obs-message-id /
1858
+ obs-in-reply-to /
1859
+ obs-references /
1860
+ obs-subject /
1861
+ obs-comments /
1862
+ obs-keywords /
1863
+ obs-resent-date /
1864
+ obs-resent-from /
1865
+ obs-resent-send /
1866
+ obs-resent-rply /
1867
+ obs-resent-to /
1868
+ obs-resent-cc /
1869
+ obs-resent-bcc /
1870
+ obs-resent-mid /
1871
+ obs-optional)
1872
+
1873
+ Except for destination address fields (described in section 4.5.3),
1874
+ the interpretation of multiple occurrences of fields is unspecified.
1875
+ Also, the interpretation of trace fields and resent fields which do
1876
+ not occur in blocks prepended to the message is unspecified as well.
1877
+ Unless otherwise noted in the following sections, interpretation of
1878
+ other fields is identical to the interpretation of their non-obsolete
1879
+ counterparts in section 3.
1880
+
1881
+ 4.5.1. Obsolete origination date field
1882
+
1883
+ obs-orig-date = "Date" *WSP ":" date-time CRLF
1884
+
1885
+ 4.5.2. Obsolete originator fields
1886
+
1887
+ obs-from = "From" *WSP ":" mailbox-list CRLF
1888
+
1889
+ obs-sender = "Sender" *WSP ":" mailbox CRLF
1890
+
1891
+ obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF
1892
+
1893
+ 4.5.3. Obsolete destination address fields
1894
+
1895
+ obs-to = "To" *WSP ":" address-list CRLF
1896
+
1897
+ obs-cc = "Cc" *WSP ":" address-list CRLF
1898
+
1899
+ obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF
1900
+
1901
+
1902
+
1903
+
1904
+
1905
+
1906
+ Resnick Standards Track [Page 34]
1907
+
1908
+ RFC 2822 Internet Message Format April 2001
1909
+
1910
+
1911
+ When multiple occurrences of destination address fields occur in a
1912
+ message, they SHOULD be treated as if the address-list in the first
1913
+ occurrence of the field is combined with the address lists of the
1914
+ subsequent occurrences by adding a comma and concatenating.
1915
+
1916
+ 4.5.4. Obsolete identification fields
1917
+
1918
+ The obsolete "In-Reply-To:" and "References:" fields differ from the
1919
+ current syntax in that they allow phrase (words or quoted strings) to
1920
+ appear. The obsolete forms of the left and right sides of msg-id
1921
+ allow interspersed CFWS, making them syntactically identical to
1922
+ local-part and domain respectively.
1923
+
1924
+ obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
1925
+
1926
+ obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
1927
+
1928
+ obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
1929
+
1930
+ obs-id-left = local-part
1931
+
1932
+ obs-id-right = domain
1933
+
1934
+ For purposes of interpretation, the phrases in the "In-Reply-To:" and
1935
+ "References:" fields are ignored.
1936
+
1937
+ Semantically, none of the optional CFWS surrounding the local-part
1938
+ and the domain are part of the obs-id-left and obs-id-right
1939
+ respectively.
1940
+
1941
+ 4.5.5. Obsolete informational fields
1942
+
1943
+ obs-subject = "Subject" *WSP ":" unstructured CRLF
1944
+
1945
+ obs-comments = "Comments" *WSP ":" unstructured CRLF
1946
+
1947
+ obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
1948
+
1949
+ 4.5.6. Obsolete resent fields
1950
+
1951
+ The obsolete syntax adds a "Resent-Reply-To:" field, which consists
1952
+ of the field name, the optional comments and folding white space, the
1953
+ colon, and a comma separated list of addresses.
1954
+
1955
+ obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
1956
+
1957
+ obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
1958
+
1959
+
1960
+
1961
+
1962
+ Resnick Standards Track [Page 35]
1963
+
1964
+ RFC 2822 Internet Message Format April 2001
1965
+
1966
+
1967
+ obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
1968
+
1969
+ obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
1970
+
1971
+ obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
1972
+
1973
+ obs-resent-bcc = "Resent-Bcc" *WSP ":"
1974
+ (address-list / [CFWS]) CRLF
1975
+
1976
+ obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
1977
+
1978
+ obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
1979
+
1980
+ As with other resent fields, the "Resent-Reply-To:" field is to be
1981
+ treated as trace information only.
1982
+
1983
+ 4.5.7. Obsolete trace fields
1984
+
1985
+ The obs-return and obs-received are again given here as template
1986
+ definitions, just as return and received are in section 3. Their
1987
+ full syntax is given in [RFC2821].
1988
+
1989
+ obs-return = "Return-Path" *WSP ":" path CRLF
1990
+
1991
+ obs-received = "Received" *WSP ":" name-val-list CRLF
1992
+
1993
+ obs-path = obs-angle-addr
1994
+
1995
+ 4.5.8. Obsolete optional fields
1996
+
1997
+ obs-optional = field-name *WSP ":" unstructured CRLF
1998
+
1999
+ 5. Security Considerations
2000
+
2001
+ Care needs to be taken when displaying messages on a terminal or
2002
+ terminal emulator. Powerful terminals may act on escape sequences
2003
+ and other combinations of ASCII control characters with a variety of
2004
+ consequences. They can remap the keyboard or permit other
2005
+ modifications to the terminal which could lead to denial of service
2006
+ or even damaged data. They can trigger (sometimes programmable)
2007
+ answerback messages which can allow a message to cause commands to be
2008
+ issued on the recipient's behalf. They can also effect the operation
2009
+ of terminal attached devices such as printers. Message viewers may
2010
+ wish to strip potentially dangerous terminal escape sequences from
2011
+ the message prior to display. However, other escape sequences appear
2012
+ in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047,
2013
+ RFC2048, RFC2049, ISO2022]) and therefore should not be stripped
2014
+ indiscriminately.
2015
+
2016
+
2017
+
2018
+ Resnick Standards Track [Page 36]
2019
+
2020
+ RFC 2822 Internet Message Format April 2001
2021
+
2022
+
2023
+ Transmission of non-text objects in messages raises additional
2024
+ security issues. These issues are discussed in [RFC2045, RFC2046,
2025
+ RFC2047, RFC2048, RFC2049].
2026
+
2027
+ Many implementations use the "Bcc:" (blind carbon copy) field
2028
+ described in section 3.6.3 to facilitate sending messages to
2029
+ recipients without revealing the addresses of one or more of the
2030
+ addressees to the other recipients. Mishandling this use of "Bcc:"
2031
+ has implications for confidential information that might be revealed,
2032
+ which could eventually lead to security problems through knowledge of
2033
+ even the existence of a particular mail address. For example, if
2034
+ using the first method described in section 3.6.3, where the "Bcc:"
2035
+ line is removed from the message, blind recipients have no explicit
2036
+ indication that they have been sent a blind copy, except insofar as
2037
+ their address does not appear in the message header. Because of
2038
+ this, one of the blind addressees could potentially send a reply to
2039
+ all of the shown recipients and accidentally reveal that the message
2040
+ went to the blind recipient. When the second method from section
2041
+ 3.6.3 is used, the blind recipient's address appears in the "Bcc:"
2042
+ field of a separate copy of the message. If the "Bcc:" field sent
2043
+ contains all of the blind addressees, all of the "Bcc:" recipients
2044
+ will be seen by each "Bcc:" recipient. Even if a separate message is
2045
+ sent to each "Bcc:" recipient with only the individual's address,
2046
+ implementations still need to be careful to process replies to the
2047
+ message as per section 3.6.3 so as not to accidentally reveal the
2048
+ blind recipient to other recipients.
2049
+
2050
+ 6. Bibliography
2051
+
2052
+ [ASCII] American National Standards Institute (ANSI), Coded
2053
+ Character Set - 7-Bit American National Standard Code for
2054
+ Information Interchange, ANSI X3.4, 1986.
2055
+
2056
+ [ISO2022] International Organization for Standardization (ISO),
2057
+ Information processing - ISO 7-bit and 8-bit coded
2058
+ character sets - Code extension techniques, Third edition
2059
+ - 1986-05-01, ISO 2022, 1986.
2060
+
2061
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
2062
+ Text Messages", RFC 822, August 1982.
2063
+
2064
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2065
+ Extensions (MIME) Part One: Format of Internet Message
2066
+ Bodies", RFC 2045, November 1996.
2067
+
2068
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2069
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
2070
+ November 1996.
2071
+
2072
+
2073
+
2074
+ Resnick Standards Track [Page 37]
2075
+
2076
+ RFC 2822 Internet Message Format April 2001
2077
+
2078
+
2079
+ [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
2080
+ Part Three: Message Header Extensions for Non-ASCII Text",
2081
+ RFC 2047, November 1996.
2082
+
2083
+ [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
2084
+ Internet Mail Extensions (MIME) Part Four: Format of
2085
+ Internet Message Bodies", RFC 2048, November 1996.
2086
+
2087
+ [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2088
+ Extensions (MIME) Part Five: Conformance Criteria and
2089
+ Examples", RFC 2049, November 1996.
2090
+
2091
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2092
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
2093
+
2094
+ [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for
2095
+ Syntax Specifications: ABNF", RFC 2234, November 1997.
2096
+
2097
+ [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
2098
+ 2821, March 2001.
2099
+
2100
+ [STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC
2101
+ 1123, October 1989.
2102
+
2103
+ [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119,
2104
+ September 1989.
2105
+
2106
+ [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034
2107
+ and RFC 1035, November 1987.
2108
+
2109
+ [STD14] Partridge, C., "Mail Routing and the Domain System", STD
2110
+ 14, RFC 974, January 1986.
2111
+
2112
+ 7. Editor's Address
2113
+
2114
+ Peter W. Resnick
2115
+ QUALCOMM Incorporated
2116
+ 5775 Morehouse Drive
2117
+ San Diego, CA 92121-1714
2118
+ USA
2119
+
2120
+ Phone: +1 858 651 4478
2121
+ Fax: +1 858 651 1102
2122
+ EMail: presnick@qualcomm.com
2123
+
2124
+
2125
+
2126
+
2127
+
2128
+
2129
+
2130
+ Resnick Standards Track [Page 38]
2131
+
2132
+ RFC 2822 Internet Message Format April 2001
2133
+
2134
+
2135
+ 8. Acknowledgements
2136
+
2137
+ Many people contributed to this document. They included folks who
2138
+ participated in the Detailed Revision and Update of Messaging
2139
+ Standards (DRUMS) Working Group of the Internet Engineering Task
2140
+ Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
2141
+ people who simply sent their comments in via e-mail. The editor is
2142
+ deeply indebted to them all and thanks them sincerely. The below
2143
+ list includes everyone who sent e-mail concerning this document.
2144
+ Hopefully, everyone who contributed is named here:
2145
+
2146
+ Matti Aarnio Barry Finkel Larry Masinter
2147
+ Tanaka Akira Erik Forsberg Denis McKeon
2148
+ Russ Allbery Chuck Foster William P McQuillan
2149
+ Eric Allman Paul Fox Alexey Melnikov
2150
+ Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger
2151
+ Ran Atkinson Ned Freed Steven Miller
2152
+ Jos Backus Jochen Friedrich Keith Moore
2153
+ Bruce Balden Randall C. Gellens John Gardiner Myers
2154
+ Dave Barr Sukvinder Singh Gill Chris Newman
2155
+ Alan Barrett Tim Goodwin John W. Noerenberg
2156
+ John Beck Philip Guenther Eric Norman
2157
+ J. Robert von Behren Tony Hansen Mike O'Dell
2158
+ Jos den Bekker John Hawkinson Larry Osterman
2159
+ D. J. Bernstein Philip Hazel Paul Overell
2160
+ James Berriman Kai Henningsen Jacob Palme
2161
+ Norbert Bollow Robert Herriot Michael A. Patton
2162
+ Raj Bose Paul Hethmon Uzi Paz
2163
+ Antony Bowesman Jim Hill Michael A. Quinlan
2164
+ Scott Bradner Paul E. Hoffman Eric S. Raymond
2165
+ Randy Bush Steve Hole Sam Roberts
2166
+ Tom Byrer Kari Hurtta Hugh Sasse
2167
+ Bruce Campbell Marco S. Hyman Bart Schaefer
2168
+ Larry Campbell Ofer Inbar Tom Scola
2169
+ W. J. Carpenter Olle Jarnefors Wolfgang Segmuller
2170
+ Michael Chapman Kevin Johnson Nick Shelness
2171
+ Richard Clayton Sudish Joseph John Stanley
2172
+ Maurizio Codogno Maynard Kang Einar Stefferud
2173
+ Jim Conklin Prabhat Keni Jeff Stephenson
2174
+ R. Kelley Cook John C. Klensin Bernard Stern
2175
+ Steve Coya Graham Klyne Peter Sylvester
2176
+ Mark Crispin Brad Knowles Mark Symons
2177
+ Dave Crocker Shuhei Kobayashi Eric Thomas
2178
+ Matt Curtin Peter Koch Lee Thompson
2179
+ Michael D'Errico Dan Kohn Karel De Vriendt
2180
+ Cyrus Daboo Christian Kuhtz Matthew Wall
2181
+ Jutta Degener Anand Kumria Rolf Weber
2182
+ Mark Delany Steen Larsen Brent B. Welch
2183
+
2184
+
2185
+
2186
+ Resnick Standards Track [Page 39]
2187
+
2188
+ RFC 2822 Internet Message Format April 2001
2189
+
2190
+
2191
+ Steve Dorner Eliot Lear Dan Wing
2192
+ Harold A. Driscoll Barry Leiba Jack De Winter
2193
+ Michael Elkins Jay Levitt Gregory J. Woodhouse
2194
+ Robert Elz Lars-Johan Liman Greg A. Woods
2195
+ Johnny Eriksson Charles Lindsey Kazu Yamamoto
2196
+ Erik E. Fair Pete Loshin Alain Zahm
2197
+ Roger Fajman Simon Lyall Jamie Zawinski
2198
+ Patrik Faltstrom Bill Manning Timothy S. Zurcher
2199
+ Claus Andre Farber John Martin
2200
+
2201
+
2202
+
2203
+
2204
+
2205
+
2206
+
2207
+
2208
+
2209
+
2210
+
2211
+
2212
+
2213
+
2214
+
2215
+
2216
+
2217
+
2218
+
2219
+
2220
+
2221
+
2222
+
2223
+
2224
+
2225
+
2226
+
2227
+
2228
+
2229
+
2230
+
2231
+
2232
+
2233
+
2234
+
2235
+
2236
+
2237
+
2238
+
2239
+
2240
+
2241
+
2242
+ Resnick Standards Track [Page 40]
2243
+
2244
+ RFC 2822 Internet Message Format April 2001
2245
+
2246
+
2247
+ Appendix A. Example messages
2248
+
2249
+ This section presents a selection of messages. These are intended to
2250
+ assist in the implementation of this standard, but should not be
2251
+ taken as normative; that is to say, although the examples in this
2252
+ section were carefully reviewed, if there happens to be a conflict
2253
+ between these examples and the syntax described in sections 3 and 4
2254
+ of this document, the syntax in those sections is to be taken as
2255
+ correct.
2256
+
2257
+ Messages are delimited in this section between lines of "----". The
2258
+ "----" lines are not part of the message itself.
2259
+
2260
+ A.1. Addressing examples
2261
+
2262
+ The following are examples of messages that might be sent between two
2263
+ individuals.
2264
+
2265
+ A.1.1. A message from one person to another with simple addressing
2266
+
2267
+ This could be called a canonical message. It has a single author,
2268
+ John Doe, a single recipient, Mary Smith, a subject, the date, a
2269
+ message identifier, and a textual message in the body.
2270
+
2271
+ ----
2272
+ From: John Doe <jdoe@machine.example>
2273
+ To: Mary Smith <mary@example.net>
2274
+ Subject: Saying Hello
2275
+ Date: Fri, 21 Nov 1997 09:55:06 -0600
2276
+ Message-ID: <1234@local.machine.example>
2277
+
2278
+ This is a message just to say hello.
2279
+ So, "Hello".
2280
+ ----
2281
+
2282
+
2283
+
2284
+
2285
+
2286
+
2287
+
2288
+
2289
+
2290
+
2291
+
2292
+
2293
+
2294
+
2295
+
2296
+
2297
+
2298
+ Resnick Standards Track [Page 41]
2299
+
2300
+ RFC 2822 Internet Message Format April 2001
2301
+
2302
+
2303
+ If John's secretary Michael actually sent the message, though John
2304
+ was the author and replies to this message should go back to him, the
2305
+ sender field would be used:
2306
+
2307
+ ----
2308
+ From: John Doe <jdoe@machine.example>
2309
+ Sender: Michael Jones <mjones@machine.example>
2310
+ To: Mary Smith <mary@example.net>
2311
+ Subject: Saying Hello
2312
+ Date: Fri, 21 Nov 1997 09:55:06 -0600
2313
+ Message-ID: <1234@local.machine.example>
2314
+
2315
+ This is a message just to say hello.
2316
+ So, "Hello".
2317
+ ----
2318
+
2319
+ A.1.2. Different types of mailboxes
2320
+
2321
+ This message includes multiple addresses in the destination fields
2322
+ and also uses several different forms of addresses.
2323
+
2324
+ ----
2325
+ From: "Joe Q. Public" <john.q.public@example.com>
2326
+ To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
2327
+ Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
2328
+ Date: Tue, 1 Jul 2003 10:52:37 +0200
2329
+ Message-ID: <5678.21-Nov-1997@example.com>
2330
+
2331
+ Hi everyone.
2332
+ ----
2333
+
2334
+ Note that the display names for Joe Q. Public and Giant; "Big" Box
2335
+ needed to be enclosed in double-quotes because the former contains
2336
+ the period and the latter contains both semicolon and double-quote
2337
+ characters (the double-quote characters appearing as quoted-pair
2338
+ construct). Conversely, the display name for Who? could appear
2339
+ without them because the question mark is legal in an atom. Notice
2340
+ also that jdoe@example.org and boss@nil.test have no display names
2341
+ associated with them at all, and jdoe@example.org uses the simpler
2342
+ address form without the angle brackets.
2343
+
2344
+
2345
+
2346
+
2347
+
2348
+
2349
+
2350
+
2351
+
2352
+
2353
+
2354
+ Resnick Standards Track [Page 42]
2355
+
2356
+ RFC 2822 Internet Message Format April 2001
2357
+
2358
+
2359
+ A.1.3. Group addresses
2360
+
2361
+ ----
2362
+ From: Pete <pete@silly.example>
2363
+ To: A Group:Chris Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
2364
+ Cc: Undisclosed recipients:;
2365
+ Date: Thu, 13 Feb 1969 23:32:54 -0330
2366
+ Message-ID: <testabcd.1234@silly.example>
2367
+
2368
+ Testing.
2369
+ ----
2370
+
2371
+ In this message, the "To:" field has a single group recipient named A
2372
+ Group which contains 3 addresses, and a "Cc:" field with an empty
2373
+ group recipient named Undisclosed recipients.
2374
+
2375
+ A.2. Reply messages
2376
+
2377
+ The following is a series of three messages that make up a
2378
+ conversation thread between John and Mary. John firsts sends a
2379
+ message to Mary, Mary then replies to John's message, and then John
2380
+ replies to Mary's reply message.
2381
+
2382
+ Note especially the "Message-ID:", "References:", and "In-Reply-To:"
2383
+ fields in each message.
2384
+
2385
+ ----
2386
+ From: John Doe <jdoe@machine.example>
2387
+ To: Mary Smith <mary@example.net>
2388
+ Subject: Saying Hello
2389
+ Date: Fri, 21 Nov 1997 09:55:06 -0600
2390
+ Message-ID: <1234@local.machine.example>
2391
+
2392
+ This is a message just to say hello.
2393
+ So, "Hello".
2394
+ ----
2395
+
2396
+
2397
+
2398
+
2399
+
2400
+
2401
+
2402
+
2403
+
2404
+
2405
+
2406
+
2407
+
2408
+
2409
+
2410
+ Resnick Standards Track [Page 43]
2411
+
2412
+ RFC 2822 Internet Message Format April 2001
2413
+
2414
+
2415
+ When sending replies, the Subject field is often retained, though
2416
+ prepended with "Re: " as described in section 3.6.5.
2417
+
2418
+ ----
2419
+ From: Mary Smith <mary@example.net>
2420
+ To: John Doe <jdoe@machine.example>
2421
+ Reply-To: "Mary Smith: Personal Account" <smith@home.example>
2422
+ Subject: Re: Saying Hello
2423
+ Date: Fri, 21 Nov 1997 10:01:10 -0600
2424
+ Message-ID: <3456@example.net>
2425
+ In-Reply-To: <1234@local.machine.example>
2426
+ References: <1234@local.machine.example>
2427
+
2428
+ This is a reply to your hello.
2429
+ ----
2430
+
2431
+ Note the "Reply-To:" field in the above message. When John replies
2432
+ to Mary's message above, the reply should go to the address in the
2433
+ "Reply-To:" field instead of the address in the "From:" field.
2434
+
2435
+ ----
2436
+ To: "Mary Smith: Personal Account" <smith@home.example>
2437
+ From: John Doe <jdoe@machine.example>
2438
+ Subject: Re: Saying Hello
2439
+ Date: Fri, 21 Nov 1997 11:00:00 -0600
2440
+ Message-ID: <abcd.1234@local.machine.tld>
2441
+ In-Reply-To: <3456@example.net>
2442
+ References: <1234@local.machine.example> <3456@example.net>
2443
+
2444
+ This is a reply to your reply.
2445
+ ----
2446
+
2447
+ A.3. Resent messages
2448
+
2449
+ Start with the message that has been used as an example several
2450
+ times:
2451
+
2452
+ ----
2453
+ From: John Doe <jdoe@machine.example>
2454
+ To: Mary Smith <mary@example.net>
2455
+ Subject: Saying Hello
2456
+ Date: Fri, 21 Nov 1997 09:55:06 -0600
2457
+ Message-ID: <1234@local.machine.example>
2458
+
2459
+ This is a message just to say hello.
2460
+ So, "Hello".
2461
+ ----
2462
+
2463
+
2464
+
2465
+
2466
+ Resnick Standards Track [Page 44]
2467
+
2468
+ RFC 2822 Internet Message Format April 2001
2469
+
2470
+
2471
+ Say that Mary, upon receiving this message, wishes to send a copy of
2472
+ the message to Jane such that (a) the message would appear to have
2473
+ come straight from John; (b) if Jane replies to the message, the
2474
+ reply should go back to John; and (c) all of the original
2475
+ information, like the date the message was originally sent to Mary,
2476
+ the message identifier, and the original addressee, is preserved. In
2477
+ this case, resent fields are prepended to the message:
2478
+
2479
+ ----
2480
+ Resent-From: Mary Smith <mary@example.net>
2481
+ Resent-To: Jane Brown <j-brown@other.example>
2482
+ Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
2483
+ Resent-Message-ID: <78910@example.net>
2484
+ From: John Doe <jdoe@machine.example>
2485
+ To: Mary Smith <mary@example.net>
2486
+ Subject: Saying Hello
2487
+ Date: Fri, 21 Nov 1997 09:55:06 -0600
2488
+ Message-ID: <1234@local.machine.example>
2489
+
2490
+ This is a message just to say hello.
2491
+ So, "Hello".
2492
+ ----
2493
+
2494
+ If Jane, in turn, wished to resend this message to another person,
2495
+ she would prepend her own set of resent header fields to the above
2496
+ and send that.
2497
+
2498
+
2499
+
2500
+
2501
+
2502
+
2503
+
2504
+
2505
+
2506
+
2507
+
2508
+
2509
+
2510
+
2511
+
2512
+
2513
+
2514
+
2515
+
2516
+
2517
+
2518
+
2519
+
2520
+
2521
+
2522
+ Resnick Standards Track [Page 45]
2523
+
2524
+ RFC 2822 Internet Message Format April 2001
2525
+
2526
+
2527
+ A.4. Messages with trace fields
2528
+
2529
+ As messages are sent through the transport system as described in
2530
+ [RFC2821], trace fields are prepended to the message. The following
2531
+ is an example of what those trace fields might look like. Note that
2532
+ there is some folding white space in the first one since these lines
2533
+ can be long.
2534
+
2535
+ ----
2536
+ Received: from x.y.test
2537
+ by example.net
2538
+ via TCP
2539
+ with ESMTP
2540
+ id ABC12345
2541
+ for <mary@example.net>; 21 Nov 1997 10:05:43 -0600
2542
+ Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
2543
+ From: John Doe <jdoe@machine.example>
2544
+ To: Mary Smith <mary@example.net>
2545
+ Subject: Saying Hello
2546
+ Date: Fri, 21 Nov 1997 09:55:06 -0600
2547
+ Message-ID: <1234@local.machine.example>
2548
+
2549
+ This is a message just to say hello.
2550
+ So, "Hello".
2551
+ ----
2552
+
2553
+
2554
+
2555
+
2556
+
2557
+
2558
+
2559
+
2560
+
2561
+
2562
+
2563
+
2564
+
2565
+
2566
+
2567
+
2568
+
2569
+
2570
+
2571
+
2572
+
2573
+
2574
+
2575
+
2576
+
2577
+
2578
+ Resnick Standards Track [Page 46]
2579
+
2580
+ RFC 2822 Internet Message Format April 2001
2581
+
2582
+
2583
+ A.5. White space, comments, and other oddities
2584
+
2585
+ White space, including folding white space, and comments can be
2586
+ inserted between many of the tokens of fields. Taking the example
2587
+ from A.1.3, white space and comments can be inserted into all of the
2588
+ fields.
2589
+
2590
+ ----
2591
+ From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
2592
+ To:A Group(Some people)
2593
+ :Chris Jones <c@(Chris's host.)public.example>,
2594
+ joe@example.org,
2595
+ John <jdoe@one.test> (my dear friend); (the end of the group)
2596
+ Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ;
2597
+ Date: Thu,
2598
+ 13
2599
+ Feb
2600
+ 1969
2601
+ 23:32
2602
+ -0330 (Newfoundland Time)
2603
+ Message-ID: <testabcd.1234@silly.test>
2604
+
2605
+ Testing.
2606
+ ----
2607
+
2608
+ The above example is aesthetically displeasing, but perfectly legal.
2609
+ Note particularly (1) the comments in the "From:" field (including
2610
+ one that has a ")" character appearing as part of a quoted-pair); (2)
2611
+ the white space absent after the ":" in the "To:" field as well as
2612
+ the comment and folding white space after the group name, the special
2613
+ character (".") in the comment in Chris Jones's address, and the
2614
+ folding white space before and after "joe@example.org,"; (3) the
2615
+ multiple and nested comments in the "Cc:" field as well as the
2616
+ comment immediately following the ":" after "Cc"; (4) the folding
2617
+ white space (but no comments except at the end) and the missing
2618
+ seconds in the time of the date field; and (5) the white space before
2619
+ (but not within) the identifier in the "Message-ID:" field.
2620
+
2621
+ A.6. Obsoleted forms
2622
+
2623
+ The following are examples of obsolete (that is, the "MUST NOT
2624
+ generate") syntactic elements described in section 4 of this
2625
+ document.
2626
+
2627
+
2628
+
2629
+
2630
+
2631
+
2632
+
2633
+
2634
+ Resnick Standards Track [Page 47]
2635
+
2636
+ RFC 2822 Internet Message Format April 2001
2637
+
2638
+
2639
+ A.6.1. Obsolete addressing
2640
+
2641
+ Note in the below example the lack of quotes around Joe Q. Public,
2642
+ the route that appears in the address for Mary Smith, the two commas
2643
+ that appear in the "To:" field, and the spaces that appear around the
2644
+ "." in the jdoe address.
2645
+
2646
+ ----
2647
+ From: Joe Q. Public <john.q.public@example.com>
2648
+ To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example
2649
+ Date: Tue, 1 Jul 2003 10:52:37 +0200
2650
+ Message-ID: <5678.21-Nov-1997@example.com>
2651
+
2652
+ Hi everyone.
2653
+ ----
2654
+
2655
+ A.6.2. Obsolete dates
2656
+
2657
+ The following message uses an obsolete date format, including a non-
2658
+ numeric time zone and a two digit year. Note that although the
2659
+ day-of-week is missing, that is not specific to the obsolete syntax;
2660
+ it is optional in the current syntax as well.
2661
+
2662
+ ----
2663
+ From: John Doe <jdoe@machine.example>
2664
+ To: Mary Smith <mary@example.net>
2665
+ Subject: Saying Hello
2666
+ Date: 21 Nov 97 09:55:06 GMT
2667
+ Message-ID: <1234@local.machine.example>
2668
+
2669
+ This is a message just to say hello.
2670
+ So, "Hello".
2671
+ ----
2672
+
2673
+ A.6.3. Obsolete white space and comments
2674
+
2675
+ White space and comments can appear between many more elements than
2676
+ in the current syntax. Also, folding lines that are made up entirely
2677
+ of white space are legal.
2678
+
2679
+
2680
+
2681
+
2682
+
2683
+
2684
+
2685
+
2686
+
2687
+
2688
+
2689
+
2690
+ Resnick Standards Track [Page 48]
2691
+
2692
+ RFC 2822 Internet Message Format April 2001
2693
+
2694
+
2695
+ ----
2696
+ From : John Doe <jdoe@machine(comment). example>
2697
+ To : Mary Smith
2698
+ __
2699
+ <mary@example.net>
2700
+ Subject : Saying Hello
2701
+ Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
2702
+ Message-ID : <1234 @ local(blah) .machine .example>
2703
+
2704
+ This is a message just to say hello.
2705
+ So, "Hello".
2706
+ ----
2707
+
2708
+ Note especially the second line of the "To:" field. It starts with
2709
+ two space characters. (Note that "__" represent blank spaces.)
2710
+ Therefore, it is considered part of the folding as described in
2711
+ section 4.2. Also, the comments and white space throughout
2712
+ addresses, dates, and message identifiers are all part of the
2713
+ obsolete syntax.
2714
+
2715
+ Appendix B. Differences from earlier standards
2716
+
2717
+ This appendix contains a list of changes that have been made in the
2718
+ Internet Message Format from earlier standards, specifically [RFC822]
2719
+ and [STD3]. Items marked with an asterisk (*) below are items which
2720
+ appear in section 4 of this document and therefore can no longer be
2721
+ generated.
2722
+
2723
+ 1. Period allowed in obsolete form of phrase.
2724
+ 2. ABNF moved out of document to [RFC2234].
2725
+ 3. Four or more digits allowed for year.
2726
+ 4. Header field ordering (and lack thereof) made explicit.
2727
+ 5. Encrypted header field removed.
2728
+ 6. Received syntax loosened to allow any token/value pair.
2729
+ 7. Specifically allow and give meaning to "-0000" time zone.
2730
+ 8. Folding white space is not allowed between every token.
2731
+ 9. Requirement for destinations removed.
2732
+ 10. Forwarding and resending redefined.
2733
+ 11. Extension header fields no longer specifically called out.
2734
+ 12. ASCII 0 (null) removed.*
2735
+ 13. Folding continuation lines cannot contain only white space.*
2736
+ 14. Free insertion of comments not allowed in date.*
2737
+ 15. Non-numeric time zones not allowed.*
2738
+ 16. Two digit years not allowed.*
2739
+ 17. Three digit years interpreted, but not allowed for generation.
2740
+ 18. Routes in addresses not allowed.*
2741
+ 19. CFWS within local-parts and domains not allowed.*
2742
+ 20. Empty members of address lists not allowed.*
2743
+
2744
+
2745
+
2746
+ Resnick Standards Track [Page 49]
2747
+
2748
+ RFC 2822 Internet Message Format April 2001
2749
+
2750
+
2751
+ 21. Folding white space between field name and colon not allowed.*
2752
+ 22. Comments between field name and colon not allowed.
2753
+ 23. Tightened syntax of in-reply-to and references.*
2754
+ 24. CFWS within msg-id not allowed.*
2755
+ 25. Tightened semantics of resent fields as informational only.
2756
+ 26. Resent-Reply-To not allowed.*
2757
+ 27. No multiple occurrences of fields (except resent and received).*
2758
+ 28. Free CR and LF not allowed.*
2759
+ 29. Routes in return path not allowed.*
2760
+ 30. Line length limits specified.
2761
+ 31. Bcc more clearly specified.
2762
+
2763
+ Appendix C. Notices
2764
+
2765
+ Intellectual Property
2766
+
2767
+ The IETF takes no position regarding the validity or scope of any
2768
+ intellectual property or other rights that might be claimed to
2769
+ pertain to the implementation or use of the technology described in
2770
+ this document or the extent to which any license under such rights
2771
+ might or might not be available; neither does it represent that it
2772
+ has made any effort to identify any such rights. Information on the
2773
+ IETF's procedures with respect to rights in standards-track and
2774
+ standards-related documentation can be found in BCP-11. Copies of
2775
+ claims of rights made available for publication and any assurances of
2776
+ licenses to be made available, or the result of an attempt made to
2777
+ obtain a general license or permission for the use of such
2778
+ proprietary rights by implementors or users of this specification can
2779
+ be obtained from the IETF Secretariat.
2780
+
2781
+
2782
+
2783
+
2784
+
2785
+
2786
+
2787
+
2788
+
2789
+
2790
+
2791
+
2792
+
2793
+
2794
+
2795
+
2796
+
2797
+
2798
+
2799
+
2800
+
2801
+
2802
+ Resnick Standards Track [Page 50]
2803
+
2804
+ RFC 2822 Internet Message Format April 2001
2805
+
2806
+
2807
+ Full Copyright Statement
2808
+
2809
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
2810
+
2811
+ This document and translations of it may be copied and furnished to
2812
+ others, and derivative works that comment on or otherwise explain it
2813
+ or assist in its implementation may be prepared, copied, published
2814
+ and distributed, in whole or in part, without restriction of any
2815
+ kind, provided that the above copyright notice and this paragraph are
2816
+ included on all such copies and derivative works. However, this
2817
+ document itself may not be modified in any way, such as by removing
2818
+ the copyright notice or references to the Internet Society or other
2819
+ Internet organizations, except as needed for the purpose of
2820
+ developing Internet standards in which case the procedures for
2821
+ copyrights defined in the Internet Standards process must be
2822
+ followed, or as required to translate it into languages other than
2823
+ English.
2824
+
2825
+ The limited permissions granted above are perpetual and will not be
2826
+ revoked by the Internet Society or its successors or assigns.
2827
+
2828
+ This document and the information contained herein is provided on an
2829
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2830
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2831
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2832
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2833
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2834
+
2835
+ Acknowledgement
2836
+
2837
+ Funding for the RFC Editor function is currently provided by the
2838
+ Internet Society.
2839
+
2840
+
2841
+
2842
+
2843
+
2844
+
2845
+
2846
+
2847
+
2848
+
2849
+
2850
+
2851
+
2852
+
2853
+
2854
+
2855
+
2856
+
2857
+
2858
+ Resnick Standards Track [Page 51]
2859
+