home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-newman-msgheader-originfo-02.txt < prev    next >
Text File  |  1997-08-28  |  12KB  |  341 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          C. Newman
  8. Internet Draft: Originator Info Message Header                  Innosoft
  9. Document: draft-newman-msgheader-originfo-02.txt             August 1997
  10.  
  11.  
  12.                      Originator-Info Message Header
  13.  
  14.  
  15. Status of this memo
  16.  
  17.      This document is an Internet-Draft.  Internet-Drafts are working
  18.      documents of the Internet Engineering Task Force (IETF), its areas,
  19.      and its working groups.  Note that other groups may also distribute
  20.      working documents as Internet-Drafts.
  21.  
  22.      Internet-Drafts are draft documents valid for a maximum of six
  23.      months and may be updated, replaced, or obsoleted by other
  24.      documents at any time.  It is inappropriate to use Internet-Drafts
  25.      as reference material or to cite them other than as "work in
  26.      progress."
  27.  
  28.      To view the entire list of current Internet-Drafts, please check
  29.      the "1id-abstracts.txt" listing contained in the Internet-Drafts
  30.      Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  31.      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  32.      Coast), or ftp.isi.edu (US West Coast).
  33.  
  34.  
  35. Introduction
  36.  
  37.      This proposal is an attempt to provide a standard header to
  38.      indicate information about the message originator without implying
  39.      that there is a deliverable mailbox or mandating that internal
  40.      network information be revealed.  The "Originator-Info" header is
  41.      intended to make the "X-Sender" and "X-X-Sender" headers obsolete.
  42.  
  43.      Many mail clients on personal computers are now using a
  44.      non-standard "X-Sender" header to identify the originator of a
  45.      message without the implication that the sender has a known
  46.      deliverable mailbox (unlike the "Sender" header).  Usually this
  47.      "X-Sender" header is constructed from the credentials used to login
  48.      to a POP [POP3], IMAP [IMAP4], or NNTP [NNTP] server.  Such
  49.      credentials often do not refer to a deliverable mailbox, and
  50.      therefore MUST NOT be used to construct a return or reply address.
  51.  
  52.      Unfortunately, some mailing list systems now use the "X-Sender"
  53.      header for authorization reply, or return messages.  This causes
  54.      misdelivery for systems where the login credentials do not refer to
  55.  
  56.  
  57.  
  58. Newman                                                          [Page 1]
  59.  
  60. Internet Draft       Originator-Info Message Header          August 1997
  61.  
  62.  
  63.      a deliverable mailbox and leaves some users unable to unsubscribe
  64.      to certain mailing lists.  Some clients have responded to this
  65.      problem by supporting an "X-X-Sender" header.  This situation is
  66.      obviously problematic.
  67.  
  68.  
  69. 1. Conventions Used in this Document
  70.  
  71.      The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
  72.      NOT", and "MAY" in this document are to be interpreted as described
  73.      in "Key words for use in RFCs to Indicate Requirement Levels"
  74.      [KEYWORDS].
  75.  
  76.  
  77. 2. Originator-Info header
  78.  
  79.      The Originator-Info header provides a list of attributes which may
  80.      be used to trace the originator of an Internet message [IMAIL].
  81.      These attributes do not in any way imply the existence of a
  82.      deliverable mailbox and MUST NOT be used for authorization or to
  83.      construct a reply or return address.
  84.  
  85.      Example:
  86.  
  87.          From: Chris Newman <chris.newman@innosoft.com>
  88.          Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu
  89.  
  90.      This example indicates that a person whose identity can be
  91.      determined from the token "avsgl" was logged into the server
  92.      "cyrus.andrew.cmu.edu" when this message was composed.
  93.  
  94.      An "Originator-Info" header SHOULD be generated by Internet mail
  95.      user agents (MUA) upon submission of an Internet message [IMAIL] to
  96.      a delivery system if the MUA is unable to verify the existence of a
  97.      deliverable mailbox for the current user and is authenticated to an
  98.      Internet service such as POP or IMAP.
  99.  
  100.      Multiple messages from a given user MAY have different
  101.      Originator-Info headers, as that user may have access to multiple
  102.      servers and/or login identities.  In addition, mail servers are
  103.      renamed more frequently than email addresses change.  For these
  104.      reasons, Originator-Info MUST NOT be used for any purpose other
  105.      than tracing the originator of the message.  Specifically,
  106.      Originator-Info MUST NOT be used to control access to mail based
  107.      services, although such services MAY record Originator-Info in log
  108.      files.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Newman                                                          [Page 2]
  115.  
  116. Internet Draft       Originator-Info Message Header          August 1997
  117.  
  118.  
  119. 2.1. "login-token" attribute
  120.  
  121.      The login-token attribute is used to allow the identity of the
  122.      sender to be traced without explicitly revealing that identity.  It
  123.      contains site-specific information which may be used to recover the
  124.      login-id (see section 2.2) of the originator.  For example, it
  125.      might be constructed with an MD5 hash [MD5] of the login-id and a
  126.      site-specific secret.  The login-token MAY use an algorithm which
  127.      produces a different token for each message.  An Originator-Info
  128.      header SHOULD include a login-token attribute.
  129.  
  130.  
  131. 2.2. "login-id" attribute
  132.  
  133.      The login-id attribute indicates the login identifier that was used
  134.      in a POP "USER" [POP3] or "AUTH" [POP3-AUTH] command or an IMAP
  135.      "LOGIN" or "AUTHENTICATE" [IMAP4] command.  The login-id may also
  136.      be obtained from other services such as a Kerberos authentication
  137.      library.  An Originator-Info header MAY include a login-id
  138.      attribute instead of a login-token attribute.  A program
  139.      interpreting this header MUST NOT form an email address from the
  140.      "login-id" and "server" attributes.  Such an address may not be
  141.      deliverable.
  142.  
  143.      Example:
  144.  
  145.          From: Chris Newman <chris.newman@innosoft.com>
  146.          Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu
  147.  
  148.  
  149. 2.3. "server" attribute
  150.  
  151.      The server attribute is a fully qualified Internet domain name
  152.      [DOM-NAME] of a mail server or other Internet server which the user
  153.      was authenticated to when the message was submitted. An
  154.      Originator-Info header SHOULD include a server attribute.
  155.  
  156.  
  157. 2.4. "token-authority" attribute
  158.  
  159.      This attribute contains a human readable string providing
  160.      information about the individual or service that is capable of
  161.      translating the login-token.  When absent, postmaster@<server> can
  162.      be assumed, where <server> is the value of the server attribute.
  163.  
  164.      Examples:
  165.  
  166.          Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu;
  167.  
  168.  
  169.  
  170. Newman                                                          [Page 3]
  171.  
  172. Internet Draft       Originator-Info Message Header          August 1997
  173.  
  174.  
  175.                     token-authority="nifty@cyrus.andrew.cmu.edu"
  176.  
  177.          Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu;
  178.                     token-authority="Don't you recognize ROT13?"
  179.  
  180.          Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu;
  181.                     token-authority="phone 555-555-5555, ask for Mr. Spook"
  182.  
  183.  
  184. 2.5. Other attributes
  185.  
  186.      Other attributes MAY be used to provide additional information.
  187.      There is no requirement to register attributes as the
  188.      Originator-Info header is not intended for automated processing.
  189.      For example, an MUA on a Macintosh may wish to include the owner
  190.      name as set in the "Sharing Setup" control panel.
  191.  
  192.      Example:
  193.  
  194.          From: Chris Newman <chris.newman@innosoft.com>
  195.          Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu;
  196.                           MacOS-owner-name=nifty
  197.  
  198.  
  199. 3. ABNF for Originator-Info header
  200.  
  201.      This defines the formal syntax for the "Originator-Info" header
  202.      using the ABNF notation defined in RFC 822 [RFC-822] and using
  203.      terminals defined in MIME [MIME-IMB].
  204.  
  205.      originator-info := "Originator-Info:" parameter *(";" parameter)
  206.  
  207. 4. Security Considerations
  208.  
  209.      The "Originator-Info" header is useful for tracing the source of
  210.      Internet messages.  However, it contains no authenticated
  211.      information and is completely susceptible to spoofing by an
  212.      intelligent sender or intervening host.  Therefore it is not a
  213.      substitute secure message systems such as PGP-MIME [PGP-MIME].
  214.  
  215.      Some sites have concerns about revealing the names of internal
  216.      servers and login identities.  MUAs could accommodate such sites
  217.      with an option to use the domain name of a SOCKS [SOCKS5] server
  218.      (or other firewall) in the "server" attribute instead of a private
  219.      mail server.  Sites with no such considerations MAY use "login-id"
  220.      instead of "login-token".
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Newman                                                          [Page 4]
  227.  
  228. Internet Draft       Originator-Info Message Header          August 1997
  229.  
  230.  
  231. 5. Multinational Considerations
  232.  
  233.      Parameters in character sets other than US-ASCII MAY use MIME
  234.      parameter extensions [MIME-PARAM].  This MAY also be used to
  235.      provide language labeling and continuations.
  236.  
  237.  
  238. 6. References
  239.  
  240.      [DOM-NAME] Mockapetris, P., "Domain Names - Implementation and
  241.      Specification", RFC 1035, ISI, November 1987.
  242.  
  243.           <ftp://ds.internic.net/rfc/rfc1035.txt>
  244.  
  245.      [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
  246.      Messages", RFC 822, University of Delaware, August 1982.
  247.  
  248.           <ftp://ds.internic.net/rfc/rfc822.txt>
  249.  
  250.      [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
  251.      4", RFC 1730, University of Washington, December 1994.
  252.  
  253.              <ftp://ds.internic.net/rfc/rfc1730.txt>
  254.  
  255.      [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
  256.      Requirement Levels", RFC 2119, Harvard University, March 1997.
  257.  
  258.          <ftp://ds.internic.net/rfc/rfc2119.txt>
  259.  
  260.      [MD5]  Rivest, R. "The MD5 Message Digest Algorithm", RFC 1321, MIT
  261.      Laboratory for Computer Science, April 1992.
  262.  
  263.           <ftp://ds.internic.net/rfc/rfc1321.txt>
  264.  
  265.      [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail
  266.      Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
  267.      2045, Innosoft, First Virtual, November 1996.
  268.  
  269.              <ftp://ds.internic.net/rfc/rfc2045.txt>
  270.  
  271.      [MIME-PARAM] Freed, Moore, "MIME Parameter Value and Encoded Word
  272.      Extensions: Character Sets, Languages, and Continuations", RFC
  273.      XXXX, Innosoft, University of Tennessee, March 1997.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Newman                                                          [Page 5]
  283.  
  284. Internet Draft       Originator-Info Message Header          August 1997
  285.  
  286.  
  287.      [NNTP] Kantor, Lapsley, "Network News Transfer Protocol: A Proposed
  288.      Standard for the Stream-Based Transmission of News", RFC 977, U.C.
  289.      San Diego, U.C. Berkeley, February 1986.
  290.  
  291.              <ftp://ds.internic.net/rfc/rfc977.txt>
  292.  
  293.      [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy
  294.      (PGP)", RFC 2015, The Aerospace Corporation, October 1996.
  295.  
  296.           <ftp://ds.internic.net/rfc/rfc2015.txt>
  297.  
  298.      [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
  299.      1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
  300.  
  301.              <ftp://ds.internic.net/rfc/rfc1939.txt>
  302.  
  303.      [SOCKS5] Leech, Ganis, Lee, Kuris, Koblas, Jones, "SOCKS Protocol
  304.      Version 5", RFC 1928, Bell-Northern Research Ltd, International
  305.      Business Machines, NEC Systems Laboratory, Unify Corporation,
  306.      Hewlett-Packard Company, March 1996.
  307.  
  308.           <ftp://ds.internic.net/rfc/rfc1928.txt>
  309.  
  310.  
  311. 7. Author's Address
  312.  
  313.      Chris Newman
  314.      Innosoft International, Inc.
  315.      1050 Lakes Drive
  316.      West Covina, CA 91790 USA
  317.  
  318.      Email: chris.newman@innosoft.com
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Newman                                                          [Page 6]
  339.  
  340.  
  341.