git.fiddlerwoaroof.com
Browse code

Merge remote-tracking branch 'franz/master'

Ed Langley authored on 16/09/2018 17:59:18
Showing 13 changed files
LICENSE
History View file @ 107577b
1 1 
new file mode 100644
... ... 
@@ -0,0 +1,18 @@
1 
+copyright (c) 2016 Franz Inc., Oakland, CA - All rights reserved.
2 
+
3 
+This code is free software; you can redistribute it and/or modify it
4 
+under the terms of the version 2.1 of the GNU Lesser General Public
5 
+License as published by the Free Software Foundation, as clarified by
6 
+the AllegroServe prequel found in license-allegroserve.txt.
7 
+
8 
+This code is distributed in the hope that it will be useful, but
9 
+without any warranty; without even the implied warranty of
10 
+merchantability or fitness for a particular purpose.  See the GNU
11 
+Lesser General Public License for more details.
12 
+
13 
+Version 2.1 of the GNU Lesser General Public License is in the file
14 
+license-lgpl.txt that was distributed with this file.  If it is not
15 
+present, you can access it from http://www.gnu.org/copyleft/lesser.txt
16 
+(until superseded by a newer version) or write to the Free Software
17 
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
18 
+USA
Makefile
History View file @ 107577b
... ... 
@@ -1,4 +1,3 @@
1 
-# $Id: Makefile,v 1.2 2000/05/27 04:53:08 duane Exp $
2 1
3 2 
 SHELL = sh
4 3
imap.cl
History View file @ 107577b
... ... 
@@ -1,3 +1,10 @@
1 
+;; -*- mode: common-lisp; package: net.post-office -*-
2 
+;;
3 
+;; imap.cl
4 
+;; imap and pop interface
5 
+;;
6 
+;; See the file LICENSE for the full license governing this code.
7 
+
1 8 
 #+(version= 7 0)
2 9 
 (sys:defpatch "imap" 1
3 10 
   "v1: fetch-letter-sequence support."
... ... 
@@ -16,27 +23,6 @@
16 23 
   :type :system
17 24 
   :post-loadable t)
18 25
19 
-;; -*- mode: common-lisp; package: net.post-office -*-
20 
-;;
21 
-;; imap.cl
22 
-;; imap and pop interface
23 
-;;
24 
-;; copyright (c) 1999-2002 Franz Inc, Berkeley, CA - All rights reserved.
25 
-;; copyright (c) 2002-2012 Franz Inc, Oakland, CA - All rights reserved.
26 
-;;
27 
-;; This code is free software; you can redistribute it and/or
28 
-;; modify it under the terms of the version 2.1 of
29 
-;; the GNU Lesser General Public License as published by
30 
-;; the Free Software Foundation, as clarified by the AllegroServe
31 
-;; prequel found in license-allegroserve.txt.
32 
-;;
33 
-;; This code is distributed in the hope that it will be useful,
34 
-;; but without any warranty; without even the implied warranty of
35 
-;; merchantability or fitness for a particular purpose.  See the GNU
36 
-;; Lesser General Public License for more details.
37 
-;;
38 
-;; $Id: imap.cl,v 1.32 2009/03/25 22:46:02 layer Exp $
39 
-
40 26 
 ;; Description:
41 27 
 ;;- This code in this file obeys the Lisp Coding Standard found in
42 28 
 ;;- http://www.franz.com/~jkf/coding_standards.html
imap.html
History View file @ 107577b
... ... 
@@ -9,7 +9,7 @@
9 9
10 10 
 <h1 align="center">Allegro CL imap and pop interface</h1>
11 11
12 
-<p align="left">copyright (c) 1999 Franz Inc.</p>
12 
+<p align="left">copyright (c) Franz Inc.</p>
13 13
14 14 
 <p align="left">&nbsp;</p>
15 15
mime-api.cl
History View file @ 107577b
... ... 
@@ -21,21 +21,8 @@ v3: add mime structure parsing support."
21 21 
 ;; imap.cl
22 22 
 ;; imap and pop interface
23 23 
 ;;
24 
-;; copyright (c) 1999-2002 Franz Inc, Berkeley, CA - All rights reserved.
25 
-;; copyright (c) 2002-2012 Franz Inc, Oakland, CA - All rights reserved.
24 
+;; See the file LICENSE for the full license governing this code.
26 25 
 ;;
27 
-;; This code is free software; you can redistribute it and/or
28 
-;; modify it under the terms of the version 2.1 of
29 
-;; the GNU Lesser General Public License as published by
30 
-;; the Free Software Foundation, as clarified by the AllegroServe
31 
-;; prequel found in license-allegroserve.txt.
32 
-;;
33 
-;; This code is distributed in the hope that it will be useful,
34 
-;; but without any warranty; without even the implied warranty of
35 
-;; merchantability or fitness for a particular purpose.  See the GNU
36 
-;; Lesser General Public License for more details.
37 
-;;
38 
-;; $Id: mime-api.cl,v 1.11 2008/11/20 21:30:12 layer Exp $
39 26
40 27 
 (defpackage :net.post-office
41 28 
   (:use #:lisp #:excl)
mime-parse.cl
History View file @ 107577b
... ... 
@@ -1,20 +1,7 @@
1 1 
 ;; -*- mode: common-lisp; package: net.post-office -*-
2 2 
 ;;
3 
-;; copyright (c) 1999-2002 Franz Inc, Berkeley, CA - All rights reserved.
4 
-;; copyright (c) 2002-2012 Franz Inc, Oakland, CA - All rights reserved.
3 
+;; See the file LICENSE for the full license governing this code.
5 4 
 ;;
6 
-;; This code is free software; you can redistribute it and/or
7 
-;; modify it under the terms of the version 2.1 of
8 
-;; the GNU Lesser General Public License as published by
9 
-;; the Free Software Foundation, as clarified by the AllegroServe
10 
-;; prequel found in license-allegroserve.txt.
11 
-;;
12 
-;; This code is distributed in the hope that it will be useful,
13 
-;; but without any warranty; without even the implied warranty of
14 
-;; merchantability or fitness for a particular purpose.  See the GNU
15 
-;; Lesser General Public License for more details.
16 
-;;
17 
-;; $Id: mime-parse.cl,v 1.8 2008/05/21 21:01:56 layer Exp $
18 5
19 6 
 (defpackage :net.post-office
20 7 
   (:use #:lisp #:excl)
mime-transfer-encoding.cl
History View file @ 107577b
... ... 
@@ -1,20 +1,7 @@
1 1 
 ;; -*- mode: common-lisp; package: net.post-office -*-
2 2 
 ;;
3 
-;; copyright (c) 1999-2002 Franz Inc, Berkeley, CA - All rights reserved.
4 
-;; copyright (c) 2002-2012 Franz Inc, Oakland, CA - All rights reserved.
3 
+;; See the file LICENSE for the full license governing this code.
5 4 
 ;;
6 
-;; This code is free software; you can redistribute it and/or
7 
-;; modify it under the terms of the version 2.1 of
8 
-;; the GNU Lesser General Public License as published by
9 
-;; the Free Software Foundation, as clarified by the AllegroServe
10 
-;; prequel found in license-allegroserve.txt.
11 
-;;
12 
-;; This code is distributed in the hope that it will be useful,
13 
-;; but without any warranty; without even the implied warranty of
14 
-;; merchantability or fitness for a particular purpose.  See the GNU
15 
-;; Lesser General Public License for more details.
16 
-;;
17 
-;; $Id: mime-transfer-encoding.cl,v 1.14 2007/08/02 18:14:31 layer Exp $
18 5
19 6 
 (defpackage :net.post-office
20 7 
   (:use #:lisp #:excl)
rfc1939.html
History View file @ 107577b
21 8 
similarity index 82%
22 9 
rename from rfc1939.html
23 10 
rename to rfc1939.txt
... ... 
@@ -1,12 +1,3 @@
1 
-<HEAD>
2 
-<TITLE>rfc1939</TITLE>
3 
-</HEAD>
4 
-
5 
-<H1>rfc1939</H1>
6 
-Press <A NAME=id1 HREF="http://www.cis.ohio-state.edu/hypertext/information/rfc.html">here</A>
7 
-to go to the top of the rfc 'tree'.<p>
8 
-
9 
-<PRE>
10 1
11 2
12 3
... ... 
@@ -14,10 +5,10 @@ to go to the top of the rfc 'tree'.<p>
14 5
15 6
16 7 
 Network Working Group                                           J. Myers
17 
-Request for Comments: <A NAME=id18 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                               Carnegie Mellon
8 
+Request for Comments: 1939                               Carnegie Mellon
18 9 
 STD: 53                                                          M. Rose
19 
-Obsoletes: <A NAME=id22 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>                             Dover Beach Consulting, Inc.
20 
-Category: Standards Track                                       May <A NAME=id24 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1996.html">1996</A>
10 
+Obsoletes: 1725                             Dover Beach Consulting, Inc.
11 
+Category: Standards Track                                       May 1996
21 12
22 13
23 14 
                     Post Office Protocol - Version 3
... ... 
@@ -60,13 +51,13 @@ Table of Contents
60 51 
    13. Security Considerations ....................................   20
61 52 
    14. Acknowledgements ...........................................   20
62 53 
    15. Authors' Addresses .........................................   21
63 
-   Appendix A. Differences from RFC <A NAME=id111 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A> ..........................   22
54 
+   Appendix A. Differences from RFC 1725 ..........................   22
64 55
65 56
66 57
67 
-Myers &#38; Rose                Standards Track                     [Page 1]
58 
+Myers & Rose                Standards Track                     [Page 1]
68 59
69 
-RFC <A NAME=id123 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
60 
+RFC 1939                          POP3                          May 1996
70 61
71 62
72 63 
    Appendix B. Command Index ......................................   23
... ... 
@@ -76,7 +67,7 @@ RFC <A NAME=id123 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
76 67 
    On certain types of smaller nodes in the Internet it is often
77 68 
    impractical to maintain a message transport system (MTS).  For
78 69 
    example, a workstation may not have sufficient resources (cycles,
79 
-   disk space) in order to permit a SMTP server [RFC<A NAME=id144 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html">821</A>] and associated
70 
+   disk space) in order to permit a SMTP server [RFC821] and associated
80 71 
    local mail delivery system to be kept resident and continuously
81 72 
    running.  Similarly, it may be expensive (or impossible) to keep a
82 73 
    personal computer interconnected to an IP-style network for long
... ... 
@@ -96,7 +87,7 @@ RFC <A NAME=id123 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
96 87 
    POP3 is not intended to provide extensive manipulation operations of
97 88 
    mail on the server; normally, mail is downloaded and then deleted.  A
98 89 
    more advanced (and complex) protocol, IMAP4, is discussed in
99 
-   [RFC<A NAME=id185 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>].
90 
+   [RFC1730].
100 91
101 92 
    For the remainder of this memo, the term "client host" refers to a
102 93 
    host making use of the POP3 service, while the term "server host"
... ... 
@@ -120,9 +111,9 @@ RFC <A NAME=id123 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
120 111
121 112
122 113
123 
-Myers &#38; Rose                Standards Track                     [Page 2]
114 
+Myers & Rose                Standards Track                     [Page 2]
124 115
125 
-RFC <A NAME=id237 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
116 
+RFC 1939                          POP3                          May 1996
126 117
127 118
128 119 
 3. Basic Operation
... ... 
@@ -176,9 +167,9 @@ RFC <A NAME=id237 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
176 167
177 168
178 169
179 
-Myers &#38; Rose                Standards Track                     [Page 3]
170 
+Myers & Rose                Standards Track                     [Page 3]
180 171
181 
-RFC <A NAME=id349 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
172 
+RFC 1939                          POP3                          May 1996
182 173
183 174
184 175 
    issued the QUIT command, the session enters the UPDATE state.  In
... ... 
@@ -214,7 +205,7 @@ RFC <A NAME=id349 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
214 205 
    possible mechanisms for doing this are described in this document,
215 206 
    the USER and PASS command combination and the APOP command.  Both
216 207 
    mechanisms are described later in this document.  Additional
217 
-   authentication mechanisms are described in [RFC<A NAME=id422 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>].  While there is
208 
+   authentication mechanisms are described in [RFC1734].  While there is
218 209 
    no single authentication mechanism that is required of all POP3
219 210 
    servers, a POP3 server must of course support at least one
220 211 
    authentication mechanism.
... ... 
@@ -232,9 +223,9 @@ RFC <A NAME=id349 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
232 223
233 224
234 225
235 
-Myers &#38; Rose                Standards Track                     [Page 4]
226 
+Myers & Rose                Standards Track                     [Page 4]
236 227
237 
-RFC <A NAME=id462 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
228 
+RFC 1939                          POP3                          May 1996
238 229
239 230
240 231 
    maildrop, or the maildrop cannot be parsed), the POP3 server responds
... ... 
@@ -288,9 +279,9 @@ RFC <A NAME=id462 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
288 279
289 280
290 281
291 
-Myers &#38; Rose                Standards Track                     [Page 5]
282 
+Myers & Rose                Standards Track                     [Page 5]
292 283
293 
-RFC <A NAME=id574 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
284 
+RFC 1939                          POP3                          May 1996
294 285
295 286
296 287 
    Here are the POP3 commands valid in the TRANSACTION state:
... ... 
@@ -344,9 +335,9 @@ RFC <A NAME=id574 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
344 335
345 336
346 337
347 
-Myers &#38; Rose                Standards Track                     [Page 6]
338 
+Myers & Rose                Standards Track                     [Page 6]
348 339
349 
-RFC <A NAME=id686 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
340 
+RFC 1939                          POP3                          May 1996
350 341
351 342
352 343 
          Restrictions:
... ... 
@@ -400,9 +391,9 @@ RFC <A NAME=id686 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
400 391
401 392
402 393
403 
-Myers &#38; Rose                Standards Track                     [Page 7]
394 
+Myers & Rose                Standards Track                     [Page 7]
404 395
405 
-RFC <A NAME=id798 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
396 
+RFC 1939                          POP3                          May 1996
406 397
407 398
408 399 
              S: 2 200
... ... 
@@ -438,7 +429,7 @@ RFC <A NAME=id798 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
438 429 
          Examples:
439 430 
              C: RETR 1
440 431 
              S: +OK 120 octets
441 
-             S: &#60;the POP3 server sends the entire message here&#62;
432 
+             S: <the POP3 server sends the entire message here>
442 433 
              S: .
443 434
444 435
... ... 
@@ -456,9 +447,9 @@ RFC <A NAME=id798 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
456 447
457 448
458 449
459 
-Myers &#38; Rose                Standards Track                     [Page 8]
450 
+Myers & Rose                Standards Track                     [Page 8]
460 451
461 
-RFC <A NAME=id910 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
452 
+RFC 1939                          POP3                          May 1996
462 453
463 454
464 455 
          Discussion:
... ... 
@@ -512,9 +503,9 @@ RFC <A NAME=id910 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">19
512 503
513 504
514 505
515 
-Myers &#38; Rose                Standards Track                     [Page 9]
506 
+Myers & Rose                Standards Track                     [Page 9]
516 507
517 
-RFC <A NAME=id1022 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
508 
+RFC 1939                          POP3                          May 1996
518 509
519 510
520 511 
              with a positive response.
... ... 
@@ -568,9 +559,9 @@ RFC <A NAME=id1022 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
568 559
569 560
570 561
571 
-Myers &#38; Rose                Standards Track                    [Page 10]
562 
+Myers & Rose                Standards Track                    [Page 10]
572 563
573 
-RFC <A NAME=id1134 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
564 
+RFC 1939                          POP3                          May 1996
574 565
575 566
576 567 
              S: +OK dewey POP3 server signing off (2 messages left)
... ... 
@@ -624,14 +615,14 @@ RFC <A NAME=id1134 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
624 615
625 616
626 617
627 
-Myers &#38; Rose                Standards Track                    [Page 11]
618 
+Myers & Rose                Standards Track                    [Page 11]
628 619
629 
-RFC <A NAME=id1246 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
620 
+RFC 1939                          POP3                          May 1996
630 621
631 622
632 
-             S: &#60;the POP3 server sends the headers of the
623 
+             S: <the POP3 server sends the headers of the
633 624 
                 message, a blank line, and the first 10 lines
634 
-                of the body of the message&#62;
625 
+                of the body of the message>
635 626 
              S: .
636 627 
                 ...
637 628 
              C: TOP 100 3
... ... 
@@ -680,9 +671,9 @@ RFC <A NAME=id1246 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
680 671
681 672
682 673
683 
-Myers &#38; Rose                Standards Track                    [Page 12]
674 
+Myers & Rose                Standards Track                    [Page 12]
684 675
685 
-RFC <A NAME=id1358 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
676 
+RFC 1939                          POP3                          May 1996
686 677
687 678
688 679 
           this specification is intended to permit unique-ids to be
... ... 
@@ -736,9 +727,9 @@ RFC <A NAME=id1358 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
736 727
737 728
738 729
739 
-Myers &#38; Rose                Standards Track                    [Page 13]
730 
+Myers & Rose                Standards Track                    [Page 13]
740 731
741 
-RFC <A NAME=id1470 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
732 
+RFC 1939                          POP3                          May 1996
742 733
743 734
744 735 
              password authentication.
... ... 
@@ -792,9 +783,9 @@ RFC <A NAME=id1470 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
792 783
793 784
794 785
795 
-Myers &#38; Rose                Standards Track                    [Page 14]
786 
+Myers & Rose                Standards Track                    [Page 14]
796 787
797 
-RFC <A NAME=id1582 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
788 
+RFC 1939                          POP3                          May 1996
798 789
799 790
800 791 
       APOP name digest
... ... 
@@ -826,13 +817,13 @@ RFC <A NAME=id1582 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
826 817
827 818 
              A POP3 server which implements the APOP command will
828 819 
              include a timestamp in its banner greeting.  The syntax of
829 
-             the timestamp corresponds to the `msg-id' in [RFC<A NAME=id1647 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>], and
820 
+             the timestamp corresponds to the `msg-id' in [RFC822], and
830 821 
              MUST be different each time the POP3 server issues a banner
831 822 
              greeting.  For example, on a UNIX implementation in which a
832 823 
              separate UNIX process is used for each instance of a POP3
833 824 
              server, the syntax of the timestamp might be:
834 825
835 
-                &#60;process-ID.clock@hostname&#62;
826 
+                <process-ID.clock@hostname>
836 827
837 828 
              where `process-ID' is the decimal value of the process's
838 829 
              PID, clock is the decimal value of the system clock, and
... ... 
@@ -843,14 +834,14 @@ RFC <A NAME=id1582 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
843 834 
              issues the APOP command.  The `name' parameter has
844 835 
              identical semantics to the `name' parameter of the USER
845 836 
              command. The `digest' parameter is calculated by applying
846 
-             the MD5 algorithm [RFC<A NAME=id1682 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>] to a string consisting of the
837 
+             the MD5 algorithm [RFC1321] to a string consisting of the
847 838 
              timestamp (including angle-brackets) followed by a shared
848 839
849 840
850 841
851 
-Myers &#38; Rose                Standards Track                    [Page 15]
842 
+Myers & Rose                Standards Track                    [Page 15]
852 843
853 
-RFC <A NAME=id1696 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
844 
+RFC 1939                          POP3                          May 1996
854 845
855 846
856 847 
              secret.  This shared secret is a string known only to the
... ... 
@@ -878,14 +869,14 @@ RFC <A NAME=id1696 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
878 869 
              -ERR permission denied
879 870
880 871 
          Examples:
881 
-             S: +OK POP3 server ready &#60;1896.697170952@dbc.mtview.ca.us&#62;
872 
+             S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
882 873 
              C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
883 874 
              S: +OK maildrop has 1 message (369 octets)
884 875
885 876 
              In this example, the shared  secret  is  the  string  `tan-
886 877 
              staaf'.  Hence, the MD5 algorithm is applied to the string
887 878
888 
-                &#60;1896.697170952@dbc.mtview.ca.us&#62;tanstaaf
879 
+                <1896.697170952@dbc.mtview.ca.us>tanstaaf
889 880
890 881 
              which produces a digest value of
891 882
... ... 
@@ -904,9 +895,9 @@ RFC <A NAME=id1696 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
904 895
905 896
906 897
907 
-Myers &#38; Rose                Standards Track                    [Page 16]
898 
+Myers & Rose                Standards Track                    [Page 16]
908 899
909 
-RFC <A NAME=id1808 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
900 
+RFC 1939                          POP3                          May 1996
910 901
911 902
912 903 
    IMAP, such as polling an existing connection for newly arrived
... ... 
@@ -960,9 +951,9 @@ RFC <A NAME=id1808 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
960 951
961 952
962 953
963 
-Myers &#38; Rose                Standards Track                    [Page 17]
954 
+Myers & Rose                Standards Track                    [Page 17]
964 955
965 
-RFC <A NAME=id1920 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
956 
+RFC 1939                          POP3                          May 1996
966 957
967 958
968 959 
       software by the following mechanism: "following a POP3 login by a
... ... 
@@ -1016,16 +1007,16 @@ RFC <A NAME=id1920 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
1016 1007
1017 1008
1018 1009
1019 
-Myers &#38; Rose                Standards Track                    [Page 18]
1010 
+Myers & Rose                Standards Track                    [Page 18]
1020 1011
1021 
-RFC <A NAME=id2032 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1012 
+RFC 1939                          POP3                          May 1996
1022 1013
1023 1014
1024 1015 
 10. Example POP3 Session
1025 1016
1026 
-      S: &#60;wait for connection on TCP port 110&#62;
1027 
-      C: &#60;open connection&#62;
1028 
-      S:    +OK POP3 server ready &#60;1896.697170952@dbc.mtview.ca.us&#62;
1017 
+      S: <wait for connection on TCP port 110>
1018 
+      C: <open connection>
1019 
+      S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
1029 1020 
       C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
1030 1021 
       S:    +OK mrose's maildrop has 2 messages (320 octets)
1031 1022 
       C:    STAT
... ... 
@@ -1037,25 +1028,25 @@ RFC <A NAME=id2032 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
1037 1028 
       S:    .
1038 1029 
       C:    RETR 1
1039 1030 
       S:    +OK 120 octets
1040 
-      S:    &#60;the POP3 server sends message 1&#62;
1031 
+      S:    <the POP3 server sends message 1>
1041 1032 
       S:    .
1042 1033 
       C:    DELE 1
1043 1034 
       S:    +OK message 1 deleted
1044 1035 
       C:    RETR 2
1045 1036 
       S:    +OK 200 octets
1046 
-      S:    &#60;the POP3 server sends message 2&#62;
1037 
+      S:    <the POP3 server sends message 2>
1047 1038 
       S:    .
1048 1039 
       C:    DELE 2
1049 1040 
       S:    +OK message 2 deleted
1050 1041 
       C:    QUIT
1051 1042 
       S:    +OK dewey POP3 server signing off (maildrop empty)
1052 
-      C:  &#60;close connection&#62;
1053 
-      S:  &#60;wait for next connection&#62;
1043 
+      C:  <close connection>
1044 
+      S:  <wait for next connection>
1054 1045
1055 1046 
 11. Message Format
1056 1047
1057 1048 
    All messages transmitted during a POP3 session are assumed to conform
1058 
-   to the standard for the format of Internet text messages [RFC<A NAME=id2107 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>].
1049 
+   to the standard for the format of Internet text messages [RFC822].
1059 1050
1060 1051 
    It is important to note that the octet count for a message on the
1061 1052 
    server host may differ from the octet count assigned to that message
... ... 
@@ -1072,26 +1063,26 @@ RFC <A NAME=id2032 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
1072 1063
1073 1064
1074 1065
1075 
-Myers &#38; Rose                Standards Track                    [Page 19]
1066 
+Myers & Rose                Standards Track                    [Page 19]
1076 1067
1077 
-RFC <A NAME=id2145 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1068 
+RFC 1939                          POP3                          May 1996
1078 1069
1079 1070
1080 1071 
 12. References
1081 1072
1082 
-   [RFC<A NAME=id2156 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html">821</A>] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1073 
+   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1083 1074 
        821, USC/Information Sciences Institute, August 1982.
1084 1075
1085 
-   [RFC<A NAME=id2163 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>] Crocker, D., "Standard for the Format of ARPA-Internet Text
1086 
-       Messages", STD 11, RFC <A NAME=id2166 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">822</A>, University of Delaware, August 1982.
1076 
+   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
1077 
+       Messages", STD 11, RFC 822, University of Delaware, August 1982.
1087 1078
1088 
-   [RFC<A NAME=id2172 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>] Rivest, R., "The MD5 Message-Digest Algorithm", RFC <A NAME=id2171 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1321.html">1321</A>,
1079 
+   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1089 1080 
        MIT Laboratory for Computer Science, April 1992.
1090 1081
1091 
-   [RFC<A NAME=id2179 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>] Crispin, M., "Internet Message Access Protocol - Version
1092 
-       4", RFC <A NAME=id2182 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1730.html">1730</A>, University of Washington, December 1994.
1082 
+   [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
1083 
+       4", RFC 1730, University of Washington, December 1994.
1093 1084
1094 
-   [RFC<A NAME=id2188 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>] Myers, J., "POP3 AUTHentication command", RFC <A NAME=id2187 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1734.html">1734</A>,
1085 
+   [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
1095 1086 
        Carnegie Mellon, December 1994.
1096 1087
1097 1088 
 13. Security Considerations
... ... 
@@ -1120,7 +1111,7 @@ RFC <A NAME=id2145 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
1120 1111 
 14. Acknowledgements
1121 1112
1122 1113 
    The POP family has a long and checkered history.  Although primarily
1123 
-   a minor revision to RFC <A NAME=id2247 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1460.html">1460</A>, POP3 is based on the ideas presented in
1114 
+   a minor revision to RFC 1460, POP3 is based on the ideas presented in
1124 1115 
    RFCs 918, 937, and 1081.
1125 1116
1126 1117 
    In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
... ... 
@@ -1128,9 +1119,9 @@ RFC <A NAME=id2145 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
1128 1119
1129 1120
1130 1121
1131 
-Myers &#38; Rose                Standards Track                    [Page 20]
1122 
+Myers & Rose                Standards Track                    [Page 20]
1132 1123
1133 
-RFC <A NAME=id2267 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1124 
+RFC 1939                          POP3                          May 1996
1134 1125
1135 1126
1136 1127 
 15. Authors' Addresses
... ... 
@@ -1184,14 +1175,14 @@ RFC <A NAME=id2267 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1
1184 1175
1185 1176
1186 1177
1187 
-Myers &#38; Rose                Standards Track                    [Page 21]
1178 
+Myers & Rose                Standards Track                    [Page 21]
1188 1179
1189 
-RFC <A NAME=id2379 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1180 
+RFC 1939                          POP3                          May 1996
1190 1181
1191 1182
1192 
-Appendix A. Differences from RFC <A NAME=id2386 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>
1183 
+Appendix A. Differences from RFC 1725
1193 1184
1194 
-   This memo is a revision to RFC <A NAME=id2391 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1725.html">1725</A>, a Draft Standard.  It makes the
1185 
+   This memo is a revision to RFC 1725, a Draft Standard.  It makes the
1195 1186 
    following changes from that document:
1196 1187
1197 1188 
       - clarifies that command keywords are case insensitive.
... ... 
@@ -1240,9 +1231,9 @@ Appendix A. Differences from RFC <A NAME=id2386 HREF="http://www.cis.ohio-state.
1240 1231
1241 1232
1242 1233
1243 
-Myers &#38; Rose                Standards Track                    [Page 22]
1234 
+Myers & Rose                Standards Track                    [Page 22]
1244 1235
1245 
-RFC <A NAME=id2493 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html">1939</A>                          POP3                          May 1996
1236 
+RFC 1939                          POP3                          May 1996
1246 1237
1247 1238
1248 1239 
       - clarifies that the second argument to the TOP command is a
... ... 
@@ -1296,8 +1287,5 @@ Appendix B. Command Index
1296 1287
1297 1288
1298 1289
1299 
-Myers &#38; Rose                Standards Track                    [Page 23]
1290 
+Myers & Rose                Standards Track                    [Page 23]
1300 1291
1301 
-</PRE>
1302 
-</BODY>
1303 
-</HTML>
rfc2822.cl
History View file @ 107577b
... ... 
@@ -1,30 +1,16 @@
1 1 
 ;; -*- mode: common-lisp; package: net.mail -*-
2 2 
 ;;
3 
-;; copyright (c) 1999-2002 Franz Inc, Berkeley, CA - All rights reserved.
4 
-;; copyright (c) 2002-2012 Franz Inc, Oakland, CA - All rights reserved.
5 
-;;
6 
-;; This code is free software; you can redistribute it and/or
7 
-;; modify it under the terms of the version 2.1 of
8 
-;; the GNU Lesser General Public License as published by
9 
-;; the Free Software Foundation, as clarified by the AllegroServe
10 
-;; prequel found in license-allegroserve.txt.
11 
-;;
12 
-;; This code is distributed in the hope that it will be useful,
13 
-;; but without any warranty; without even the implied warranty of
14 
-;; merchantability or fitness for a particular purpose.  See the GNU
15 
-;; Lesser General Public License for more details.
16 
-;;
17 
-;; $Id: rfc2822.cl,v 1.11 2007/09/24 22:17:45 layer Exp $
3 
+;; See the file LICENSE for the full license governing this code.
18 4
19 
-#+(version= 8 0)
20 
-(sys:defpatch "rfc2822" 0
21 
-  "v0: New module.  See documentation."
5 
+#+(version= 9 0)
6 
+(sys:defpatch "rfc2822" 1
7 
+  "v1: parse-email-address: check length of local-part"
22 8 
   :type :system
23 9 
   :post-loadable t)
24 10
25 
-#+(version= 8 1)
11 
+#+(version= 8 2)
26 12 
 (sys:defpatch "rfc2822" 1
27 
-  "v1: extract-email-addresses enhancements & parsing fix."
13 
+  "v1: parse-email-address: check length of local-part"
28 14 
   :type :system
29 15 
   :post-loadable t)
30 16
... ... 
@@ -126,16 +112,18 @@ domain.
126 112
127 113 
 (defun parse-email-address (string &key (require-domain t)
128 114 
 					(require-dotted-domain t))
129 
-  (multiple-value-bind (matched x user domain)
115 
+  (multiple-value-bind (matched x local-part domain)
130 116 
       (match-re #.*email-address-re* string)
131 117 
     (declare (ignore x))
132 118 
     (if* (or
133 119 
 	  ;; Failure cases
134 120 
 	  (not matched)
135 121 
 	  (and require-domain (null domain))
136 
-	  (and require-dotted-domain domain (zerop (count #\. domain))))
122 
+	  (and require-dotted-domain domain (zerop (count #\. domain)))
123 
+	  ;; From rfc3696
124 
+	  (> (length local-part) 64))
137 125 
        then nil
138 
-       else (values user domain))))
126 
+       else (values local-part domain))))
139 127
140 128 
 ;; Returns a list of entries like so:
141 129 
 ;;  (:mailbox display-name user domain)
rfc2822.txt
History View file @ 107577b
142 130 
new file mode 100644
... ... 
@@ -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 
+
rfc3696.txt
History View file @ 107577b
0 2860 
new file mode 100644
... ... 
@@ -0,0 +1,899 @@
1 
+
2 
+
3 
+
4 
+
5 
+
6 
+
7 
+Network Working Group                                         J. Klensin
8 
+Request for Comments: 3696                                 February 2004
9 
+Category: Informational
10 
+
11 
+
12 
+    Application Techniques for Checking and Transformation of Names
13 
+
14 
+Status of this Memo
15 
+
16 
+   This memo provides information for the Internet community.  It does
17 
+   not specify an Internet standard of any kind.  Distribution of this
18 
+   memo is unlimited.
19 
+
20 
+Copyright Notice
21 
+
22 
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
23 
+
24 
+Abstract
25 
+
26 
+   Many Internet applications have been designed to deduce top-level
27 
+   domains (or other domain name labels) from partial information.  The
28 
+   introduction of new top-level domains, especially non-country-code
29 
+   ones, has exposed flaws in some of the methods used by these
30 
+   applications.  These flaws make it more difficult, or impossible, for
31 
+   users of the applications to access the full Internet.  This memo
32 
+   discusses some of the techniques that have been used and gives some
33 
+   guidance for minimizing their negative impact as the domain name
34 
+   environment evolves.  This document draws summaries of the applicable
35 
+   rules together in one place and supplies references to the actual
36 
+   standards.
37 
+
38 
+
39 
+
40 
+
41 
+
42 
+
43 
+
44 
+
45 
+
46 
+
47 
+
48 
+
49 
+
50 
+
51 
+
52 
+
53 
+
54 
+
55 
+
56 
+
57 
+
58 
+Klensin                      Informational                      [Page 1]
59 
+
60 
+RFC 3696          Checking and Transformation of Names     February 2004
61 
+
62 
+
63 
+Table of Contents
64 
+
65 
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
66 
+   2.  Restrictions on domain (DNS) names . . . . . . . . . . . . . .  3
67 
+   3.  Restrictions on email addresses  . . . . . . . . . . . . . . .  5
68 
+   4.  URLs and URIs  . . . . . . . . . . . . . . . . . . . . . . . .  7
69 
+       4.1.  URI syntax definitions and issues  . . . . . . . . . . .  7
70 
+       4.2.  The HTTP URL . . . . . . . . . . . . . . . . . . . . . .  8
71 
+       4.3.  The MAILTO URL . . . . . . . . . . . . . . . . . . . . .  9
72 
+       4.4.  Guessing domain names in web contexts  . . . . . . . . . 11
73 
+   5.  Implications of internationalization . . . . . . . . . . . . . 11
74 
+   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
75 
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
76 
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
77 
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
78 
+       9.1.  Normative References . . . . . . . . . . . . . . . . . . 14
79 
+       9.2.  Informative References . . . . . . . . . . . . . . . . . 15
80 
+   10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
81 
+   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
82 
+
83 
+1.  Introduction
84 
+
85 
+   Designers of user interfaces to Internet applications have often
86 
+   found it useful to examine user-provided values for validity before
87 
+   passing them to the Internet tools themselves.  This type of test,
88 
+   most commonly involving syntax checks or application of other rules
89 
+   to domain names, email addresses, or "web addresses" (URLs or,
90 
+   occasionally, extended URI forms (see Section 4)) may enable better-
91 
+   quality diagnostics for the user than might be available from the
92 
+   protocol itself.  Local validity tests on values are also thought to
93 
+   improve the efficiency of back-office processing programs and to
94 
+   reduce the load on the protocols themselves.  Certainly, they are
95 
+   consistent with the well-established principle that it is better to
96 
+   detect errors as early as possible.
97 
+
98 
+   The tests must, however, be made correctly or at least safely.  If
99 
+   criteria are applied that do not match the protocols, users will be
100 
+   inconvenienced, addresses and sites will effectively become
101 
+   inaccessible to some groups, and business and communications
102 
+   opportunities will be lost.  Experience in recent years indicates
103 
+   that syntax tests are often performed incorrectly and that tests for
104 
+   top-level domain names are applied using obsolete lists and
105 
+   conventions.  We assume that most of these incorrect tests are the
106 
+   result of the inability to conveniently locate exact definitions for
107 
+   the criteria to be applied.  This document draws summaries of the
108 
+   applicable rules together in one place and supplies references to the
109 
+
110 
+
111 
+
112 
+
113 
+
114 
+Klensin                      Informational                      [Page 2]
115 
+
116 
+RFC 3696          Checking and Transformation of Names     February 2004
117 
+
118 
+
119 
+   actual standards.  It does not add anything to those standards; it
120 
+   merely draws the information together into a form that may be more
121 
+   accessible.
122 
+
123 
+   Many experts on Internet protocols believe that tests and rules of
124 
+   these sorts should be avoided in applications and that the tests in
125 
+   the protocols and back-office systems should be relied on instead.
126 
+   Certainly implementations of the protocols cannot assume that the
127 
+   data passed to them will be valid.  Unless the standards specify
128 
+   particular behavior, this document takes no position on whether or
129 
+   not the testing is desirable.  It only identifies the correct tests
130 
+   to be made if tests are to be applied.
131 
+
132 
+   The sections that follow discuss domain names, email addresses, and
133 
+   URLs.
134 
+
135 
+2.  Restrictions on domain (DNS) names
136 
+
137 
+   The authoritative definitions of the format and syntax of domain
138 
+   names appear in RFCs 1035 [RFC1035], 1123 [RFC1123], and 2181
139 
+   [RFC2181].
140 
+
141 
+   Any characters, or combination of bits (as octets), are permitted in
142 
+   DNS names.  However, there is a preferred form that is required by
143 
+   most applications.  This preferred form has been the only one
144 
+   permitted in the names of top-level domains, or TLDs.  In general, it
145 
+   is also the only form permitted in most second-level names registered
146 
+   in TLDs, although some names that are normally not seen by users obey
147 
+   other rules.  It derives from the original ARPANET rules for the
148 
+   naming of hosts (i.e., the "hostname" rule) and is perhaps better
149 
+   described as the "LDH rule", after the characters that it permits.
150 
+   The LDH rule, as updated, provides that the labels (words or strings
151 
+   separated by periods) that make up a domain name must consist of only
152 
+   the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen.
153 
+   No other symbols or punctuation characters are permitted, nor is
154 
+   blank space.  If the hyphen is used, it is not permitted to appear at
155 
+   either the beginning or end of a label.  There is an additional rule
156 
+   that essentially requires that top-level domain names not be all-
157 
+   numeric.
158 
+
159 
+   When it is necessary to express labels with non-character octets, or
160 
+   to embed periods within labels, there is a mechanism for keying them
161 
+   in that utilizes an escape sequence.  RFC 1035 [RFC1035] should be
162 
+   consulted if that mechanism is needed (most common applications,
163 
+   including email and the Web, will generally not permit those escaped
164 
+   strings).  A special encoding is now available for non-ASCII
165 
+   characters, see the brief discussion in Section 5.
166 
+
167 
+
168 
+
169 
+
170 
+Klensin                      Informational                      [Page 3]
171 
+
172 
+RFC 3696          Checking and Transformation of Names     February 2004
173 
+
174 
+
175 
+   Most internet applications that reference other hosts or systems
176 
+   assume they will be supplied with "fully-qualified" domain names,
177 
+   i.e., ones that include all of the labels leading to the root,
178 
+   including the TLD name.  Those fully-qualified domain names are then
179 
+   passed to either the domain name resolution protocol itself or to the
180 
+   remote systems.  Consequently, purported DNS names to be used in
181 
+   applications and to locate resources generally must contain at least
182 
+   one period (".") character.  Those that do not are either invalid or
183 
+   require the application to supply additional information.  Of course,
184 
+   this principle does not apply when the purpose of the application is
185 
+   to process or query TLD names themselves.  The DNS specification also
186 
+   permits a trailing period to be used to denote the root, e.g.,
187 
+   "a.b.c" and "a.b.c." are equivalent, but the latter is more explicit
188 
+   and is required to be accepted by applications.  This convention is
189 
+   especially important when a TLD name is being referred to directly.
190 
+   For example, while ".COM" has become the popular terminology for
191 
+   referring to that top-level domain, "COM." would be strictly and
192 
+   technically correct in talking about the DNS, since it shows that
193 
+   "COM" is a top-level domain name.
194 
+
195 
+   There is a long history of applications moving beyond the "one or
196 
+   more periods" test in an attempt to verify that a valid TLD name is
197 
+   actually present.  They have done this either by applying some
198 
+   heuristics to the form of the name or by consulting a local list of
199 
+   valid names.  The historical heuristics are no longer effective.  If
200 
+   one is to keep a local list, much more effort must be devoted to
201 
+   keeping it up-to-date than was the case several years ago.
202 
+
203 
+   The heuristics were based on the observation that, since the DNS was
204 
+   first deployed, all top-level domain names were two, three, or four
205 
+   characters in length.  All two-character names were associated with
206 
+   "country code" domains, with the specific labels (with a few early
207 
+   exceptions) drawn from the ISO list of codes for countries and
208 
+   similar entities [IS3166].  The three-letter names were "generic"
209 
+   TLDs, whose function was not country-specific, and there was exactly
210 
+   one four-letter TLD, the infrastructure domain "ARPA."  [RFC1591].
211 
+   However, these length-dependent rules were conventions, rather than
212 
+   anything on which the protocols depended.
213 
+
214 
+   Before the mid-1990s, lists of valid top-level domain names changed
215 
+   infrequently.  New country codes were gradually, and then more
216 
+   rapidly, added as the Internet expanded, but the list of generic
217 
+   domains did not change at all between the establishment of the "INT."
218 
+   domain in 1988 and ICANN's allocation of new generic TLDs in 2000.
219 
+   Some application developers responded by assuming that any two-letter
220 
+   domain name could be valid as a TLD, but the list of generic TLDs was
221 
+   fixed and could be kept locally and tested.  Several of these
222 
+   assumptions changed as ICANN started to allocate new top-level
223 
+
224 
+
225 
+
226 
+Klensin                      Informational                      [Page 4]
227 
+
228 
+RFC 3696          Checking and Transformation of Names     February 2004
229 
+
230 
+
231 
+   domains: one two-letter domain that does not appear in the ISO 3166-1
232 
+   table [ISO.3166.1988] was tentatively approved, and new domains were
233 
+   created with three, four, and even six letter codes.
234 
+
235 
+   As of the first quarter of 2003, the list of valid, non-country,
236 
+   top-level domains was .AERO, .BIZ, .COM, .COOP, .EDU, .GOV, .INFO,
237 
+   .INT, .MIL, .MUSEUM, .NAME, .NET, .ORG, .PRO, and .ARPA.  ICANN is
238 
+   expected to expand that list at regular intervals, so the list that
239 
+   appears here should not be used in testing.  Instead, systems that
240 
+   filter by testing top-level domain names should regularly update
241 
+   their local tables of TLDs (both "generic" and country-code-related)
242 
+   by polling the list published by IANA [DomainList].  It is
243 
+   likely that the better strategy has now become to make the "at least
244 
+   one period" test, to verify LDH conformance (including verification
245 
+   that the apparent TLD name is not all-numeric), and then to use the
246 
+   DNS to determine domain name validity, rather than trying to maintain
247 
+   a local list of valid TLD names.
248 
+
249 
+   A DNS label may be no more than 63 octets long.  This is in the form
250 
+   actually stored; if a non-ASCII label is converted to encoded
251 
+   "punycode" form (see Section 5), the length of that form may restrict
252 
+   the number of actual characters (in the original character set) that
253 
+   can be accommodated.  A complete, fully-qualified, domain name must
254 
+   not exceed 255 octets.
255 
+
256 
+   Some additional mechanisms for guessing correct domain names when
257 
+   incomplete information is provided have been developed for use with
258 
+   the web and are discussed in Section 4.4.
259 
+
260 
+3.  Restrictions on email addresses
261 
+
262 
+   Reference documents: RFC 2821 [RFC2821] and RFC 2822 [RFC2822]
263 
+
264 
+   Contemporary email addresses consist of a "local part" separated from
265 
+   a "domain part" (a fully-qualified domain name) by an at-sign ("@").
266 
+   The syntax of the domain part corresponds to that in the previous
267 
+   section.  The concerns identified in that section about filtering and
268 
+   lists of names apply to the domain names used in an email context as
269 
+   well.  The domain name can also be replaced by an IP address in
270 
+   square brackets, but that form is strongly discouraged except for
271 
+   testing and troubleshooting purposes.
272 
+
273 
+   The local part may appear using the quoting conventions described
274 
+   below.  The quoted forms are rarely used in practice, but are
275 
+   required for some legitimate purposes.  Hence, they should not be
276 
+   rejected in filtering routines but, should instead be passed to the
277 
+   email system for evaluation by the destination host.
278 
+
279 
+
280 
+
281 
+
282 
+Klensin                      Informational                      [Page 5]
283 
+
284 
+RFC 3696          Checking and Transformation of Names     February 2004
285 
+
286 
+
287 
+   The exact rule is that any ASCII character, including control
288 
+   characters, may appear quoted, or in a quoted string.  When quoting
289 
+   is needed, the backslash character is used to quote the following
290 
+   character.  For example
291 
+
292 
+      Abc\@def@example.com
293 
+
294 
+   is a valid form of an email address.  Blank spaces may also appear,
295 
+   as in
296 
+
297 
+      Fred\ Bloggs@example.com
298 
+
299 
+   The backslash character may also be used to quote itself, e.g.,
300 
+
301 
+      Joe.\\Blow@example.com
302 
+
303 
+   In addition to quoting using the backslash character, conventional
304 
+   double-quote characters may be used to surround strings.  For example
305 
+
306 
+      "Abc@def"@example.com
307 
+
308 
+      "Fred Bloggs"@example.com
309 
+
310 
+   are alternate forms of the first two examples above.  These quoted
311 
+   forms are rarely recommended, and are uncommon in practice, but, as
312 
+   discussed above, must be supported by applications that are
313 
+   processing email addresses.  In particular, the quoted forms often
314 
+   appear in the context of addresses associated with transitions from
315 
+   other systems and contexts; those transitional requirements do still
316 
+   arise and, since a system that accepts a user-provided email address
317 
+   cannot "know" whether that address is associated with a legacy
318 
+   system, the address forms must be accepted and passed into the email
319 
+   environment.
320 
+
321 
+   Without quotes, local-parts may consist of any combination of
322 
+   alphabetic characters, digits, or any of the special characters
323 
+
324 
+      ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~
325 
+
326 
+   period (".") may also appear, but may not be used to start or end the
327 
+   local part, nor may two or more consecutive periods appear.  Stated
328 
+   differently, any ASCII graphic (printing) character other than the
329 
+   at-sign ("@"), backslash, double quote, comma, or square brackets may
330 
+   appear without quoting.  If any of that list of excluded characters
331 
+   are to appear, they must be quoted.  Forms such as
332 
+
333 
+      user+mailbox@example.com
334 
+
335 
+
336 
+
337 
+
338 
+Klensin                      Informational                      [Page 6]
339 
+
340 
+RFC 3696          Checking and Transformation of Names     February 2004
341 
+
342 
+
343 
+      customer/department=shipping@example.com
344 
+
345 
+      $A12345@example.com
346 
+
347 
+      !def!xyz%abc@example.com
348 
+
349 
+      _somename@example.com
350 
+
351 
+   are valid and are seen fairly regularly, but any of the characters
352 
+   listed above are permitted.  In the context of local parts,
353 
+   apostrophe ("'") and acute accent ("`") are ordinary characters, not
354 
+   quoting characters.  Some of the characters listed above are used in
355 
+   conventions about routing or other types of special handling by some
356 
+   receiving hosts.  But, since there is no way to know whether the
357 
+   remote host is using those conventions or just treating these
358 
+   characters as normal text, sending programs (and programs evaluating
359 
+   address validity) must simply accept the strings and pass them on.
360 
+
361 
+   In addition to restrictions on syntax, there is a length limit on
362 
+   email addresses.  That limit is a maximum of 64 characters (octets)
363 
+   in the "local part" (before the "@") and a maximum of 255 characters
364 
+   (octets) in the domain part (after the "@") for a total length of 320
365 
+   characters.  Systems that handle email should be prepared to process
366 
+   addresses which are that long, even though they are rarely
367 
+   encountered.
368 
+
369 
+4.  URLs and URIs
370 
+
371 
+4.1.  URI syntax definitions and issues
372 
+
373 
+   The syntax for URLs (Uniform Resource Locators) is specified in
374 
+   [RFC1738].  The syntax for the more general "URI" (Uniform Resource
375 
+   Identifier) is specified in [RFC2396].  The URI syntax is extremely
376 
+   general, with considerable variations permitted according to the type
377 
+   of "scheme" (e.g., "http", "ftp", "mailto") that is being used.
378 
+   While it is possible to use the general syntax rules of RFC 2396 to
379 
+   perform syntax checks, they are general enough --essentially only
380 
+   specifying the separation of the scheme name and "scheme specific
381 
+   part" with a colon (":") and excluding some characters that must be
382 
+   escaped if used-- to provide little significant filtering or
383 
+   validation power.
384 
+
385 
+   The following characters are reserved in many URIs -- they must be
386 
+   used for either their URI-intended purpose or must be encoded.  Some
387 
+   particular schemes may either broaden or relax these restrictions
388 
+   (see the following sections for URLs applicable to "web pages" and
389 
+   electronic mail), or apply them only to particular URI component
390 
+   parts.
391 
+
392 
+
393 
+
394 
+Klensin                      Informational                      [Page 7]
395 
+
396 
+RFC 3696          Checking and Transformation of Names     February 2004
397 
+
398 
+
399 
+      ; / ? : @ & = + $ , ?
400 
+
401 
+   In addition, control characters, the space character, the double-
402 
+   quote (") character, and the following special characters
403 
+
404 
+      < > # %
405 
+
406 
+   are generally forbidden and must either be avoided or escaped, as
407 
+   discussed below.
408 
+
409 
+   The colon after the scheme name, and the percent sign used to escape
410 
+   characters, are specifically reserved for those purposes, although
411 
+   ":" may also be used elsewhere in some schemes.
412 
+
413 
+   When it is necessary to encode these, or other, characters, the
414 
+   method used is to replace it with a percent-sign ("%") followed by
415 
+   two hexidecimal digits representing its octet value.  See section
416 
+   2.4.1 of [RFC2396] for an exact definition.  Unless it is used as a
417 
+   delimiter of the URI scheme itself, any character may optionally be
418 
+   encoded this way; systems that are testing URI syntax should be
419 
+   prepared for these encodings to appear in any component of the URI
420 
+   except the scheme name itself.
421 
+
422 
+   A "generic URI" syntax is specified and is more restrictive, but
423 
+   using it to test URI strings requires that one know whether or not
424 
+   the particular scheme in use obeys that syntax.  Consequently,
425 
+   applications that intend to check or validate URIs should normally
426 
+   identify the scheme name and then apply scheme-specific tests.  The
427 
+   rules for two of those -- HTTP [RFC1738] and MAILTO [RFC2368] URLs --
428 
+   are discussed below, but the author of an application which intends
429 
+   to make very precise checks, or to reject particular syntax rather
430 
+   than just warning the user, should consult the relevant scheme-
431 
+   definition documents for precise syntax and relationships.
432 
+
433 
+4.2.  The HTTP URL
434 
+
435 
+   Absolute HTTP URLs consist of the scheme name, a host name (expressed
436 
+   as a domain name or IP address), and optional port number, and then,
437 
+   optionally, a path, a search part, and a fragment identifier.  These
438 
+   are separated, respectively, by a colon and the two slashes that
439 
+   precede the host name, a colon, a slash, a question mark, and a hash
440 
+   mark ("#").  So we have
441 
+
442 
+      http://host:port/path?search#fragment
443 
+
444 
+      http://host/path/
445 
+
446 
+      http://host/path#fragment
447 
+
448 
+
449 
+
450 
+Klensin                      Informational                      [Page 8]
451 
+
452 
+RFC 3696          Checking and Transformation of Names     February 2004
453 
+
454 
+
455 
+      http://host/path?search
456 
+
457 
+      http://host
458 
+
459 
+   and other variations on that form.  There is also a "relative" form,
460 
+   but it almost never appears in text that a user might, e.g., enter
461 
+   into a form.  See [RFC2616] for details.
462 
+
463 
+   The characters
464 
+
465 
+      / ; ?
466 
+
467 
+   are reserved within the path and search parts and must be encoded;
468 
+   the first of these may be used unencoded, and is often used within
469 
+   the path, to designate hierarchy.
470 
+
471 
+4.3.  The MAILTO URL
472 
+
473 
+   MAILTO is a URL type whose content is an email address.  It can be
474 
+   used to encode any of the email address formats discussed in Section
475 
+   3 above.  It can also support multiple addresses and the inclusion of
476 
+   headers (e.g., Subject lines) within the body of the URL.  MAILTO is
477 
+   authoritatively defined in RFC 2368 [RFC2368]; anyone expecting to
478 
+   accept and test multiple addresses or mail header or body formats
479 
+   should consult that document carefully.
480 
+
481 
+   In accepting text for, or validating, a MAILTO URL, it is important
482 
+   to note that, while it can be used to encode any valid email address,
483 
+   it is not sufficient to copy an email address into a MAILTO URL since
484 
+   email addresses may include a number of characters that are invalid
485 
+   in, or have reserved uses for, URLs.  Those characters must be
486 
+   encoded, as outlined in Section 4.1 above, when the addresses are
487 
+   mapped into the URL form.  Conversely, addresses in MAILTO URLs
488 
+   cannot, in general, be copied directly into email contexts, since few
489 
+   email programs will reverse the decodings (and doing so might be
490 
+   interpreted as a protocol violation).
491 
+
492 
+   The following characters may appear in MAILTO URLs only with the
493 
+   specific defined meanings given.  If they appear in an email address
494 
+   (i.e., for some other purpose), they must be encoded:
495 
+
496 
+      :       The colon in "mailto:"
497 
+
498 
+      < > # " % { } | \ ^ ~ `
499 
+
500 
+      These characters are "unsafe" in any URL, and must always be
501 
+      encoded.
502 
+
503 
+
504 
+
505 
+
506 
+Klensin                      Informational                      [Page 9]
507 
+
508 
+RFC 3696          Checking and Transformation of Names     February 2004
509 
+
510 
+
511 
+   The following characters must also be encoded if they appear in a
512 
+   MAILTO URL
513 
+
514 
+      ? & =
515 
+         Used to delimit headers and their values when these are encoded
516 
+         into URLs.
517 
+
518 
+   Some examples may be helpful:
519 
+
520 
+   +-------------------------+-----------------------------+-----------+
521 
+   |      Email address      |         MAILTO URL          |   Notes   |
522 
+   +-------------------------+-----------------------------+-----------+
523 
+   |     Joe@example.com     |  mailto:joe@example.com     |     1     |
524 
+   |                         |                             |           |
525 
+   |  user+mailbox@example   |         mailto:             |     2     |
526 
+   |          .com           |  user%2Bmailbox@example     |           |
527 
+   |                         |          .com               |           |
528 
+   |                         |                             |           |
529 
+   |  customer/department=   |  mailto:customer%2F         |     3     |
530 
+   |  shipping@example.com   | department=shipping@example |           |
531 
+   |                         |          .com               |           |
532 
+   |                         |                             |           |
533 
+   |   $A12345@example.com   |  mailto:$A12345@example     |     4     |
534 
+   |                         |          .com               |           |
535 
+   |                         |                             |           |
536 
+   |  !def!xyz%abc@example   |  mailto:!def!xyz%25abc      |     5     |
537 
+   |          .com           |       @example.com          |           |
538 
+   |                         |                             |           |
539 
+   |  _somename@example.com  |  mailto:_somename@example   |     4     |
540 
+   |                         |          .com               |           |
541 
+   +-------------------------+-----------------------------+-----------+
542 
+
543 
+                                  Table 1
544 
+
545 
+   Notes on Table
546 
+
547 
+   1.  No characters appear in the email address that require escaping,
548 
+       so the body of the MAILTO URL is identical to the email address.
549 
+
550 
+   2.  There is actually some uncertainty as to whether or not the "+"
551 
+       characters requires escaping in MAILTO URLs (the standards are
552 
+       not precisely clear).  But, since any character in the address
553 
+       specification may optionally be encoded, it is probably safer to
554 
+       encode it.
555 
+
556 
+   3.  The "/" character is generally reserved in URLs, and must be
557 
+       encoded as %2F.
558 
+
559 
+
560 
+
561 
+
562 
+Klensin                      Informational                     [Page 10]
563 
+
564 
+RFC 3696          Checking and Transformation of Names     February 2004
565 
+
566 
+
567 
+   4.  Neither the "$" nor the "_" character are given any special
568 
+       interpretation in MAILTO URLs, so need not be encoded.
569 
+
570 
+   5.  While the "!" character has no special interpretation, the "%"
571 
+       character is used to introduce encoded sequences and hence it
572 
+       must always be encoded.
573 
+
574 
+4.4.  Guessing domain names in web contexts
575 
+
576 
+   Several web browsers have adopted a practice that permits an
577 
+   incomplete domain name to be used as input instead of a complete URL.
578 
+   This has, for example, permitted users to type "microsoft" and have
579 
+   the browser interpret the input as "http://www.microsoft.com/".
580 
+   Other browser versions have gone even further, trying to build DNS
581 
+   names up through a series of heuristics, testing each variation in
582 
+   turn to see if it appears in the DNS, and accepting the first one
583 
+   found as the intended domain name.  Still, others automatically
584 
+   invoke search engines if no period appears or if the reference fails.
585 
+   If any of these approaches are to be used, it is often critical that
586 
+   the browser recognize the complete list of TLDs.  If an incomplete
587 
+   list is used, complete domain names may not be recognized as such and
588 
+   the system may try to turn them into completely different names.  For
589 
+   example, "example.aero" is a fully-qualified name, since "AERO." is a
590 
+   TLD name.  But, if the system doesn't recognize "AERO" as a TLD name,
591 
+   it is likely to try to look up "example.aero.com" and
592 
+   "www.example.aero.com" (and then fail or find the wrong host), rather
593 
+   than simply looking up the user-supplied name.
594 
+
595 
+   As discussed in Section 2 above, there are dangers associated with
596 
+   software that attempts to "know" the list of top-level domain names
597 
+   locally and take advantage of that knowledge.  These name-guessing
598 
+   heuristics are another example of that situation: if the lists are
599 
+   up-to-date and used carefully, the systems in which they are embedded
600 
+   may provide an easier, and more attractive, experience for at least
601 
+   some users.  But finding the wrong host, or being unable to find a
602 
+   host even when its name is precisely known, constitute bad
603 
+   experiences by any measure.
604 
+
605 
+   More generally, there have been bad experiences with attempts to
606 
+   "complete" domain names by adding additional information to them.
607 
+   These issues are described in some detail in RFC 1535 [RFC1535].
608 
+
609 
+5.  Implications of internationalization
610 
+
611 
+   The IETF has adopted a series of proposals ([RFC3490] - [RFC3492])
612 
+   whose purpose is to permit encoding internationalized (i.e., non-
613 
+   ASCII) names in the DNS.  The primary standard, and the group
614 
+   generically, are known as "IDNA".  The actual strings stored in the
615 
+
616 
+
617 
+
618 
+Klensin                      Informational                     [Page 11]
619 
+
620 
+RFC 3696          Checking and Transformation of Names     February 2004
621 
+
622 
+
623 
+   DNS are in an encoded form: the labels begin with the characters
624 
+   "xn--" followed by the encoded string.  Applications should be
625 
+   prepared to accept and process the encoded form (those strings are
626 
+   consistent with the "LDH rule" (see Section 2) so should not raise
627 
+   any separate issues) and the use of local, and potentially other,
628 
+   characters as appropriate to local systems and circumstances.
629 
+
630 
+   The IDNA specification describes the exact process to be used to
631 
+   validate a name or encoded string.  The process is sufficiently
632 
+   complex that shortcuts or heuristics, especially for versions of
633 
+   labels written directly in Unicode or other coded character sets, are
634 
+   likely to fail and cause problems.  In particular, the strings cannot
635 
+   be validated with syntax or semantic rules of any of the usual sorts:
636 
+   syntax validity is defined only in terms of the result of executing a
637 
+   particular function.
638 
+
639 
+   In addition to the restrictions imposed by the protocols themselves,
640 
+   many domains are implementing rules about just which non-ASCII names
641 
+   they will permit to be registered (see, e.g., [JET], [RegRestr]).
642 
+   This work is still relatively new, and the rules and conventions are
643 
+   likely to be different for each domain, or at least each language or
644 
+   script group.  Attempting to test for those rules in a client program
645 
+   to see if a user-supplied name might possibly exist in the relevant
646 
+   domain would almost certainly be ill-advised.
647 
+
648 
+   One quick local test however, may be reasonable: as of the time of
649 
+   this writing, there should be no instances of labels in the DNS that
650 
+   start with two characters, followed by two hyphens, where the two
651 
+   characters are not "xn" (in, of course, either upper or lower case).
652 
+   Such label strings, if they appear, are probably erroneous or
653 
+   obsolete, and it may be reasonable to at least warn the user about
654 
+   them.
655 
+
656 
+   There is ongoing work in the IETF and elsewhere to define
657 
+   internationalized formats for use in other protocols, including email
658 
+   addresses.  Those forms may or may not conform to existing rules for
659 
+   ASCII-only identifiers; anyone designing evaluators or filters should
660 
+   watch that work closely.
661 
+
662 
+6.  Summary
663 
+
664 
+   When an application accepts a string from the user and ultimately
665 
+   passes it on to an API for a protocol, the desirability of testing or
666 
+   filtering the text in any way not required by the protocol itself is
667 
+   hotly debated.  If it must divide the string into its components, or
668 
+   otherwise interpret it, it obviously must make at least enough tests
669 
+   to validate that process.  With, e.g., domain names or email
670 
+   addresses that can be passed on untouched, the appropriateness of
671 
+
672 
+
673 
+
674 
+Klensin                      Informational                     [Page 12]
675 
+
676 
+RFC 3696          Checking and Transformation of Names     February 2004
677 
+
678 
+
679 
+   trying to figure out which ones are valid and which ones are not
680 
+   requires a more complex decision, one that should include
681 
+   considerations of how to make exactly the correct tests and to keep
682 
+   information that changes and evolves up-to-date.  A test containing
683 
+   obsolete information, can be extremely frustrating for potential
684 
+   correspondents or customers and may harm desired relationships.
685 
+
686 
+7.  Security Considerations
687 
+
688 
+   Since this document merely summarizes the requirements of existing
689 
+   standards, it does not introduce any new security issues.  However,
690 
+   many of the techniques that motivate the document raise important
691 
+   security concerns of their own.  Rejecting valid forms of domain
692 
+   names, email addresses, or URIs often denies service to the user of
693 
+   those entities.  Worse, guessing at the user's intent when an
694 
+   incomplete address, or other string, is given can result in
695 
+   compromises to privacy or accuracy of reference if the wrong target
696 
+   is found and returned.  From a security standpoint, the optimum
697 
+   behavior is probably to never guess, but instead, to force the user
698 
+   to specify exactly what is wanted.  When that position involves a
699 
+   tradeoff with an acceptable user experience, good judgment should be
700 
+   used and the fact that it is a tradeoff recognized.
701 
+
702 
+   Some characters have special or privileged meanings on some systems
703 
+   (i.e., ` on Unix).  Applications should be careful to escape those
704 
+   locally if necessary.  By the same token, they are valid, and should
705 
+   not be disallowed locally, or escaped when transmitted through
706 
+   Internet protocols, for such reasons if a remote site chooses to use
707 
+   them.
708 
+
709 
+   The presence of local checking does not permit remote checking to be
710 
+   bypassed.  Note that this can apply to a single machine; in
711 
+   particular, a local MTA should not assume that a local MUA has
712 
+   properly escaped locally-significant special characters.
713 
+
714 
+8.  Acknowledgements
715 
+
716 
+   The author would like to express his appreciation for helpful
717 
+   comments from Harald Alvestrand, Eric A. Hall, and the RFC Editor,
718 
+   and for partial support of this work from SITA.  Responsibility for
719 
+   any errors remains, of course, with the author.
720 
+
721 
+   The first Internet-Draft on this subject was posted in February 2003.
722 
+   The document was submitted to the RFC Editor on 20 June 2003,
723 
+   returned for revisions on 19 August, and resubmitted on 5 September
724 
+   2003.
725 
+
726 
+
727 
+
728 
+
729 
+
730 
+Klensin                      Informational                     [Page 13]
731 
+
732 
+RFC 3696          Checking and Transformation of Names     February 2004
733 
+
734 
+
735 
+9.  References
736 
+
737 
+9.1.  Normative References
738 
+
739 
+   [RFC1035]       Mockapetris, P., "Domain names - implementation and
740 
+                   specification", STD 13, RFC 1035, November 1987.
741 
+
742 
+   [RFC1123]       Braden, R., Ed., "Requirements for Internet Hosts -
743 
+                   Application and Support", STD 3, RFC 1123, October
744 
+                   1989.
745 
+
746 
+   [RFC1535]       Gavron, E., "A Security Problem and Proposed
747 
+                   Correction With Widely Deployed DNS Software", RFC
748 
+                   1535, October 1993.
749 
+
750 
+   [RFC1738]       Berners-Lee, T., Masinter, L. and M. McCahill,
751 
+                   "Uniform Resource Locators (URL)", RFC 1738, December
752 
+                   1994.
753 
+
754 
+   [RFC2181]       Elz, R. and R. Bush, "Clarifications to the DNS
755 
+                   Specification", RFC 2181, July 1997.
756 
+
757 
+   [RFC2368]       Hoffman, P., Masinter, L. and J. Zawinski, "The
758 
+                   mailto URL scheme", RFC 2368, July 1998.
759 
+
760 
+   [RFC2396]       Berners-Lee, T., Fielding, R. and L. Masinter,
761 
+                   "Uniform Resource Identifiers (URI): Generic Syntax",
762 
+                   RFC 2396, August 1998.
763 
+
764 
+   [RFC2616]       Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
765 
+                   Masinter, L., Leach, P. and T. Berners-Lee,
766 
+                   "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
767 
+                   June 1999.
768 
+
769 
+   [RFC2821]       Klensin, J., Ed., "Simple Mail Transfer Protocol",
770 
+                   RFC 2821, April 2001.
771 
+
772 
+   [RFC2822]       Resnick, P., Ed., "Internet Message Format", RFC
773 
+                   2822, April 2001.
774 
+
775 
+   [RFC3490]       Faltstrom, P., Hoffman, P. and A. Costello,
776 
+                   "Internationalizing Domain Names in Applications
777 
+                   (IDNA)", RFC 3490, March 2003.
778 
+
779 
+   [RFC3491]       Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
780 
+                   Profile for Internationalized Domain Names (IDN)",
781 
+                   RFC 3491, March 2003.
782 
+
783 
+
784 
+
785 
+
786 
+Klensin                      Informational                     [Page 14]
787 
+
788 
+RFC 3696          Checking and Transformation of Names     February 2004
789 
+
790 
+
791 
+   [RFC3492]       Costello, A., "Punycode: A Bootstring encoding of
792 
+                   Unicode for Internationalized Domain Names in
793 
+                   Applications (IDNA)", RFC 3492, March 2003.
794 
+
795 
+   [ASCII]         American National Standards Institute (formerly
796 
+                   United States of America Standards Institute), "USA
797 
+                   Code for Information Interchange", ANSI X3.4-1968.
798 
+                   ANSI X3.4-1968 has been replaced by newer versions
799 
+                   with slight modifications, but the 1968 version
800 
+                   remains definitive for the Internet.
801 
+
802 
+   [DomainList]    Internet Assigned Numbers Authority (IANA), Untitled
803 
+                   alphabetical list of current top-level domains.
804 
+                   http://data.iana.org/TLD/tlds-alpha-by-domain.txt
805 
+                   ftp://data.iana.org/TLD/tlds-alpha-by-domain.txt
806 
+
807 
+9.2.  Informative References
808 
+
809 
+   [ISO.3166.1988] International Organization for Standardization,
810 
+                   "Codes for the representation of names of countries,
811 
+                   3rd edition", ISO Standard 3166, August 1988.
812 
+
813 
+   [JET]           Konishi, K., et al., "Internationalized Domain Names
814 
+                   Registration and Administration Guideline for
815 
+                   Chinese, Japanese and Korean", Work in Progress.
816 
+
817 
+   [RFC1591]       Postel, J., "Domain Name System Structure and
818 
+                   Delegation", RFC 1591, March 1994.
819 
+
820 
+   [RegRestr]      Klensin, J., "Registration of Internationalized
821 
+                   Domain Names: Overview and Method", Work in Progress,
822 
+                   February 2004.
823 
+
824 
+10.  Author's Address
825 
+
826 
+   John C Klensin
827 
+   1770 Massachusetts Ave, #322
828 
+   Cambridge, MA  02140
829 
+   USA
830 
+
831 
+   Phone: +1 617 491 5735
832 
+   EMail: john-ietf@jck.com
833 
+
834 
+
835 
+
836 
+
837 
+
838 
+
839 
+
840 
+
841 
+
842 
+Klensin                      Informational                     [Page 15]
843 
+
844 
+RFC 3696          Checking and Transformation of Names     February 2004
845 
+
846 
+
847 
+11.  Full Copyright Statement
848 
+
849 
+   Copyright (C) The Internet Society (2004).  This document is subject
850 
+   to the rights, licenses and restrictions contained in BCP 78 and
851 
+   except as set forth therein, the authors retain all their rights.
852 
+
853 
+   This document and the information contained herein are provided on an
854 
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
855 
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
856 
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
857 
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
858 
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
859 
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
860 
+
861 
+Intellectual Property
862 
+
863 
+   The IETF takes no position regarding the validity or scope of any
864 
+   Intellectual Property Rights or other rights that might be claimed to
865 
+   pertain to the implementation or use of the technology described in
866 
+   this document or the extent to which any license under such rights
867 
+   might or might not be available; nor does it represent that it has
868 
+   made any independent effort to identify any such rights.  Information
869 
+   on the procedures with respect to rights in RFC documents can be
870 
+   found in BCP 78 and BCP 79.
871 
+
872 
+   Copies of IPR disclosures made to the IETF Secretariat and any
873 
+   assurances of licenses to be made available, or the result of an
874 
+   attempt made to obtain a general license or permission for the use of
875 
+   such proprietary rights by implementers or users of this
876 
+   specification can be obtained from the IETF on-line IPR repository at
877 
+   http://www.ietf.org/ipr.
878 
+
879 
+   The IETF invites any interested party to bring to its attention any
880 
+   copyrights, patents or patent applications, or other proprietary
881 
+   rights that may cover technology that may be required to implement
882 
+   this standard.  Please address the information to the IETF at ietf-
883 
+   ipr@ietf.org.
884 
+
885 
+Acknowledgement
886 
+
887 
+   Funding for the RFC Editor function is currently provided by the
888 
+   Internet Society.
889 
+
890 
+
891 
+
892 
+
893 
+
894 
+
895 
+
896 
+
897 
+
898 
+Klensin                      Informational                     [Page 16]
899 
+
smtp.cl
History View file @ 107577b
... ... 
@@ -1,66 +1,27 @@
1 
-#+(version= 8 1)
2 
-(sys:defpatch "smtp" 1
3 
-  "v1: add smtp support for ssl connections and STARTTLS negotiation."
4 
-  :type :system
5 
-  :post-loadable t)
1 
+;; -*- mode: common-lisp; package: net.post-office -*-
2 
+;; send mail to an smtp server.  See rfc821 for the spec.
3 
+;;
4 
+;; See the file LICENSE for the full license governing this code.
6 5
7 
-#+(version= 8 0) ;; not current with latest sources
8 
-(sys:defpatch "smtp" 5
9 
-  "v1: send-letter w/attachments; send-smtp* can take streams;
10 
-v2: add :port argument to send-letter, send-smtp, send-smtp-auth;
11 
-v3: fix incompatibility introduced in v2;
12 
-v4: remove stray force-output of t;
13 
-v5: send-smtp-1: New external-format keyword arg."
6 
+#+(or (version= 8 2)
7 
+      (version= 9 0))
8 
+(sys:defpatch "smtp" 2
9 
+  "v1: Handle SMTP servers which violate SMTP SASL AUTH protocol;
10 
+v2: add new type of server argument to send-letter."
14 11 
   :type :system
15 12 
   :post-loadable t)
16 13
17 
-#+(version= 7 0) ;; not current with latest sources
18 
-(sys:defpatch "smtp" 5
19 
-  "v2: send-letter w/attachments; send-smtp* can take streams;
20 
-v3: add :port argument to send-letter, send-smtp, send-smtp-auth;
21 
-v4: fix incompatibility introduced in v3;
22 
-v5: rm stray force-output of t; send-smtp-1: New external-format keyword arg."
14 
+#+(version= 8 1)
15 
+(sys:defpatch "smtp" 1
16 
+  "v1: add smtp support for ssl connections and STARTTLS negotiation."
23 17 
   :type :system
24 18 
   :post-loadable t)
25 19
26 
-;; -*- mode: common-lisp; package: net.post-office -*-
27 
-;;
28 
-;; smtp.cl
29 
-;;
30 
-;; copyright (c) 1986-2002 Franz Inc, Berkeley, CA  - All rights reserved.
31 
-;; copyright (c) 2002-2012 Franz Inc, Oakland, CA - All rights reserved.
32 
-;;
33 
-;; This code is free software; you can redistribute it and/or
34 
-;; modify it under the terms of the version 2.1 of
35 
-;; the GNU Lesser General Public License as published by
36 
-;; the Free Software Foundation, as clarified by the AllegroServe
37 
-;; prequel found in license-allegroserve.txt.
38 
-;;
39 
-;; This code is distributed in the hope that it will be useful,
40 
-;; but without any warranty; without even the implied warranty of
41 
-;; merchantability or fitness for a particular purpose.  See the GNU
42 
-;; Lesser General Public License for more details.
43 
-;;
44 
-;; Version 2.1 of the GNU Lesser General Public License is in the file
45 
-;; license-lgpl.txt that was distributed with this file.
46 
-;; If it is not present, you can access it from
47 
-;; http://www.gnu.org/copyleft/lesser.txt (until superseded by a newer
48 
-;; version) or write to the Free Software Foundation, Inc., 59 Temple Place,
49 
-;; Suite 330, Boston, MA  02111-1307  USA
50 
-;;
51 
-;;
52 
-;; $Id: smtp.cl,v 1.24 2008/09/16 23:22:14 layer Exp $
53 
-
54 
-;; Description:
55 
-;;   send mail to an smtp server.  See rfc821 for the spec.
56 
-
57 
-;;- This code in this file obeys the Lisp Coding Standard found in
58 
-;;- http://www.franz.com/~jkf/coding_standards.html
59 
-;;-
60 
-
20 
+(eval-when (compile eval load)
21 
+  (require :osi))
61 22
62 23 
 (defpackage :net.post-office
63 
-  (:use #:lisp #:excl)
24 
+  (:use #:lisp #:excl #:excl.osi)
64 25 
   (:export
65 26 
    #:send-letter
66 27 
    #:send-smtp
... ... 
@@ -261,16 +222,65 @@ Attachments must be filenames, streams, or mime-part-constructed, not ~s"
261 222 
 		(setf (mime-part-parts message) (append parts-save res))))
262 223
263 224 
       (with-mime-part-constructed-stream (s message)
264 
-	(send-smtp-auth server from (append tos ccs bccs)
265 
-			login password
266 
-			hdrs
267 
-			user-headers
268 
-			s))
225 
+	(if* (and (consp server) (eq :program (car server)))
226 
+	   then (send-external-program (cdr server) hdrs user-headers s)
227 
+	   else (send-smtp-auth server from (append tos ccs bccs)
228 
+				login password
229 
+				hdrs
230 
+				user-headers
231 
+				s)))
269 232
270 233 
       (setf (mime-part-parts message) parts-save)
271 234 
       t)))
272 
-
273 
-
235 
+
236 
+(defun send-external-program (program &rest messages
237 
+			      &aux (external-format :default))
238 
+  (multiple-value-bind (stdout stderr exit-status)
239 
+      (command-output
240 
+       (if* (stringp program)
241 
+	  then program
242 
+	elseif (consp program)
243 
+	  then #+mswindows program
244 
+	       #-mswindows (apply #'vector (car program) program)
245 
+	  else (error "Bad program argument: ~s." program))
246 
+       :input (lambda (stream)
247 
+		(create-message stream messages external-format)))
248 
+    (when (/= 0 exit-status)
249 
+      (error "external program failed to send email (~s, ~s)."
250 
+	     stdout stderr))))
251 
+
252 
+(defun create-message (output-stream messages external-format)
253 
+  (let ((at-bol t)
254 
+	(prev-ch nil)
255 
+	ch input-stream)
256 
+    (dolist (message messages)
257 
+      (when message
258 
+	(setq input-stream
259 
+	  (if* (streamp message)
260 
+	     then message
261 
+	     else (make-buffer-input-stream
262 
+		   (string-to-octets
263 
+		    message
264 
+		    :null-terminate nil
265 
+		    :external-format external-format))))
266 
+
267 
+	(while (setf ch (read-byte input-stream nil))
268 
+	  (if* (and at-bol (eq ch #.(char-code #\.)))
269 
+	     then ;; to prevent . from being interpreted as eol
270 
+		  (write-char #\. output-stream))
271 
+	  (if* (eq ch #.(char-code #\newline))
272 
+	     then (setq at-bol t)
273 
+		  (if* (not (eq prev-ch #.(char-code #\return)))
274 
+		     then (write-char #\return output-stream))
275 
+	     else (setq at-bol nil))
276 
+	  (write-byte ch output-stream)
277 
+	  (setq prev-ch ch)))))
278 
+  (write-char #\return output-stream)
279 
+  (write-char #\linefeed output-stream)
280 
+  (write-char #\. output-stream)
281 
+  (write-char #\return output-stream)
282 
+  (write-char #\linefeed output-stream))
283 
+
274 284 
 (defun send-smtp (server from to &rest messages)
275 285 
   (send-smtp-1 server from to nil nil messages))
276 286
... ... 
@@ -278,7 +288,10 @@ Attachments must be filenames, streams, or mime-part-constructed, not ~s"
278 288 
   (send-smtp-1 server from to login password messages))
279 289
280 290 
 (defun send-smtp-1 (server from to login password messages
281 
-		    &key (external-format :default))
291 
+		    &key (external-format
292 
+			  ;; Never used, this might as well be an &aux
293 
+			  ;; variable
294 
+			  :default))
282 295 
   ;; send the effective concatenation of the messages via
283 296 
   ;; smtp to the mail server
284 297 
   ;; Each message should be a string or a stream.
... ... 
@@ -317,36 +330,8 @@ Attachments must be filenames, streams, or mime-part-constructed, not ~s"
317 330 
 	    (t (smtp-transaction-error)))
318 331
319 332
333 
+	  (create-message sock messages external-format)
320 334
321 
-	  (let ((at-bol t)
322 
-		(prev-ch nil)
323 
-		ch stream)
324 
-	    (dolist (message messages)
325 
-	      (when message
326 
-		(setf stream (if* (streamp message)
327 
-				then message
328 
-				else (make-buffer-input-stream
329 
-				      (string-to-octets
330 
-				       message
331 
-				       :null-terminate nil
332 
-				       :external-format external-format))))
333 
-
334 
-		(while (setf ch (read-byte stream nil))
335 
-		  (if* (and at-bol (eq ch #.(char-code #\.)))
336 
-		     then ;; to prevent . from being interpreted as eol
337 
-			  (write-char #\. sock))
338 
-		  (if* (eq ch #.(char-code #\newline))
339 
-		     then (setq at-bol t)
340 
-			  (if* (not (eq prev-ch #.(char-code #\return)))
341 
-			     then (write-char #\return sock))
342 
-		     else (setq at-bol nil))
343 
-		  (write-byte ch sock)
344 
-		  (setq prev-ch ch)))))
345 
-
346 
-	  (write-char #\return sock) (write-char #\linefeed sock)
347 
-	  (write-char #\. sock)
348 
-	  (write-char #\return sock) (write-char #\linefeed sock)
349 
-
350 335 
 	  (response-case (sock msg)
351 336 
 	    (2 nil ; (format t "Message sent to ~a~%" to)
352 337 
 	       )
... ... 
@@ -359,6 +344,7 @@ Attachments must be filenames, streams, or mime-part-constructed, not ~s"
359 344 
 	    (t (smtp-transaction-error))))
360 345 
       ;; Cleanup
361 346 
       (close sock))))
347 
+
362 348
363 349 
 (defun connect-to-mail-server (server login password)
364 350 
   ;; make that initial connection to the mail server
... ... 
@@ -472,7 +458,8 @@ Attachments must be filenames, streams, or mime-part-constructed, not ~s"
472 458 
 (defun smtp-authenticate (sock server mechs login password)
473 459 
   (let ((ctx (net.sasl:sasl-client-new "smtp" server
474 460 
 				       :user login
475 
-				       :pass password)))
461 
+				       :pass password))
462 
+	(first-server-response t))
476 463 
     (multiple-value-bind (res selected-mech response)
477 464 
 	(net.sasl:sasl-client-start ctx mechs)
478 465 
       (if (not (eq res :continue))
... ... 
@@ -481,12 +468,30 @@ Attachments must be filenames, streams, or mime-part-constructed, not ~s"
481 468 
       (loop
482 469 
 	(response-case (sock msg)
483 470 
 	  (3  ;; need more interaction
484 
-	   (multiple-value-setq (res response)
485 
-	     (net.sasl:sasl-step
486 
-	      ctx
487 
-	      (base64-string-to-usb8-array (subseq msg 4))))
488 
-	   (smtp-command sock "~a"
489 
-			 (usb8-array-to-base64-string response nil)))
471 
+	   ;; [rfe12276] Some SMTP servers (notably The Amazon SES
472 
+	   ;; SMTP endpoint (email-smtp.us-east-1.amazonaws.com))
473 
+	   ;; violate the protocol rules on the first server response.
474 
+	   ;; Apparently other SMTP clients are tolerant of this, so
475 
+	   ;; we try to be as well.
476 
+
477 
+	   (multiple-value-bind (decoded-server-response err)
478 
+	       (ignore-errors (base64-string-to-usb8-array (subseq msg 4)))
479 
+	     (when (null decoded-server-response)
480 
+	       (if* first-server-response
481 
+		  then ;; Ignore initial server response if it's
482 
+		       ;; bogus.
483 
+		       ;;;(warn "Bogus server initial response: ~s~%" (subseq msg 4))
484 
+		       (setf first-server-response nil)
485 
+		  else ;; We tolerate a bogus initial response, but no others
486 
+		       (error "Failed to decode server response of ~s: ~a"
487 
+			      (subseq msg 4)
488 
+			      err)))
489 
+
490 
+	     (multiple-value-setq (res response)
491 
+	       (net.sasl:sasl-step ctx decoded-server-response))
492 
+
493 
+	     (smtp-command sock "~a"
494 
+			   (usb8-array-to-base64-string response nil))))
490 495 
 	  (2 ;; server is satisfied.
491 496 
 	   ;; Make sure the auth process really completed
492 497 
 	   (if (not (net.sasl:sasl-conn-auth-complete-p ctx))
t-imap.cl
History View file @ 107577b
... ... 
@@ -1,25 +1,10 @@
1 
-;; copyright (c) 2002-2012 Franz Inc, Oakland, CA - All rights reserved.
2 
-;;
3 
-;; The software, data and information contained herein are proprietary
4 
-;; to, and comprise valuable trade secrets of, Franz, Inc.  They are
5 
-;; given in confidence by Franz, Inc. pursuant to a written license
6 
-;; agreement, and may be stored and used only in accordance with the terms
7 
-;; of such license.
8 
-;;
9 
-;; Restricted Rights Legend
10 
-;; ------------------------
11 
-;; Use, duplication, and disclosure of the software, data and information
12 
-;; contained herein by any agency, department or entity of the U.S.
13 
-;; Government are subject to restrictions of Restricted Rights for
14 
-;; Commercial Software developed at private expense as specified in
15 
-;; DOD FAR Supplement 52.227-7013 (c) (1) (ii), as applicable.
16 
-;;
17 
-;; $Id: t-imap.cl,v 1.9 2007/04/17 22:01:42 layer Exp $
1 
+;; See the file LICENSE for the full license governing this code.
18 2
19 3 
 ;; imap testing
20 4 
 ;; requires smtp module too
21 5
22 6 
 (eval-when (compile load eval)
7 
+  (require :rfc2822)
23 8 
   (require :smtp)
24 9 
   (require :imap)
25 10 
   (require :test))
... ... 
@@ -243,6 +228,38 @@
243 228 
    (net.post-office:decode-header-text "=?utf-8?q?=5BFranz_Wiki=5D_Update_of_=22Office/EmployeeDirectory=22_by_St?=
244 229 
  =?utf-8?q?eveHaflich?="))
245 230 
   )
231 
+
232 
+(defun test-parse-email-address ()
233 
+  (dolist (good `(("foo@bar.com" "foo" "bar.com")
234 
+		  ("layer@franz.com" "layer" "franz.com")
235 
+		  ("
236 
+
237 
+layer@franz.com" "layer" "franz.com")
238 
+		  (,(replace-re "XXlayer@franz.comX  X"
239 
+				"X"
240 
+				(format nil "~c" #\newline)
241 
+				:single-line t)
242 
+		   "layer" "franz.com")
243 
+		  (,(replace-re "XXlayer@franz.comX  X"
244 
+				"X"
245 
+				(format nil "~c" #\return)
246 
+				:single-line t)
247 
+		   "layer" "franz.com")
248 
+		  ;; local-part length = 64
249 
+		  ("1234567890123456789012345678901234567890123456789012345678901234@foo.com"
250 
+		   "1234567890123456789012345678901234567890123456789012345678901234"
251 
+		   "foo.com")
252 
+		  ))
253 
+    (multiple-value-bind (local-part domain)
254 
+	(net.mail:parse-email-address (first good))
255 
+      (test-equal (second good) local-part)
256 
+      (test-equal (third good) domain)))
257 
+  (dolist (bad (list "@foo.com"
258 
+		     ;; local-part length = 65
259 
+		     "12345678901234567890123456789012345678901234567890123456789012345@foo.com"
260 
+		     ))
261 
+    (test-nil (net.mail:parse-email-address bad)))
262 
+  )
246 263
247 264
248 265 
 (defun test-imap ()
... ... 
@@ -250,13 +267,15 @@
250 267 
 		  #'(lambda (con)
251 268 
 		      (format t "Got imap condition: ~a~%" con))))
252 269 
     (test-mime)
270 
+    (test-parse-email-address)
253 271 
 ;;;; Only jkf is setup to run the tests.
254 272 
     (when (string= "jkf" (sys:getenv "USER"))
255 273 
       (test-connect)
256 274 
       (test-sends)
257 275 
       (test-flags)
258 276 
       (test-mailboxes)
259 
-      (test-pop))))
277 
+      (test-pop)
278 
+      )))
260 279
261 280
262 281 
 (if* *do-test* then (do-test :imap #'test-imap))