[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 05                                                
Network Working Group                                          C. Newman
Internet Draft: Originator Info Message Header                  Innosoft
Document: draft-newman-msgheader-originfo-01.txt               July 1997


                     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 and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
     Coast), or ftp.isi.edu (US West Coast).


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
     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
     misdelivery for systems where the login credentials do not refer to



Newman                                                          [Page 1]


Internet Draft       Originator-Info Message Header            July 1997


     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.


1. Originator-Info header

     The Originator-Info header provides a list of attributes which may
     be used to trace the originator of an Internet message [IMAIL].
     These attributes do not in any way imply the existence 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 [IMAIL] to
     a delivery system if the MUA is unable to verify the existence 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.


1.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
     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



Newman                                                          [Page 2]


Internet Draft       Originator-Info Message Header            July 1997


     header SHOULD include a login-token attribute.

     1.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


1.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.


1.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?"

         Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu;
                    token-authority="phone 555-555-5555, ask for Mr. Spook"


1.5. Other attributes



Newman                                                          [Page 3]


Internet Draft       Originator-Info Message Header            July 1997


     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


2. 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)

3. Security Considerations

     The "Originator-Info" header is useful for tracing 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 accommodate 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".


4. Multinational Considerations

     Parameters in character sets other than US-ASCII MAY use MIME
     parameter extensions [MIME-PARAM].  This MAY also be used to
     provide language labeling and continuations.








Newman                                                          [Page 4]


Internet Draft       Originator-Info Message Header            July 1997


5. References

[DOM-NAME] Mockapetris, P., "Domain Names - Implementation and
 Specification", RFC 1035, ISI, November 1987.

        <ftp://ds.internic.net/rfc/rfc1035.txt>

[IMAIL] 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>


[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
 RFC 1730, University of Washington, December 1994.

        <ftp://ds.internic.net/rfc/rfc1730.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>

[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>

[MIME-PARAM] Freed, Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", RFC XXXX,
Innosoft, University of Tennessee, March 1997.

[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>

[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>

[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>



Newman                                                          [Page 5]


Internet Draft       Originator-Info Message Header            July 1997


[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
 Work in Progress, February 1997.

[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 Lakes Drive
West Covina, CA 91790 USA

Email: chris.newman@innosoft.com
































Newman                                                          [Page 6]