One document matched: draft-newman-msgheader-originfo-03.txt
Differences from draft-newman-msgheader-originfo-02.txt
Network Working Group C. Newman
Internet Draft: Originator Info Message Header Innosoft
Document: draft-newman-msgheader-originfo-03.txt November 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).
Copyright Notice
Copyright (C) The Internet Society 1997. All Rights Reserved.
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
Newman [Page 1]
Internet Draft Originator-Info Message Header November 1997
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
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. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
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 [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,
Newman [Page 2]
Internet Draft Originator-Info Message Header November 1997
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
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. The
named server is encouraged to support applicable contact addresses
as specified in [MBOX-NAMES].
2.4. "token-authority" attribute
This attribute contains a human readable string providing
Newman [Page 3]
Internet Draft Originator-Info Message Header November 1997
information about the individual or service that is capable of
translating the login-token.
Examples:
Originator-Info: login-token=avsgl; server=cyrus.andrew.cmu.edu;
token-authority="ask <fhred@example.com>"
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"
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 ABNF 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 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 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
Newman [Page 4]
Internet Draft Originator-Info Message Header November 1997
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".
5. 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.
6. 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>
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
<ftp://ds.internic.net/rfc/rfc2119.txt>
[MBOX-NAMES] Crocker, D., "Mailbox Names for Common Services, Roles
and Functions", RFC 2142, Internet Mail Consortium, May 1997.
<ftp://ds.internic.net/rfc/rfc2142.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>
Newman [Page 5]
Internet Draft Originator-Info Message Header November 1997
[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
2231, Innosoft, University of Tennessee, November 1997.
<ftp://ds.internic.net/rfc/rfc2231.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>
[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>
[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>
7. Full Copyright Statement
Copyright (C) The Internet Society 1997. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Newman [Page 6]
Internet Draft Originator-Info Message Header November 1997
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. Author's Address
Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA
Email: chris.newman@innosoft.com
Newman [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 15:40:17 |