s-o-1036 June 1994

6.4. Sender

The Sender header identifies the poster, in the  event  that
this differs from the author identified in the From header:

     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.

--- ../rfc1036/Sender.out          December 1987
+++ ../s-o-1036/Sender.out          June 1994
@@ -1,24 +1,57 @@
-2.2.2.  Sender
+6.4. Sender
 
-    This field is present only if the submitter manually enters a "From"
-    line.  It is intended to record the entity responsible for
-    submitting the message to the network.  It should be verified by the
-    software at the submitting host.
-    For example, if John Smith is visiting CCA and wishes to post a
-    message to the network, using friend Sarah Jones' account, the
-    message might read:
-
-    From: smith@ucbvax.Berkeley.EDU (John Smith)
-    Sender: jones@cca.COM (Sarah Jones)
-
-    If a gateway program enters a mail message into the network at host
-    unix.SRI.COM, the lines might read:
-
-    From: John.Doe@A.CS.CMU.EDU
-    Sender: network@unix.SRI.COM
-
-    The primary purpose of this field is to be able to track down
-    messages to determine how they were entered into the network.  The
-    full name may be optionally given, in parentheses, as in the "From"
-    line.
+The Sender header identifies the poster, in the  event  that
+this differs from the author identified in the From header:
+
+     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.