Network Working Group C. Newman Internet Draft: Originator Info Mail Header Innosoft Document: draft-newman-msgheader-originfo-00.txt December 1996 Originator-Info Message Header Status of this memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress''. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire six months after publication. Distribution of this draft is unlimited. 1. Introduction This proposal is an attempt to provide a standard header to indicate information about the message originator without implying that there is a deliverable mailbox or mandating that internal network information be revealed. The "Originator-Info" header is intended to make the "X-Sender" and "X-X-Sender" headers obsolete. Many mail clients on personal computers are now using a non- standard "X-Sender" header to identify the originator of a message without the implication that the sender has a known deliverable mailbox (unlike the "Sender" header). Usually this "X-Sender" header is constructed from the credentials used to login to a POP [POP3], IMAP [IMAP4], or NNTP [NNTP] server. Such credentials often do not refer to a deliverable mailbox, and therefore MUST NOT Newman [Page 1]
Internet Draft Originator-Info Message Header December 1996 be used to construct a return or reply address. Unfortunately, some mailing list systems now use the "X-Sender" header for authorization reply, or return messages. This causes mis-delivery for systems where the login credentials do not refer to a deliverable mailbox and leaves some users unable to unsubscribe to certain mailing lists. Some clients have responded to this problem by supporting an "X-X-Sender" header. This situation is obviously problematic. 2. Originator-Info header The Originator-Info header provides a list of attributes which may be used to trace the originator of an Internet message [IMESSAGE]. These attributes do not in any way imply the existance of a deliverable mailbox and MUST NOT be used for authorization or to construct a reply or return address. Example: From: Chris Newman <chris.newman@innosoft.com> Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu This example indicates that a person whose identity can be determined from the token "avsgl" was logged into the server "cyrus.andrew.cmu.edu" when this message was composed. An "Originator-Info" header SHOULD be generated by Internet mail user agents (MUA) upon submission of an Internet message [IMESSAGE] to a delivery system if the MUA is unable to verify the existance of a deliverable mailbox for the current user and is authenticated to an Internet service such as POP or IMAP. Multiple messages from a given user MAY have different Originator- Info headers, as that user may have access to multiple servers and/or login identities. In addition, mail servers are renamed more frequently than email addresses change. For these reasons, Originator-Info MUST NOT be used for any purpose other than tracing the originator of the message. Specifically, Originator-Info MUST NOT be used to control access to mail based services, although such services MAY record Originator-Info in log files. 2.1. "login-token" attribute The login-token attribute is used to allow the identity of the sender to be traced without explicitly revealing that identity. It Newman [Page 2]
Internet Draft Originator-Info Message Header December 1996 contains site-specific information which may be used to recover the login-id (see section 2.2) of the originator. For example, it might be constructed with an MD5 hash [MD5] of the login-id and a site-specific secret. The login-token MAY use an algorithm which produces a different token for each message. An Originator-Info header SHOULD include a login-token attribute. 2.2. "login-id" attribute The login-id attribute indicates the login identifier that was used in a POP "USER" [POP3] or "AUTH" [POP3-AUTH] command or an IMAP "LOGIN" or "AUTHENTICATE" [IMAP4] command. The login-id may also be obtained from other services such as a Kerberos authentication library. An Originator-Info header MAY include a login-id attribute instead of a login-token attribute. A program interpreting this header MUST NOT form an email address from the "login-id" and "server" attributes. Such an address may not be deliverable. Example: From: Chris Newman <chris.newman@innosoft.com> Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu 2.3. "server" attribute The server attribute is a fully qualified Internet domain name [DOM-NAME] of a mail server or other Internet server which the user was authenticated to when the message was submitted. An Originator-Info header SHOULD include a server attribute. 2.4. "token-authority" attribute This attribute contains a human readable string providing information about the individual or service that is capable of translating the login-token. When absent, postmaster@<server> can be assumed, where <server> is the value of the server attribute. Examples: Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; token-authority="nifty@cyrus.andrew.cmu.edu" Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; token-authority="Don't you recognize ROT13?" Newman [Page 3]
Internet Draft Originator-Info Message Header December 1996 Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu; token-authority="phone 555-555-5555, ask for Mr. Spook" 2.5. Other attributes Other attributes MAY be used to provide additional information. There is no requirement to register attributes as the Originator- Info header is not intended for automated processing. For example, an MUA on a Macintosh may wish to include the owner name as set in the "Sharing Setup" control panel. Example: From: Chris Newman <chris.newman@innosoft.com> Originator-Info: login-id=nifty; server=cyrus.andrew.cmu.edu; MacOS-owner-name=nifty 3. ABNF for Originator-Info header This defines the formal syntax for the "Originator-Info" header using the notation defined in RFC 822 [RFC-822] and using terminals defined in MIME [MIME-IMB]. originator-info := "Originator-Info:" parameter *(";" parameter) 4. Security Considerations The "Originator-Info" header is useful for traceing the source of Internet messages. However, it contains no authenticated information and is completely susceptible to spoofing by an intelligent sender or intervening host. Therefore it is not a substitute for authenticated delivery [SMTP-AUTH] and secure message systems such as PGP-MIME [PGP-MIME]. Some sites have concerns about revealing the names of internal servers and login identities. MUAs could accomodate such sites with an option to use the domain name of a SOCKS [SOCKS5] server (or other firewall) in the "server" attribute instead of a private mail server. Sites with no such considerations MAY use "login-id" instead of "login-token". Newman [Page 4]
Internet Draft Originator-Info Message Header December 1996 5. References [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. <ftp://ds.internic.net/rfc/rfc1939.txt> [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 1730, University of Washington, December 1994. <ftp://ds.internic.net/rfc/rfc1730.txt> [NNTP] Kantor, Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, U.C. San Diego, U.C. Berkeley, February 1986. <ftp://ds.internic.net/rfc/rfc977.txt> [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996. <ftp://ds.internic.net/rfc/rfc2045.txt> [IMESSAGE] Crocker, D., "Standard for the Format of Arpa Internet Text Messages", RFC 822, University of Delaware, August 1982. <ftp://ds.internic.net/rfc/rfc822.txt> [DOM-NAME] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, ISI, November 1987 <ftp://ds.internic.net/rfc/rfc1035.txt> [MD5] Rivest, R. "The MD5 Message Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April, 1992. <ftp://ds.internic.net/rfc/rfc1321.txt> [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", Work in Progress, Carnegie Mellon, October 1996. [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, The Aerospace Corporation, October 1996. <ftp://ds.internic.net/rfc/rfc2015.txt> Newman [Page 5]
Internet Draft Originator-Info Message Header December 1996 [SOCKS5] Leech, Ganis, Lee, Kuris, Koblas, Jones, "SOCKS Protocol Version 5", RFC 1928, Bell-Northern Research Ltd, International Business Machines, NEC Systems Laboratory, Unify Corporation, Hewlett-Packard Company, March 1996. <ftp://ds.internic.net/rfc/rfc1928.txt> 6. Author's Address Chris Newman Innosoft International, Inc. 1050 East Garvey Ave. South West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman [Page 6]
