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