usefor-article-03 February 2000

6.2.  Sender

   The Sender header specifies the mailbox of the entity which actually
   sent this article, if that entity is different from that given in the
   From header or if more than one address appears in the From header.
   This header SHOULD NOT appear in an article unless the sender is
   different from the author. This header is appropriate for use by
   automatic article posters. The content syntax makes use of syntax
   defined in [MESSFOR].

      Sender-content      = mailbox

--- ../s-o-1036/Sender.out          June 1994
+++ ../usefor-article-03/Sender.out          February 2000
@@ -1,57 +1,12 @@
-6.4. Sender
+6.2.  Sender
 
-The Sender header identifies the poster, in the  event  that
-this differs from the author identified in the From header:
+   The Sender header specifies the mailbox of the entity which actually
+   sent this article, if that entity is different from that given in the
+   From header or if more than one address appears in the From header.
+   This header SHOULD NOT appear in an article unless the sender is
+   different from the author. This header is appropriate for use by
+   automatic article posters. The content syntax makes use of syntax
+   defined in [MESSFOR].
 
-     Sender-content = From-content
-
-In  the  absence of Sender, the default poster is the author
-(named in the From header).
-
-     NOTE: The intent is that the Sender header have  a
-     fairly  high probability of identifying the person
-     who really posted the  article.   The  ability  to
-     specify  a  From  header naming someone other than
-     the poster is useful but can be abused.
-
-If the poster supplies a From header, the posting agent MUST
-ensure that a Sender header is present, unless it can verify
-that the mailing address in the From header is a valid mail-
-ing address for the poster.  A poster-supplied Sender header
-MAY be used, if its mailing address is  verifiably  a  valid
-mailing  address for the poster; otherwise the posting agent
-MUST supply a Sender header and delete (or rename,  e.g.  to
-X-Unverifiable-Sender) any poster-supplied Sender header.
-
-     NOTE:  It  might  be  useful to preserve a poster-
-     supplied Sender header so that the poster can sup-
-     ply  the full-name part of the content.  The mail-
-     ing address, however, must be right.   Hence,  the
-     posting  agent  must generate the Sender header if
-     it is unable to verify the mailing  address  of  a
-     poster-supplied one.
-
-     NOTE:  NNTP implementors, in particular, are urged
-     to note this requirement  (which  would  eliminate
-     the  need  for  ad  hoc headers like NNTP-Posting-
-     Host), although there are admittedly  some  imple-
-     mentation  difficulties.   A user name from an RFC
-     1413 server and a host name from an  inverse  map-
-     ping  of  the  address, perhaps with a "full name"
-     comment noting  the  origin  of  the  information,
-     would be at least a first approximation:
-
-          Sender: fred@zoo.toronto.edu (RFC-1413@reverse-lookup; not verified)
-
-     While  this does not completely meet the specs, it
-     comes a lot closer than not having a Sender header
-     at all.  Even just supplying a placeholder for the
-     user name:
-
-INTERNET DRAFT to be        NEWS                    sec. 6.4
-
-
-          Sender: somebody@zoo.toronto.edu (user name unknown)
-
-     would be better than nothing.
+      Sender-content      = mailbox