usefor-article-08 August 2002

5.2.  From

   The From-header contains the email address(es), possibly including
   the full name(s), of the article's poster(s). The content syntax
   makes use of syntax defined in [RFC 2822], subject to the following
   revised definition of local-part.

      header              =/ From-header
      From-header         = "From" ":" SP From-content
      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 [RFC 2822]), whilst allowing any UTF-8 character to be used
        in a preceding quoted-string containing the poster's full name.
        If some future extension to the Email protocols should relax
        this restriction, one would expect the Netnews protocols to
        follow.

        Observe that there is no provision for parameters in this
        header, or in other headers containing addresses likely to be
        used for sending email (see 4.2.2).

   Each mailbox in the From-content SHOULD be a valid address, belonging
   to the poster(s) of the article, or person or agent on whose behalf
   the post is being sent (see the Sender-header, 6.2).  When, for
   whatever reason, the poster does not wish to include such an address,
   the From-content SHOULD then be an address which ends in the top
   level domain of ".invalid" [RFC 2606].

        NOTE: Since such addresses ending in ".invalid" are
        undeliverable, user agents Ought to warn any user attempting to
        reply to them and Ought Not, in any case, to attempt to deliver
        to them (since that would be pointless anyway).  Whether or not
        a valid address can subsequently be extracted from such an
        address falls outside the scope of this standard (obviously,
        posters wishing to disguise their address need to do more than
        just add ".invalid" to it).

        Be warned, however, that some injecting agents which are unable
        to detect that the address belongs to the poster may choose to
        insert a Sender-header (but see 8.2.2) or some entry in an
        Injector-Info-header (6.19) which discloses some valid address
        for the poster.

--- ../usefor-article-07/From.out          May 2002
+++ ../usefor-article-08/From.out          August 2002
@@ -1,9 +1,9 @@
 5.2.  From
 
-   The From-header contains the electronic address(es), and possibly the
-   full name, of the article's poster(s). The content syntax makes use
-   of syntax defined in [RFC 2822], subject to the following revised
-   definition of local-part.
+   The From-header contains the email address(es), possibly including
+   the full name(s), of the article's poster(s). The content syntax
+   makes use of syntax defined in [RFC 2822], subject to the following
+   revised definition of local-part.
 
       header              =/ From-header
       From-header         = "From" ":" SP From-content
@@ -19,6 +19,10 @@
         this restriction, one would expect the Netnews protocols to
         follow.
 
+        Observe that there is no provision for parameters in this
+        header, or in other headers containing addresses likely to be
+        used for sending email (see 4.2.2).
+
    Each mailbox in the From-content SHOULD be a valid address, belonging
    to the poster(s) of the article, or person or agent on whose behalf
    the post is being sent (see the Sender-header, 6.2).  When, for
@@ -31,11 +35,13 @@
         reply to them and Ought Not, in any case, to attempt to deliver
         to them (since that would be pointless anyway).  Whether or not
         a valid address can subsequently be extracted from such an
-        address falls outside the scope of this standard (though it
-        would be pointless to use a disguise so easily penetrable).
+        address falls outside the scope of this standard (obviously,
+        posters wishing to disguise their address need to do more than
+        just add ".invalid" to it).
 
         Be warned, however, that some injecting agents which are unable
         to detect that the address belongs to the poster may choose to
-        insert a Sender-header (6.2) or some entry in an Injector-Info-
-        header (6.19) which discloses some valid address for the poster.
+        insert a Sender-header (but see 8.2.2) or some entry in an
+        Injector-Info-header (6.19) which discloses some valid address
+        for the poster.