usefor-article-03 February 2000

5.2.  From

   The From header contains the electronic address(es), and possibly the
   full name, of the article's author(s). The content syntax makes use
   of syntax defined in [MESSFOR], subject to the following revised
   definition of local-part.

      From-content        = mailbox-list
      addr-spec           = local-part "@" domain
      local-part          = dot-atom / strict-quoted-string

        NOTE: This syntax ensures that the local-part of an addr-spec is
        restricted to pure US-ASCII (and is thus in strict compliance
        with [MESSFOR]), whilst allowing any UTF-8 character to be used
        in a preceding quoted-string containing the author's full name.
        If some future extension to the Mail protocols should relax this
        restriction, one would expect the Netnews protocols to follow.

   Any mailbox in the From-content MUST belong to one of the poster(s)
   of the article, or be a mailbox which he is authorized by its owner
   to use, or be an address which ends in the top level domain of
   ".invalid" [RFC 2606].

--- ../s-o-1036/From.out          June 1994
+++ ../usefor-article-03/From.out          February 2000
@@ -1,129 +1,23 @@
 5.2. From
 
-The  From header contains the electronic address, and possi-
-bly the full name, of the article's author:
-
-     From-content  = address [ space "(" paren-phrase ")" ]
-                   /  [ plain-phrase space ] "<" address ">"
-     paren-phrase  = 1*( paren-char / space / encoded-word )
-     paren-char    = <ASCII printable character except ()<>\>
-     plain-phrase  = plain-word *( space plain-word )
-     plain-word    = unquoted-word / quoted-word / encoded-word
-     unquoted-word = 1*unquoted-char
-     unquoted-char = <ASCII printable character except !()<>@,;:\".[]>
-     quoted-word   = quote 1*( quoted-char / space ) quote
-     quote         = <" (ASCII 34)>
-     quoted-char   = <ASCII printable character except "()<>\>
-     address       = local-part "@" domain
-     local-part    = unquoted-word *( "." unquoted-word )
-     domain        = unquoted-word *( "." unquoted-word )
-
-(Encoded words are described in section 4.5.)  The full name
-is  distinguished  from  the  electronic  address  either by
-enclosing the former in parentheses (making  it  resemble  a
-MAIL  comment, after the address) or by enclosing the latter
-in angle brackets.  The second form is  preferred.   In  the
-first  form, encoded words inside the full name MUST be com-
-posed  entirely  of  <paren-char>s.   In  the  second  form,
-encoded  words  inside the full name may not contain charac-
-ters other than letters (of either case),  digits,  and  the
-characters "!", "*", "+", "-", "/", "=", and "_".  The local
-part is case-sensitive (except that all case counterparts of
-"postmaster"  are  deemed  equivalent),  the domain is case-
-insensitive, and all other parts of  the  From  content  are
-comments  which  MUST  be  ignored  by news software (except
-insofar as reading agents may wish to display  them  to  the
-reader).   Posters  and  posting  agents MUST restrict them-
-selves to this subset of the MAIL From syntax; relayers  MAY
-accept  a  broader subset, but see the discussion in section
-9.1.
-
-     NOTE: The syntax here is a  restricted  subset  of
-     the  MAIL  From  syntax, with quoting particularly
-     restricted, for simple  parsing.   In  particular,
-     the  presence of "<" in the From content indicates
-     that the second form is being used, otherwise  the
-     first  form is being used.  The major restrictions
-     here are those already de-facto imposed by  exist-
-     ing software.
-
-INTERNET DRAFT to be        NEWS                    sec. 5.2
-
-
-     NOTE: Overly-lenient posting agents sometimes per-
-     mit the second form with a  full  name  containing
-     "("  or  ")",  but it is extremely rare for a full
-     name to contain "<" or ">" even in mail.   Accord-
-     ingly,  reading  agents wishing to robustly deter-
-     mine which form is in use in a particular  article
-     should  key on the presence or absence of "<", not
-     the presence or absence of "(".
-
-The address SHOULD be a valid and complete  Internet  domain
-address,  capable  of  being  successfully  mailed  to by an
-Internet host (possibly via an MX record and  a  forwarder).
-The  pseudo-domain  ".uucp" MAY be used for hosts registered
-in the UUCP maps (e.g. name "xyz.uucp" for  registered  site
-"xyz"), but such hosts SHOULD discontinue this usage (either
-by arranging a proper Internet address and forwarder, or  by
-using  the "% hack" (see below)), as soon as possible.  Bit-
-net hosts SHOULD use Internet addresses, avoiding the  obso-
-lescent  ".bitnet"  pseudo-domain.   Other  forms of address
-MUST not be used.
-
-     NOTE: "Other forms" specifically include  UK-style
-     "backward"  domains  ("uk.oxbridge.cs"  is  in the
-     Czech Republic, not the UK), pure-UUCP  addressing
-     ("knee!shin!foot"            instead            of
-     "foot%shin@knee.uucp"),  and  abbreviated  domains
-     ("zebra.zoo"  instead of "zebra.zoo.toronto.edu").
-
-If it is necessary to use the local part to specify a  rout-
-ing relative to the nearest Internet host, this MUST be done
-using the "% hack", using "%" as a secondary "@".  For exam-
-ple, to specify that mail to the address should go to Inter-
-net host "foo.bar.edu", then  to  non-Internet  host  "ein",
-then  to  non-Internet  host  "deux",  for delivery there to
-mailbox "fred", a suitable address would be:
-
-     fred%deux%ein@foo.bar.edu
-
-Analogous forms using "!" in the  local  part  MUST  not  be
-used, as they are ambiguous; they should be expressed in the
-"%" form.
-
-     NOTE: "a!b@c" can be interpreted as either "b%c@a"
-     or  "b%a@c",  and there is no consistency in which
-     choice is made.  Such addresses  consequently  are
-     unreliable.   The  "%"  form  does not suffer from
-     this problem, and although its use  is  officially
-     discouraged,  it  is  a  de-facto standard, to the
-     point that MAIL recognizes it.
-
-Relayers MUST not, repeat MUST not, repeat MUST not, rewrite
-From  lines,  in any way, however minor or innocent-seeming.
-Trying to "fix" a non-conforming address  has  a  very  high
-probability  of  making  things worse.  Either pass it along
-
-INTERNET DRAFT to be        NEWS                    sec. 5.2
-
-
-unchanged, or reject the article.
-
-     NOTE: An additional reason for banning the use  of
-     "!" addressing is that it has a much higher proba-
-     bility of being rewritten into mangled unrecogniz-
-     ability by old relayers.
-
-Posters  and  posting agents SHOULD avoid use of the charac-
-ters "!" and "@" in full names, as they may trigger unwanted
-header rewriting by old, simple-minded news software.
-
-     NOTE: Also, the characters "." and ",", not infre-
-     quently found in names (e.g., "John  W.  Campbell,
-     Jr."), are NOT, repeat NOT, allowed in an unquoted
-     word.  A From header like the following  MUST  not
-     be written without the quotation marks:
-
-          From: "John W. Campbell, Jr." <editor@analog.com>
+   The From header contains the electronic address(es), and possibly the
+   full name, of the article's author(s). The content syntax makes use
+   of syntax defined in [MESSFOR], subject to the following revised
+   definition of local-part.
+
+      From-content        = mailbox-list
+      addr-spec           = local-part "@" domain
+      local-part          = dot-atom / strict-quoted-string
+
+        NOTE: This syntax ensures that the local-part of an addr-spec is
+        restricted to pure US-ASCII (and is thus in strict compliance
+        with [MESSFOR]), whilst allowing any UTF-8 character to be used
+        in a preceding quoted-string containing the author's full name.
+        If some future extension to the Mail protocols should relax this
+        restriction, one would expect the Netnews protocols to follow.
+
+   Any mailbox in the From-content MUST belong to one of the poster(s)
+   of the article, or be a mailbox which he is authorized by its owner
+   to use, or be an address which ends in the top level domain of
+   ".invalid" [RFC 2606].